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:

roamTouch GestureKit

September 16th, 2014

roamtouch.pngI have been following roamTouch for a long while now. Their latest incarnation is GestureKit a cross-platform tool to create and use gestures in apps. They currently have a new Indiegogo crowdfunding campaign to fund further development.


The proliferation of apps, devices and types of device increasing need new ways to control them more easily. GestureKit extends and adapts the popular swipe metaphor to help people cut through complex UIs and do things with the minimum of steps. 

The Future of Apple Pay and NFC

September 15th, 2014

apple.gifI have been analysing Apple Pay to determine if it’s likely to accelerate mobile payment in general and the use of NFC. FirstPartner have an explanation how Apple Pay Works and Penrillian explain how the market isn’t open yet.

The initial implementation is US only, supports only 1.5% of US merchants, relies on the unpopular Apple Passbook and will only work on newer devices containing NFC. Hence, in the short term it won’t be used by many people. More importantly, the implementation is currently closed in that it only allows NFC payments via Apple. It isn’t possible for third parties to use NFC to build more universal, ubiquitous payment solutions. While the essential building blocks for ‘universal’ NFC-based systems across Android/iOS will soon be in place, such systems are blocked by Apple’s strategies.

NFC isn’t just about payment. It can be used in security, authentication, stock control and a myriad of contextual triggering apps, many in the growing realm of the Internet of Things (IoT). All these possibilities of using NFC are closed on iOS for now. However, I suspect that as with apps, when initially Apple said there would be no native apps and only web apps, they will have to open things up. A universal payments system is too compelling and it’s incomprehensible that Apple will stay closed in this area for so little apparent gain. The Internet of Things needs NFC as well as Bluetooth LE (iBeacons). I believe Apple will see themselves under increasing pressure from many directions to open up the NFC APIs.

Update: Adam Cohen-Rose has pointed me to an interesting article by Clover that describes how the network-side token system was proposed/implemented by the payment networks (Mastercard, Visa). There’s no reason why this couldn’t be, and probably will be, implemented on say Android. This suggests a ‘universal’ system might be viable provided it uses a similar network-side token system.

Update: In an email to Cult of Mac, an Apple spokeswoman confirmed that NFC chip on the iPhone 6 and 6 Plus is only for use with Apple Pay. Like Touch ID on the iPhone 5s, Apple is keeping its NFC restricted from developers, at least for its first year.

Update: Mark Ranta asks Where’s the Beef? and hopes Apple Pay is just the first (baby) step.

Update: Teardown shows NFC chip is from NXP.

Update: Why Apple Pay Won’t Work.  

Related Articles:

Comprehensive Mobile Device Usage Report (and data)

September 11th, 2014
scientiamobile.pngScientiamobile has a MOVR report for April to July 2014. It’s a free report (pdf) based on WURFL and WIT usage data. It gives information on smartphone and tablet use across manufacturers, devices, operating systems, screens size and countries. 

The report covers only a small subset of the raw data that’s also available as csv and JSON data. The data is useful if you wish to analyse usage in a specific country or for a class of devices.