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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
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.
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.
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 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.
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.
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.
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.
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.
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.
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 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
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.
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.
105 comments
[ 5.0 ms ] story [ 185 ms ] threadThis is a free open-source wrapper.
hmm, nah.
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 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.
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.
where exactly does the cut off line exist? native/html5 is kinda gray.
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?
[1] http://xamarin.com/
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.
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.
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.
What do you mean by this? That doesn't match my understanding of the current state.
I personally use Cocos2dx HTML5 which then can be compiled to native iOS and Android code, and can be run in a browser.
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[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
(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?
http://developer.android.com/tools/sdk/ndk/index.html
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
And I don't think native takes more time. Debugging is much easier with native apps (imho).
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.