How Apple should open up the iPhone (and likely is prepared to do)

20070613_widsetspersonal.pngA couple of weeks ago i installed widsets on my tried and true Nokia 6630 as well as my wifes’s E61 (BTW: does anybody know how to disable Wi-FI on that thing?). And i must say that my speculations that widsets is the most interesting framework/service for developing mobile information applications are indeed true. And, since i’ve been working in that area for over 8 years, i’ve seen quite a number.

In addition widsets shows the way how Apple should open up the iPhone to the general public. If Apple for some stupid reason not dares to do so, i hope sincerely that widsets will try everything to run also on the iPhone, despite their very close relationship to Nokia. Especially because they have already everything in place to do WAY better than widsets.

Regarding the announcements at WWDC about Safari+AJAX being the base for 3rdParty app development i’m not sure what to make out of it. They sure point into the right direction, but some bits and pieces are still missing from the picture. In the remainder i’ll present you my reading between the lines and reasoning for filling these missing pieces.

So what is Widsets?

20070613_widsetslibrary.png

Basically it’s a widget ecosystem for mobile phones. Some might call it a personalized homepage (like netvibes, pageflakes, iGoogle etc.) but for me it is still a widget system. Not at least because Apple still calls the mini-applications running in the dashboard widgets. So it does everything one expects from such an ecosystem, e.g. a web accessible directory, personalization of the personal homepage, hot-deployment to the device, …

Since i’m assuming that you’re already familiar with personal homepages, feeds and widgets I’m not going into detail here, just have a look at Widsets or read about my take on personalized homepages over here.

On the mobile device, Widsets is primarily a container for deploying the widgets. In addition to providing a run time environment for the widgets (most of them being specialized RSS feed widgets) this container is able to store some data such as the authentication data, the traffic volume etc. within the realm of the application as well as the widgets themselves. As far as i can see the widgets themselve have no capability to access functions of the mobile device or store data locally.

How does that translate to Apple and the iPhone (and what does Mondays keynote tell us)?

Learning from Widsets, the following two capabilities were crucial but also proved sufficient to enable a prospering widget ecosystem on mobile device:

  1. Ability to download and install widgets to a container application on the mobile device. This contaier app only needs the rights to locally store the widgets and to store some preferences etc.
  2. Enabling the widgets to locally store preferences and other small amounts of data

Presumably most of you now know where i’m headed. But nevertheless the remainder of this article might be of interest to you.

So what do we know:

  1. Apple already has a very prospering widget ecosystem (actually they were the first to have one, at least to my knowledge)
  2. Apple also has a container application called Dashboard
  3. In addition Apple also has a development environment /SDK for developing widgets called Dashcode. (If you want to know what widsets calls SDK just have a look and a laugh if you compare it to dashcode). Actually the perspective to be able to develop widgets for the iPhone was the reason why i downloaded the Dashcode beta in just before this years Macworld keynote.
  4. Compared to other widget/gadget environments Apples widgets are more powerful. Especially they are able to store preferences locally. Thats what’s that other side of the widget is for, you remember?
  5. We also know that the iPhone runs a non crippled Mac OS X (thanks to the All things D interview of El Jobso with Walt Mossberg) , especially a non crippled version of WebKit/Safari.

Hence there is no reason why there couldn’t be Dashboard like container application on the iPhone that is able to store widgets on the phone.

Remember that this was one of the two requirements that were necessary for widsets to become a succesful widget ecosystem on mobile devices? And in order to fulfill the second requirement, just give widgets the right to store local preferences the way they already do (i.e. as ressources local to the app bundle).

Then do everything you want to separate widgets from the rest of the phone (e.g. put them onto a separate partition that has no rights to write whatsoever on other partitions, …) And for the time being just disable all the nice things that are described in the “Leveraging the Mac OS X Technologies” section of your “Developing Dashboard Widgets” document.

I’ll come back to what i think about doing problem in a second, but first i’ll give you my views on Mondays keynote having the views from above in my mind:

Mondays keynote “One last thing” gave the impression that the 3rd Party applications are running within Safari but there is no real reason why they couldn’t run in a dashboard like container app. Most of the critism after the stevenote concerning app developement for iPhone that i’ve read, focused on the fact that the applications have to live in the web and not on the phone (see for example here).

Here I definitely agree with James Tauber’s remarks on the keynote:

But I think Steve presented it the wrong way. It felt too much like “sorry, it’s the best we could do under the circumstances”.

I also agree (to some extent) with Alex Hung from downloadsquad in his assessment on the reasons for introducing safari for windows:

