Smartphones and Beyond

October 1st, 2014

symbian.gifOver the last few weeks I have been reading the 800 page book by David Wood on Smartphones and beyond: Lessons from the remarkable rise and fall of Symbian.

It’s fascinating reading especially if, like me, you developed Symbian apps and worked at Symbian. It’s useful reading even if you aren’t in any way linked to Symbian as many of the learnings are just as applicable today. Don’t let the 800 pages put you off. There are lots of press releases, blog and news articles that you don’t really have to read entirely and the latter portion of the book hasn’t much to do with Symbian or necessarily mobile at all and delves into David’s other passion of predicting what might lie ahead. In fact, if you are interested in this kind of stuff you are better skipping this part and instead reading ‘Anticipating 2025′ which is part authored by David and includes similar material.

Back to the Symbian book, it describes how Symbian’s loss of control of the UI, to Nokia, affected the OS. It describes the difficult situation when your customers (licensees in Symbian’s case) aren’t the end user (network operators, consumers). It also shows how there can be conflicts of interest when your shareholders are your customers and how they can prevent the company from exploring what could be more profitable or successful areas. It also demonstrates how it’s easy to under-estimate competitors who have taken up recent easy-to-deploy commoditised solutions for which you have historically had to use a customised solution to which you are now tied. It describes how large software is difficult and differentiates between team agile and enterprise agile. The book also shows it’s possible to consider creating custom solutions for customers but to make them pay through consultancy.

There’s a useful observation that recruiting the best is important. If your don’t then when your recruits recruit further people there can be downward spiral as people recruit weaker and weaker people so as to protect themselves. The book shows how technical debt and strategic debt can cripple a large company (Nokia) thus advantaging faster-moving newcomers such as Google and Apple. There’s also a possible explanation of why Stephen Elop killed Symbian so quickly rather than slowly, a strategy that lead Nokia to financial ruin. You can also learn how David’s openness, while representing the ‘open’ Symbian Foundation, caused him to be asked to leave his job.

Many of the insights can be used to provide advice to today’s startups. For example, if you are thinking you can’t compete with an incumbent, there’s a possibility you can. They will be much much slower, especially if you can use commoditised solutions while they use custom solutions.

Related Articles:

Same Origin Bypass and Android Apps

September 30th, 2014

trendmicro.pngThere has recently been a high profile ‘Same Origin Bypass’ security issue regarding the Android browser, prior to Android 4.4 KitKat, that allows a client session on one site to affect a client session on another. TrendLabs have just posted some information that shows that this vulnerability has wider reach than first thought. Like me, you might have thought it was only a web browser problem in that visiting one infected site can then cause problems when you visit further sites. However, as TrendLabs state… 

"A more significant problem right now might be apps that show a website within their own user interface. Messaging apps, or other apps where users can view an arbitrary URL, are a particular problem if the site is opened within the app and not sent to the user’s default browser."

I guess what they are getting at is that opening one infected URL followed by other uninfected URLs can compromise the security (data and behaviour) of the later sites. I urge you to think about if your Android app opens arbitrary URLs or even defined URLs, the content of which, you have no control over. Opening them into a WebView can cause unintended Javascript to be run. I have some further guidelines for using Android WebViews where I already advise not to use WebViews if your app involves processing any data that needs to remain secure.

Related Articles:

Permissionless Innovation

September 29th, 2014
Steve Cheney Technologist, thinker and doer and co-founder of Estimote, has an interesting, pro iOS, post on The Future of Apple and Google. In his summary he says…

"It’s provocative to think about where Apple and Google each go next. In mobile there’s a term called ‘permissionless innovation’, the basic  premise of which is you don’t need anyone else’s permission to innovate. The beauty of the modern mobile era is that it isn’t held back by anti-innovators like the carriers or monopolists like Microsoft and Intel who gated the pace of innovation in previous platform eras. The mobile stack has decoupled these previous incumbents from control."

While things are more open than say 10 years ago, I believe progress in areas such as mobile payment and use of NFC have been held up by Apple. Steve says "Apple Pay is 3 years ahead of Google in almost every regard". This might be so for Apple’s small scale Apple Pay. Meanwhile, the World needs something more universal.

Apple Pay is half way there but has Apple’s characteristic ‘let’s do it our way’. Another example, a client I am currently working with creates NFC tagging solutions that they would love to offer across iOS and Android. For now, it’s Android only even though iOS now supports NFC. It’s similar with iBeacons. iBeacons are based on Bluetooth LE. On Android it’s possible to detect all Bluetooth LE devices in the vicinity, including iBeacons. On iOS you have to know the beacon (id) you are looking for before it can be detected. Again, Apple have implemented something to satisfy just their needs. This isn’t an Android vs iOS thing. Businesses want and need to innovate across all mobile platforms. A 3rd party solution offered across all platforms will benefit everyone.

Another small thing and a bit of a curiosity, even Apple’s USB extension cables are protected against use with other cables.

In this post I have perhaps unfairly targeted only Apple. To redress the balance, latest news of tightler control of Android hardware OEMs and controlling developers  suggests that ‘permissionless innovation’ is starting to undergo lockdown even within Google. On the latter issue, Al Sutton has contacted the EU competition commission asking how Google can enforce a SLA on developers when Google themselves don’t have an SLA for developers. It’s an interesting question, especially when a problem might originate at Google rather than be within the app itself.

