I don't normally go so aggressive with a title, but this statement made me see red:
"If you plan to write an app for iOS or Android, you will save time and create a better product if you stick to Objective-C and Java, respectively."
Go to the iTunes store, download Jetpac for your iPad, and tell me whether you think it's native or HTML5. Guess what, it's heavily reliant on web code! Facebook's iOS apps take the same route, and in fact I'd recommend anybody with an 'always-online' app seriously consider the same approach.
Funnily enough, I agree with a lot of Benjamin's points about the costs of an HTML5 approach to app development. There's a lot more to creating a real app than pointing a native web view at your site, and that gets lost in the hype. What he misses is how much of a development tax you're paying when you're writing native code.
Designing in Interface Builder
"Remember web development in 2004? When you had to create pixel-perfect comps because every element on screen was an image?" I spent five years at Apple writing desktop applications, and I'm still often baffled and confused by Interface Builder. The whole process of creating native screens is an order of magnitude harder for designers, and not much better for developers. Just being able to preview the design in a web page and tweak the CSS live through Firebug is a massive time-saver.
Forgiving languages
Objective C is finally starting to offer automatic memory management, but you'll still have to worry about buffer overflows and all sorts of other low-level details. Java is better, but not by much, and both require static typing. Modern languages like Ruby and Javascript are a lot more forgiving, and I've found that makes development faster and doesn't seem to introduce more bugs. Again, building Jetpac in a combination of server-side Ruby and client-side Javascript got us to market a lot quicker than we'd be able to manage with a native approach. Just as one example, I forgot a retain on a single string in the little native code we do have, and that caused an intermittent crash that put our launch back a week.
Debuggable
Being able to remotely inspect a web view makes a world of difference to debugging. If you keep your app runnable in a desktop browser too, the tools for stepping through code are superb, and in a lot of ways they're now superior to something like XCode. The amount of documentation and community answers from places like StackOverflow for common problems is much larger for the web world than native code, which also is a massive help for resolving bugs.
Extendable
JQuery and Ruby's gem system are incredibly powerful. When we needed an autocomplete text box, grabbing a jquery plugin was simple. Need support for Amazon S3 interaction? We could just grab a gem. The development community behind these technologies is far larger than that for native development, so you're a lot more likely to find an off-the-shelf solution to your problems.
Slow Deployment
We built up a whole set of useful practices around long installation cycles. In a lot of ways I still miss the extended stages of QA that were required for apps that shipped on physical media. The catch is, while you could theoretically do the same thing with an app that's served directly off a website, the disadvantages are so much larger that nobody does! I love being able to fix bugs and solve user problems immediately, and the iteration cycles on new features are much, much faster than anything that requires waiting on Apple's approval process.
Don't believe the hype
We still had to work hard to support hardware-accelerated scrolling and native-feeling swiping, but going HTML5 was definitely the right decision for our app. Is it for yours? I don't know, and neither does Benjamin. As always in engineering it's all about tradeoffs, and no alternative to researching how the drawbacks and advantages of each approach fit your unique requirements. Just don't believe anyone who tells you they know the One True Way to develop for mobile, on either side.
Comments