Slashdot Mirror
Has the Native Vs. HTML5 Mobile Debate Changed?
itwbennett writes: The tools available to developers who need to build an application once and deploy everywhere have exploded. Frameworks like famo.us, Ionic, PhoneGap, Sencha Touch, Appcelerator, Xamarin, and others are reducing the grunt work and improving the overall quality of web based mobile applications dramatically. The benefits of a build once, deploy everywhere platform are pretty obvious, but are they enough to make up for the hits to user experience?
For 99% of the applications out there, there's no reason not to do it in the browser if you're starting from scratch today. Most (useful) mobile apps simply display remote content in a way that's contextually relevant to the moment (Yelp, shopping (ordering and product reviews), *Maps, news sites, social media, etc). There's no reason for any of those to be app based. Most apps that aggregate content are poorly designed and not updated frequently. Couple that with the fact that most do not have useful offline modes (the only reason to have an app for content, IMHO), it just makes sense to optimize for the mobile browser rather than spend all the time and effort on an app. Hell, even most games I play casually have no reason being written as apps any more - any word game or puzzler would work fine in the browser.
Instead, put the effort into good mobile design and development practices. Hire good developers to optimize for JavaScript. Hire good developers to optimize your backend operations to reduce latency. Find what features are missing in HTML/JavaScript (e.g., a good client side persistence layer) and encourage the browser vendors to improve there so everyone can benefit.
For context, I develop complex scientific software. We use the browser (desktop) as our client and push the limits of what you can do there. Mobile is not far behind and should be the first choice for new development.
-Chris
Dunno... I've seen where a well-built common UI framework (Qt specifically) can make cross-platform not only easier, but improves the UI beyond the OS it rides on, and more importantly, provides a consistent user experience for those who do switch between platforms.
A perfect example of this is in desktop CG applications (...like this one, ferinstance.) In this case, there are no real OS-specific strengths that your UI would even need to care about. In the case of cross-platform CG apps, a professional artist can use the Mac version at work, the Windows version at home, and not have to care about interrupting his workflow because of UI inconsistency.
Now on the mobile side, this becomes even more important I suspect, with a not-insignificant number of folks swapping between platforms every year or two... your app remaining consistent between them is kind of important at that stage. For anything cute/unique that you want to add or remove for a specific platform, I suspect that case statements (or equivalent) would take care of that, no? It would at least allow you to keep it all in one codebase if nothing else. You just have to know what you're doing when you build it, and be sure that the underlying language is equally cross-platform (in the above example, C++ is the weapon of choice).
Besides, the only way you really would be able to commit to tight hardware integration would be the case of iPhones - it'd be the only platform where you could expect a consistent and relatively limited variety of hardware specs and features across all users - a condition you'd never see with Android, WP, or even (heh) Blackberries.
Quo usque tandem abutere, Nimbus, patientia nostra?
If only it were that easy. The problems with cross-platform development are myriad. The LCD experience has already been outlined, so here are the others:
1) It's write once, TEST everywhere, and you can't debug the code you actually wrote -- only the specific translation of that code into native code. And that sucks beyond words. It can be incredibly time consuming to the point where it easily erases any time you saved in development. And the longer the lifecycle, the more of your budget this is going to consume.
2) On a related note, profiling and performance tuning is a bear. If you do anything that requires performance, cross-platform is the wrong way to do it.
3) The potential for bugs is twice as high, because now you don't just have to worry about bugs in the native SDK, but also in the abstraction as well. While the OEM can generally afford to test the hell out of their SDKs, cross-platform suites have much less resources at their disposal. And it shows.
4) You are always playing catchup. New features take longer to implement, because you have to wait for the third party to either implement the new feature, or to implement it right.
5) You're needlessly adding another layer of dependence. None of the "popular" third party platforms are anywhere close to guaranteed that they'll be around in a month, or 6 months, let alone 2 years from now. If your favorite library goes away, you find a new one and make a few changes. If your entire SDK goes away, you're fscked.
If your software doesn't matter at all, if it's just a hobby, has no business case, and you have no plans (or potential) for going commercial, then by all means, use whatever development tool strikes your fancy. Personally, I would never recommend that anyone use cross-platform tools for anything they plan to support indefinitely. Even for a prototype or an MVP -- too often the prototype becomes the codebase for the final software, despite prior assurances to the contrary. Don't waste effort developing something you can't build on, unless you have no other choice.
https://www.eff.org/https-everywhere
It's important to understand that the context of use for a mobile web page is different from that of a successful mobile app.
There are a bunch of dumb apps developed for online news sites - as though I'd ever want to go to just one news site, vs. have the mobile web spread out before me.
OTOH, good mobile apps do things that the mobile web doesn't or can't. Perform read/write operations on local data. Use local processing power - as much as is available. Access local sensors not available to mobile web. Aggregate data from multiple sources - perhaps blending web and local data.
Even apps that do nothing more than provide deep search - if the vertical market for the app is well defined (Movie geeks: IMDB, small investors: finance apps...), it's possible for a mobile app to excel over a web site by providing native gadgets and a platform native UI that doesn't have to leave room for the (admittedly minimal) mobile browser UI.
Finally, mobile apps can scrape a bunch more information from the user's device than can mobile web. Definitely a help in monetizing a popular vertical, if you roll that way.