Debugging mobile web applications was always a painful process. In this post I’m presenting the free tool iWebInspector I’ve created to enable a full Web Inspector -including JavaScript debugging & profiling- in Safari for iPhone and iPad and in PhoneGap apps.

First of all, full credit of the hack behind the tool to Nathan de Vries. He has discovered some days ago a private API and he has published a post about it. With this solution we can enable a Remote Web Inspector on iOS Simulator included with Xcode 4.2 and iOS 5 SDK using some gdb (debugger) commands.

I’ve started this post as a tutorial on how to enable this option and debug webapps on the iOS Simulator. After writing this post, I’ve realized it was too difficult to use and enable for a typical web developer without Xcode experience.

My next thought was: “it should be great to have a tool making these steps for us“. And my saturday’s afternoon paid for that thought. I’d experience with Objective-C for iOS so it wasn’t difficult to create my first Cocoa Mac application using the same language. After a couple of hours, the first version of iWebInspector was ready to go.

The solution is not working -yet- on real iOS devices, just on the iOS Simulator -available only for Mac OS-. The tool can attach the Web Inspector to any tab opened in Safari for iOS, to a chrome-less webapp (full screen) or to a PhoneGap application -or any native application using UIWebView-.

iWebInspector

I’m pretty sure that Apple will make this tool public in a future version of iOS.

Download iWebInspector

Attaching to PhoneGap and UIWebView

If you are creating a PhoneGap application or a native iOS app with some UIWebView content, it’s easy to enable the Remote Web Inspector with a line of code instead of using iWebInspector. This is a private API so remember to remove this line for the final compilation or you may have an AppStore rejection for private API usage.

Find your application:didFinishLaunchingWithOptions method on your AppDelegate.m file and add this line of code inside:

// Remove me after debugging
[NSClassFromString(@"WebView") _enableRemoteInspector];


That’s all! After that, run your app on the simulator and localhost:9999 will be pointing to the same Remote Web Inspector as in iWebInspector.

Suggestions and Bug Report

iWebInspector was created in a couple of hours, and this is the first version available.  If you find bugs, problems or if you have a suggestion, feel free to contact me or leave a comment here.

Enjoy!

Android 4.0 was announced and the SDK was released. So, I’ve washed my hands, I’ve opened the emulator and I’ve started to dive into the new browser and see what’s in there and what’s not. Unfortunately it’s still Android Browser and not Chrome, but it comes in a better way.

Busy month

October 2011: Busy month for mobile web world.  Just a few days ago, I’ve blogged about Safari on iOS 5; yesterday BlackBerry announced the first mobile browser with WebGL support on the (future) PlayBook platform and a few weeks ago Amazon announced Silk, a new proxy-based browser for tablets.

And now, it’s the Android turn. Android 4.0 was released and while there is no real phone yet to test it on (the Galaxy Nexus will be available soon) I’ve downloaded the emulator and I’ve tested the browser comparing it to Android 2.3 (smartphones) and Android 3.2 (tablet) that I both have on my hands.

Google announced that Google Chrome will be the future of browsing in Android but it was not 4.0 the time for that.

Smartphones meets tablets

This version merges both smartphones and tablets, so smartphones jumps from 2.3 to 4.0 acquiring all the new things on the browser available on 3.x, including:

• SVG
• Motion Sensor API (accelerometer and gyroscope -on compatible devices-)
• 3D Transforms on CSS3
• XHR 2 & CORS
• File API
• HTML Media Capture API for camera/microphone access through file management
• Binary Arrays (Int16Array, Float32Array, etc.)

What’s still missing on Android 4.0

Unfortunately, there are still some missing APIs that are available on Google Chrome and on iOS5 -some of them-, including:

• No Server-sent events (BTW, does anybody use it?)
• No WebSockets
• No WebWorkers
• No IndexedDB
• No Web Notifications (that is a real shame for this platform – Firefox on Android is doing it-)
• No WebGL
• No History Management API
• No rich input controls! I’ve found a huge bug on the range input type (no rendering at all), and no date controls are working. Even it seems that Android 3.x has better support than 4.x (more testing soon)

New stuff

The new stuff for both smartphones and platforms I’ve found:

• Navigation Timing API, same API in IE9 on Windows Phone and in Firefox 7 for Android
• New Console API, but not working properly, for example there is a console.memory.usedJSHeapSize and console.memory.totalJSHeapSize attributes, and some new functions but I could not make them work yet.
• The HTML5 <keygen> new form is available
• Basic MathML seems to work

