≈ Relations

While lots of people are eagerly waiting for the iPhone to land in Germany next week, i finally bought the birthday present i asked my wife to buy me last year: a decent successor to my 4G iPod (which began having hard drive failures just after it’s two year guarantee expired). With decent being specified as: Having a big screen and wi-fi, being able to play videos and if possible being touch controlled.

Since my birthday is in late August i hoped that i could get it sometimes in September 2006. But unfortunately i had to wait until January and the iPhone announcement to be quite sure that this years iPod lineup would include one a device that fizs that spec.

So after the iPod Touch was announced i knew that this is going to be my late birthday present. But before i present you my first impressions let me answer the question you may have formed in your mind: “Why not wait a couple more days and get an iPhone?”

Well. Because i don’t need one. I already have a digital camera and a Nokia N95. So i’m already able to take picturs and make phone calls. And since i’m doing all kinds of mobile platforms at work i presumably have access to an iPhone sooner or later if i need to

I needed a device that allows me to surf the web at home without booting a computer first, a device that allows me to listen t music and watch Google TechTalks or iTunes U videos (maybe some real movie) while commuting or use it as an addressbook etc. while traveling.

And i wanted the device with the ultimate user experience and great design.

But what wrt. internet connectivity while being away from home? Most of the time i’m staying at a place that has wi-fi so no problem there, and for the cases when there is no wi-f i, first i think that i can actually manage enjoy time without connectivity and secondly wait until somebody comes up with a similar solution to this for Series60 phones.

And i wanted a device that i can hack / develop for (see here). Hence i waited with my purchase until a jailbreak for the iTouch was available and it was clear that Apple would open up development for the device.

So lets have a closer look (I’ll occasionally include comparison to other mobile devices or gadgets i own /used like the N95, the iLiad, the Sharp Zaurus C700, a JVC MP-C33, a Nokia N800, …)

Setup & Initial Browser Test

The initial setup was as expected, seamless. Nothing to actually write about: Connect, sync, done. Since i already played with MobileSafari for a couple of hours, i already knew that, although MobileSafari and the browser of the N95 share the same roots (i.e. WebKit) they are incomparable. MobileSafari is waaaaay better it provides a completely different user experience.
Especially double-tap to zoom to the nearest enclosing block of a web page together with panning and flicking, for the first time made me feel comfortable to surf normal, non mobile-optimized web sites on mobile devices (and i tried it now for 8 years with all kind of devices) .

But there where a few things i couldn’t test without owning the device. E.g. if it could cope with that strange Radius and token based authentication scheme involving lots of redirects that is used for wi-fi access at work. Since the N95 couldn’t, i was prepared that the iTouch couldn’t do it either. Hence i was pleasantly surprised that it wasn’t a problem at all.

Jailbreaking

Since i wanted to hack / develop for the iTouch i started to jailbreak the device immediately after the initial tests. Since http://jailbreakme.com was just announced this was the first thing to try. Unfortunately, although i made at least 10 attempts and even left one attempt to download installer.app run overnight all i got was MobileSafari crash reports when i connect the iTouch to the MBP.

Looking at various forums i’m not the only one that has / had this problem. Does anyone know the reason? I already began to accomodate to the fact that i had to wait until February in order to access the iTouch via ssh when i thougth that may be i should try sme other jailbreaking methods.

The first method i remembered was iJailbreak so i tried this one. Downloaded it and started, followed the instructions and about 15 minutes later i had an jailbroken iTouch with Maps, Mail and Installer.app installed.

So i was happy. But then i tried to use installer. Knowing other PackageManagers e.g. the OPIE PackageManager for the Zaurus, and having read about installer.app i expected a long list of installable apps. But the list was empty and there there was only one entry in the update list. Installer.app itself. So i tried to update the Installer.app but this always resulted in a checksum error.

After some googleing i found that this may be caused by the wrong permissions for the application. If i remember the iJailbreak correctly this was one of the things that wehre expected to be done, but may it didn’t go through. No problem i thought, just ssh to the iTouch and do a chmod and your done. So i ssh’d to the iTouch and tried to cd . Another surprise. the BSD subsystem wasn’t installed by iJailbreak, hence no cd command.

