Rafe Colburn on the Nitro Thing in iOS 4.3

post from Daring Fireball on 17 March 2011 10:04:04 PM. © Daring Fireball

A clarification I neglected to make in my piece on it earlier today:

Web apps running from home screen but not in full-screen mode(which launch inside Safari) run Nitro fine.
Web apps running from home screen in full-screen mode launchinside Web.app, which is a system app and in theory should beable to run Nitro but it?s not because it lacks theentitlement.

So, yes, it’s only those web apps which invoke the special markup syntax to run in full-screen mode that are affected by this. Home screen web apps that open inside Mobile Safari do get Nitro (and all other Mobile Safari performance optimizations). As for why Apple couldn’t/didn’t allow full-screen web apps to get Nitro in iOS 4.3, I don’t know.

?

Read The Full Article:
http://rc3.org/2011/03/15/is-apple-intentionally-crippling-web-applications-on-io
s/

Digg this

If I Could Have Linked to This Tweet a Few Hours
Ago, It Would Have Saved Me a Lot of Typing

post from Daring Fireball on 17 March 2011 09:04:32 PM. © Daring Fireball

Mark Pilgrim:

Wait, so the big conspiracy is that Apple made their browserfaster? We should all have these problems.

?

Read The Full Article:
https://twitter.com/diveintomark/status/48512225597591552

Digg this

WebKit2 and the Split-Process Model

post from Daring Fireball on 17 March 2011 08:04:26 PM. © Daring Fireball

Still in development:

WebKit2 is a new API layer for WebKit designed from the ground upto support a split process model, where the web content(JavaScript, HTML, layout, etc) lives in a separate process fromthe application UI. This model is very similar to what GoogleChrome offers, with the major difference being that we have builtthe process split model directly into the framework, allowingother clients of WebKit to use it.

After publishing my piece today on why the Nitro JavaScript engine isn’t available system-wide in iOS 4.3, several readers reminded me of the in-progress WebKit2 project. Surely, this will eventually come to iOS, and when it does, it solves a lot of problems for Apple. I think iOS 4.3 granting Mobile Safari an exception to the rule against marking pages in memory executable is a stopgap.

?

Read The Full Article:
http://trac.webkit.org/wiki/WebKit2

Digg this

Post-Production Community Celebrates 10th
Anniversary of NAB SuperMeet

post from prMac on 17 March 2011 06:14:00 PM. © prMac

Celebrating its Silver Anniversary, the annual NAB SuperMeet, now in its 10th year, will be held at Bally's Hotel Event Center (Las Vegas, NV) on Tuesday, April 12, 2011. One of the largest gatherings of Final Cut Studio(R), Avid(R), Autodesk(R), and Adobe(R) editors, HDSLR filmmakers and digital content creators, and gurus on the planet, the NAB SuperMeet provides an open forum for the discussion and presentation of the latest trends in the ever-evolving post-production and broadcast markets.

Read The Full Article:
http://prmac.com/release-id-23127.htm

Digg this

How Does a 5 Yr Old Make A To Do List Faster Than
You Without a Keyboard

post from prMac on 17 March 2011 05:19:00 PM. © prMac

Right Brain Solutionz LLC has released iCondu 1.0 for iOS. iCondu is a new innovative way to create and manage your Daily To Do lists, your contacts and a ton of other data on your iPad. You can even create and review your Dreams/Goals quickly in a visual way. People want a To Do List App to be easy and fast, so that means minimal use of the keyboard. It also means, making it intuitive so you don't have to stumble through menus and pages to make a quick or extensive data filled To Do List.

Read The Full Article:
http://prmac.com/release-id-22976.htm

Digg this

Why the Nitro JavaScript Engine Isnt Available
to Apps Outside Mobile Safari in iOS 4.3

post from Daring Fireball on 17 March 2011 05:05:06 PM. © Daring Fireball