New things to know

It’s time again for a new version of iOS for iPhone and iPad and a bunch of news about mobile web development. I’ve analyzed every new feature I could found in Safari on iOS5, including what’s the final resolution with expected features as WebGL (3d) on Safari.

Overview of new things

• HTML5 new APIs and feature support, including: Web Workers, Web History, new web form controls, inline SVG, MathML, Compass support, new external script attributes, some new CSS3 improvements and contenteditable
• Fixed zones and scrolling areas support
• New tabbed browsing for iPad but no desktop-like support
• Performance improvements and Nitro engine on home screen webapps

HTML5 news for iOS 5

HTML5 Elements

Safari on iOS still doesn’t render anything special on the new elements progress, meter, detail and summary. If your web content is well and semantically designed, the new reader mode will be activated and your content will be converted into a “article mode” view if the user presses the reader button on the URL bar. There is no API or attributes to manage or customize reader mode. Create a good mobile web experience and your user will never use the reader mode :).

Web Workers

We can use workers to execute code in a different thread than the main UI thread using the HTML5 Web Workers API. This is great to provide good UI experiences when using lot of JavaScript execution.

New Input types support

iOS 5 supports new form rich controls using the input element, supporting range (rendered as a nice touch slider) and most date/time controls using date, time, datetime, month and datetime-local. From the HTML5 standard, color and week selector are still unsupported being rendered as plain text inputs. Datalist is still unsupported.

That is how this simple HTML elements are being rendered on iOS5 (iPhone and iPad):

<input type="date">
<input type="datetime">
<input type="month">
<input type="range" min="0" max="40">

Inline SVG

Now we can embed easily SVG graphics and animations using inline SVG, a new way to embed this kind of files inside an HTML using just a svg element, like que next example:

ClassList API

Now we can use this new API on every DOM node using the classList attribute that provides different methods for class manipulation (a la jQuery) such as add, remove, toggle and contains. For example: menuList.classList.add('touch');

ContentEditable

This new attribute, global to all the HTML5 elements, allows us to convert any HTML element into an editable one. That means that now a user can edit a list (ul element) or even we can create rich editors for iOS using contenteditable and execCommand. On my quick tests most visual rich editors for HTML are working properly on iOS5. Some of them are not optimized for touch, but in functionality, you can change formats and styles without any problem.

Here you have CKEditor working on iPad:

History Management API