It is obvious, at least to me, that releasing Safari for Windows is primarily a move to open up the iPhone’s development environment to the largest audience possible.

Well may be the primary reason is to introduce a development environment and runtime platform that is agnostic to the underlying OS (be i Mac OS X, Windows, iPhone etc.) but under the control of Apple. I think the underlying idea is to provide somethig that compares to AIR, Silverlight, OpenLaszlo, … etc in the RIA space.

Hence more along the lines of Aaron Brazell assessment for technosailor / but not going as far as saying that safari is the new OS):

Yes, I did say Safari Platform. If the “read between the lines” moment was the intuitive announcement that there is no SDK for the iPhone and, in fact, web apps are the means of deploying iPhone software, and in fact Safari will be available to the vast majority of folks, there is no reason to believe that Safari is not the new OS platform.

Considering the more mundane aspects of how the integration with existing iPhone applications works i join Matt Croydon in his “It’s the URL scheme stupid” assessment

Tap on a phone number to call

This technology dates back to the wtai:// pragma from the WAP/WML dark ages and has since been codified with the tel: uri scheme as outlined in RFC 3966. The tel: scheme is used with XHTML MP and existing mobile browsers (here’s an example from one of Brain Fling’s presentations). I would hope for consistency sake that Apple makes use of tel: but there’s a chance they might go for the unstandardized-but-used-a-lot callto: instead. The callto: scheme is used by Microsoft Netmeeting and Skype on most desktop systems.

Tap on an email address to invoke the native mail client

It’s mailto: folks, let’s move along.

Tap on an address to launch the Google Maps app

I’m assuming that this is being handled via a proprietary URI scheme which the Google Maps app is registered to. I can’t tell you if it’s going to be gmaps:// or something else, but it’s going to be as simple as creating a link to gmaps://q=20+Infinite+Loop+Cupertino,+CA (or something very similar). This functionality is the most intriguing to me as a geowanker, but my gut tells me that it just boils down to a URL scheme.

