▲ 49 points
back
14 comments
We make an app written as HTML5 CSS3. We made this decision because with limited dev resources it allowed us to write once deploy many. That is powerful. Our app required more testing than a native app, and less.
With a native app if you write your code for Version X of the OS you can be 99% certain that Version X.1, X+1, and X+1.3 are all going to treat it the same. With HTML5 "fixes" to the renderer can mean that what was working will stop working. Or stop looking like it used to.
With an HTML5 app you should be able to write once and deploy many, but Mobile Safari, and Mobile Chrome, that do the renderings on IOS and Android don't handle all JS and CSS quite the same. So you may have slight differences. Much less than you would have with ObjectiveC vs Java, but differences none the less.
PhoneGap makes much of the stuff you want to do with the hardware easier, but not perfect. If you want to send a Text, or make a call or access the contacts you will have to at least touch a plugin, if not write some native code. Most of the time you can just clip a snippet from someone else, but if you want to do anything awe inspiring you will have to still get your hands dirty with native code.
http://tldrstuff.com shows what we were able to do with a single UI Core across Windows Phone 8, Android, and IOS.
We hit all of the platforms, and had less code to change, but our app doesn't "Feel" native. We don't have a UI that looks integrated with the OS, but we have concistency across platforms. Was our decision "right"? Hard to say. We spent less resources which was a major driving factor so I say yes. Did it keep us from being Wavii or Summly? I hope not. But it is hard to say. I don't know if we traded dev resources for glory, or if we saved money we will want and need to be bigger than either.
Thanks for the interesting postmortem. I've been thinking along the same lines recently - HTML5 + app packager for teams with limited development resources, multiple parallel native apps for teams that handle it. Or native if you have some specific requirement that can only be met by native.
Fwiw, the Flat/Tiled/Metro design motiff seems to taking off enough that it's a satisfactory cross-device substitute for native.
Summly used it too; as such, yours doesn't look significantly different theirs, other than their use of transparency in places.
Maybe it was their mention of their use of genetic algorithms in their well-done launch video [1], and having a 15yr old founder, that did it for them. Of the Three T's they nailed two - team and technology. Attention, interest, and Traction were sure to follow.
A few years ago Adobe open sourced flex http://flex.apache.org/
This is an "write once, deploy many" that has a bit different offering then html5, specifically, it deploys natively, allows offline usage, can be set up to use native ui elements, has a gpu accelerated animated vector engine available, etc.
I really like Flex. It's supposedly flowed and buggy and abandoned though.
Yet I can easily write a dozen lines of code with my 1990s GUI knowledge that display 20,000 items in a sortable table and work at full speed in any browser -- while having endless performance problems/memory leaks when using HTML and various "data tables" plugins.
Maybe in 10 years we'll have something that will let you build a GUI right in the browser and will work cross-browser properly.
I don't think there's a good reason such a distinction exists. You have ChromeOS and FirefoxOS, which prove that web applications given access to system APIs are just as capable as ObjectiveC and Java. But there's still a "web" vs "native" distinction. Why can't Android or iOS launch a "web" application with JS having access to privileged API and HTML/CSS simply rendering the UI? When did we decide to build worlds where your programming language dictates whether your application is "real" or not?
ChromeOS is a strange choice, because of the box, ChromeOS is not especially capable. That's why there's interest in tools like Crouton.
What distinguishes native apps is not whether they are rendered with HTML (many native apps use HTML rendering for parts), or whether they have access to privileged APIs, but instead whether they conform to the behaviors and conventions of the platform. Getting that conformance requires using the APIs the platform gives you - you cannot adequately copy it, as Java Swing has proven.
For example, Light Table fits your criteria: it's a double clickable .app file with access to privileged APIs, with HTML and CSS rendering the UI. But it's obviously not a native app, and will never feel like one.
Note that I didn't say "real". Light Table is certainly a _real_ app. But the distinction is inescapable: it's impossible to miss the fact that Light Table is non-native.
Not all Android APIs make sense in a Web browser. How does one implement an AppWidget, or violate the browser sandbox with a remote API?
Different runtime environments and different OSs have real differences. For some apps those differences don't matter. For others, they can make the difference between useful functionality and a pleasurable UX and a dull trudge through interactions that don't benefit from native platform capabilities.
Maybe Web apps will find their highest expression in OSs that feature Web runtimes. Java was supposed to be "write once, run anywhere" but, for interactive apps, it only became popular once Google wrote an OS and class library specific to that Java OS.
It is a one word explanation to users asking why their app is slow/drains battery/doesn't feel like other apps.
I think the "functionality" axis doesn't work. One could argue some high-value enterprise Web apps are more "functional" than Facebook Home, but that does nothing to capture why it is appropriate for the Web app to be implemented that way and why it is preposterous to suggest Facebook should be done in HTML5.
The importance of power consumption, fine-grained interactivity, the need to fit non-browser concepts in user experience such as AppWidget in Android, the desirability of sync vs. CRUD-over-IP etc. are among the decision points for choosing one or more client implementation approaches.
Then there is the fact that most high-value apps do not have a single answer for implementation approach, and that these high value apps were not born that way. When Facebook turned away from making mobile Web apps, they did not also start making native desktop clients.
This is how I would boil it down: Is your app valuable enough to be worth spending enough on a mobile client implementation than can do things a Web interface cannot do? That is, for a minimum viable product, you probably need to do almost everything your Web interface does, but in order to really justify the effort, you should, at least, have a road map to some place where the mobile app exceeds what the Web app can do. This might be as simple as notifications and an AppWidget. But preferably it's something app-specific.
I have good experiences with writing HTML5 "apps" for phones and tablets. But the common factor is that they're not very advanced, just a website with some interactivity. If I were to make something advanced, like Facebook with chat, tracking, uploading/sharing etc. I'd reconsider my choice, though.
Exactly. Right tool for a right task. No hype.
From our experience to develop the mobile app with HTML5/Javascript/CSS i.e. Cordova, not only that the mobile safari in iOS and webkit in Android sometimes not render js/css the same ( the point brandon_wirtz has raised), but another difficulty we found very hard is to debug the javasript (js that resides in the device, not on the server side) .
in iOS it's okay we could connect device/simulator and open the safari inspector to debug. But in android it's almost impossible to know what & where the javascript has gone wrong and fix.
The webkit in android 2.3.x version also will render differently on some css properties compared to 4.x version.
On a related note: "No, I'm not going to download your bullshit app": http://tommorris.org/posts/8070
Appcelerator Titanium is not a cross-compiler. In fact, you missed this entire category of "native" apps. They embed actual Javascript interpreters in your app to run your Javascript. They provide bindings in Javascript to native APIs so you can call native code via Javascript.