Now we can change the URL without refreshing the page (and without using #) with this new API inside HTML5 standard. It exposes some new methods over the history object, such as pushState.

Canvas

Now it is hardware-accelerated as in Internet Explorer 9, so the performance is much more faster. CanvasPattern is now supported.

Geolocation and iOS Simulator

The iOS 5 Simulator for Mac now includes the ability to simulate different locations using latitude/longitude.

MathML

The markup language for math expressions is now available on iOS, so we can use the new math element in HTML and provide a MathML document inside. However, not every math special character is rendering propertly as I could check, such as Sum and big parentheses.

XMLHttpRequest 2

XHR 2 is now supported but to be honest, it’s absolutely useless as file uploads and File API are disabled in Safari on iOS. The great advantage of XHR 2, the progress upload mechanism, is not allowed.

LocalStorage

Now it can be cleaned by the user in Settings > Safari at the same time as cookies. The other new thing to keep in mind is that now a Private Browsing mode exists and we will receive exceptions if we try to use any offline API, such as LocalStorage, inside this mode. Keep in mind that you should catch this exceptions.

When activating Private Browsing Safari changes its whole UI to black:

Error handling

Finally, window.onerror event is exposed so we can catch any JavaScript exception easily.

DeviceMotion API

Compass support is available in the devicemotion event through new attributes: webkitCompassHeading and webkitCompassAccuracy. There is also a new event we can subscribe to: compassneedscalibration. This will work only on iPad 2, iPhone 4, 4S and iPod touch last generation.

Font Design

Some CSS3 features were enhanced, such as support for :first-letter pseudo-element to have a different style for the first letter of a paragraph. Also text-rendering: optimizeLegibility; is now improving handling of kerning pairs and ligatures on typography. Now, WOFF (Web Open Font Format) is supported for CSS3 Web Fonts.

New Gradient Syntax

The new WebKit gradient syntax is supported, including: -webkit-linear-gradient, -webkit-radial-gradient, -webkit-repeating-linear-gradient, -webkit-repeating-radial-gradient

External script files

Async scripts are now available using the async attribute. With asynchronic external script references, the script will be loaded without interfering with other resouces’ downloads.

<script src="external.js" async></script>

It’s also available the defer attribute that allows the browser to defer the script execution until onload executes first.

<script src="external.js" defer></script>

Sandboxed iframes

Now, an iframe can have different security implementations regarding the sandbox attribute as defined in this spec.

Keep Waiting

We still don’t have WebGL (3d canvas) even after demonstrating that WebGL is definitely there. It is deactivated and the rumor says that it’s there only for iAds usage inside a native app. We still don’t have IndexedDB, so Web SQL is the way to continue working with databases. And File Uploads or Camera APIs are also unsupported.

Fixed Zones

Finally, position: fixed is now working. This means that we can now leave those obscure tricks using touch events to emulate fixed toolbars and a lot of JavaScript code (equals CPU usage, equals battery consumption) for emulate momentum animation.

Keep in mind that when using position: fixed and a scalable viewport (or no viewport definition at all), the fixed zone zooms in/out as the viewport and it’s not really fixed as we could expect.

BTW, if you have a desktop website (not mobile-optimized) and fixed zones, you have a big problem! The fixed zones will create useless experiences when the user zooms in.

Scrolling zones

Before iOS 5 any scrolling zone, such as an element with overflow: scroll or an iframe had usability problems. That is because the user needs to use a two-finger scrolling gesture to scroll inside smaller areas in a page.

Now this problem has ended, as now every inner scrolling area will be scrolled using only one finger. And a new CSS extended attribute allows us to define what kinds of scrolling do we want: -webkit-overflow-scrolling that can accept auto (standard “desktop-like” scroll) or touch (with momentum, like native iOS applications or even like the page scroll momentum).

.scrollingWithMomentum {
height: 200px;
overflow: scroll;
-webkit-overflow-scrolling: touch;
}


Tabs in iPad

On iPad with iOS 5 we have now navigation using tabs. But be very careful! Tabs don’t work as in desktop. No tab will work in background or execute any background JavaScript and there is also no favicon support for the tab name. The user can now open a tab in background but your page will be live until onload and it will be frozen and reactivate when the user activate the tab.

If the browsers needs memory can release our page (even being already on an open tab) and when the user activates, the page will be reloaded. We can use sessionStorage to store information for this case.

Performance and Nitro

There is an excellent coverage of performance on iOS5 on Blaze.io blog, so I will not get deeper in this topc. Performance on HTML5 is really improved, as well as some HTTP techniques for loading pages faster. After my testing I can now conclude that Nitro engine is now available on Home Screen apps and it’s still out of UIWebView (PhoneGap-like apps and pseudo-browsers such as SkyFire).

Conclusion

iOS 5 is in the line of HTML5 evolution but it still owe us some new features that are being added in other mobile browsers, such as WebGL, HTML Media Capture API, Device Network Information API and maybe a remote web inspector.

However, Safari on iOS is still the leader in terms of mobile browsers and it’s still the most important browser today to look at when developing mobile web experiences. However, be responsible and don’t create applications and websites that only works on Safari or WebKit.

What do you think? Are you happy with the new changes? Were you expecting more? Did you find anything else new? Feel free to use the comment area!

September 2011 was a busy month for the mobile web space. While we are still waiting for iOS5, Android Ice cream sandwich, new mobile browsers appeared in the ecosystem: Internet Explorer 9 for Windows Phone 7.5, Firefox 7 for Android and the upcoming Amazon Silk to be included in the new Amazon Prime tablet.

While the mobile space changes, there is one problem in the HTML5 world: the web community doesn’t fully understand the mobile world. That is why excellent resources such as Modernizr & Caniuse.com don’t have accurate information about the mobile web space and web developers should not rely on that information.

HTML5 is on everybody’s mouth but web developers have a great challenge: understanding mobile web space and guessing if an HTML5 feature has enough compatibility in the market to start using and testing with it.

That is why, while I was presenting at the great Breaking Development conference in Nashville, I’ve announced a new project: MobileHTML5.org.

Back in 2010 for my book Programming the Mobile Web, I’ve made a lot of testing over dozens of different mobile browsers. And that was the start for this new project.

And now I have a new big impulse for creating this site, a new upcoming book is now official: Mobile HTML5 to be published in early 2012 by O’Reilly Media, co-authored with Estelle Weyl, a great partner for this new project.

So MobileHTML5.org is the result of hours of testing over mobile browsers and I hope everyone can use and contribute to. This is just the start and I’m planning a bunch of new features for the following weeks, including: getting deeper in each API to understand differences between platforms; testing suites and code samples.

On July, 26th I’m doing a workshop at OSCON about jQuery Mobile. If you are there (or not) here you can download the files we are going to use there. It’s algo a very good time to present my new book jQuery Mobile: Up and Running, available un Early Access.

Download workshop files

Velocity is an excellent annual conference organized by O’Reilly about web performance (WPO) and web operations. This was my second Velocity as speaker and I’m really surprised how bigger the show is this year. I did a workshop about mobile web & html5 performance optimization and here you have my presentation.

If you attended my workshop in Santa Clara, California and you have a feedback about it, please use the official workshop page to give it. You can always comment here or send me an e-mail, of course. Thanks again to Steve Souders, the guy behind WPO (Web Performance Optimization) and Velocity co-chair for inviting me again to this great conference.

Full video of my conference will be available later!

As you may already known, iOS 5 beta 1 was released for registered developers and there was a presentation showing some of the new features in Safari. I’ve made the usual investigation to see what’s new and I find a way to show you what’s new in HTML5.

Nokia has just announced Symbian ‘Anna’, an updated version of Symbian^3 that will be shipped with new devices, such as X7 and E6, and will be available as an OTA update for other devices, such as N8 and E7. I’ve the opportunity to test the new updated browser and here are the results.

As you may know, Symbian is one of the main smartphone platforms out there. Of course, if you live in the US you may think I’m crazy. Outside US, Symbian still has a great amount of devices available and even with the future Windows Phone replacement, dozens of millons of Symbian devices are going to be sold in the next two years.

I’ve tested a Nokia X7-00 prototype device with the final version of the new Symbian Anna. If we see the website, “the new browser” is one of the key features. It’s funny to see that the announcement was done the same day as Microsoft showing the Internet Explorer 9 future browser for Windows Phone.

Symbian browser, as mentioned in my book, has a lot of history. It was one of the first mobile browser using WebKit as its engine. However, since devices like Nokia N95 (shipped before iPhone arrives to the market), the browser has not evolve as fast as developers wanted. It was WebKit, but it was far away in terms of standards supports if we compare it with Safari on iOS, Android Browser or other WebKit-based mobile engines.

You are waiting for my veredict, I know. Well… honestly, I was expecting more. The browser is much faster than before, but it still feels old compared to other smartphone’s browsers.

Here you can see what Modernizr has to say about this browser:

The features detected by Modernizr have some mistakes. For example, it does support SVG.

The new stuff

The key new features are enhanced CSS3 support and multi-window browsing. Without taking performance on the test, the Symbian Anna Browser add support for mostly every CSS3 feature on WebKit browsers, such as Android, iOS and webOS including:

• Gradients
• Transformations 2D
• Transitions
• Animations
• Media Queries

Talking about APIs and Graphic drawing, it supports:

• Canvas – 2D drawing API
• SVG (it was supported before)

The browser seems much faster than the previous version but it’s difficult to have an exact measure because I couldn’t test it yet on the same device.

HTML5, are you there?

We know that HTML5 is not a simple concept. It’s an umbrella for many, many different things. However, every browser shipped in 2011 needs to be HTML5-some-kind-compatible.

I can’t believe that a mobile browser released this year can be shipped without W3C Geolocation API support. It’s a basic API, a more mature standard than HTML5 and very simple to implement. So: Symbian Anna Browser does not support Geolocation.

In fact, it doesn’t support any HTML5 API apart from Canvas (2D drawing). Other great missing is video & audio support. You can still use Flash for video playing on Symbian browser, but video tag was a feature I was expecting for this release.

What is missing from the main HTML5 features available on other platforms:

• No Viewport support
• No Audio & Video tag support (the multimedia events seems to be there, but I couldn’t see a <video> tag working)
• No Application Cache / Offline storage mechanisms
• No Geolocation API
• No Accelerometer / Motion API
• No HTML5 new input types (even when Modernizr says ‘supported’, every input type uses the same text input with the same on-screen keyboard)

We can still access most of these features from the WRT widget platform (see Chapter 12). In fact, Symbian is one of the main platform supporting Home Screen widgets created entirely from HTML, CSS & JavaScript. But the lack of these features from the browser environment makes me feel strange about this new browser.

I believe Nokia has work to do in the next two years for the Symbian Browser. I hope a new update later this year will add more compatibility. BTW, I’m a Forum Nokia Champion and I have a lot of Nokia devices on my pocket’s history ;).

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.

