Having decided to create a Native iPhone app last month (more on that in a future entry) I have run up against many brick walls. The biggest trouble, it seems, is that while Apple protects “Look and Feel” for the apps they approve, they cause hell for the developers during implementation.
My App is almost complete and my friend Gene and I decided to release it as a “fremium” style app. This is one where the base app is free but allows an in-app upgrade to an extended feature set. Easier said than done. There are many ways to do this but here are just a few things I have run across:
Parental Controls: If these are turned on, in-app purchasing may be disabled.
Interruption of a purchase: If the user is in the middle of purchasing your upgrade inside the app they are able to, for instance, answer an incoming call. This call/interruption could happen in the middle of your (the app’s) attempt to “check out”. So, Apple, in it’s infinite wisdom sends you a restoreTransaction message the next time your app opens. This would not be a bad idea, actually it is quite a good idea, except: every time my app starts, I will have to check for restoreTransaction. No big deal. Just another layer of complexity.
Network Availability: Apple requires you to monitor network availability during your app if it uses the network at all. This is really not a problem since they provide the code to do this, however it is frustrating to read things like the following by noob programmers: “I could not get the Reachability.h code to work, so I simply fake it.” or “I did not understand how to implement this Reachability so I simply attempt to get a file from my own website. If it times out, the network must be down.” This really proves that the wrong people are attempting to make apps. They are not people who care why these tests are implemented nor do they care about the user experience degradation when they are implemented incorrectly.
Here is the main problem: Apple documentation is like the documentation of many programming environments out there. They give details on the routine, the arguments to the routine and what it does. What they are woefully lacking in is well-written, error free examples of using that routine. Reachability, for example. There is documentation here for Reachability. Not really documentation, but an app that actually does compile. However, they leave it up to you for any kind of instructions on how you would implement this in your app. Reachability is important to many apps…but they create an app that shows status of network interfaces. They do not give suggestions on what commands to put in which methods in your own app.
So, here I am at 10:30 on a Friday night (I know…no social life) congratulating myself that I actually got Reachability functioning and now find myself dreading wading into the uncertain waters of In-App-Purchasing.
Wish me luck.