“This is a guest post written by Tom Horn, who has produced ‘WW2 Daily‘, ‘Ballet Index‘ and ‘Monster Memory‘ and several other iPhone and iPad applications. For more of his work, visit cannonade.net/dev“
I have encountered a perception in developer circles that iPhone development is hard, frustrating and, with the Apple walled garden, potentially fruitless. I couldn’t disagree with this sentiment more. I have been building software for a respectable chunk of my life and in that time have experienced a wide range of development environments and platforms. With that context, I feel that process of building apps for these arguably beautiful devices has been the most satisfying and productive of my career as a software developer.
As with any unfamiliar set of development tools, there is a steep learning curve and there are hidden mires that will eat up your time if you aren’t careful. If you haven’t written Objective-C before, the syntax will seem weird, but give it time and it will grow on you.
I have been building iPhone, and more recently iPad, apps for the past year and in the process have made a whole pile of mistakes. Remembering these frequent roadblocks, while frustrating at the time, gives me some satisfaction that I have learned something from each one. If you are starting out in iPhone and iPad development I hope that perusing this list will help you avoid some of the pitfalls.
1. Build your application to support rotation from the beginning
When you start building apps for the iPhone the capability to support arbitrary rotation of the device seemed like a ‘nice to have’ feature, but by no means mandatory. In fact, you could argue that without a hardware orientation switch, apps that rotate unexpectedly can degrade the user experience rather than enhance it. With that in mind, it is very easy to starting building on iOS without considering the implications of auto resizing your views.
This is a mistake. At some point you will want to port your application to the iPad and although you can get apps into the store with just the two portrait orientations supported, your users will expect your app to support landscape. Trying to retro-fit an application to support landscape is a painful process and I don’t recommend it.
2. Understand the memory model before you start writing code
I love the memory model in Objective-C on iOS, but it isn’t garbage collected and it has some features that you will not have seen in other languages you have used. Having a solid understanding of how this stuff works before you start writing code will save you lots of debugging time later on. Check out the Stanford iPhone lectures for a great introduction to the iPhone memory model.
3. Test on the device from day one
This might be an obvious point, but there are cases where you might be tempted to build on the simulator and check it on the device later. For instance, because of the later release date for the iPad in Australia, I was forced to build my first iPad app without running it on the actual device. I submitted before the iPad arrived and subsequently had to resubmit because of bugs that only turned up on the real thing (user experience, multi-touch and file system bugs).
The simulator is a very useful tool and you should definitely use it to build your app, but you need to use the real thing.
4. Try to avoid making assumptions about screen dimensions.
It is very tempting, when you are building your first native iPhone app, to assume the 320×480 resolution and build your app accordingly. The launch of iPad and iPhone 4.0 make this choice seem like an obviously bad one.
5. Test your app in airplane mode
As a developer, access to broadband internet is pretty much ubiquitous. It is very easy to forget to test your app when that access is not available. Apple will reject your app if you don’t handle a lack of connectivity gracefully.
6. Think about a lite version (or free and in app purchase) from day one
Unless you are building one of the small percentage of apps that immediately go viral and sell hundreds of thousands of copies, your biggest problem will be getting exposure on the app store. In my experience the best way to do this is with a free ‘try before you buy’ version of the app. A free version with a limited set of functionality (not a crippled version of the full app, see my next point) will have an order of magnitude more downloads than your paid version and will give your app the exposure that it needs.
With the introduction of ‘in app purchases’ you have the option of giving your app away and charging for premium content or functionality. This gives you the same exposure as a free app and has the added benefit of providing you with the option to add further monetized functionality or content down the road.
7. Don’t ‘up sell’ in your lite version.
Apple policy on demonstration versions of your apps is that the demo version must be a fully functional stand alone entity. This is all a bit ambiguous, it seems to me that the whole point of a demo version is to up sell to your paid version. So here are a few guidelines:
- You can’t explicitly reference paid version functionality in your lite app. For instance, one of my apps got rejected because I had a toolbar button in my lite app that took you to a “buy now” view rather than the functionality in the paid app.
- The words “Demo” or “Beta” will get you instantly rejected. “Free” or “Lite” are ok.
- Time trials are explicitly forbidden, but I have seen examples of iPad apps that have managed to get through the approval process with expiring features. I am not sure if this is something they are allowing now or if they just got lucky.
8. If you don’t have a lite version, do price drops, but be careful making it free
If, for whatever reason, you aren’t able to do a lite version of your app, you can adjust your price for ‘on sale’ periods. There are a variety of web services that track iPhone and iPad prices and deliver feeds of ‘on sale’ apps, so this is a great way to boost ranking and visibility for your app.
The one caveat I will mention is that if you make your paid application free, you will get a big boost in downloads, but when you switch back to paid your ranking will suffer. This makes sense to avoid people gaming the ranking system by alternating between paid and free.
9. Careful with multiple provisioning profiles. XCode can get confused.
I have done some bespoke iPhone development for third parties with their own provisioning profiles. XCode can sometimes get confused about which provisioning profile is selected for a particular project. If you find you can’t debug on your device, you might need to explicitly set the provisioning profile in the project settings and perhaps restart XCode to get it to recognize the change.
10. Don’t go it alone
There are a few places online where can find useful content on iPhone/iPad development, so don’t spend too much time banging your head against a problem before seeking outside help. I would start in the iPhone tag on StackOverflow. This question has an index of some of the other sites out there.
I hope this list was useful and wish you the best of luck in your development endeavors.