What’s with the iPhone SDK FUD, O’Reilly?
Filed under Apple, Software on March 26th, 2008
I just came across a hack job of an article on O’Reilly’s Network regarding Apple’s iPhone SDK.
It’s by Jonathan A. Zdziarski and you can read a printer-friendly version of it here.
Let’s examine mr. Zdziarski’s claims.
With the release of Apple’s SDK for building iPhone applications, many have plunged head-first into this new platform for the first time, with the new-found excitement that comes in discovering something entirely new and innovative. The energy surrounding the iPhone has been building steadily since its release last June, and Apple’s initial “beta” offering of their SDK gave developers many of the tools they needed to get engaged. Within a short time, however, the community hit a brick wall in many respects, leaving many disenchanted by the restrictions imposed on developers. While Apple insists that the SDK provides the same tools used to create their own software, developers have found that they don’t have access to the same low-level functions of the iPhone, such as the ability to run applications in the background, build certain types of objects, or use low-level frameworks such as CoreSurface, Celestial, or LayerKit — all of which provide direct access to graphics and sound components. These, along with many other features, are found in Apple’s own applications, but nowhere to be found in the SDK.
Em, I call BS here.. Apple never said that the SDK “provides the same tools used to create their own software” in the sense that those are the only tools they use. They really are the same tools Apple uses, just not the only ones. Every developer knows that every SDK has some internal APIs, and for good reason, don’t they? Thus, there is no reason for the sensationalist tone. Besides, Apple explicitly stated the restrictions imposed upon the SDK (no background apps, no device drivers, no using the phone network, etc).
Furthermore, several Mac and iPhone developers pitched in on why such restrictions make perfect sense, especially the no running in the background policy. Reasons include stability, battery life, CPU utilization etc. And it makes even more sense considering that the user will be installing an unspecified number of apps (consider the battery drain of 10 background running apps checking the network periodically). Actually there’s an excellent post from Craig Hockenberry about this.
Jump ahead to March 2008. Apple finally realized what a huge financial opportunity they were missing out on when they snubbed third party developers, and decided to release their own version of what the community already had been using for nearly a year, a software development kit (the Apple SDK) and application distribution chain (the iTunes AppStore). Ironically, due to this delay, Apple was surprisingly the one lagging behind the open community, and rather than the open source community duplicating commercial efforts, Apple embarrassingly became the one trying to duplicate the open source community today.
I’m afraid I’ll have to call BS again. Apple “ snubbed the third party developers”? Apple “finally realized what a huge financial opportunity they were missing out”?
Since mr. Zdziarski is, as it seems, I programmer himself, he should know that releasing an SDK takes time. To get it right, to finalize it, to ensure that you won’t burn your developers with unneeded changes down the road, etc. Isn’t this essential knowledge on Software Engineering 101? It is, therefore, silly to imply that Apple only recently jumped on the iPhone SDK bandwagon. The breadth of work, the quality of the documentation, the preparation of the App Store, the negotiations with third parties —such as Microsoft, shows the exact opposite: Apple has been working on an iPhone SDK for a long time.
I cannot understand the line about how Apple“ embarrassingly became the one trying to duplicate the open source community today”. WTF? Jailbreaking the iPhone and linking to a non stable, internal API somehow amounts to the same as the production of a proper SDK? Besides, Apple is not duplicating anything. The company polished and SDK-ized the internal APIs that they themselves produced, those same APIs that the open source community unofficially used.
It was used to write applications that could look and act just like Apple’s preloaded software, so when Apple announced that their SDK was “the same set of tools,” many expected that it would look and feel like the open tool chain.
Very few had anticipated the many restrictions they’ve come to find in the official SDK.
Only those very few with any sort of programming experience in the real world, I guess.
While roughly 75% of the two SDKs do overlap, the remaining 25% has shown to be very restrictive, removing the developer’s ability to do “the real fun stuff” with their application.
I’m not sure I would want anybody to do “the real fun stuff” on my cellular phone. You know, the same one I carry all day, and use on emergencies and such.
Back to the present, the APIs available in the Apple SDK are useful for building your average game, or your average application, but very lacking for building applications with more sophisticated, low-level requirements. Fortunately, there is another set of interfaces that Apple never wanted you to know about, the “real” set of APIs that Apple uses.
So how the proper API is not real? Especially since it overlaps with 75% of the unofficial stuff, except the low-level stuff. Also, doesn’t mr. Zdziarski know that Apple really does limit itself in using the official API on most of the applications on the iPhone, except where it is critical not to do so (a few selected apps such as Safari, etc).
The rest of the article is a guide for using the unofficial, non-SDK API. Which is all nice and fine, and something that I have no qualms about. Except maybe about this line:
It’s important to note that it is unclear whether using these hidden APIs will disqualify your project from being listed in Apple’s AppStore.
Anybody out there that also thinks that “it is unclear”? I have a bridge in Brooklyn you might be interested in.
I would accept this kind of BS from Dvorak or Thurrott, but mr. Zdziarski is a Mac programmer. And he is writing for O’Reilly. He should know better. Perhaps he does. Maybe he is just bitter because the official SDK came out now that he has just published a book on the unofficial SDK.
P.S Also what’s with the article being on OnLAMP.com? Where’s the L, the A the M or the P?
April 20th, 2008 at 5:45 pm
Exactly my feelings on the issue. These people claiming the unofficial SDK is more powerful because of the access it gives to unofficial api’s are nuts. Before apple came along, the entire api was undocumented! All programmers had to work from was what the name of the method was, and what the names of the parameters it accepts were.
Open developers have been extremely limited to using only pieces of the API’s that have been figured out through guess work, and as a result some developers have become extremely cautious about making any UI changes to avoid having to touch the undocumented Objective C UI code and potentially break something.
That’s what makes the ugly, crashy, difficult to use open apps amazing. It’s amazing someone went to all that effort just to make an iPhone app. With the real SDK (the one that’s more than just a compiler and a folder full of headers) it’s a lot easier to play with and experiment with the iPhone API’s, and to make really great UI. I truly expect that once firmware 2.0 ships, the majority of the open app developers will move over to the Apple SDK to build and test their apps, then continue sending them to the Installer package manager for distribution. I really hope the Installer folks figure out how to package an application in such a way to store it in the media partition and not the system partition, and to provide UI like the (X) delete button in the wiggly icon rearrangement mode that allows easy removal of applications.