Will PhoneGap apps seemingly suck because of UIWebView in iOS 4.3?
So Blaze Software made some headlines touting that in a recent browser speed tests, Android was faster than iPhone by a fairly large margin. Apple said non-sense, because you didn’t use Safari in your tests. Blaze put a UIWebView control in an app and used it to do the tests. Which opened up another can of worms.
UIWebView is what is used on Apple platforms like the iPhone by some developers who create iPhone / iPad apps. With the latest update to iOS, there are reports that HTML5 and JavaScript apps are running significantly slower when they’re run from the iPhone or iPad home screen.
So right now there’s a debate raging about browser performance. Some people claim this is fan boy stupidity of the highest order because who cares if a page loads 600ms faster on one platform versus the other. Others point out that this is very important because those 600ms will add up with HTML based apps and those that use a lot of Ajax. Which brings us to our headline.
The Register in the UK is reporting an exclusive on this. In the article, they quote a mobile web app developer (who requested anonymity) as saying:
“Apple is basically using subtle defects to make web apps appear to be low quality – even when they claim HTML5 is a fully supported platform,”
That’s a pretty serious accusation.
If you have an app that uses UIWebView and the user puts in on their home screen, the app will appear sucky according to this article. Or at the very least, Apple is being very slow to fix an obvious bug.
Basically, PhoneGap developers are getting no Nitro Love. So you want your UIWebView app to be popular, but not so popular that the user puts in on their home screen next to other apps.
Apparently, there are two JavaScript engines according to one blogger quoted. One for the Safari browser and one for non-Safari browsing.
“Essentially, there are two different JavaScript engines,” says Alex Kessinger, a mobile application developer and blogger who has focused on building web-standards-based apps for the iPhone. “They’re not using the new JavaScript engine with applications that launch from the home screen.”
If this turns out to be true, platforms like PhoneGap could suffer greatly. PhoneGap is an awesome tool that lets developers write mobile apps using technologies like those mentioned above (HTML5 and JavaScript). In fact, my good friend Josh over at EvolvingWe has a popular app called GoodDay that he wrote with PhoneGap. He’s also doing a cool set of training videos called OneDayApp that you can get more info about here if you are interested in creating your own iPhone app.
My friend Ken, at Twin Engine Labs, told me he would only recommend going native when doing app development. That all the time you save using a cross platform tool are lost due to market place integration issues, problems with updating your app, and being beholden to a third party to ensure delivery of your app. Twin Engine Labs has created some awesome stuff, and are getting tons of press and were recently on the SXSW Startup Bus.
I respect both of these guys immensely, so you’ll have to decide for yourself which direction you wish to go.
My advice? If you want to create an app for fun or prototyping, PhoneGap might be a great tool to check out. If you are wanting to write apps professionally, however, you can avoid all of this mess by just writing the app in Objective C; the native language iOS applications.
I believe native is the best long term strategy.
So what evidence does the Register present to support the claim of Apple slowing down web apps in their latest edition of iOS? Compare these two screenshots below. The one on the left was run on an iPhone 4 loaded with iOS 4.3. Sunspider took about 4047ms to run. Meanwhile, running from the home screen took about 10747ms.
The Resister points out that Apple isn’t degrading the speed of home screen web apps. Instead, it’s boosting the speed of web apps in the browser.
On top of this, in iOS 4.2 caching was cut off. That feature let your app run in “offline” mode. Nor do they use Apple’s newer “asynchronous mode”, but have to stay in the “synchronous mode” sandbox. This means they don’t quite look as good.
Although Apple has not responded to multiple requests for comment by The Register, they are apparently aware of all three issues.
Apple has the bugs on file according to the developer forums. However, if your app is out there in the app store and someone installs right now and it runs incredibly slow; will the user chalk that up to a bug in the Apple operating system or will they think your app sucks and uninstall it? The answer is so very, very obvious.
Here’s the rub, folks.
If you want to create iPhone apps, make sure your app runs native code. You’ll avoid a lot of headaches and heartache. Take the time to invest in yourself to learn how to do this. Ken gave me this advice when I was just starting out, and when I see stories like this I’m thankful he took the time to give me guidance.
The new reality moving forward will be Hybrid Applications and HTML5 in a webview and a plugin aside can be used to tap into native platforms. There should be no need in these modern times to go back to an early 90s Objective-C language. Todays mobile world is bigger than Apple and I refuse to be walled into their crap!