I’ll especially join him in the tel: scheme argument (i’ve also wandered the wtai: woods in the dark ages) and note that unfortunately at least the last time i look the RFC for the sms: scheme didn’t make it into a recommendation, but maybe rfc4355 compensates that (sorry i don’t speak ENUM

Putting all together

20060713_iphonewidgets.pngSo I envision the following route taken by apple:

  1. There is (or is going to be shortly) a dashboard like widget container on the phone and one of the free application spots on the iPhone UI is reserved for an Dashboard icon. Or widgets are directly showing up in the finder equivalent that is used to show the application icons.
  2. Widgets can be downloaded as app bundles just the way they are downloaded today (No need to clutter with that part of safari on the i phone Apple ). There will be a separate iPhone widget directory at apple.com (or some way to filter the widgets to iPhone compatible)
  3. Widgets are able to store their preferences locally (Initially that restriction may be waved later, see below)
  4. Dashcode supports some iPhone specific templates and actions in order to provide the development environment called for by the masses (but actually not needed by the experts)
  5. Maybe there is an action “Check for iPhone compatibility” included with Dashcode, maybe even an “Transcode to iPhone widget” wizard.

But wait. While looking for a decent iPhone picture I just found the following snippet on Apple’s iPhone page:

Widgets

iPhone even has widgets: small applications that give you helpful information like stock reports, weather reports, and more in real time.

Did i overlook it earlier or is this new? At least it is for me strongest indication that apple is prepared to take this route.

If they are not taking this route, i’m very eager to hear the reasons why. IMHO, although being first in the widget space they lost big to the purely web based players like netvibes, pageflakes and iGoogle. I’ll attribute that to the greater capabilities of Apple’s widgets.

But if they don’t use these capabilities (e.g. downloading the widget to the device and storing preferences on the device) to their advantage, i have real problems of understanding why they don’t do it although everything is in place. And maybe some analysts join in in wondering.

In the long run it will not gain anything from this attitude, not the least because Google Gears and/or RIA approaches will likely enabled clever developers to do so without asking Apple. The only counteraction Apple can do to this is crippling the browser, which would counter one of the major USPs Apple is using to sell the iPhone.

Leveraging the Mac OS X Technologies

While you can do already quite a bit of 3rdParty app development in the scenario sketched above, still the real SDK and the real access to the phone apps is missing. Things that quite a number of developers want to have.

I think the key to that will be the methods described in the “Leveraging the Mac OS X Technologies” part of the “Developing Dashboard Widgets”, namely Unix Commands, Quartz Drawing, Internet Plug-Ins and Widget Plugins.

Since ElJobso always cited security concerns as the main reason for not opening the iPhone i will first have a deeper look how this security concerns are resolved in J2ME and Symbian and then take my view how this can be interpreted having a look at Apples actions.

Security models of J2ME MIDP2.0 and Symbian

I won’t go into the details of the MIDP2.0 security model but the important points are: MIDP2.0 uses protection domains in order to provide or deny access to certain capabilities. But even in the untrusted domain it is at least possible to download and store the widsets application on the mobile device, and for the application to store local data (to a limited amount ) in its local “record store.” These capabilities are the ones used by Widsets.

More sensitive operations are located in protection domains that are protected by certificates. These domains are only accessible if the root certificate of the CA that has signed the application certificate is granted access rights to that protection domain.

Symbian basically follows a similar road but provides an additional layer of security (or inconvenience) by the requirement that all applications that are going to be deployed on a phone (and especially Series60) have to be signed (at least in its 3rd edition. I wont’ go into details here either (if you want to know more about it: a good starting points are here, here and here ) but it is a very fine grained system that allows to open up the capabilities of the phone based on the kind and type of certificate the application is signed with.

E.g. one special kind of certificate is a developer certificate. This certificate can be self signed by the developer but in general asks the user of the phone when he is trying to install the app as well as when trying to access some not so critical capabilities of the phone (e.g. bluetooth). Other capabilities of the phone could generally not be used with this kind of certificate.

Another kind of certificate is the symbian signed certificate were a complex process involving testing of the application submitted for signing is used to ensure that the capabilities are only used in the proper way. Since quite some money and time is involved in this process fortunately some special provisions care for the signing of freeware apps.

This process also gives the phone manufacturer and the operator the chance to further restrict the kind of certificate needed in order for an application to be installable. Most operators opt for an otion that the users are warned if a self signed certificate is used for an application but they can also opt for only symbian signed applications to be installable.

Whats in there for Apple?

The road chosen by J2ME and Symbian can also easily be taken by Apple. Since the operators didn’t object to the procedures for J2ME and Symbian they should also be ok with a similar process by Apple.

Apple already has the Apple ID of all potential developers via AD. So its easy to leverage the ADC memebrship for this process. Apple is also capable of setting up their own CA (or let somebody else do it for them) and provide different kinds of certificates corresponding to the different capabilities required by the application.

For example self-signed or automatically signed certificates could be sufficient for gaining access to the quartz drawing and certain unix command capabilities (e.g. only read access to information) whereas “Apple signed” certificates are necessary for accessing the internet-plugin and widget plugin capabilities of the widgets. Businesswise certain certificate levels can be coupled to certain ADC levels etc.

This principle can be even taken from a widget level to a real application level (i Apple wants to do so) And guess what, I think this is the place were the additional security measures coming with leopard will kick in. Especially application sandboxing and digital signatures come in handy for the scenario described above. Citing from the Leopard Security page on apple.com:

Sandbox tested.

Sometimes hackers try to hijack an application to run malicious code. Sandboxing helps ensure that applications do only what they’re intended to by restricting which files they can access, whether they can talk to the network, and whether they can be used to launch other applications. Helper applications in Leopard — including the network time daemon and the Spotlight indexer — are sandboxed to guard against attackers.

Danger-free downloads.

Sometimes innocent-looking files contain malicious applications in disguise. That’s why files downloaded using Safari, Mail, and iChat are screened to determine if they contain applications. If they do, Leopard alerts you, then warns you the first time you open one. You decide whether to open the application or cancel the attempt. And Leopard can use digital signatures to verify that an application hasn’t been changed since it was created.

It shouldn’t also be to big a problem for Apple to set up web portals and procedures for self signing / automatic signing of widgets and apps. These processes can even be integrated directly into Dashcode.

Since the security model is based on certificates etc. Apple even still can claim that they are only using web techniques (something that at the moment seems to be very important to Apple PR).

One last Thing

Putting everything together i would bet that:

  1. iPhone will run on a Leopard core and the security components and everything else that is needed for this scheme will not only be feature complete but tested to the max.
  2. The original plan of Apple was to have Leopard out of the door in spring . Hence they planned to have everything in place and announce it as the “One last thing ” at WWDC. This would have guaranteed them yet another of these typical underpromise, overdeliver moments. But unfortunately not everything is ready and the result of this was the crippled “One Last Thing” announcement we heard on monday leaving the impression of “sorry, it’s the best we could do under the circumstances” to cite James Tauber again. So i hope that we can change that to “sorry, it’s the best we could announce under the circumstances”.

Your opinion? Am i fantasizing or does the reasoning make sense?

3 thoughts on “How Apple should open up the iPhone (and likely is prepared to do)

Comments are closed.