Mobile and web 2.0 developer, consultant and speaker. Author of "Programming the Mobile Web" book, published by O'Reilly in 2010. Forum Nokia Champion. Maximiliano is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Is Apple trying to hinder PhoneGap and other HTML5 frameworks with iOS 4.3?

  • submit to reddit

Last week Apple released iOS 4.3 and the new Nitro engine was presented inside Safari on iOS for iPhone, iPod Touch and iPad. The iPad 2 with iOS 4.3 is on its way in US and worldwide in next days. However, a new situation was discovered last days alarming a lot of developers: Nitro is not available for PhoneGap and other webapp-related solutions. Is it a deliberate attempt to hinder PhoneGap and other HTML5 frameworks?

After my tweets last Saturday about this limitations, I’ve received dozens of contacts (e-mails, tweets, contacts from the press) asking me about why Apple is doing this. First, let’s see what is the problem and let’s analyze it later.

Nitro engine

As I showed on my last post about iOS 4.3 new stuff, Nitro engine provides a 2x performance increase in JavaScript inside Safari on iOS for iPhone and iPad. It is good for HTML5 webapps, mostly using heavy JavaScript code, and for frameworks, like jQuery Mobile, Sencha Touch and many others.

Everyone (myself included) thought: “if Nitro is available in Safari, it will be available also on other places where we normally execute JavaScript”. And that is wrong. Right now (iOS 4.3), the Nitro engine only works inside Safari: a webpage based on a URL with the full Safari UI loaded.

Nitro on UIWebView

I’ve started making other tests and I’ve found (like many others on Twitter) that Nitro seems to be disabled on UIWebView. UIWebView is a native control inside UIKit, one of the frameworks inside iOS SDK for native development. It provides a WebKit engine inside a native app. In fact, because of the iOS Developer Agreement, UIWebView is the only accepted web runtime for a native app. That is why there is not a Firefox for iOS (Opera Mini is a different thing).

The UIWebView control is useful in many cases, including:

  • Apps showing HTML5 content inside, such as magazines and newspapers.
  • Apps with a quick web browsing feature, such as Twitter for iPad when you click on a link.
  • Browser apps“. I like to call them “pseudo-browsers”. They are on AppStore and publicite themselves as browsers, but they are just the same Safari engine on steroids, providing some additional feature (such as tab navigation). One example of a pseudo-browser is SkyFire.
  • PhoneGap and other Full-HTML5 hybrid apps. This kind of projects are just a full-screen UIWebView loading some web content inside.

Right now, Nitro is not available. Here you will find two screenshots: one from a native app with a UIWebView I’ve created in two minutes; the other is just SkyFire for iPad. On the SunSpider benchmark test, using the same iPad as in this post, I’ve received similar results as in iOS 4.2: no Nitro engine on UIWebView. Remember, in Safari for iOS 4.3 the results were 3.5 seconds.

UPDATE: A lot of discussion is going on in Twitter. Right now, the theory about why Nitro is not on UIWebView is because of a security and kernel problem. Here you will find more information. Nitro is a JIT (just in time) compiler, and that can lead to security issues (JavaScript code that could potentially execute non-secure native code) and there are some problems with memory management also for JIT to work. However, this theory leads to other question: is then Safari for iOS 4.3 with Nitro secure enough? If this is true, maybe an official response will clarify and calm down some developers ;)

Nitro on full-screen webapps

Safari on iOS has an excellent feature that I still can’t believe Android, Nokia or BlackBerry doesn’t support yet. Using just some HTML and some JavaScript, (as discussed on Chapter 9) you can suggest, or even force, a user to add the app to the Home Screen. When done, the user will receive an icon inside the home menu as any other native app installed. Using a second meta tag (apple-mobile-web-app-capable) you can force your webapp to be opened in full-screen mode.

Well, a webapp opened in full-screen mode does not use Nitro engine (again, this is not a native app, just an HTML with a shortcut from Safari). Here is the test that you can do it yourself at using an iOS 4.3 device.

Here you will find two results using an iPod Touch 4G with the exactly same HTML file: one using the classic Safari UI (result: 4.2 seconds) and other after install an icon on the Home Screen and opened in full-screen mode (result: 10.2 seconds).