ALERT: If you are in a hurry and don’t want to read the whole post, the answer is NO. I don’t believe it is a deliberate attempt to hinder HTML5/hybrid frameworks. If you want to know why, then read the post.

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 http://ad.ag/pjmamj 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 WebSheet.app

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?

Once more, we have an iOS update for iPhone, iPod and iPad: version 4.3. And like previous versions, I was playing with Safari, the native browser, to see what’s new for web designers and developers. And here are the results.

Last version (4.2) gave us new HTML5 stuff, like DeviceMotion API for accelerometer support and WebSockets for full-duplex server-client communication.

This version doesn’t give us big changes or new APIs. However, there are some minor (and core) changes to talk about it.

There is still no support for file uploads, Web Workers or WebGL. WebGL (3D canvas) seems to be there in the DOM with the WebGLRenderingContext constructor. However, I couldn’t find any way to initiate the WebGL engine, so I’m pretty sure it is currently disabled by Apple.

Performance on Nitro

Safari gets its first big change at core level: a new JavaScript engine called Nitro. It is transparent for us, there is nothing new to do for having support for this new engine. With Nitro Apple claimed to improve JavaScript performance  up to twice as fast as in previous version.

UPDATE: Nitro engine seems to be available only in Safari (the browser) and not by embedding a UIWebView inside a native app, like in a hybrid app such as PhoneGap app or using any pseudo-browser, such as SkyFire. At least, in my tests this happens with every app compiled for 4.2 and for 4.3.

