In “The Golden Girls” there was a well known directive stating that episodes could not be named something like “Rose Dates Miles”. Instead, they wanted a “Caring Name” like “72 Hours”. (see bit.ly/ebbti… ) .. In rejection of that “Caring Name” naming convention, Marc Sotkin (Executive Producer of The Golden Girls) started writing episodes with titles like “Ebbtide”, “Ebbtide’s Revenge”, “Ebbtide IV The Wrath of Stan”. By the same token, iPhone apps must, it seems, be have one-word name in order to be “in”, “hip” and “cool”. You know, there are very few one-word app names that can be considered cool! I am *very* close to simply calling our new app: “Ebbtide”.

Pondering the app name, my friend and co-developer: Gene Cowan just began tossing out name and word combination. After that, choosing a name was quite easy. It just popped into our heads. But now I continually refer to it accidentally as the competition. My husband asks how work went on the new program last night and I respond: “Oh, competition_name is gonna be great! I just finished this feature…” or whatever. My husband just sits there and stares at me…then kindly reminds me: Tell Gene not to let you do any interviews about the app. You cannot keep the name straight! sigh.

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.