Is this a deliberate attempt from Apple?

This is a big question. I’m seeing a lot of angry people out there. I’m seeing a lot of conspiracy theories about this. I don’t believe this is a deliberate attempt from Apple. I can’t be 100% sure because I don’t work at Apple, but I’m not seeing any excuse to do that. I believe it’s more a “missing feature”, a security problem, an AppStore Rules problem, or maybe a bug.

First of all, does this problem mean that PhoneGap apps or SkyFire doesn’t work anymore? No, they just work as in iOS 4.2 (and I believe everyone was happy with that, a month ago). Ok, I know… it’s a shame that Nitro is not available there. Yes, it’s a shame and I really hope to have this included in a future release (maybe 4.3.1, 4.4 or 5) but I believe that it doesn’t worth new conspiracy theories.

UIWebView vs Safari

One guy from Apple commented me in an informal chat that the engine behind UIWebView and Safari is the same one. However, he also confirmed me that Safari IS NOT using UIWebView inside. That is, they share the same engine but they are two different things inside the O.S. So, technically they can work different without any conspiracy theory. Therefore, UIWebView is not a Safari loaded inside an app.

And it’s also possible that when a full-screen webapp is opened, it is done using UIWebView and not Safari. Because the Safari UI is hidden, why use the full Safari controls if they can do it with just UIWebView? This is just my guess on why Nitro is not available on full-screen webapps. I’m not completely sure but it makes sense to me.

UPDATE: Some guys told me that apparently a full-screen webapp is using an internal process called

It can be deliberate, it can be because of a bug or it can be because they forgot about it, I don’t know. I’m trying not being naive about this, but this is not the first time I see bugs around UIWebView or full-screen webapps on a big change (I remember a lot of bugs in iOS 4.0). Maybe it’s not a priority inside internal Apple testings.

What to do?

Unfortunately, Safari on iOS and even UIWebView without Nitro, are the most powerful mobile HTML5 engines out there. I say “unfortunately”, because I want Android, BlackBerry, Nokia, HP to reach Apple’s engine. Some are close, but Apple is still ahead.

Even if we talk about full-screen webapps: Apple is the only platform supporting this feature.

You can love or hate Apple, but you can’t ignore that it is the best WebKit engine out there in the mobile space. Therefore, why do something against it?

I can not believe today in Steve Jobs saying: “let’s remove PhoneGap from the equation”. (I’m using PhoneGap just as a sample: it can be anyone on the HTML5 webapp side). I’m not seeing how PhoneGap can hurt Apple today. I’m not seeing any political issue like in Apple-Adobe. And I’m not seeing that the lack of Nitro is hurting PhoneGap apps directly right now. It’d be better to have it, but right now it’s not the worst thing in the world; it’s still the best platform for this kind of projects.

In my opinion we need to wait until next release and in the meantime, use the Bug Request Form to submit our opinion and suggestions for next versions.

What do you think?

Published at DZone with permission of Maximiliano Firtman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Dimitris Menounos replied on Tue, 2011/03/15 - 3:41pm

IMO it is deliberate and it makes sense. This way they make sure that web apps are identified as such. Their web runtime is really powerful and disguised as a standard app can hinder the their native ecosystem.

Olivier Duval replied on Wed, 2011/03/16 - 2:29am

Just FYI: on android, a WebView seems to do what an IOS UIWebView does including running fullscreen (like any other app), with javascript (with the Webkit engine) and so on... That's why it's the most common solution used to wrap webapps, either online or as local webapps (by intercepting URLs, binding java objects to javascript objects). As it is just a "browser" component, it can be embedded in any app so will be shown in android launcher, like any app. Have a look to for the technical doc.

Chee-keong Lee replied on Thu, 2011/03/17 - 9:44am

I have a simple Javascript webpage that worked in Safari on iPAD on iOS 4.2 but when I ran it on the same iPAD which was updated to iOS 4.3, Safari crashed.  I have narrowed it down to the amount of memory used in my Javascript which is loading 105k+ words into memory for quick searches. If I reduce the number of words stored to 100k+, the application can load and run without crashing.

This is a major bummer for me and perhaps there should be a switch to turn off the JIT or the NITRO engine as required.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.