Poll: HTML 5 or Native mobile development ?
Which one will you prefer for mobile application development and why?
53 comments
I've created native iOS apps, native Android apps, HTML5 apps and I've used wrappers (Titanium Mobile and PhoneGap) over the last few years and these are my findings:
- 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.
- 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.
Native apps take a lot of time to build, especially when you are a web-developer
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.
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.
I'm curious in how you put Titanium next to PhoneGap (Disclaimer: I may be reading too much into that, or not understanding your meaning - 2nd language etc.).
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?
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?
You are absolutely right: It's been a while since I last used Titanium. At the time you had to use a crappy/buggy UI to compile your app, with random bugs ocuring all the time, not being able to build once you've upgraded to a newer version due to backwards incompatible changes and more weird incompatibility bugs with other versions of XCode, and so on. I hated the experience since I couldn't rely on being able to building my app and Objective C library support wasn't available at the time or didn't work very well. I quitted using Titanium once they switched from their own buggy UI to Eclipse for building, my code was backwards incompatible, the UI couldn't compile to older versions of Titanium, I had enough. It's true, it has better performance as say a Phonegap, but it did have some weird layout issues from time to time which were hard to fix. Overall I think it's a nice product for creating an app without learning Objective C but I won't use it for a clients app any more, too unreliable.
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.
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 think you're right to make this distinction. Titanium doesn't belong in the 'wrappers' family and would be better grouped with other 'cross-platform native' solutions like Xamarin [1], perhaps a 4th category in parent's list.
[1] http://xamarin.com/
[1] http://xamarin.com/
Titanium is still not quite the same as Xamarin. Xamarin cross-compiles to fully native code from my understanding. Titanium, on the other hand, has JavaScript-to-native bindings i.e. a TiView is a JavaScript object which proxies UIView on iOS.
All business logic is still running in JavaScript. In fact, Titanium spins up a V8 engine just to run your app. This may be fine for the most simple apps, but if you need to kick off a long running operation to a background thread, for example, you're in for some gymnastics.
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.
All business logic is still running in JavaScript. In fact, Titanium spins up a V8 engine just to run your app. This may be fine for the most simple apps, but if you need to kick off a long running operation to a background thread, for example, you're in for some gymnastics.
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.
[deleted]
Have you got experience with Titanium? How is it? I've had a few clients inquire about mobile applications as of late and I'd like to start exploring options for me as a web developer.
There's a slight learning curve, but it's overall very nice to work with. Been making a living from it for a year now, so I'm rather comfortable with it.
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.
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.
you can't access things like the camera with HTML5 only
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.
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.
A file upload form field also accesses the camera in iOS and Android.
You can also access the camera on iOS using HTML5, a bit buggy though: https://github.com/daraosn/Cordova-CanvasCamera, anyways I also second you, native development is always better, imo.
> HTML5 only apps are not available in the market/store
What do you mean by this? That doesn't match my understanding of the current state.
What do you mean by this? That doesn't match my understanding of the current state.
HTML5 apps are wrapped. We did one using Native5. IT is available on app store (https://itunes.apple.com/in/app/kotak-treasury-calendar/id63...) and on Play store https://play.google.com/store/apps/details?id=com.native5.ap....
Always goes only for native. Here're why I don't go HTML5.
(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.
(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.
> There's no computing platform doesn't support C/C++
Does that include Android devices?
Does that include Android devices?
NDK on Android supports C/C++.
http://developer.android.com/tools/sdk/ndk/index.html
http://developer.android.com/tools/sdk/ndk/index.html
Dropbox uses C++ as a cross-platform language for iOS and Android: http://www.youtube.com/watch?v=S5rXCvu9-NM
HTML5 is designed to run in a browser which is always on. Native development is designed so that the user can switch betweens apps easily, without having an app to be slow.
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.
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.
1. Close tab/window.
2. Use Page Visibility API[0] 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?"
[0]: http://www.w3.org/blog/news/archives/3351
2. Use Page Visibility API[0] 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?"
[0]: http://www.w3.org/blog/news/archives/3351
Many there comment that developing with HTML is faster. This is true only and only when you are not familiar with the native language and frameworks. Really, native SDKs have solved pretty much all the common problems. With native you implement the functionality of your app, and don't have to invent views management, list views, notifications, events management, gesture recognisers, etc.
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.
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.
> 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?
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).
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).
I tried to make a simple calendar with swipe gestures with PhoneGap and Sencha. The performance was horrible on my iPhone 5 (!). Wouldn't use HTML5 again, except maybe as a wrapper for some static HTML5 content without much user interaction (exactly the kind of app that Apple doesn't like btw)
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.
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.
I'm sticking with HTML 5.
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.
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.
The question leaves room for ambiguous response & misinterpretation of results. You ask : which one will you 'prefer' to use. From a personal standpoint, my preference would be html 5, however from a logical standpoint, my preference would be native.
This should be split into two polls:
1) Which one would you want to use ideally
2) Which one do you end up using
This should be split into two polls:
1) Which one would you want to use ideally
2) Which one do you end up using
HTML5. My (Meteor & D3-based) application is primarily aimed desktop browsers, and it already very nearly works out of the box on mobile -- there are a few D3 touch events that need to be revisited, and a new layout that is friendlier for smaller screens; otherwise we're done. We don't need to access low-level hardware, and the idea of doing Native re-implementations of Meteor's bidirectional data bindings or D3's force-directed graphs is, frankly, ridiculous. So we're going HTML5 all the way.
Looks like a cool project! Is Elon Musk involved? :) http://www.podaris.com/
Thank you! This is actually for my prior startup (probably too profitable to call a "startup" at this point, actually), http://www.futurescaper.com/. But Podaris is shaping up to be HTML5/JS from top to bottom as well. Unlike Futurescaper, it doesn't need a smartphone incarnation, and the alpha version works surprisingly well on tablets, pretty much out of the box.
No Elon Musk involvement. Yet. :-)
No Elon Musk involvement. Yet. :-)
Not having much experience with developing native mobile apps, I can only say what a pain it is to develop non trivial HTML5 apps that need to support a wide array of browsers. Your initial euphoria of 'oh wow I could make this thing for [insert browser of you choice] in less than [x amount of time]' is quickly mitigated when you try it on other browsers. Different browsers _will_ vary greatly in performance for different approaches and at least one browser _will_ have a bug. Fixing these performance issues (and not killing performance on other browsers again) and finding workarounds for bugs will then take 80% of the entire development time.
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!?)
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!?)
> Not having much experience with developing native mobile apps, I can only say what a pain it is to develop non trivial HTML5 apps that need to support a wide array of browsers
Multiply that pain with 10x and now you know what it's like to develop native apps. (Disclaimer: Grass is always greener etc)
Multiply that pain with 10x and now you know what it's like to develop native apps. (Disclaimer: Grass is always greener etc)
How many native mobile apps have you developed? I'm curious because your GitHub repos are all JavaScript projects.
Here's what I've tried (mostly just for kicks) and my thoughts:
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.
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.
it depends on what the mobile application will do. E.g. for more performance heavy apps native is the way to go. See reasons why: http://speedcheckerapp.com/NativeApps.aspx
"It depends" is the only sensible answer. How many people do you have to work on it? Can you get both iOS and Android programmers? How does it fit in with the rest of your company and its goals? What is the purpose of the application? How solid are the specs - in the sense of knowing exactly what the app should do, or is it more a MVP type of thing where you're trying to see what the problem space is like?
I'm using Xamarin.iOS and Xamarin.Android for a modest app. I've already spent about half a year on the Android version, with special care to have all logic in a separate layer. The iOS version had catched up in 2 weeks, from scratch.
We hired a second guy for that, who had no C# experience (but more on iOS) just before I went on a 2 week holiday I just got back from.
Needless to say: Xamarin is the perfect mix of cross platform and native for us.
Needless to say: Xamarin is the perfect mix of cross platform and native for us.
We prefer native 99% of the time. Performance of HTML is easily outmatched by native on both iOS and Android, and the multi-platformness of HTML is usually limited if you want to adhere to UX guidelines and conventions that are platform specific.
Intestesting that the poll results (currently) only give a slight edge to native, but the comments are overwhelmingly pro-native.
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
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
Right, I think there are just overall more web developers than mobile developers out there (one has been around for much longer), and people who have had real experiences building mobile apps are still in the minority.
Maybe it's due to the phrasing of the question. I certainly prefer native (ok semi-close-ish native, I use Titanium), but I _will_ in the future prefer to be using HTML5, once it's ready.
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".
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".
and
3) nothing is stopping anyone from upvoting the two
3) nothing is stopping anyone from upvoting the two
How about kivy (http://kivy.org/#home) for something of a middle ground? It's a python graphical framework making heavy use of opengl via an optimised cython interface. It has fairly powerful access to the android api through pyjnius (which gives direct access to java classes) or pyobjus on ios (which is less mature but has the same idea).
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.
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.
The biggest downside I found with kivy is the amount of time it takes to launch the app as it has to set up the python environment et al. If that's improved with newer versions of kivy I might go back to see what it can do.
That's still a problem unfortunately, though less so than it used to be so your perception might depend on when you last used it.
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.
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.
The other standard downside of kivy is the mandatory giant app footprint. Hello World is going to set you back 25mb on Android.
I think this could be misleading...a kivy apk has a minimum size of about 6-7MB. When installed it will extract the contents but the apk remains, which more than doubles that size on the device storage. The extraction can be done to the sd card (or internal equivalent) so as not to take up system internal memory space.
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.
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.
[deleted]
Native, using Xamarin. Native apps still give users the most optimal UI. Using Xamarin work can be reduced, because a big part of the code can be shared between platforms. Code for all platforms is written in C#. Xamarin still gives developers the option to wrap libraries written in e.g. Java or Objective-C for use in the apps.
Html5, because easier to prototype and iterate. Clearly native once you have the right idea and funding for it.
How it is easier? At least on iOS you can prototype extremely quickly and almost without writing any code: drop your views on controllers, wire them up and there you have it.
An HTML5 app is a lot easier to make cross-platform than writing separate native apps for each platform. It depends on the type of app though; running inside a browser is definitely a step away from native APIs, even when you have pass-through access to them.
Wait, we were talking about prototyping an reiterating, not cross platform development.
And even for cross-platform I wouldn't be so sure about "a lot". You may get initial version faster, but all the tweaks and ironing of the cross-platform kinks can eat a lot of time and make a lot of hairs grey.
If facebook's HTML5 fiasco is any lesson, I would rather go with Native.
The native app didn't help much. The biggest deal with the HTML5 app was adding DOM content as the user scrolled. They were experiencing memory leaks. The native app may have fixed that part, but their backend API service was still sucking pretty badly for months after that. Even now, on an iPhone4, the performance of the native app kinda sucks. It's better on a 5 or 5s, but still fairly slow to get a JSON stream, parse it and build dynamic views.
fb.html5isready.com
Just tried that on ios7 and it crashes every 20s or so. Not that that really proves anything
fastbkapp will receive the following info: your public profile, friend list, email address, custom friends lists, messages, friend requests, News Feed, relationships, relationship interests, birthday, chat status, notes, work history, status updates, education history, events, groups, hometown, interests, current city, Photos, religious and political views, videos, website, personal description and likes and your friends' relationships, relationship interests, birthdays, chat statuses, notes, work histories, status updates, education histories, events, groups, hometowns, interests, current cities, photos, religious and political views, videos, websites, personal description and likes.
hmm, nah.
hmm, nah.
So will the native facebook app. Of COURSE the fastbkapp will receive that info.
OF COURSE. That does not mean I want to give ALL that to ANOTHER third party.
It depends on what kind of application you are developing:-
Go Native if-
1. Need to access platform specific features example camera,gs,etc
2. Need performance intensive app
3. There is enough time for you to develop native app and can afford different native app developers (if planning to go cross platform)
4.You already know java/C#/Objective-C and it's a pain for you to learn HTML5
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
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
Native will always perform better.
I personally use Cocos2dx HTML5 which then can be compiled to native iOS and Android code, and can be run in a browser.
I personally use Cocos2dx HTML5 which then can be compiled to native iOS and Android code, and can be run in a browser.
It 100% depends on the use case, if there is a ton of interactivity in your app then native is far better. If your app is primarily informational, HTML5 is generally easier for most folks.
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.
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.
tl;dr: If you can, go native all the way, but if it makes a lot of sense from biz perspective to support platforms other than iOS, HTML5 is not as bad as it seems.
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.
My conclusions:
- 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 JavaScript on Android sucks
- 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.
- interfacing with native capabilities is hard. iOS's WebView doesn't expose direct access to the JavaScript VM, so the bridge between two worlds is based on callbacks. Async is much uglier and more error-prone.
- 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 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.
My conclusions:
- 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 JavaScript on Android sucks
- 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.
- interfacing with native capabilities is hard. iOS's WebView doesn't expose direct access to the JavaScript VM, so the bridge between two worlds is based on callbacks. Async is much uglier and more error-prone.
- 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.
Would just like to add to this answer that, as of Android 4.4, the WebView is based off of Chromium, enabling you to perform remote debugging with your chrome web developer tools (basically everything you can do on a website you can now do on a WebView).
I'd still pick native any day. Control > ease.
I'd still pick native any day. Control > ease.
That's true, but sometimes things work just fine 4.4 and only break on the undebuggable Jelly Bean or older ;)
A bit of both - we have an HTML 5 application used internally, and an iOS app we distribute to customers.
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.
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.
I think many people forget that "native" is a very abstract term.
"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".
"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".
HTML 5, cross platformness. We wrap it into a native container though.
Can you elaborate on the 'Wrapping it into a native container'?
Take a look here: http://phonegap.com/
This is a free open-source wrapper.
This is a free open-source wrapper.
Yes, we also use StageWebView with Adobe Air.
I think it is a question of complexity, for simple Apps HTML5 is definitely the way to go, easy to iterate, more freedom and prospect of being around (no chance of being pushed out of business for some vague policy issue -- App Store rejection or pull off -- or no risk of being forced to pay portions of subscriptions to a 3rd party).
With that being said, HTML5 still can't compete with native Apps when it come to performance and stability.
tl;dr: Is your project process or data intensive ? native : html5.
Edit: Rephrasing.
tl;dr: Is your project process or data intensive ? native : html5.
Edit: Rephrasing.
My vote goes for native, i've built a series of wrapped html applications and the experience always is awful, as soon as you try to target something other than an iOS device you get tons of hard to fix bugs, awful performance and a bunch of weird glitches.
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).
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).
From my experience, clients generally prefer native, as the quality is so much better. Looking more closely, however, agencies / freelancers pitch HTML5 apps at a considerably lower cost than native. I've seen them come in at half the cost.
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?
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?
I'm mid-way through developing a Phonegap/Cordova app that's a fairly basic turn-based game that uses the Canvas to render the game board. So far I haven't found any limitations with the needs of this app imposed by going with the wrapper. Certainly it's not the right solution for every type of app, but in the right circumstances I'm convinced this is a perfectly acceptable approach.
Bit of both. We did an HTML5 app with Cordova/Phonegap as the wrapper and worked very well - it is fast but took quite a lot of optimization. Only problem is some things are not supported in mobile browsers (eg position fixed) so menu behavior could be quirky, so we've rewritten to use html5 content with native menus/nav bar/slider and this works the best.
Depends on what features you want to build.
If you do need access to the phone's native APIs, you WILL need to make a native app.
HTML5 works great for first versions and specifically if everything can be done over back-end API.
HTML5 first, Native later. To make available more seamless "native" experience to the user.
HTML5 first, Native later. To make available more seamless "native" experience to the user.
HTML5 (hybrid).
Especially in today's world it's unacceptable (for most projects) to take 5x time to whip up a simple view.
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).
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).
HTML wrapped apps are just lowering the bar for great native apps; also, I've seen so many web designers that now think that they can develop an app that's almost embarrassing, it only works when you want an app that's basically a mobile website
Those who have tried to create an HTML5 based app and native. And who don't get the right "native" feeling on the HTML5.
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.
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.
I also prefer native apps. We have heavy use of API functions and that kills ever HTML5 app
We do Cordova/PhoneGap development - the best of both worlds. HTML 5 wrapped into a native iOS/Android app. We still use plugins with native code though (Java/ObjC), for receiving push notifications and accessing the camera.
This really depends... if you are building a consumer app, native is probably better given that you typically need access to device features...but for business apps, with few exceptions I say HTML5 hands down.
[deleted]
Which one is 'native using JS?' Apple introduced JavaSciptCore in iOS 7. I don't care for ObjC so JS calling native UI from a familiar language sounds good.
I prefer native apps, but the solution depends of the problem
It makes sense to me to use both to a degree. The frontend and UI will greatly benefit from using HTML5 while stability will depend a lot on the native aspects.
I would say native. But i need to know what the product is to take this choice. I always prefer hybrids apps since I can take the best of both worlds.
In my company (www.reportest.com) we made our SDK native. It performs better but, on the other side, HTML5 is much much quicker to develop.
Can you expand more why it is quicker? You have to do so much reinvention of the wheel with html that I really don't get how can it be quicker.
There's only one real answer to this.
How many HTML 5 apps do you use on your phone on a daily basis?
Compare that to Native...
OMG: the pain of doing a mobile HTML5 app and having it work across the entire spectrum of Android and iOS devices. OMG.
[deleted]
Why not both?
Neither, but Air.
what kind of app? that's the question you should be asking yourself first.
Black as well
I'm confused on this question. If someone asks you, "Between a BMW that needs repair (without a sunroof) and a functional Dodge Saturn (with a sunroof), which will you prefer?" you don't answer "Well, the Dodge Saturn, because work tomorrow morning."
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[0] and adoption altogether[1], "what works today", "APIs available today" is largely negligible.
[0]: http://www.w3.org/wiki/Closing_the_gap_with_native
[1]: http://www.w3.org/2013/11/w3c-highlights/
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[0] and adoption altogether[1], "what works today", "APIs available today" is largely negligible.
[0]: http://www.w3.org/wiki/Closing_the_gap_with_native
[1]: http://www.w3.org/2013/11/w3c-highlights/
Why is this an either/or question? Do you prefer native or html for PC apps? It depends on the app, I prefer whichever is appropriate for the application in question. This is just as true with a pocket sized computer as it is with a laptop or desktop computer.