The iPhone SDK: Forced or Preordained?
October 17th, 2007You know a lot of what Steve Jobs says during interviews may be overlooked when controversy erupts about something Apple is doing at any given moment.
Months back, for example, when Jobs was asked about a Software Development Kit (SDK) for the iPhone, to give third-party software developers a chance to build applications for it, he demurred and said not right away. He added, and this is important, that Apple was considering the best ways to accomplish that goal without making the iPhone vulnerable to security threats.
Indeed, the so-called “jailbreak” software that allows you to run unsupported applications or unlock the iPhone all take advantage of some sort of security hole to take control of the device. That may not be so big a deal, if that’s what you want. But it also creates the possibility that some Internet vandal could do the very same thing with nefarious intent, and you wouldn’t want that to happen, I hope.
One of the key features of the recent iPhone 1.1.1 firmware update, for example, was improved security, which locked down the gadget in a way that made the third party hacks incompatible. Of course, the prevailing wisdom is that this was a bad thing to do, because there was a growing cottage industry of such hacks that provided all sorts of cool stuff for the iPhone.
Now understand that it’s very easy to look at the nasty consequences, and blame Apple for wanting to protect its contract with its exclusive carriers. From a business standpoint, that makes a lot of sense, even if many of you don’t like the result.
Let’s shift to another development: At the recent WWDC, Jobs talked of a way to provide iPhone applications through the Safari browser. Again, this was done to create a sort of safe sandbox to allow you to gain additional features, but not at the expense of harming security. And, of course, it meant that the hoped-for SDK wasn’t here, and somehow far too many people got the wrong impression that it would never arrive.
In the ensuing weeks, there was a loud demand for Apple to open up the iPhone’s software to let third-parties in. Again, there was the general feeling that it wouldn’t happen, unless you filed class action suits, held picket signs outside of Apple’s corporate campus — or prayed a lot.
Well, I’m going to quote two key paragraphs from Job’s latest blog, which I think simply reflects a position that he’s expressed previously:
“Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers.
“It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task. Some claim that viruses and malware are not a problem on mobile phones—this is simply not true. There have been serious viruses on other mobile phones already, including some that silently spread from phone to phone over the cell network. As our phones become more powerful, these malicious programs will become more dangerous. And since the iPhone is the most advanced phone ever, it will be a highly visible target.”
Forgetting the marketing spin, what he says in the second paragraph seems on the mark to me. If Apple is doing to get the job done, give them time to do it right and make the experience a happy and safe one for all of you.
Indeed, in addition to providing a secure framework, I also suspect Apple wants to incorporate some of the new features of Leopard in a forthcoming iPhone update.
Now one reason that the news of Leopard’s actual release came so close to that event is because Apple was probably struggling until the last possible moment to get a build that they could, with clear conscience, declare to be Golden Master. Or, to be cynical, they held out in an effort to eradicate as many serious bugs as possible, and the marketing people finally said “ship it and fix the rest with a 10.5.1.”
All right, maybe I’m inclined to favor the latter, because that’s the way and the truth in the software business. In fact, if you look at the results of our new Leopard poll, you’ll see a heavy percentage of the people voting — and we really want all of you to get involved, since we have thousands and thousands of visitors every day — prefer to wait for the first maintenance update before diving in.
Certainly, the shaky experience with Tiger might loom foremost in your memories, particularly those of you who needed to use VPN to log into corporate servers. My friend John Rizzo, at his MacWindows.com site, carefully logged those early problems. Fortunately, it seems that the ongoing updates to Tiger repaired most of the issues, along with a host of third-party updates.
Let’s just hope Leopard doesn’t force us to revisit old nightmares, and that the forthcoming iPhone SDK is indeed something worth waiting for.
Print This Post
OSX 10.5.1 will be a beta. So will OX 10.5.2, 5.3 and right on down the line. Why? Because Apple follows a policy that has been called “continuous beta,” where they release a less-than-perfect piece of software. This is one possible strategy. The other is don’t put it out the door until it’s perfected. This was the philosophy behind Vista, Adobe CSS, MS Office, and so forth, and many users are irate at MS and Adobe because this strategy made them take so long to get to market. But the fallacy of their strategy is that it turns out that modern software is so complex that perfection or even near-perfection is an impossible goal (case in point: after all that wait, CSS Dreamweaver still has some fairly severe screen-draw bugs, and since they don’t follow the “continuous beta” policy they still haven’t issued an update fixing these — if this were an Apple product with the same bugs, a fix would have been issued within weeks or even days of the original release, because Apple’s corporate culture is equipped to react quickly to this sort of thing). So I vote for “continuous beta,” my pre-order is in with the Apple Store, and on October 26 I’ll be installing the upgrade before the FedEx guy can restart his truck. But I’m not a complete idiot — because I understand the “continuous beta” policy it will be a long time before I erase the bootable copy of Tiger on my external h. d.
Damn right. The first thing I do when I get a copy of Leopard will be to clone my current HD to one of the spares, and then run a back-up to get a second copy.
It isn’t just Apple. EVERY software company follows a policy of continuous beta. Aside from one or two trivial programs with extremely limited inputs and function, there is no such thing as completely bug free software. Bug free software is a fantasy, not all that different from the fantasy of a perfect legal system. My guess is that it cannot exist. Only the fight to attain it can exist.
Yes, Sutton, you are absolutely doing the right thing when you install the latest, but keep a safe fallback. In the 70s we always used to suggest using the experimental version or the old version, since the installed current version was surely the worst.
As for the SDK, I remember Apple’s delay in not providing an SDK for items up on the right of the menu bar back in early versions of OS X. Third parties would keep offering little menu gizmos, and Apple would keep breaking them as they changed the menu code to fix other problems and clean up what was probably a good enough hack. Even something as simple as pull down menu code has all sorts of bug potential. What if the user selects a menu item, e.g. Eject Drive, and between selection and erasing the pop up, the invoked routine crashes. What if someone else is changing the menu item while the user is looking at it?
Eventually Apple provided an SDK, and now anyone can write menu bar extensions.
Apple does have some serious issues to deal with. Even if they had wanted to provide a solid SDK up front, they had to deal with issues, security, resource usage and so on. Sure, you want a third party application to turn off your phone, but how can you keep a buggy or malicious program from turning it off whenever you turn it on? I’m sure the February iPhone SDK will be full of disappointments, and most likely, problems. On the other hand, it will be a big step forward in the continuous beta process.
Preordained. It was a matter of “when” not “if”.
Apple is a hardware vendor that is competing against other hardware vendors. Those other vendors provide SDKs for developers to write software for their mobile platforms, so it’s inevitable that Apple would too. I wouldn’t be surprised to see Apple reverse itself and put Java and Flash on the iPhone too since those technologies are pretty much ubiquitous in mobile devices. Java will be required for the corporate market. Flash will be required for the consumer market. How can they compete with Nokia and Motorola and Windows Mobile and (soon) Google without an SDK and essential technologies?
So why wasn’t an SDK delivered when the iPhone shipped? In a word: “Economics”. They had a BILLION dollar market waiting for their phone. Given that they couldn’t have an SDK ready for the better part of the year, and given that time waits for no one and their competitors were working on new technologies, and given that there would be no immediate sales benefit by waiting, they had to ship the hardware as soon as they possibly could and follow up with the SDK when it was ready.
So why tell the market the phone would be closed except for browser extensions? Ahhh, now this is where Apple is brilliant. First of all, SJ likes to make black and white statements. Their effect is that they polarize the users so that opinions can be clearly defined. Market research is much, much easier when you can measure the camps. And secondly, Apple is the best technology tease there is. I’m not talking about some slutty come-hither-and-slip-your-dollar-bill-in-my-garter kind of tease. I’m talking about that classy and seductive come-hither-and-slip-your-dollar-bill-in-my-garter kind of tease. 🙂 Apple knows how to build anticipation, but in the end they’re all about giving their users what they need. They also know that saying “yes” sounds so much sweeter after all the pent-up demand built by first saying “no”. Now we just need to sit back, dollar bills in hand, panting for February. Let the wolf-whistles begin!
Not so. Apple has not provided an SDK to do menu extras, and this is a problem for us third-party developers. The only way to implement proper menu extras is to use third party hacks like MenuExtraEnabler. And, of course, Apple broke MenuExtraEnabler in Leopard so the Unsanity folks will again have work to do.
Some background: Apple has proprietary technology to create objects of class NSMenuExtra. Those objects are then managed by the SystemUI Server process and you can drag re-order them and things like that. There is another class called NSStatusItem that has existed since way back during the NeXT days. Apple lets us third party developers write NSStatusItems, but NSStatusItems cannot be reordered, they can’t be dragged, and you can’t just pull them out of the menubar like you can NSMenuExtras. The Unsanity folks implemented the MenuExtraEnabler so that third party developers could implement proper menu extras. Apple has broken that code with every major OS release.
What concerns me is that Apple has a history of limiting what third party developers can do. Sometimes this makes sense. But sometimes it seems that Apple has a misguided desire to protect users from code that users want to run and that developers want to provide. When it comes to security, sure Apple should protect us. When it comes to features, let the users and developers and market forces figure that out on their own.
Said another way: if it is secure and Apple can do it, then third party developers should be able to do it too.
“It isn’t just Apple. EVERY software company follows a policy of continuous beta.” Okay, you’re right. But some software companies seem to have a better awareness that this is what they are in fact doing, so that they are geared up to get out betas quickly. Others have a hideously sluggish reaction time. I bet there will be an OS 10.5.2 released by the end of 2007 (actually that’s a pretty conservative guess). How long do you think it will be before we see an upgrade for Vista, Photoshop, or any of the important items in the CSS suite? In some way that I don’t claim to understand, this has to do with the different internal cultures of various companies (it may, for example, have to do with how soon different companies break up the original design team after v. 1 is released). In this way, as in many others, Apple comes up smelling like roses.
“What concerns me is that Apple has a history of limiting what third party developers can do. Sometimes this makes sense. But sometimes it seems that Apple has a misguided desire to protect users from code that users want to run and that developers want to provide. When it comes to security, sure Apple should protect us. When it comes to features, let the users and developers and market forces figure that out on their own.” I suppose the problem here is what you mean by “security”. Most people associate that word with the issue of protecting computers against outside intrusion. But “security” also can mean maintaining system stability, and Apple is concerned with maintaining system security in this latter sense too. “Code that users want to run and that developers want to provide” may include hacks which degrade performance or destablize systems, and I can see why Apple is reluctant to throw the door wide open. After all, an individual user suffering the consequences of a bad hack is likely to put the blame on Apple, not the author of the hack, so Apple probably feels some need to protect its corporate reputation.
You can use Time Machine to do backups once you install Leopard on that external drive.
Peace,
Gene