Apple’s iPhone AppStore model fails with Internet applications and platforms.
Here’s another example of Apple’s iPhone AppStore model failure – the TwitterFon example.
TwitterFon is a (great) Twitter client for the iPhone. All Twitter clients rely on Twitter’s public API. Twitter is one of the stars of the Internet social medias / social networking applications. Like most Internet application startups, they have an agile development model which involves doing lots of incremental modifications/enhancements on their platform with frequent release cycles. Also like most Internet applications/platforms, they offer a public API for 3rd party applications to connect to their platform. Note that In the case of Twitter, the bulk of their traffic comes from their API and not from twitter.com. More generally, this model is the new model for Internet applications and platforms development.
This is where iPhone app developers have a problem: they develop native iPhone apps that connect to these Internet applications through their API but can’t keep up with these because of the slow AppStore approval process.
Case in point: TwitterFon. This morning when I tried to launch TwitterFon, it crashed on startup. Tried again, no go. Tweetted about it from my laptop and received a reply of similar problems from a friend. A few minutes later, the @twitterfon Twitter user started following me so I went to check it’s user profile and tweet stream to see that it was discussing the issues and also gave a link to it’s blog, here’s a quote:
The root cause is that twitter respond JSON contents which contain unexpected values.
[...]
I have already submitted a new version which implemented a workaround to address the issue, but it will take a few days to get an approval from AppStore. Also, I reported the issue to Twitter. I hope they fix the issue soon. Otherwise, you have to wait until Apple approves the new version of TwitterFon.
Now, can you see the problem? On one side you have agile Internet application developers which move fast, release often. On the other side you have Apple’s slow, bureaucratic AppStore approval process. In the middle you have the iPhone who want to be the best mobile Internet device.
If you want to be the best mobile Internet device you have to be able to cope efficiently with the Internet speed development style, period. In the TwitterFon example, we don’t really care if Twitter introduced a bug or not in their API that killed TwitterFon: by today’s standards, everyone must be able to move fast and in our example the only one that can’t move fast is Apple with its boggus AppStore model. Fail!
thanks for the explanation.
and with apple’s licence agreement barring apps from interpreting downloaded code, it means that you can’t even make your app update itself with scripting hooks or whatever.
@bunnyhero: right. Apple should revisit that policy or somehow allow already approved apps for a fast track process for updates and/or bug fixes. As it is, the current AppStore model cannot scale. Already with some 10k apps, what will it be with 100k apps?
So then, what’s the best option? A thin “shim” app for device specific calls (like corelocation) and the other part of the app and most of the UI in a webview… Also makes it easier to develop apps with web developers for most of the work instead of an Objective C dev for everything… that’s the current state of my thinking.
I think it is important to note that all the other Twitter Clients I have on my iPhone (Tweetie, Twinkle, Twitterific) do not suffer from that API change. Not sure if they are all using the JSON or the XML API however.
So while I agree that the Apple approval process for updated applications needs to be streamlined, and they have made some progress on that front, what I call defensive programming for malformed values must also be taken into account.