Journey to App - Part 10 - Destination App Store!

The journey is complete!  Go PDF App is live on the App Store (Go PDF).

So it took a few weeks for the app to pass the Apple Review process.  The normal length is about a week, but we had some items that we needed to change in order to pass review (so yes ... Apple really does look at everything).  So we had to tweak the icon, since it used a symbol typically associated with Adobe, and wouldn't you know ... we had to rate the app 17+ because it allows unrestricted access to the internet.

Well I made the changes and resubmitted the app ... another week, and the app was approved.

So with the app approved, I posted the press release on http://www.prmac.com.  It will take a few days for the press release to be released, I'll post a link when the release is published.

Well, it was enjoyable putting this blog series together on developing this app.  I hope that you enjoyed reading it, and that you found it informative about the app development process. 

As a thank you to all you readers, first 20 comments to THIS post will get free Promo Code for the App!!

Thanks to Appcelerator for putting out some great tools and supporting their developer community

Summary of Hours

• Part 1  - Journey to App - The Idea
• Part 2 - Layout - 2 hrs
• Part 3 - Tools - 2 hrs 
• Part 4 - Prototyping - 3.5 hrs
• Part 5 - iPhone and iPad - 5 hrs
• Part 6 - Coding - 16 hrs
• Part 7  - Graphic Assets - 4 hrs
• Part 8 - Publishing - 1.5 hrs 
• Part 9 - Marketing and Support - 2 hrs
• Part 10 - Cleanup and Publishing the App - 2 hrs

Total Hours - 38 Hours

Journey to App - Part 9 - Marketing and Support

With the App completed, and while we are waiting for Apple to review it, it is time to focus on some of the non-development activities.

There are several things that will help make our app more successful.  These include establishing a support site, and Marketing the App.

Support
Since we are charging for the App, having a professional support site is expected.  For support, I use http://desk.com.  Desk.com offers a free package for a single user.  This works great if you are an independent developer.  Desk.com has all of the features that you would expect of a support site, including articles, Q&A, and can integrate to email and social media such as Facebook and Twitter.  For the Go PDF App, I created a new FAQ topic, which has an RSS feed that I encorporated into the Go PDF page.

Marketing - Web Site
There are many ways to market your app, but starting with a simple web site or page is a good way to start.  Finding a good host for your site is covered is many blog posts, so I will not go into it in this post.  One thing to consider when making your page for your app, is that most users will visit your site from their mobile device (at least that is what my web logs show), as they may be thinking about installing the app, looking for some additional information, or looking for some support information.  So when creating your web page, consider that the page should look good on a PC, Tablet, or Handheld device.  Check out jQuery Mobile as a framework for your web page to deliver a responsive design.  The web page for the Go PDF app is at http://www.snackableapps.com/gopdf.html if you want to take a look.

Marketing - Press Releases
Another way to get the word out is to write a press release.  There are many different sites that will publish your press release, some for free, and some paid.  Here are two sites that I have used in the past.  For paid releases (currently about $20) http://prmac.com does a good job.  For free press releases, I have used http://www.pr-inside.com/.    Press releases can increase your exposure and help drive app downloads.

For Go PDF, I have drafted a press release, which can be found at: http://www.snackableapps.com/dl/gopdf/GoPDFV1PressRelease.pdf

Marketing - Social Media
If you have bunches of friends on facebook or twitter followers or other social media circles ... get the word out.  Your friends are more likely to leave good reviews which can help attract users to your app.