Then i had to go to work being prepared to try some other jailbreaking utility (like INdependence) after returning from home. After returning home i gave the Installe.app updater another try and fro some reason i don’t know this time it worked. Presumably i tried another iJailbreak in the morning and this time the chmod step worked or there was a real problem with the package and the package was updated during work.

Finally i was ready to install some 3rd-Party-Apps.

Essential Developer Apps

The first things i had to install was the BSD subsystem and the TIFF exploit fix that fixes the security hole in MobileSafari that makes the jailbreak possible but also enables all kinds of malicious attacks. Another thing i wanted to install was the first application a geek normally needs on a mobile device, a terminal emulator.

Then three other application caught my eyes: Python, Apache and Lighttpd. I’ve already written that i installed Python for Series 60 and MobileWebServer on my N95, so it was clear that i had to install them.

So lets do that.

• First the installation process on the iTouch is much faster and easier than the installation process on the N95.
• Second , i had the choice between Apache and Lighttpd on the iTouch whereas there is only the Apache based MWS for series60. I opted for the much more lightweigth Lighttpd.
• Third Python on Series60 is still at version 2.2.x whereas Python on the iTouch is at version 2.5.1 the same version that comes with Leopard.
• On the plus side for the N95 is the fact that the MWS comes with a user interface for starting /stopping the server etc. and with a server side gateway, that makes it possible to connect to the Websserver on the phone from the internet. This is important when the server is running on a phone and the connetion is going through a carrier that is assigning dynamic addresses and playing all kinds of tricks, but irrelevant when you just want to access the iTouch server from the iTouch itself or some other device in yout home network.

In addition i also installed Erica’s Utilities and Erica’s Ported Utilities especially in order to be able to take screenshots.

Reading Apps

After this essential apps i tested a couple of other apps finally settling on the following: Books, Labyrinth and Sensors. The first because i wanted to test how the iTouch compares to the iLiad and the Zaurus as a an eBook reading device, the second becaus i wanted to knowmore about the resolution of the the accelerometers. So lets have a look at the Books first.

Compared with the iLiad the iTouch obviously has a smaller screen. Hence it is only able to display less text. But as you can see from the example screenshots, the texts are very readable, and since HTML and not PDF is used you can easily scale the size of the text to your needs.

As all 3rdParty-Apps if seen so far it doesn’t support landscape mode but this is something that definitely will change in the future.

Judging from my limited experiences, the battery life of the iTouch and the iLiad is comparable, but with the iTouch and Books you get a much more versatile device, that e.g. also is able to display color and video etc. Especially the latter is something i wouldn’t expect in production eInk displays in the near future.

It’s far easier for me to image an iReader device, that is as slim as the iTouch and has the same functionality but is of the size of a paperback book, sporting a 1024×768 screen or so. This kind of device would make reading cool again.

Comparing the display of the iTouch to the higher resolution and higher density displays of the Zaurus C700 and the N800, i have to say that Apple made the right tradeoff. Higher density displays typically result in smaller texts which lead to higher fonts sizes and only marginally better readability. being able to zoom with a easy gesture easily compesates this.

I alsp tried PDF Viewer and weDict as reading applications, but PDF is at version 0.02 and wasn’t able to render the PDFs i tried, and i couldn’t figure out quickly where to put the various dictionaries so that weDict was able to find them. I now did but it wasn’t that impressive. It’s practical to have MerrianWebster as well as the German Duden around, but the UI is lacking right now.

Accelerometer Apps

With the advent of accelerometers in Macs people have found interesting ways to build user experience that take advantage of these sensors. hence i was very interested to have a look at the first iTouch apps that take advantage of these sensors. Whereas Sensors is just a demo aoo show the sensor readings, Library is a gap-stop solution completely replacing the classical wooden gam with a digital counterpart. It is amazing how quick and sensible the tactile feedback is. Unfortunately the screenshot utility does not work with Labyrinth, do you have to try it yourself.

Summary

The iTouch is definitely the device i hoped it is going to be. So i’m very much looking forward to building webapplications / applications for the iPhone/iTouch platform. I already i have a couple of ideas related to my other interests: news services and neogeography.

Hence the Apple-centricity of this blog will hopefully come to an end and i’m going to shift into a more content oriented mode with my next blog entries.