Along a similar line to today’s story about the performance differences between Mobile Safari and the system-wide UIWebView control in iOS 4.3, was Tuesday’s mini-brouhaha about web app performance outside Mobile Safari. The Register, as usual, sensationalized it best, in a story headlined “Apple Handcuffs ‘Open’ Web Apps on iPhone Home Screen”:

Apple’s iOS mobile operating system runs web applications atsignificantly slower speeds when they’re launched from the iPhoneor iPad home screen in “full-screen mode” as opposed to in theApple Safari browser, and at the same time, the operating systemhampers the performance of these apps in other ways, according totests from multiple developers and The Register.
It’s unclear whether these are accidental bugs or issuesconsciously introduced by Apple. But the end result is that, atleast in some ways, the iOS platform makes it harder for web appsto replace native applications distributed through the Apple AppStore, where the company takes a 30 per cent cut of allapplications sold. Whereas native apps can only run on Apple’soperating system, web apps — built with standard webtechnologies such as HTML, CSS, and JavaScript — can potentiallyrun on any device.
“Apple is basically using subtle defects to make web apps appearto be low quality — even when they claim HTML5 is a fullysupported platform,” says one mobile web app developer, who askedthat his name not be used.

The clear insinuation is that web apps running outside Mobile Safari have been made to run slower, but that’s not true. What happened with iOS 4.3 is that web apps (and JavaScript in general) running inside Mobile Safari have been made significantly faster.

The Nitro JavaScript engine is only available within Mobile Safari. Outside Mobile Safari — whether in App Store apps using the UIWebView control, or in true web apps that have been saved to the home screen — apps get iOS’s older JavaScript engine.

Put another way: nothing is slower regarding web apps or web page rendering in iOS 4.3 compared to 4.2 or earlier. If anything, everything is at least a little bit faster. But: the most significant performance improvements in iOS 4.3, particularly for JavaScript, are exclusive to Mobile Safari.

The obvious question: Why? The cynical answer is that Apple seeks to discourage the use of home screen web apps. But if that were the case, why don’t apps from the App Store get Nitro, either? Many, many App Store apps use embedded UIWebView controls for displaying web content.

The real answer is about security. Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation. Here’s Wikipedia’s page on JIT. A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and Android¹. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently readonly first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.

Apple, as of iOS 4.3, trusts Mobile Safari enough to allow this. The upside is that Mobile Safari is now significantly faster. The downside is that any security exploits against Mobile Safari now potentially allow worse things to happen.

Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control. (That’s why they show up individually in the task bar, just like apps from the App Store.) Home screen apps may well eventually get access to the Nitro JavaScript engine — Apple simply hasn’t yet done (or perhaps finished?) the security work to allow it.

One way Apple could make Nitro available system-wide in iOS would be to do something similar to what they’ve done with web content plugins (like Flash Player) on Mac OS X: execute JavaScript in a separate (trusted) process that maps back to the host app. On Snow Leopard, Flash Player no longer executes within Safari; instead it gets its own process. Similarly, Apple could introduce a dedicated Nitro JavaScript process that executes JavaScript for any app, rather than executing within any app. I have no idea whether this is something Apple is considering or working on, I’m just saying it’s one way they could off JIT compilation to apps system-wide without allowing most processes to mark writable pages in memory as executable.

In short, iOS was designed from the ground up to be more secure than Mac OS X. The price for this trade-off is performance.

Note too, that Nitro isn’t new. The WebKit team first announced it (then known as “SquirrelFish Extreme”) back in September 2008. That it took until now to show up at all on iOS is an indication of how complicated these security implications are. That Nitro’s availability on iOS is limited to Mobile Safari today does not imply that it will always be limited to Mobile Safari.

I’m actually not 100 percent sure that this is true for Android, but my understanding is that every app on Android is running in a JIT. That’s how the Dalvik virtual machine works — and the use of a JIT is the reason why recent versions of Android have performed significantly better than previous ones. I don’t see how they could be using a system-wide JIT if the Android OS disallowed processes from marking pages in memory as executable. But if I’m wrong about this, let me know. ↩

