Let me getting it out there: Writing an iPhone app is asking for a whole mess of problems.
I’m proud of what I’ve accomplished for making transit easier in the past two years, but it’s been a painful process. Lots has been said about the shortcomings of Apples AppStore, and more importantly Apples disregard for developers building on their platform. But I also want to share my story of how developing for the iPhone has gone. Hopefully others can learn from my trial and error.
When I first started working on my theNextTrain application in 2008, the AppStore was not live, so it was a guess as to how to best structure things. I wanted to publish schedules for every commuter railroad known to man, so I started with the few I had data for.
I had already been publishing schedules on theNextTrain.com in the format I wanted, so I had all the logic nailed down; I just needed to code up a version in Objective C.
It seemed simple enough; I’d just put a sqlite db file in the application, and when I needed to update the schedules, I would just release a new version of the application with a new sqlite db file. Apple would then earn their 30% cut and quickly get it distributed to the right users.
Over a year later, this is still wishful thinking.
The AppStore still doesn’t even use it’s own push notification service to notify phones of pending updates.
Don’t get me wrong, parts of this setup do work… or did work. At first pushing out a schedule took 2 or 3 days to be approved and show up in the AppStore, and users were (seemingly) quick to get them installed.
As the AppStore grew and users installed more Apps, users updated less and less frequently. A Typical update cycle for my application is now a month. It takes a whole freaking month for an update, once released by Apple, to get installed on most of my users.
As is now common knowledge, apple also takes it’s sweet old time with their update queue.
actually, let’s stop calling it a queue. it’s not a queue.
I just had two apps released after 15 days in the approval process, and one immediately after that which was released after only 7 days. Meanwhile, I still have an application (the exact same as the first two except with different data file) which is STILL waiting for approval after 23 days. Have I heard from apple about it? of course not!
Now my application deals with schedules. Every update is time sensitive and critical. I get very little notice from agencies on when schedules are going to be updated. The total time I have to get updates pushed out from when I first learn about them and when they go into effect is between 0 and 14 days. Clearly well short the total of 45~55 days it currently takes to get schedules out to all my users.
That brings about the review problem. Users take the easy route and complain about lack of schedules. They don’t bother contacting me; They don’t bother leaving any contact information; They don’t even bother looking for resolution, they just leave a poor rating and/or review and leave.
Can I respond to reviews and say, “hey, this has been in apples queue for 14 days; I know it’s 1 day over due for you now, but I’ve done everything I can to stay up late and get this into apples approval queue.”?
No. of course I can’t respond; that would be easy. I can’t reach out and say; hey I feel your pain. I can’t let them know when the schedule is finally available.
When starting to write for the iPhone it seemed to make sense to have a different application for each agency as that would keep things simple for users. Each application would share the same code base right, so it couldn’t be that bad right? answer:really bad. Managing 9 different applications that all have the same code base but different update cycles has turned out to be a nightmare. Managing user feedback and reviews on 9 different applications has also been a nightmare. It’s hard enough to keep up on blogs with RSS feeds, but it’s impossible to keep up on reviews on multiple applications.
Worse yet once I chose to go down that path of separate applications, Apple gave me no choice but to screw my users in order to switch to anything else. I have users that purchase my applications every day, and to merge them it means that some users will have just purchased a copy very very recently under the impression they would get schedule updates (which remember need to be delivered through application updates). I can’t ever remove that application and continue to give these users what they expected when they purchased it.
I can’t magically move all existing users of 9 applications into a new single merged application; apple, of course, gives me no user management ability.
I can’t contact all users and say ‘hey go download this new version on day x’ because I don’t even get a list of users and their iTunes contact info.
That leaves me with the difficulty of rolling my own tools to gather user contact info, my own notification systems.
And so it was that in February, after only a few months in the AppStore, I realized I could not add any new schedules until I merged my 9 applications, and I could not merge my 9 applications without infrastructure to handle over the air schedule syncing, and I could not get users onto a merged application until I rolled out my own notification systems.
Once the application development was well under way, and the server infrastructure for over the air schedule syncing was working, I set out to develop tools to facilitate a group of beta testers. This of course required ways to gather beta tester info, ways to manage and distribute beta applications, ways to distribute provisioning files, and ways to collect feedback and track and communicate known issues and their resolution, and hopefully enough tools to keep myself sane through the process. More work that I didn’t really want to invest the time into, but work which needed to be done one way or another.
(sidenote: Apple appears not to like beta testing either as they recently further restricted the number of devices that you can test against; you can now only test against 100 unique devices in a year across all applications (it was previously 100 devices at any given point in time); heaven forbid you have a small group of say 50 testers that do something like upgrade to 3GS or say, break a phone and/or replace it once or twice)
Mind you, I have a day job too, but it’s September now, 7 months after starting this version, and just TODAY I’ve finally pushed out this long awaited version 2.0 to the AppStore.
I’ve also gone out of my way and (at the risk of attracting users looking for a ‘free’ application, which I don’t want), I’ve set the price to FREE for 3 days to give existing users a great opportunity to upgrade.
It will still be another month before all the old versions will be pulled from the AppStore as I want to be extra sure that all existing users have updated to get their notification messages about the end-of-life on their version, and the chance to upgrade (I’ll probably another discount upgrade window next month).
whew, I’m glad to finally be moving on to the next chapter of my life.
Finally: nine individual versions are depreciated.
Finally: I won’t have to wait for Apple’s approval queue to push out schedule changes.
Finally: I will be able to measure schedule updates in hours instead of weeks.
Finally: I will be able to add schedules for more transit agencies.
Finally: I will be able to work on interesting features like realtime delays
p.s. Huge shout out to the many beta testers that put up with version after version for 4 months of testing.
p.p.s hello again interwebs