iPhone SDK Developers Angry At Apple's Tight ControliPhone SDK Developers Angry At Apple's Tight Control
Steve Jobs giveth, but only a little bit, and only when his hand is forced. This is the case with the iPhone SDK, which is both a parry against <a href="http://www.information.com/news/showArticle.jhtml?articleID=202805257">Google's Android tool kit</a> and a recognition (in the wake of Apple's <a href="http://www.information.com/blog/main/archives/2007/09/iphone_users_ta.html">iBricking scandal</a>) that iPhone owners want third-party apps, no matter what. But Apple's stated intention t
Steve Jobs giveth, but only a little bit, and only when his hand is forced. This is the case with the iPhone SDK, which is both a parry against Google's Android tool kit and a recognition (in the wake of Apple's iBricking scandal) that iPhone owners want third-party apps, no matter what. But Apple's stated intention to tightly control all apps built with the SDK -- and you can bet they'll do so -- is causing lots of complaining among developers.Apple's mindset is apparent from the get-go. It's gone nondisclosure crazy with the iPhone SDK, though admittedly no more nuts than usual. Here, what its doing is keeping the all the stuff people want to know under much tighter wraps than it needs to. For example, you can download the iPhone SDK for free, but you have to pony up $99 to get at the really good documentation, sample code, and developers' videos.
[Clarification: After reviewing many of the comments below, from folks who believe I was misleading in my comment above about the $99, I want to note that, while the SDK and much of the Apple documentation is indeed for free, as I noted above, I was referring to the $99 you have to pay to join the Apple iPhone Developer Program, here: http://developer.apple.com/iphone/program/ ($250 for Enterprise membership). I can see that I should have been clearer about what "really good" stuff I was referring to, and I regret the lack of clarity.]
OK, that's relatively minor. Pay the $99 and be done with it. I think the bigger problem for developers is going to be death by a thousand cuts. By this, I mean that Apple never seems to put all its cards on the table at once. For example, on Sunday Phonemag reported that the SDK contains a tidbit noting that the iPhone won't run more than one app at a time, so when users switch applications, whatever is running in the background will get killed.
From Apple's standpoint, this is done to maintain decent performance. However, developers are likely to see it as just another screwing. Me, I want to know what's supposed to happen if you're in the middle of something important and your iPhone rings. Does your app blow up?
Like I said at the outset, it may be obvious, but it bears repeating: Apple intends to retain very tight control of all iPhone apps. There's lots of complaining about the fact that all iPhone apps have to be approved by Apple, will be sold by Apple, and Apple will get a 30% cut of all sales. On the other hand, John Siracusa at Ars Technica says that "developers see dollar signs" in iPhone apps, so presumably they'll deal with the restrictions.
Turns out, though, that developers are limited in what iPhone functions that can tap for the apps they're building, according to Adam Houghton's post on his eponymous blog. Houghton characterizes as a "glaring" omission his discovery that developers can't access calendar appointments, music, and videos from the phone's iPod app, nor phone and SMS functionality.
While the phone-function and SMS lockdowns are, as Houghton notes, likely due to security, one can't help but think that the other restrictions are because Apple wants to keep all the really good stuff to itself.
More on Apple's tight control: John Gruber over at Daring Fireball wonders whether "approved developers will be able to freely exchange unsigned apps with each other?" (Because it'll be just another PITA to deal with if they can't.) Over at the Artima Developer iPhone SDK forum, Jonathan Dodds opines in reply: "If you as a developer get an application or two approved for the App Store and it later turns that you're breaking Apple's rules, it seems safe to presume that one of Apple's possible recourses is to revoke your certificate and all your (as in signed with your cert) iPhone OS applications will stop working."
How is Apple's rule that only apps it has signed can run on the iPhone going to play when it comes to corporate applications? One commenter on Slashdot summed it up nicely:
"Suppose I want to distribute my app, which implements an interface to my service? It is not a publicly available service and I don't particularly care to distribute my app to anyone under the sun. Not only that, I need to be in control of updates. In other words, in a corporate environment there is a very legitimate need to be able to distribute a mobile application yourself, or be able to install it directly on a device from a local repository.
It would be ludicrous for me to now say to my client 'OK, to install this you have to go to the Apple app store and download it.' I don't have a problem with the App Store itself as a concept, but it certainly isn't even close to meeting business needs, and if this is going to be the ONLY way to get an app on the iPhone, then it will not be a supported platform for a wide range of business applications."
This is a lot to digest, and quite frankly most developers will suck it all up because, hey, it's the iPhone. The question with the longest legs is clearly the one regarding corporate apps. True, it isn't as burning a question as it might appear on first glance -- just pay the $99 and get your app signed -- but it relates to the iPhone's potential for adoption in the enterprise. Despite the fact that the iPhone will be supporting Microsoft Exchange, I continue to believe that the BlackBerry remains a better business smartphone.
Like this blog? Subscribe to its RSS feed, here.
For a mobile experience, follow my daily observations on Twitter.
Check out my tech videos on this YouTube channel.
About the Author
You May Also Like