Read The Full Article:
http://daringfireball.net/2011/03/nitro_ios_43

Digg this

Mewshop's Red-Hot Digital Cinema and DSLR
Workshop Returns

post from prMac on 17 March 2011 04:09:00 PM. © prMac

Manhattan Edit Workshop (Mewshop), the cutting-edge authorized digital training destination for post-production and content creators, is pleased to announce the return of its wildly popular training workshop, Digital Cinema/DSLR Fundamentals fromom March 25 - 27, 2011. Students of all levels can immerse themselves in three unforgettable days of the latest techniques in shooting, accessories, and proven workflow solutions in Digital Cinema and DSLR filmmaking.

Read The Full Article:
http://prmac.com/release-id-23126.htm

Digg this

Study Comparing Android to iPhone Web Browsing
Speed Flawed

Jim Dalrymple:

One of the biggest surprises the Blaze team found was that?despite significant JavaScript performance gains in the latestApple iOS 4.3 release and Google Android 2.3 releases, theseimprovement made no measurable improvement on the actual page loadtimes of the sites tested.?
There is a good reason for this. According to Blaze?s owndocumentation the ?measurement itself was done using the customapps which use the platform?s embedded browser. This meansWebView (based on Chrome) for Android, and UIWebView (based onSafari) for iPhone.?

Right. The problem with Blaze’s entire study is that they didn’t test what they claimed to be testing. They used custom apps for iOS and Android, but claim the results show that Android’s browser is faster than iOS’s Mobile Safari. Instead, their results show that Android’s WebView control is faster than iOS’s UIWebView control. Mobile Safari is not just a thin wrapper around the system’s UIWebView control — it has its own caching system, its renderer uses asynchronous multithreading (UIWebView does not), and, as of iOS 4.3, Mobile Safari uses its own much faster JavaScript engine (“Nitro”).

That’s not to say it isn’t interesting that Android’s WebView for apps is faster than iOS’s UIWebView for apps, but it just isn’t true that these results are indicative of anything regarding Mobile Safari’s performance. It’s easy to see that Mobile Safari is faster than UIWebView — just run something like the SunSpider benchmark twice, once in Mobile Safari and once in any app from the App Store with a web content view. On my iPhone 4, Mobile Safari runs SunSpider almost three times as fast as an app using UIWebView.

These Blaze guys are either incompetent or dishonest attention seekers, given that they claim this, in an update to their report:

Some wonder whether the new Nitro JavaScript engine was used inour measurements. We?re still investigating this issue, as thereport was completed before it was made known. So far we?ve seenindications in both directions, so we can?t say for sure it?sbeing applied.
That said, the results from measuring Android show that JavaScriptonly accounts for a small percentage of the total load time, about15% on average. This implies that even if Nitro is not in use, itlikely can only slightly narrow the gap. We?ll follow up withany additional info.

Because the thing is, Nitro isn’t the only difference Mobile Safari’s rendering and UIWebView’s rendering. Mobile Safari has better caching and asynchronous multithreading, too.

?

Read The Full Article:
http://www.loopinsight.com/2011/03/17/study-comparing-android-to-iphone-web-brows
ing-speed-flawed/

Digg this

Panic: Lets Help Japan

Cabel Sasser:

Panic will donate 100% of today?s proceeds directly to theJapanese relief effort.
It doesn?t matter if you buy direct from us or via the Mac AppStore, we?ll take care of it. We?ll total up sales from 10:00AM PST Mar 17th to 10:00 AM PST Mar 18th. And we plan to donateto a mix of the Japanese Red Cross Society and Portland?s ownMercy Corps.

?

Read The Full Article:
http://www.panic.com/blog/2011/03/lets-help-japan/

Digg this