Older WebViews Not Being Updated

securitystreet.pngIf you have been following my posts on Android WebView security concerns then you might be interested to know that Google No Longer Provides Patches for WebView Jelly Bean and Prior. However, as one of the post comments points out "Even if Google does continue support, would the devices even get it?". Learn more about Android WebView vulnerabilities

The Web vs Apps Outcome

android.gifThere was time when some people thought the future of mobile development was the web. That thinking was based on the fact that the web was a common platform across all types of device and that would be the only way to solve fragmentation. If you look at the ‘Web Technologies’ section at the bottom of this site you will see I was sceptical.

In practice, we all know apps have dominated. While Apple and Google have improved their web browsers, they haven’t put in as much effort to allow the browser access to APIs nor improve the user experience for web-based apps. However, I believe the situation has become even worse than this.

The lack of browser-based access to native APIs has caused workarounds to be devised that are used in hybrid apps that contain WebViews and code included by most 3rd party ‘easy’ app creation tools. On Android these involve use of Javascript access to the Android native Context to call into native code. Unfortunately, as these are workarounds, they are very insecure. My article on ‘Use WebViews Carefully’ gives more details. Anyone using app creating tools based on WebViews or using WebViews in their app needs to be aware of these vulnerabilities. In fact, as of last week, outside of embedding in apps, even using the browser on its own has been the subject of a security scare.

A second problem is that there’s now no one ‘Android Browser’ upon which the WebViews are based. Niels Leenheer has a great set of slides that explains how browsers vary across Android versions, devices and phone manufacturers. The consequence of this is that getting any non-trivial WebView-based app to work across many device types is very difficult. The many 3rd party companies creating app creation tools based on web technologies face an uphill battle – as do people using their tools.

It’s ironic that the (web) platform that some people thought might solve the fragmentation problem has, arguably due to under-investment and lack of innovation by Google and Apple, become one that has security and fragmentation headaches.

Apps vs Internet

orange.gifOrange has some new free Orange Exposure research conducted by TNS that concentrates on the path to purchase across the UK, France and Spain. It concludes that 4G networks are igniting uptake in m-commerce, showrooming is on the rise and Android’s dominance over iOS is continuing (also with a leap in tablet market share).

useofbrowservsapps.png 

An interesting insight for mobile developers is that people are increasingly using apps to access the internet rather than the traditional browser. I suspect this means that there are opportunities for brands/companies/developers to create apps that present web site data in more innovative and easier to use ways as opposed to just within a webview in the app.

Tablet Usability Study

nielsennormangroup.pngNielsen Norman Group have a new article on the results of six rounds of usability studies with tablet users across iPad, Android and Windows tablets.

The main problems were the same as for applications on other platforms…

"Difficult features, mismatch with user workflow and poor instructions that people don’t read"

Nielsen Norman Group observes that websites are much more usable than on smartphones. This together with the requirement  for apps to modify the user interface for different tablet models causes Nielsen Norman Group to advise developers to "stick to websites" and only create an app if it really adds value over a website. If you do make an app then don’t make it a scaled up phone app. The article also covers other issues such as Web UX bleedthrough and gesture problems.

I’d say the advice to only create an app if it really adds value over a website is equally applicable to smartphone apps. There are too many ‘shallow’ smartphone apps that might as well be websites. In the past it might have been worth creating the equivalent of a site in an app in order to gain visibility via the app stores but, with so many apps in the stores, that time is well over.

Gartner Technology Trends for 2013

gartner136.gifMany companies doing development are looking at the ‘here and now’. I previously observed how successful products sometimes project the technical and market roadmap to the next few years and try to fill a gap. In mobile, things change very quickly, timescales are compressed and it’s rarely sensible to try to project more than a year or two into the future. So what are the trends for the say the next year?

Gartner identifies the Top 10 Strategic Technology Trends for 2013. First of all notice Gartner is talking about "Technology Trends" not "Mobile Trends". The fact that many of Gartner’s trends directly or indirectly implicate mobile demonstrates how important mobile has become.

I will leave you to read the press release. However, there are just two statements I find harder to believe will come to fruition…

"However, only 20 percent of those handsets are likely to be Windows phones."

20% of smartphones sold in mature markets in 2013 will be Windows Phones? They must be dreaming. I believe it’s more likely to be single digit percentages, as now. To discover why, see my previous post on Windows 8.

"However, there will be a long term shift away from native apps to Web apps as HTML5 becomes more capable."

