If you are a developer, the web browser should be on your target platform. Why? Because it is the most ubiquitous platform there is – on the desktop, smartphone and tablet. But since the latter two are dominated by commercial vendors, the web browser is not the be-all and end-all of computing. The W3C strives to lob everything together in the web browser as much as possible, but no futher. Since the web browser runs on top of the host OS, it is limited in scope and functionality. So the vendors will try to fuse their hardware and OS as tight as they can so it will produce the speed and native functionality they want for optimum experience.
Here is the hierarchy:
1. Tier One – controls the hardware and software stack (Apple)
2. Tier Two – controls either the hardware (Samsung, Acer, etc) or the software (Google Android)
The W3C controls the HTML5 standard. You see, Apple has a distinct advantage in that, it controls the full stack. Apple doesn’t have the heterogeneity or fragmentation problem unlike the Tier Two vendors. It is this homogeneity and total control over the user experience that Apple wields its enormous power over the competition, and yet command the premium prices in the market.
The web browser may be a commodity from the vendors’ point of view, but Google and Apple duke it out in hardware features. As far as these vendors are concerned, they come up with hardware features first and bake those onto the OS. The web browser is a distant third in consideration. If the web browser won’t be able to accommodate it, it will be a native hardware feature and there is no choice but to access it through iOS or Android directly.
So you see, it is HTML 5 that is playing catch-up to these two dominant vendors. Until the dust settles, that’s the time you will see HTML 5 refactor all those features for cross-browser implementation. Sooner or later, HTML5 will mature and the web platform will reclaim more space from native apps landscape.
For now, iOS and Android rule the mobile OS landscape. And then some.
Developers have basically these choices:
1. Code in native language – Objective-C (iOS) or Java (Android)
- upload it to the PhoneGap Build service and get back your apps ready to deploy to vendor app stores or
- use the PhoneGap framework and get native access by enabling the Foreign Function Interface
6. Wrap Sencha Touch in a native shell (such as PhoneGap) to access native features
It is interesting to note that Appcelerator and PhoneGap are essentially stop-gap solutions to bridge the gap brought about by native features found in smartphones and tablets which are not currently supported by the web browser platform, hence the existence and continuing evolution of HTML 5.