Monday, 27 February 2012

Updated iPhone killer apps list


read more

Monday, 6 February 2012

Killer Apps Ecosystem


Friday, 3 February 2012

HTML5 vs. Native app development

The HTML 5 vs Native debate was raging yesterday in the Mobile Monday London event (see my digest on this blog) and will continue to for a long time, just as the java vs. native did and the widget vs. native did, and just as much as the "which OS choice/debate" I discuss here in my blog as well

The reality is blurring with recent announcements of high profile games on HTML5 like cut the rope however the issues that I found when heading up the iPhone porting for Voda 360, the first major W3C HTML with APIs if not HTML5 still remain even with these successes.

Then I go out into the market and hear some game developers doing cross platform, some adopting HTML and other focusing on the multiple approach of iOS and Android, looking at HTML5 to cover the rest. That is with games at least, and will be the case of many apps with access to low level functions and APIs (beyond GPS, audio, video, etc).

With certain apps it is much clearer:  I spoke to a developer of a major social network that was launched recently who said they would never have gone native if they did it over again: the user experience is just two fragmented between the web, tablets and the main app OSs and then mobile web. I also know users who have ditched native apps for social networks in favour of the HTML5 experience: quicker, closer to the web, the same on tablet as smartphone and the closet to their web experience... and as a result I specified a social network for a client recently in html5 with native in potential roadmap...

Then there are the mobile operator clients considering portals and app store, more relevant to my portal blog, but still very interesting for the case in hand: Its important to maintain flexibility in these situations, and fix your roadmap (in scope) only for one or at most two quarters ahead. Just recently, for example, a mobile operator client was faced with a situation where their development on an app store/portal was lead natively on two platforms with another two following and another two in roadmap... when Microsoft announced that W7 was going to be a closed environment, symbian split, meego was sidelined and RIM became evidently more fragmented (bb5 vs bb6 vs bb7, etc) then the option was very clearly android plus... native or java or HTML5. It was still a little early then, but the answer would be much clearer today.

So, with so much depending on what you are doing where and with whom... and so much social, regional and international fragmentation, however there are some key considerations to take into account:
  1. what device is it running on? which will affect many things, but in short, running in  a sandbox without native extensions will be slower on things like
  2. refresh rate: while low end Java devices and even proprietary runtimes like Offscreen Media's were running 50-100 frames per second, the first web runtimes were at 3-5, with the best developers on best devices eeking out 10-15. Even if you get this much higher, its still a limiting factor over native, and those pushing the boundaries will always prefer native
  3. how many platforms are you going to distribute on. Its all very very well having a cross platform app and cross platform intentions, but do you have the time and resources to update APIs across 20 stores, check 100's devices, upload across many platforms, have the project management and roadmap skills to manage the process, etc, etc.
  4. What is your target audience now and later. if you are going after advanced users and then mass market then native first, html5 later maybe an option, if revered, then reversed, obviously. if you have a product like Sonos, why go to the extra effort of making the platform universal when all your customers will have at least one android or iOS phone or tablet at their disposal?
  5. What regions are you looking at? HTML5 will play better to strong growths in ever cheaper smartphones, like Africa, vs those with a solid smartphone base (Nokia in parts of Asia and Latam, others varied in US, Europe and ROW)
  6. Do the stores you are planning to roll-out on have the features and APIs you want? There is no point creating your freemium app that requires in-app upgrades or subscriptions in HTML5 for flexibility if it would have been quicker to do it natively in the two stores that support what you want to do, and the ad serving and other APIs are completely different in each deployment
  7. Do you want to be off-line?
  8. Do you want to obfuscate and/or only have certain functionality using server based algorithms for extra security.