UPDATE: Mark Murphy has predictions of the Play Store fallout. He anticipates more intermediaries will end up selling apps but he says "Some agents will likely be scum, if for no other reason than middlemen tend to run the gamut from sensational to scum in other places".

UPDATE: Meanwhile, the EU Director-General for Competition is probing Android OEMs on their contracts with Google.

The Best Way of Doing Things

September 26th, 2014

uxmagazine.pngUX Magazine has a recent article on balancing product User Experience (UX) and lean execution. It describes how effort put into the UX should vary depending on the stage of product development. For example, if you are at the initial ‘Technology Stage’ you probably need little UX effort and should be concentrating on a minimum viable product (MVP). Conversely, if you are at the ‘Experience Stage’ you need to concentrate heavily on the UX.

There’s more to learn from this. The preponderance of conferences, articles, webinars, blogs and even my sites describing how things should be best done are often taken to be the way they should be done. People love to latch onto the ‘best’ way when, in fact, the best way depends on the situation. You can usually recognise this when someone says ‘that’s the accepted/standard/best way’ in response to a discussion, with no further justification.

This doesn’t just apply to UX. In app development it applies to many other areas such as what server backend to use, what 3rd party libraries to use, how secure the app has to be or even what mobile OS platform to use. The next time you have a choice how to do something don’t just look at reviews/comments on the technologies available but also think about the project situation. This includes the stage of product development, the team’s skills, the budget and timescales.

If you are a startup creating a team, remember that some seemingly clever but pedantic people can send you down an expensive and deep back hole. Instead, search out cleverer pragmatic people who have previously demonstrated they can balance implementation with the needs of the company.

Related Articles:

Android vs iOS Development and Ageing Apps

September 23rd, 2014

gqueues.pngI came a cross an article today comparing the development of the same app, across iOS and Android, by a programmer not experienced in either platform. There are some useful insights such as both platforms took approximately the same time, needed a similar number of lines of code and that neither platform outshone the other.

One aspect I find interesting is that iOS took longer to learn due to the quantity of outdated documentation. This is a problem on any platform, especially for newcomers. It can take a long time to assess what’s an old way of doing things, what’s a newer way and what’s best given interoperability with other parts of the app. Android apps I wrote in 2008 used some internal mechanisms that, while recommended by Google at that time, are now frowned upon. Developers such as myself need to keep up-to-date but interestingly, old apps don’t tend to need to keep up-to-date unless they are successful enough to warrant being updated. Apps age if not updated.

Apps can also age when their look and feel no longer fits the latest update to the OS. They can even occasionally but rarely die if a new API is different or, more commonly, the OS changes to do the same things but in a different order.

The effort required to keep apps up-to-date shouldn’t be under-estimated. Often companies only financially plan for initial development when, in fact, they usually have to be maintained to at least support new phones and screen sizes. I have even had a few cases, particularly when the app has been successful, where the ongoing development has been orders of magnitude greater than the original development. Another related question to ask yourself is whether your developer will still be around to do such changes.

Related Articles:

The Web vs Apps Outcome

September 22nd, 2014

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.

Related Articles:

Collaborative Battery Use Analysis

September 18th, 2014

carat.pngThere’s an interesting free app for iOS and Android called Carat created as a research project by UC Berkeley and the University of Helsinki that performs collaborative analysis of battery use as well as personal recommendations for your particular device.

The statistics page shows some pretty, interactive the results from the 760,000 people who have installed the app. The public admonitions of particular apps are a great incentive to keep your app out of the analysis of energy-intensive apps. I am not sure why it’s called Carat though given that their icon is a carrot.

Related Articles:

Interesting Android Projects

September 17th, 2014

android.gifThere’s a post by Alessandro Crugnola that asks why it’s hard to find Android developers. He thinks it’s because most companies do iOS first and the Android work is a less-interesting porting job that companies are less committed to, don’t take advantage of the benefits of the platform and consequently end up being not as good as expected with lower profits compared to iOS. He says developers don’t want to join a company where Android is 2nd choice.

While I suppose this is partly true and there are some good examples where great Android apps such as Evernote monetising better on Android (PDF) than iOS, Apple will always have the high-end customers with greater disposable income that will cause iOS first strategies.

Having said this I am doing more and more work that will only work on Android. My current work for Tap2Connect involves use of NFC that won’t work on iOS. My work for Vizzbook involved use of tablets in a kiosk type situation that couldn’t have been implemented on the iPad and the devices would have been too expensive anyway. My work for IRISS Medical involved (and still involves) image processing of high quality 15Mpixel images that can’t be obtained on iOS devices. My work last year for an entertainment hardware manufacturer to re-purpose inexpensive Android TV devices wouldn’t have worked on iOS devices. There’s lots of opportunity in areas iOS can’t reach.

There are some interesting projects out there that make best use of the Android platform but they tend to be Android-only rather than Android and iOS. One observation is that these projects tend to, but not always, have longer lifetimes than apps that are just ports of ‘information’ type iOS apps. The business models also tend to be B2B rather than B2C even if the end user of the app is the mass market.

Related Articles: