iPhone SDK, Leopard and 1.1.2

As I suspected, Apple plans to release an SDK for native apps on the iPhone next year. The official word is on Apple's Hot News site. They appear to have pre-announced the SDK which is likely to have its official announcement at MacWorld in January, and they say it will ship in February. I'm sure that this was the plan all along, and the developer frenzy has managed to flush out a pre-announcement to give some guidance to the market, which I think is a good move at this point.

There has also been speculation that the iPhone "runs Leopard". I think that the truth is likely to be a bit more subtle than that. There has to be a master code base for MacOSX, and efficient engineering management practices should try to minimize branches in that code base. The master code base has a release branch called "Leopard" and another one called "iPhone", but the differences between them should be as small as possible. Bug fixes and features get checked back into the master code base whenever possible. So the work put into Leopard is leveraged for the iPhone, and we should see some of the feature set that was announced for Leopard transfer to the iPhone.

I think there is a good chance that Apple will release iPhone 1.1.2 immediately after they release Leopard, and that some Leopard features will be included. One obvious feature would be localized versions of Mail and other apps for the iPhone and iPod Touch, bringing the iPod Touch more in line with the iPhone's application set. There is a new and upgraded iChat in Leopard, and it would also make sense to release this for the iPhone/Touch.

I also noticed that the DTrace analysis/monitoring framework from Solaris 10 is included in Leopard. This is very cool, it provides a huge upgrade in observability for performance analysis of both desktop and server applications.

WWJD - What Would Jobs Do...

Somewhere in Apple there is a product team with a plan. We now have observed several steps unfolding in this plan, so I'm going to put myself in their place and try to make sense of the plan so far and where it could be going.

I have *no inside knowledge* of anything going on at Apple, this is all conjecture, OK?

Product teams have four big things that can be traded off against each other to some extent.

1. The release date
2. The available resources
3. The feature set at launch
4. The product quality at launch

For the iPhone, they waited until they had working prototypes in January, and set a release date for June that they kept to. The product quality at Apple has to be very high, and I think they did a great job with the iPhone at launch. However, products always take longer than planned, and we know that Apple delayed the launch of MacOSX Leopard so that they could put extra resources into the iPhone, so it was probably slipping at that point. The one thing that I think they were able to trade down to get a high quality product on the release date was the feature set. This is why I regard the iPhone as an unfinished product. To get a high quality product, you can simplify testing by having fewer features and fewer options in those features. This is the Minimum Marketable Features (MMF) approach I have mentioned before. Some simplifications at launch:

• US Market Only - no internationalization
• Basic camera support, no video capture (not even demo'd at the launch event)
• Relatively few preferences and options

Apple appeared to schedule bugfix and minor features releases shortly after launch (1.0.1 and 1.0.2), while concentrating development and testing to include internationalization for the worldwide rollout of the sister product, the iPod Touch and the international iPhone with 1.1.1. The Starbucks feature of the iPhone music store has its own roll-out issues, so it makes sense to add that feature as a major update rather than on initial launch.

I expect that Apple thought they had locked down the phone well enough in its first release and were surprised by the speed and extent of application and SIM based hacking. Adding digital signatures to prevent hacking in the initial launch version would have also made the final stages of debug and testing harder, so it makes sense that they didn't do it. Once Apple realized that they needed to lock down the phone to take back control of their product feature rollout plan, they  had to find extra resources to develop and test the extra security features. This had to steal resources from something else, so I expect that some features originally planned for 1.0.2 and 1.1.1 have been delayed.

Opening up a product for developers is a lot of work if you do it right. There are developer specific tools, APIs that need to be stabilized, extended and documented; training classes and developer support organizations to put together. We already know that Apple was pulling resources from Leopard development just to get the iPhone out of the door. We also know that Apple already has a developer support organization, but that organization already has its hands full trying to get Leopard out of the door as a high quality product with a lot of new features that need to be documented etc. Leopard ships this month, so Apple's developer support organization should now have some spare resources to focus its attention on doing the work required to do proper high quality iPhone developer features and documentation. Based on this analysis, the earliest I would expect to announce developer support is MacWorld in January, and that plan could have been set over a year ago. I also think Apple underestimated the demand from iPhone developers, but had no spare resources to do anything about it other than emphasizing Safari based applications.

The iPod Touch has a smaller set of applications that have been fully internationalized. The extra applications on the iPhone are the US specific ones. I still think this is a transitional problem, and I expect that a minor update in October or November will upgrade the iPhone to have more extensive internationalized support, and that the non-phone-specific applications will all end up on the iPod Touch as well. If I was planning the release calendar, I would bring out one new application in each release, along with a set of less exciting upgrades like internationalization.

There are three empty slots in the iPhone user interface. I think they will all be filled by the time we get to January's release. One will be the Finder, so that users can store and browse files and applications, one could be an iWork launcher to highlight some of Apple's own business oriented applications, and January's icon could be related to installing and managing third party applications, hopefully including Flash and Java.

Its possible that iChat could merge with the SMS tool, and I would expect video support to be a feature of the camera tool. I would like a terminal with ssh support, but that's not mainstream enough to get its own icon....

Of course, Steve calls the shots, but what do you think the three remaining icons will be used for? Let's collect some suggestions in the comments.

iPhone 1.1.1 and the iBrick

This blog just got mentioned by a Wired News posting about the iPhone. Other than some random spellings of my name I think it picked up on my points quite well.

I haven't hacked my iPhone, and it upgraded to 1.1.1 cleanly. The new features and upgrades are welcome, but the upgrade process didn't clear out the ever increasing amount of "Other Memory". I had resorted to removing videos from my iPhone to make space and avoid out of memory errors. You can see 1.6GB in the display below.



I went through the settings, cleared out deleted mail and safari history and it made no difference. I deleted all the content and it made no difference, so I re-loaded the iPhone from scratch, and it dropped to 14MB after I had put my content back.



There are some posts on the iPhone support forums about this problem, but no mention of an official fix from Apple. One user claims that it could be related to Google Maps, which I use quite often. I'm going to watch this "other memory" usage to try to figure out which apps are increasing it.

I haven't seen a clear explanation of what is going on inside the iPhone that makes hacking applications very different from hacking the carrier, and from my experience building myPhone I can hopefully clarify this issue.

There are two CPUs inside just about all phones of any type. One is part of a GSM modem module that interfaces to the phone network, the other is the application CPU that runs the user interface (e.g. OSX on the iPhone). For the Gumstix Goliath a Siemens MC75 module interfaces to the SIM card, and the GSM antenna directly, and has USB, serial and audio interfaces. The way all these GSM modems are managed is by sending it command sequences that would be familiar to any old-timers, its a derivative of the Hayes AT command set. Inside the iPhone is a similar module. The GSM modem has a low speed low power CPU with its own flash memory. The service providers don't like having people mess with this firmware, because it controls the wireless signaling, power levels and cellular communication protocol directly, and they have to be certified for connection to the GSM network. For our homebrew phones we buy Telit or Siemens modules off the shelf and don't mess with their internals, and they just work. Thats why we can build usable homebrew phones.

Since this firmware interfaces directly with the SIM card, it can contain code that locks the phone to a particular service provider. The iPhone's GSM modem firmware is locked to AT&T. In order to modify this firmware the unlock applications such as iPhoneSIMFree had to take advantage of a debug feature or security flaw to load modified firmware into the GSM modem. Since the GSM modem is a standard component, hackers were probably able to find out its supplier and part number and get hold of a lot of documentation on how it works.

With the 1.1.1 release it appears that Apple closed off some security holes that were being used to hack into the iPhone, but also digitally signed the code inside the phone. This means that any attempt to modify OSX or the GSM firmware breaks the signature, and since the CPUs have hardware support for digital signatures, its extremely difficult to get around this form of protection. Its now several weeks since 1.1.1 was released on the iPhone and iPod Touch and it hasn't been broken into yet. The hackers have to find and exploit a completely new security flaw to get into the application CPU first, then find a way into the GSM modem. It is then easy for Apple to figure out how they are getting in, and fix it in their next release. With Apple releasing monthly updates, there isn't a viable business proposition based on hacking iPhones.

I still think Apple has a lot of unreleased iPhone software in the pipeline and will open up to developers when it has pushed out a few more updates. I think the ideal audience for an iPhone developer launch is MacWorld San Francisco in January. The highest density of startups and developers is in the Bay Area, and its the anniversary of the iPhone launch. Thats as near as I'm getting to a prediction....

In the meantime, the developers who want something to do could join the OpenMoko project, help build applications for it and maybe even port the Linux based OpenMoko to the iPhone hardware. Thats what I will be working on when I get myPhone up and running....