Tracking your App in the press
Once your app is released, consider setting up a Google Alert (http://www.google.com/alerts).  Google will monitor your key words, and email you if your key words show up in new web pages.

Running Total Hours
Activities

• Update Support Site - 0.5 hour
• Update Web Page - 1 hour
• Write a press release - 0.5 hours

Total Hours 37 Hours

Previous Part 8 - Publishing 

Next Part 10 - Cleanup and Publishing the App 

Journey to App - Part 8 - Publishing and Monetizing your App

The big day is here ...
Coding ... Done
Graphics ... Done
Testing ... Done

So let publish the App!  The actual process to publish the App to Apple is pretty straight forward, but there are several steps, and everything must line up or, you will have to redo it.

All Apps that are sold on the App Store must be digitally signed with a production certification and provisioned with a distribution provision.  You can create both in the developer console at http://developer.apple.com.  You also need an application bundle (also created in developer console).  The application bundle identifier is a unique name for your app.  Typically, you use a reverse domain format, so for our app, the bundle identifier is com.snackableapps.gopdf.

Armed with these items, you can tell the App Store that you want to publish an App.  Log into the app store at http://itunesconnect.apple.com, select Manage my Apps, and then create a new App.

You will need some screenshots of the app from an iPhone as well as an iPad.  You will also need a large version of your app icon.  After you answer a few questions about your app (category, rating, cryptography, description etc), you can save your App and Apple will indicate that it is "Ready for Upload".

Do a final production Build in XCode (or Titanium Studio if using Appcelerator) an go to the XCode Archives.   Your App should show up.  When you select your app, you will have the choice of Validate or Upload.  You should validate first.  I typically find a problem or two (this time it was missing an icon).  Correct, re-build, and re-validate.

Once your App passes validation, you can upload it.  It then goes into the Apple queue "Waiting for Review"  This typically takes about a Week.  Check out  http://appreviewtimes.com/ for updates on how long reviews are taking.

Now a big question when you publish the App is "Free or Paid"?

There are 5 typical approaches to monetizing your app

1. Paid: Users pays at the time of purchase.
2. In App Upgrade: Users buys limited version and can upgrade if they want the app
3. Ad-Supported: Display Ads to the users and get paid for the number of apps shown and clicked
4. Free: enough said
5. Freemium: Used for games, where a user can purchase "perishable" items for the game, like currency or upgrades or items.

Since Go PDF is a productivity utility, and since our functionality is pretty straight forward in this version, the two viable options are Paid and Ad-Supported.

Hmmm ... since this is an educational focused blog series, lets do both.  The first release will be as a Paid App ... $0.99, which should be in the "impulse buy" range.  After a month or so (and we incorporate an ad engine, we will release a Free Ad-Supported version.  I'll keep track and post the information to see how the two Apps do.

So ... We're done? Right? Wrong!

We are mostly done, but there is a few more topics to cover, and the next one is very important.  In our next post we will cover Marketing and Support.  These are aspects of publishing an app that you need to account for in your plan.

Running Total Hours

Activities

• Final Testing - 1 hour
• Publishing to App Store 0.5 hour

Total to Date: 35 Hours 

Previous Part 7  - Graphic Assets 

Next Part 9 - Marketing and Support

Journey to App - Part 7 - Graphic Assets

Up until now, the focus of the development has been on the functionality.  For a simple app, like this PDF App, that is fine.  But now, it is time to complete the Graphic Assets and complete the app.  Depending on what type of app you are building, you may need to tackle the Graphics much earlier in the development process.

Tools
For the most part, most graphical assets for apps are deployed as PNG graphics, although you can use GIF and JPEG files as well.   But whereas PNG files are bit maps, it is much better to develop your graphic assets in a vector drawing program that will very easily allow you to scale, rotate and work with the images that you are creating.  Some common tools include Illustrator and Photoshop from Adobe, but I use an opensource package call Inkscape (http://www.inkscape.org).  In addition to a good drawing program, you can always use a good place to start.  Google of course can help you out, and there are lots of free and paid sites that can provide icons and other images, just make sure you can use the image.  One great starting point with many open source (creative commons) images is Wiki Common at http://commons.wikimedia.org.

Required Assets
Even for a simple app, there are several required graphical assets that you must create.  As you may expect, Apple requires these in specific sizes.  For iOS 7, here is the common list of required assets.  (Please note, you can define different names in the info.plist file, but these are common.)

Description	File Name	Resolution
Large icon for iTunes	iTunesArtwork	1024 X 1024
iPad Retina icon	Icon-76@2x.png	152 X 152
iPad icon	Icon-76.png	76 X 76
iPhone Retina icon	Icon@2x.png	120 X 120
iPhone icon	Icon.png	60 X 60
iPhone 4 Splash Screen	Default@2X.png	640 X 960
iPhone 5 Splash Screen	Default-568H.png	640 X 1136
iPad Retina Splash Screen	Default-Landscape@2x.png	2048X 1536
	Default-Portrait@2x.png	1536 X 2048
iPhone 3 Splash Screen	Default.png	320 X 480

In addition to the require assets in the table above, I needed to create a few small icons.  The Chariti framework includes some default assets, but I wanted to customize some of the icons to make it easier for the user to choose the correct option.

Here are the assets that were developed for the App.
App Icon

Splash Screen (iPad)

Screenshot

Small Icons

Whats up next ...
With our assets complete, the app is ready to upload to Apple.  The next post will discuss the publishing process as well as monetizing your app.

Running Total Hours
Activities

• Create Graphic Assets - 3 hours
• Additional Testing - 1 hour

Total Hours to Date 32.5 hrs

Previous Part 6 - Coding 

Next Part 8 - Publishing

Journey to App: Writing and publishing an iOS App Part 1

For the last few years, I have been developing and publishing some iOS and android apps.  I published a few apps for my previous employer, and I have published a few for myself.  (Check out SnackableApps.com for my currently published Apps).

When I tell people that I write apps, they often ask about the process and how hard is writing an App.  Depending on their technical background, it isn't always an easy question to answer.

So I decided to do a series of blog posts that will document the process I use to develop an app.  As a companion to these posts, I will also Open Source the App Code, and in the end, I'll publish the app to the Apple App Store and you can download the App. 

Please NOTE: This blog series is NOT a HOW-TO.  Google is a wonderful reference if you need specific help on a topic, and there are great communitties of wonderful, helpful people that will point you in the right direction.  This series IS a description of the process of writing an App.  I hope you enjoy the posts ... and add comments if you have any.

The app process is more than just writing software code, and I will also cover setting up the support system, monetizing the app, and some basic App marketing as well.

The focus of this post will be "The Idea".

Each app has to start with an idea.  Now, coming up with ideas for apps is not that difficult ... coming up with an idea for a great app, that is very elusive.

For this series of posts, I decided not to tackle anything too ambitious, so I want to start with a pretty simple problem to solve.  I often come across articles and information on the web that I either want to read later, or that I want to save.  A really good way to do that (and one that I use on my laptop) is to save the web page to PDF.

So the focus of this App will be to save a web page to PDF.  Yes I know there is a bunch of apps out there (paid and free) that do this, but I think that it is a good problem for this series of posts.  (Comment on this post if you would have different ideas that you think would be interesting to write an blog series on).

Web Pages to PDF ...  What are the Requirements
So ... what does the App need to do?  Defining the "User Requirements" should be the first step in evaluating an idea and developing an App.  Here are the requirements for our PDF App. (have additional requirements?  add them in the comments).

In iOS on the iPhone or iPAD, most people browse the web using either Safari or Chrome.  It is unlikely that they will open up the App to browse the web, so ...
1. We need to pass a URL from Safari or Chrome to the App

Some web sites require a password, or other user input, so ...
2. The App needs to show the web page so that the user can interact before creating the PDF

Web addresses often do not provide good "file names" that would be required for naming the PDF File, so ...
3. The user needs to be able to set the file name, but it would be nice if the App could propose a file name from the URL

Assuming that the user will use the App more than once ..
4. The App needs to be able to display a list of the PDF files that the user has created.
5. The App needs to be able to read / display the PDF
6. The App needs to be able to send the PDF file to other apps, such as iBooks or Good Reader
7. The user needs to be able to delete PDF files that they no longer want.

It is possible that the user may want to create PDFs of the same URL more than once (say for a news site or other sites that change content frequently), so ...
8. The App needs to be able to save and display the history of URLs that have been converted.
9. The user needs to be able to delete URLs from the history list.

Sounds like enough requirements to make the App usable for many users, but still keeps the app Simple. 

Next up ... Laying out the App ... Once we have the requirements understood, it is time to start laying out (also called wire framing) the App.

That will be the topic of our next post.

Hope that you will follow me on this journey to an iOS App!

Next: Part 2