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.
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.
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.