UPDATE #2: Nitro engine is also disabled on full-screen webapps added to the Home Screen. That is, not native webapps, using the apple-mobile-web-app-capable meta tag.

I’ve tested it using Sun Spider JavaScript Benchmark tool using the same iPad 3G with 4.2.1 and 4.3. The results seems promising: 8.2 seconds in iOS 4.2 vs. 3.4 seconds in iOS 4.3. That is near a 2.5X performance improvement!.

SunSpider running on the same iPad with 4.2 and 4.3

I’m not the only one doing this benchmarks, look at this ZDNet Article.

HTML5 video and AppleTV

This version of the OS supports AirPlay, that is the ability to stream multimedia content to our TV through AppleTV. Our HTML5 content can also make use of this ability through a new attribute applied to the video tag: x-webkit-airplay with value “allow”, for example:

<video src="" x-webkit-airplay="allow"></video>

When this attribute is there and you actually have an Apple TV (with an updated firmware), the player will show a new icon over the video player to start the streaming. The attribute also supports the value “deny”, acting as the default value for the player. This attribute also works for the non-HTML5 embed tag. I’m not really sure why it is denied by default as this seems to be an useful feature if you have an Apple TV for all videos.

This is how the player looks when streaming the video to the TV:

CSS Variables

On the CSS side, Safari for iOS 4.2 made available in the DOM the variable rule (had anyone notice it?). A variable rule is a non-standard way to declare variable values in CSS (pretty cool!). But I couldn’t make it work on real code. Don’t get too excited about it: the support for this feature was finally removed in iOS 4.3.

The CSSRule is a JavaScript interface available in WebKit that shows every CSS rule available as object constants, for example: CSSRule.FONT_FACE_RULE. In 4.2 CSSRule.VARIABLES_RULE was there and now it’s gone.

Other changes? Let’s submit our requests

I’ve made a research over the DOM and the CSS variable rule removal is the only visible change between Safari iOS 4.2 and iOS 4.3.The WebKit engine seems to be the same: 533.17.9. So no more big news for now.

At the Mobile World Congress I have met one of the guys behind Safari on iOS, I’ve talked with him about Safari new features. Of course, he can not talk about future versions. But I would like to highlight one thing: he recommends all the developer community to fill a New Feature Bug Report for new features/abilities that we want to have on the browser. They really look at them and if many developers want a new feature, they will seriously think about it. (forget about Flash Player for now ;) )

What HTML5/CSS/JS feature do you want to see in next versions?

I want to start my list with:

• A meta tag to force an orientation mode or at least, to force orientation lock (useful for HTML5 games and DeviceOrientation API apps)
• File uploads, at least from the gallery (as the UIImagePickerController available on the native side).

What do you think? Leave your comments!