The big takeaways from today’s announcement of iPhone native SDK availability in February:

1. Partly this is a preemptive strike for the holiday season – remove a reason for some people not to buy, and take away the only real “down” side to the iPhone story in consumers minds post-launch. Instead turn it into another focus of desire for consumers – let the lust begin for the native apps just around the corner.

2. Give app developers the confidence to begin writing apps now on hacked iPhones, knowing that with a bit of tweaking they will be deployable on non-hacked devices when the SDK arrives.

3. Predictably, application signing will be part of the equation. Much depends on the signing model. The big questions – will compliance testing be required to get signed? what capabilities will be restricted?

4. The SDK release coincides roughly with the reported release date of the first GPS-enabled iPhones. Prediction: Apple is going to make 2008 the year location-based services go mainstream.

The actual announcement:

Third Party Applications on the iPhone

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.

Some companies are already taking action. Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. While this makes such a phone less than “totally open,” we believe it is a step in the right direction. We are working on an advanced system which will offer developers broad access to natively program the iPhone’s amazing software platform while at the same time protecting users from malicious programs.

We think a few months of patience now will be rewarded by many years of great third party applications running on safe and reliable iPhones.

Steve

P.S.: The SDK will also allow developers to create applications for iPod touch. [Oct 17, 2007]

 

Adobe’s AIR platform has shown that the web development model is fundamentally capable of delivering applications every bit as rich as native platform apps. Hence the outcry over the idea of web applications as the primary development model for the iPhone is overblown. Yes, the current iPhone development environment sucks but it’s important to keep in mind that we haven’t seen the true power of this model.

So what will Apple do if they are serious about the web development platform?

First up, a JavaScript bridge into native device capabilities on the iPhone. Right now in terms of access to device functions via web technologies, the iPhone offers nothing beyond the microbrowsers on feature phones. Yes, the AJAX support enables a quantum leap in usability, but we need more.

Top of the list – “the basics”

• file access
• camera access
• location
• address book
• calendar

But beyond these now familiar mobile device capabilities, there is an opportunity for Apple to provide powerful APIs that would provide an unparalleled mobile development environment, web or otherwise:

• SQLite local store
• Access to iTunes account-based charging
• Event subscriptions with persistent ECMAScript object handlers
  • timers
  • calendar events
  • location
  • support for installable URI handlers

Key to app usability is that these capabilities should be provided through a user consent system which does not take away the user’s choice to make use of device features with a given application, a la the restrictions in many J2ME runtimes:

On first load, present the list of “privacy affecting” services being requested by the application – and listen to what the user wants! Empower the user already – they bought the damn thing.

When can we expect such features? Who knows, but I would be very surprised if the first GPS-enabled iPhones, expected in Q1 2008, ship without at minimum a JavaScript bridge to location data following soon after.

Gut check: For anyone with development experience on J2ME, can you imagine going back to the underachiever that is the J2ME RMS storage API after being provided with a local SQL store?

The native app vs. web app argument is stale!

Jeff
Chief Software Architect, EQO