Call Us (888) 840-3246 & Get a Free 30 min Inbound Marketing Assessment
An HTML5 app is essentially a website with JavaScript code written to allow the app to perform dynamically, as opposed to a static website that you need to “refresh” to see the changes. It works interactively to make it feel like an “app”, but it is running in a web browser, and is essentially a website, which (since it looks like your focus is mobile) will support multiple viewports or screen sizes so that it works well on mobile. Because it is running in a browser, it is confined to what is known is the browser sandbox, which is a limitation on what the app is capable of doing with the system hardware. It can only support features which are permissible inside the sandbox. This is done for security reasons.
You choose this if you are going to be wanting to support multiple platforms with the same app / codebase. You want to deploy it on the web, you are probably going to be making a website application anyway, and you can kill two birds with one stone like this. You get the widest possible support across multiple device OS’s and manufacturers because they are all implementing HTML5 compliant browsers on their devices. The screen sizes will be different and you will have to take this into consideration, however most of your code will just work. You get the added benefit of being able to update your source files on your server and have them immediately deployed to all devices, there is no app approval process. Clearly, your app is not discoverable in the App Store, however it IS possible to give it an icon on the homescreen of devices like the iphone such that it looks exactly like a native app, even though it isn’t.
A native app is an app written to a specific platform like iOS or Android, where the app is written in the language used for development on that platform (Objective-C and Java in this case). The portability of the code to other platforms depends on how it was written (if portability was in the developer’s mind), but will always require some level of rewriting to use on another platform. When you write native, you get access to all the hardware features exposed by the native code APIs, which is typically most of the functionality of the device, definitely more than a web app. Apple push notifications is one example from your list that is an iOS specific feature which is not supported by a web app. It is “Native” because the code you write is essentially written for that platform, it is built for the native architecture of that device (implicitly implying that cross-platform support might be an area of concern, and it is).
You choose Native if you want to use the UI components from Apple’s proprietary UI libraries (the usability is better) and for better device hardware access. The UI experience is very likely what you are thinking of when you think of “iphone apps” and how you are used to them functioning. You choose it if you need hardware access to graphics for performance reasons (as with games) or need access to some other features that are proprietary to Apple and not supported in a browser sandbox, like Apple push notifications, in-app purchase or appropriate camera access. Your code is less portable but more performant, and more powerful and capable for the platform it is written on. Your app is discoverable in the app store and you can monetize your app by leveraging initial purchase price or in-app purchase, in addition to advertising.
A hybrid app is a web app that is deployed to a native platform like iPhone inside a native harness. This harness is usually little more than a browser view (to display the HTML5 content) and some other hooks to allow your web app to potentially access some more hardware features that are not available inside the browser sandbox. It improves code portability because if you want to port your app to another platform, you only need a native harness on that other platform to run it, the HTML5 content of the app is directly portable. These harnesses can be hand written, but can also be generated automatically by tools in the marketplace like the much lauded PhoneGap. These tools try and make a single point of contact for the developer, who can then turn around and push their app out to multiple platforms quickly by generating the harness and packages required to do so automatically. This sounds powerful, and it is, but clearly the PhoneGap people have a ton of configurations and hardware to support, and thus, the solutions do not always work the same across all devices, and in practice, testing and hacking of special cases will be required by the developer to get proper support if the app is anything more than a website in a browser control.
This is a more complicated decision because of the deployment tools out there, some will make a harness for you to run the web app in, and others will try and convert your javascript code written to their platform into native code, and thus generate native UI controls as a result. If you go this way you need to investigate the capabilities of whatever platform you are choosing (Appcelerator is another example), and you need to test to get a feel for what the resulting product will look like and is capable of. These hybrid generators are an ongoing area of innovation and are constantly improving, but their current state, and how good the product is as a result of using them, is unknown to me. I have definitely read many times about implementation problems, such as using a gradient function that works on one platform but simply fails on another, or works differently. It is theoretically possible for your app to be denied to the App Store if deployed this way, those decisions are up to Apple and their criteria for what passes and what doesn’t varies by reviewer and is unknown to the public. Another factor is that when a new iOS version comes out, you won’t have access to it until the platform you are using enables support for it. This will probably come too late to give you the bleeding edge, the guys writing Native code have that and you will be one step behind by design because you are dependent on a third party to implement this support for you.
Start Getting Results |
|
12526 High Bluff Drive, Suite 300 San Diego, CA 92130 USA
Phone: (858) 888-9151
Toll Free: (888) 840-3246
888 3rd Street SW, Suite1000 Calgary, Alberta, T2P 5C5, Canada
Toll Free: (888) 840-3246
Phone: (403) 800-5026