Sems that i’ve been right with my ideas how Apple is going to open up the iPhone (see here and here). Ive just read on AppleInsider that Steve Jobs announced that there will be an SDK by February.

In the announcement there is a direct reference to the security through digital signaturs concepts i anticipated they will use (as Symbian and J2ME are already doing):

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.

Back in June , prior to the iPhone launch i’ve written about how “Apple should open up the iPhone and likely is prepared to do so“. I the meantime a lot happened . The iPhone was and is a resounding success, third party developers and hackers worked furiously to reverse engineer the software in order to be able to develop 3rdParty apps, lots of great apps were developed, among them a one click installer, and a package/application manager.

People were happy. But then firmware 1.1.1 came along and with it encrypted images and broken apps. Hackers are once again furiously working on a jailbreak (and progressing slowly). I still think that Apple is prepared to open up the iPhone /iPod touch along the lines i sketched in my June post (read my full post here):

• widgets first,
• access to OS functions second
• real 3rd party apps third
• securing access to critical functions via certificates (like Symbian and J2ME are already successfully doing)
• Leopard being instrumental for providing sandboxes and application signing via certificates

I even hope think that firmware 1.1.1 is a step into that direction ( e.g. bringing sandboxing etc closer to the iPhone). There are some indicators that i might be not to wrong. See here, here and here.

And if Apple isn’t going to go that route, i have no understanding whatsoever, why they are intentionally and willingly giving up this field to Nokia, a company that is more and more postitioning itself as the main rival in the mobile space.

Not only is Nokia the the worlds biggest handset manufacturer, directly targeting iTunes with their OVI brand and their new handsets (read a comprehensive comparion between Nokia and Apple over here.), acquiring mobile marketing companies and map data providers and sign up video distribution deals and are going head with Apple on their latet ad campaign, touting their openness (however, some person think that apple is not the only target of that campaign).

Web Run Time – Widgets Running on Mobile phones

In a very much overlooked announcement back in April (Unfortunately i did overlook it too, the announcement was brought to my attention just last week by a good old friend at T-Mobile) that they are going to bring widgets to their mobile phones (or as Nokia would say multimedia computers) . And they are going the same browser engine as Apple is using on the iPhone: WebKit.
(Rem: Although both the N95 and the iPhone are using WebKit i have to say that due to the zippiness and the gesture interaction (especially pinching and panning) the iPhone browser IMHO plays in a completely different league)

The widget Platform built on top of WebKit is called Web Run Time (read more about it here and here). And it exactly goes the way i sketched:

Web Run-Time offers numerous possibilities for Web application development. As the Web Run-Time is built with standard Web technologies, developers can create new innovative widgets and also migrate existing widgets from the desktop to S60 with minimal effort. In the future, widgets will benefit from connecting both to Web 2.0 services, Web content and to the core applications and capabilities of S60, such as phonebook, calendar and GPS.

Simple widgets with local storage first, access to functionality later. What is especially telling is the experience report describing the port of the WeatherBug dashboard widget (see here and here). Basically it tells that porting of simple widgets is a no brainer.

Right now neither is Web Run Time available to the general developer nor are their handsets in the marketplace ( And given Nokias series 60 platform philosophy where existing handsets never get a feature pack upgrade, it is unlikely that current N95 will be able to run widgets (They are on 3rd edition, FP1, Web Run time is part of 3rd edition FP2). But the availability of the developer tools is scheduled for Q3 and might coincide with the Nokia Tech Days scheduled for October 10th – 11th (that is tomorrow!) in Miami and November 13 – 14th in Palo Alto. Hav a look at the conference features yourself:

Conference features:

• What’s new in Nokia developer platforms
• Tips for improving your developer skills even more
• How to use Nokia platforms and technologies as a business advantage
• Info on widgets, browser run-time technologies, Linux and Maemo open source platforms, S60, Java and Flash (Lite)
• Ideas on finding new and profitable channels (courtesy of the Nokia Business Development staff)
• Symbian technology experts and partners and more

IMHO, Apple has still a very tiny window of opportunity left to communicate their third party strategy for the iPhone (and the iPod touch). I still hope that this announcement will be at least synchronized with the introduction of Leopard (if not earlier). If not not only imyself but may be also some journalists and analysts are going to ask questions.

A 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?

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

So 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?