- Native apps take a lot of time to build, especially when you are a web-developer without in-depth knowledge of the extensive frameworks available to the native platforms.
- Wrappers work, but are not nearly as great and snappy as native apps; They might contain a lot of hard to fix bugs as well and are harder to debug if they tend to crash.
- HTML5 only apps are not available in the market/store so no free advertising, you can't access things like the camera with HTML5 only, you therefore need a wrapper.
My vote goes to native development; Although it's more work and code to write it's much faster and stable if done correctly. You've got more freedom and bugs can be solved. A native app just feels right, where a HTML5 only app won't give you the best user experience you can get, no matter how much time you put into it. If you need a flexible, big, cross-platform app without a lot of budget to build at least 2 native apps a HTML5 app with wrapper would be a decent option, but for anything else (especially the more simple apps with just 2 or 3 different views) you should go with native.
True, just as writing in any language you're not familiar with will take longer.
For even a semi-experienced iOS/Android developer, it can be faster than writing an HTML/web app.
My experience with Titanium is that you code in js or Alloy, then when building and deploying, you get native code, with native elements and everything.
Comparing it to PhoneGap, which purely runs in a slowish WebView isn't quite fair I think. Or has your experience been different?
Oh, and yes, it is 'cross-platform', except for the fact that there are so many things not working on Android (either bugs or non supported in the API for Android) that you need a seperate build for android to make it reasonably useful.
This is al based on my experience with Titanium Mobile from around 2 years ago, so it might be better now.
I'd rather have Grand Central Dispatch, CoreGraphics, CoreAnimation, etc. all at my disposal. Using Titanium felt very restrictive. Their API is a one-size-fits-all between iOS/Android/etc. As soon as you want to step out of that least common denomination, you've got to write native modules. Which, if the people on your team don't know native development, can be a problem.
You have to get in a kind of different mindset than with HTML, where you use div's for everything - here you create windows and views - but shouldn't take more than a couple days to get dangerous with it :)
There's a few quirks though - differences between iOS/Android for a small number of things, when coding, which can take up a lot of your time to troubleshoot.
An example of such an issue can be on Android, an imageView which you've applied rotation to, suddenly appears to be not rotated, if you put a backgroundColor on it as well as rounded corners. The fix here could be to use a regular view instead, and use a backgroundImage. Thankfully those kinds of weird things aren't as plentyful any longer, the company behind, Appcelerator, are in my experience pretty helpful and fast with bugfixes.
What do you mean by this? That doesn't match my understanding of the current state.
where exactly does the cut off line exist? native/html5 is kinda gray.
Just a small point of clarification, you can access the camera on Android using the Camera API. You can access accelerometers / gyroscopes and location in both Android and iOS.
(1) Access to low-level and platform-specific features. Whatever I do, I always eventually need it as program gets specialized, and always be frustrated on non-native platforms. Usually cross platform stuffs lack this or needlessly painful even they offer it. Also you still have to write platform specific code even they support it. (2) Freedom of development. From native, it's relatively easier to build up HTML5 stuffs on top of it. (or whatever…) So I still can utilize HTML5 stuff if I really need it. Reverse is mostly impossible. (3) (Though that's arguable, what's native?…) Compatibility. Native development on C/C++ level always offer best compatibility. There's no computing platform doesn't support C/C++. Emscripten extended this even to HTML5. HTML stuffs are available only on browsers and a few specialized platforms. (4) Legacy. I always discover a mostly ideal implementation exists on native platform where HTML5 people are making efforts to bring. This includes better toolset for code writing and debugging. (5) Future. (I imply HTML5 == markup+CSS+JS). No serious major browser vendor really loves HTLM5. Because that limits their platform features. That's why they're adding WebGL and C/C++ support or whatever non-HTML stuffs from native world.
Does that include Android devices?
Also with native you have access to the full device api such as sensors. HTML5 is closing the gap, but Native increases the gap every few months.
Mind the gap.
2. Use Page Visibility API to throttle app.
I'm frankly just unclear on why so many of us are answering the question "What works...?" when clearly the question is "Which do you PREFER?"
There was a post (by sencha, iirc) where they brag how they managed to make html version of FB faster. I was reading and shaking my head: you get all that ingenuity out of the box with native. Two lines of code: register the class/nib for reuse and dequeue cell when needed. Hook in NSFetchedResultsController and there you have it: extremely fast and memory efficient solution.
Good luck replicating capabilities of autolayout with flexbox (with rotation support).
Good luck replicating capabilities of Core Animation with CSS/JS animations.
How about localisation? How about accessibility? How about getting anything like Core Data?
Meanwhile in HTML5 land the debate goes on what is the best way to deliver responsive images.
Where does this notion, that mobile apps should be developed with web technology comes from? I don't see similar push for desktop apps. Is this all just because of all the web devs seeing the increasing usage of smartphones and proclaiming that html is the better way, because they are too lazy even to investigate what native really offers?
I know both stacks extremely well and the answer is very clear to me.
Another possibility is: browsers are advanced enough to allow web apps to be possible, and as such, options other than native apps become available. Products requirements vary, and so do the devices you deploy to. There are a myriad other reasons one may weight the options and decide to develop a web app other than being lazy.
> I don't see similar push for desktop apps
I dunno. I use a number of web apps on a regular basis, Rdio being the closest thing to a native app I've used (I run it via Fluid to remove some cognitive gaps). Also, what about Chromebooks? Google's been aggressively pushing that. I think it just may be that more apps get developed for mobile, period, and as such the degree of interest in mobile web apps seems higher (which is ironic given how much easier it is to develop smooth web-based UX for desktop).
However, here's an idea: I recently bought the Impact.js game engine. It comes with Ejecta, which is a hardware-accelerated "browser" for iOS that supports only the canvas-element. If you can manage to implement your HTML5-app in canvas only, this might be an alternative for apps that feel almost native. However, it might be too troublesome to go down that path.
Of course, I don't have a deployed production app, just stuff I've fooled around with. If I had real customers on the other end, I could very well go the other way.
The problem here is walled gardens. From a strategic standpoint, frankly, I've had my freaking fill of vendors trying to lock down platforms and own everything in them. So I'm all for sticking with HTML5 and letting the performance issues work themselves out over time.
This should be split into two polls:
1) Which one would you want to use ideally
2) Which one do you end up using
No Elon Musk involvement. Yet. :-)
Having said that, things have improved the last years, especially when you don't need to support older android versions (> 4). However, performance will always be suboptimal and I found that people who claim the opposite simply have a lower bar for what good UI performance means - as harsh as it sounds. There is also a great number of tips and knowhow on how to make 'blazing fast' HTML5 apps, which people are quick to point out. Many of these help, but they don't always work for all browsers and they potentially limit you in what you can achieve (my favourite: don't use images. But what if the whole point of my app is to work with large images!?)
Multiply that pain with 10x and now you know what it's like to develop native apps. (Disclaimer: Grass is always greener etc)
1. Native (iOS/Android)
2. Native (iOS/Android) with some content in webviews
3. PhoneGap (iOS & Android, cross platform, same app)
4. Xamarin (iOS)
5. RubyMotion (iOS)
I recommend 1 & 2 if you have the resources (time to learn native iOS/Android or an experienced developer available). A good approach is to write all the structure/navigation natively and individual content in webviews. LinkedIn's mobile team uses this technique exhaustively.
Xamarin and RubyMotion (4 & 5) are both great 2nd choices if you dislike the Objective-C / Java languages or your team is well versed in C#/ruby, but you'll still have to learn the SDKs. There isn't much you can't do in these frameworks that you could do "natively", since you're still hooking into the native runtimes (loosely speaking). Xamarin is a bit more stable than RubyMotion, imho.
I'd stay away from PhoneGap if possible. My main takeaway is that "write once, run everywhere, sdk agnostic" is a pipe dream. You'll be disappointed when you're investing tons of time in the last 10-20% of development, working with fringe cases on different platforms. If you find yourself considering PhoneGap, consider whether or not being on the App Store is necessary at all, or if you can get away with a standard web app through the browser.
Needless to say: Xamarin is the perfect mix of cross platform and native for us.
I can see two possible reasons for this:
1) Native developers are the more opinionated of the two.
2) People who actually have experience to communicate prefer native
HTML5 isn't ready yet in my opinion, as it takes too much effort (read: hours, money) and many workarounds to get a polished, fast and responsive app out of it to rival native. Sure it's awesome for fast prototyping, but it's still too hard to get "dat native feel".
3) nothing is stopping anyone from upvoting the two
On the plus side, since it's native to the device (albeit with a different interface), you can do pretty well for speed through the already optimised graphical interface and through optimising your own apps with cython or even C modules if necessary. Other pros include pyjnius/pyobjus for api integration as above (some of which is already abstracted as python modules), and neat perks like the ability to mostly develop on desktop without an emulator.
On the other hand, it has some of the same disadvantages as html5, such as non-native widgets. So by no means a perfect solution, but an interesting contender.
If you're interested, you could try perhaps FlatJewels from the play store. It's a simple game with a fairly quick loading time (except the first run, which is always slower). I don't know if the author put effort into specifically optimising its start time, but it's probably fairly representative of what's currently normal.
It's certainly another downside of course, but to be clear to anyone reading the apks are much less than 25MB. And 25MB actually sounds like more than I'd expect even uncompressed, but I haven't looked at it much.
HTML5 if(you have some knowledge of HTML5/CSS and...):-
1. You need to build something quickly and cross platform
2. You can't afford different native app devs.
3. Performance is not that big an issue
4. You have/are a designer who can quickly conceptualize and build prototype using HTML5/CSS
I personally use Cocos2dx HTML5 which then can be compiled to native iOS and Android code, and can be run in a browser.
Hybrid approaches can be nice: build the interactive sections natively and then display the results in a web view so you can re use things from your mobile website, if that use case makes sense to your product.
And I don't think native takes more time. Debugging is much easier with native apps (imho).
I recently made an app for http://productivemag.com (for iOS and soon Android) using web tech, but I also have experience in native iOS/OSX dev. I use Cordova as a wrapper around HTML5.
- HTML5 is great for custom UI and prototyping. You can do that right in your browser, no compilation needed. And Web Inspector is _awesome_. Experimenting with UI in ObjC (or Photoshop, IMO) is PITA, but Web Inspector makes it super nice and easy.
- Native is great for using native UI. I had to recreate not just the appearance, but the behavior of a lot of elements. It takes a lot of time to get right.
- I don't know about Java and Android, but ObjC is a poor language. I used CoffeeScript for the project and it was a far superior experience.
- Debugging JS on iOS is pretty good, but it's still more painful than using Xcode's debugger. OTOH, JS is harder to _really_ break. If there's an error, _something_ won't work, but the app won't crash. Not always true with ObjC.
- Cordova sucks balls
- you can get pretty damn close with how fast and smooth the app works with CSS&JS, but you can never quite get there. Lots of little bugs and quirks, which are hard to fix.
- it sucks not to have control over how things are rendered. You can make wonders with `-webkit-transform: translate3d(0,0,0);`, but it's not perfect.
I'd still pick native any day. Control > ease.
HTML 5 is a big win for letting us get new releases out fast, and not having to battle with native APIs that we don't usually, but native wins out if you need something polished.
"Native Android" means you are developing a single app that runs and adapts to tens of thousands of different hardware and software configurations. It would be much more native to make an app only for the Samsung Galaxy devices, and then another app only for HTC Sense. Which is what iOS and Windows phone developers do.
If we say HTML5 is a very abstract/cross platform solution, and iOS is very native approach, then Android is definately something in between. And I would say it is much more "cross platform" then it is "native".
This is a free open-source wrapper.
tl;dr: Is your project process or data intensive ? native : html5.
Going native takes only some more time at the beginning, but as every technology you can only get better at it with time, I would totally recommend avoiding wasting your time with hybrid solutions (Cordova) and go straight native (I know i wish i had).
What would the result be if you got 2 developers, 1 with 5 years experience building HTML5 apps and 1 with 5 years building native apps, and gave them 3 months to create an apps for Android and iOS?
HTML5 first, Native later.
To make available more seamless "native" experience to the user.
However, native/hybrid/html5 all have their place int he ecosystem. A "best" can only be determined if in a given context (i.e. specs).
There is a lot of tips and trick to get the native feeling. I just think that you should give HTML5 a chance and not out rule it.
The question is not asking "What works?", but you're all giving that kind of answer. Is it possible to ask indeed what this question is asking? Can we detach the "I need to launch YESTERDAY!" attitude from these types of questions?
[MOAR EDIT:] Add in the qualification to the BMW/Saturn analogy that you're planning a road trip.
[EDIT:] To emphasize, the question asks, "Which will you prefer..." rather than "Which do you prefer..." It seems like the OP is trying to sideline the "functionality of today" question, which frankly given the rapid rate of growth and adoption altogether, "what works today", "APIs available today" is largely negligible.