Some thoughts on PhoneGap
Today, I’ll post in english to reach a bigger audience with this post. I want to tell you something about the experiences I had while developing two Apps using PhoneGap as a bridge between JavaScript and native device APIs. As this is my opinion based on the pain I felt while working on those two projects it may not reflect your very own experience with PhoneGap, but to keep it short: using PhoneGap sucked hard and I still feel the pain in my ass.
As we decided to use PhoneGap our decision was based on three key points:
1. The app would be developed using web-technologies, so we would be able to reuse existing knowledge in HTML/JavaScript/CSS
2. Porting it to other platforms would be easy as pie (actually we had to support BlackBerry, iOS and Android in one of those projects)
3. Everybody in our “web department” could apply changes to those apps without learning some other programming language like Objective-C or Java
What’s PhoneGap
As I wrote in my introduction, PhoneGap exploits native device APIs like the Accelerometer API, GPS API, File/IO APIs to JavaScript so you can develop apps for mobile platforms without learning a platform-specific programming language. This is achieved by wrapping HTML/JavaScript/CSS into a native WebView of the target platform. This “wrapper” is everything that makes this app native, you’re not required to write a single line of native code – all the logic, animations/transitions, input handling et cetera is written in JavaScript.
JavaScript vs. Native code = Ferrari F50 vs. Bicycle
This is where the first problem comes in: JavaScript is slower than native code. This is not caused by PhoneGap and I don’t blame it for that – it’s just a general issue so no minus for this. But if you have to handle large sets of data like we had to, it kills the overall performance of your app and – most important – the user experience, leading to bad AppStore reviews and unsatisfied customers. Maybe we can optimize the JavaScript but we already cutted out all unneeded JavaScript operations and outsourced any possible task to the backend server of the App.
Starting at 0
If you start designing an iPhone App you want to have all that animations that users are used to from other iOS Apps – like the animation when navigating through UITableViews that are inside of a UINavigationController or the fixed positioning of the UINavigationBar. You don’t have such animations or even fixed positioning in a UIWebView when you develop using PhoneGap.
You now have these options to get this job done:
a) Use a 3rd party JavaScript framework that includes support for animations and the native scrolling or, if you just need animations you can use CSS3′s properties to have animations between views
b) Rewrite everything from ground up
Option a) sounded good to us as we would not have to rewrite most of the stuff and used iScrollJS for native scrolling and CSS3 for animations/transitions.
Using a JavaScript library for native scrolling looked cool in the iPhone simulator, but on an acutal device (iPhone 3G and iPhone 4) it turned out not to be that cool anymore, so we removed it and used the native browser scrolling. No fixed positioned navigation bar anymore.
Now the UIWebView got in our way: It parses the website not at once, it just parses the visible area which gives it a performance boost, no doubt about that, but if you scroll through a long list it looks bad when you see unrendered parts of your “App” as a blank space…
The evil three: Images, CSS gradients, transparency
As our layout included transparent list items, gradients on buttons and preview images in the lists (no, removing preview images was not an option) we already had three performance killers: CSS gradients, many images and transparency.
These three things are so bad for the overall performance that you can not talk about a usable App anymore. So think about this when designing your App in Photoshop or whatever tool you use for this task. The performance was so bad, that we cutted out transparency and gradients. Now our App does not look that nice anymore, but it’s a bit faster.
Summary
PhoneGap is a nice way to prototype an App and to test different navigation concepts fastly, but it’s not a good option if you’re developing Apps for a real customer that expects a A+ product. And they are right, they pay you a lot of money for that, but a WebApp wrapped up in a native WebView does not perform good enough and – in my hones opinion – do not deserve to be called an App, they should stay in the web browser.
Because at the end, the customer does not care if it was developed using Objective-C, Java or whatever programming language/scripting language – they want an awesome product.
P.S.: I’ve tried to cover every aspect that came across during the development but maybe I’ve overseen some points.
If you want to know more about specific issues or bonus points regarding PhoneGap -> please comment and I’ll update the post or provide you more information covering this topic.