How will HTML5 become more capable? I can’t yet see how (or why) Apple and Google, the current browser gatekeepers, might make HTML5 have capabilities closer to those of native apps. Is it in their interest? How have mobile browsers’ capability improved over the last five years let alone the next five years? Don’t get me wrong, I would like it to happen but I don’t yet see the commercial drivers for this. If you want to help make this actually happen then check out CoreMob.

MoMo London HTML5 vs Native

mobilemondaylondon.gifOn Monday evening I was at MoMo London at the ‘annual’ HTML5 vs Native debate. It was excellently chaired by the entertaining Ewan MacLeod of Mobile Industry Review, with two teams of debaters. Andrew Betts (FT Labs), Sam Arora (DeviceAnywhere) and Jose Valles (BlueVia) were in the ‘Pro-HTML5’ team  while Nick Barnett (Mippin), Alex Caccia (Marmalade) and Chris Book (Bardowl) were in the ‘pro-native’ team.

To cut a long story short, the usual pros and cons of HTML5 and native were discussed (see my previous posts) and predictably it came down to ‘horses for courses’. It all depends on your project. However, there were some items of interest that might be worth further thought…

  • All the latest apps the panel had downloaded were native.
  • Andrew Betts from FT Labs suggested HTML5 hasn’t been found suitable for many projects because HTML app implementors "didn’t do it very well".
  • Jose Valles said that maybe there’s a need to push to get (HTML) APIs open. Later, Jon Rabin, organiser of MoMoLo mentioned CoreMob that has these goals. 
  • Alex Caccia commented on how they (Marmalade) think of ARM as a platform across devices, in a similar way to the way some people see HTML5 as cross platform.
  • Alex also observed that when you get stuck, HTML5 tends to be a black box that needs difficult experimentation while native has APIs that are easier to explore.
  • There was contention as to whether an app should look and behave like other apps on the phone or use brand-familiar idioms. Again, it depends on the actual app (and brand).
  • There was an observation from Andrew that companies tend to blow their budget on creating an iOS app. When they suddenly realise Android is needed, there’s much less money available and the result is a poorer app. When further platforms are needed, the budgets get even smaller.
  • There was a question as to what the next billion users, in less developed countries, might end up using and whether this might influence development trends.
  • Finally, reversing last year’s result, the audience voted for native over HTML.

 

Mobile Web Technologies Tide is Turning?

allthingsd.pngThere’s a thought-provoking article at at AlThingsD that observes that the Mobile Tide is Turning Towards Full-Fledged Apps rather web-based technologies. It describes the case of Facebook and to a lesser extent Quora who have embraced native rather than web technologies.

The lesson here is that if you want the best user experience you have to go native. However, remember not everyone needs ‘the best experience’ and it’s possible to trade this for quicker, less expensive development and more flexible cross-platform deployment by using HTML5 development. I see the more dangerous scenario as one where a company takes on HTML5 development without really knowing they are making a tradeoff. Trying to get HTML close to the user experience of a native app costs a huge amount of effort that might as well have been spent on native apps. Conversely, if you know and accept, rather than fight, HTML5’s limitations then its advantages will be maximised.

There are three main areas to consider…

  • Look and Feel: It’s possible to get HTML close to the look and feel of Android and iOS but it takes a considerable amount of effort due to browser fragmentation. If you want an Android/iOS look and feel then I would recommend you go native. If you want more of a custom, branded look then HTML will be ok.
  • Functionality: If you are just displaying information then HTML5 is ok. If you are doing lots clever things with the information together with phone features (improving the user experience) you should go native as adding many of these things via web technologies ends up being either impossible or will require native code written anyway (e.g. for PhoneGap).
  • Performance: The main issue here, for non-games, is usually scrolling. Less smooth scrolling is the tradeoff for using HTML5.

12 September UPDATE: Mark Zuckerberg admits wasting 2 years on HTML5

Developer Garden Component Marketplace

developergarden.pngDeveloper Garden Component Marketplace is a new online marketplace from Deutsche Telekom (powered by Verious) where developers can buy and sell software components for Android, iOS, Windows Phone and HTML5. It includes some Deutsche Telekom components as well as those provided by Verious.

Components are a great way to get your project up and running quickly. However, here are some things to think about before blindly using a 3rd party component…

  • What happens if there’s a problem, for example a bug in the component?
  • What happens if the 3rd party goes out of business?
  • What happens if the component becomes incompatible with future released devices?
  • What are the costs? Is there a per-user/device cost? Do the costs scale well?

The first three considerations are non-issues if you can also obtain the source code.

Also, another thought. Some of the components I found on the component marketplace had open source equivalents with slightly less functionality – check these first to work out what extra a commercial solution is actually offering.