Gartner Q1/17 Smartphone Sales

Gartner has new research that says Worldwide Sales of Smartphones Grew 9 Percent in First Quarter of 2017. Here’s the breakdown by operating system:

What’s significant is that the ‘Other OS’ category is now negligible at 0.2%. There are effectively only two mobile OS platforms, iOS and Android.

Where are the IoT Mobile Opportunities?

I previously wrote about IoT and mobile and how IoT (still) needs custom development. Server side dashboards and remote apps are needed to control devices and visualise data. So, if you are thinking of getting into IoT apps, where are the opportunities?

McKinsey has a useful article where they estimate the potential impact of IoT on various industries:

‘Factory’ has the greatest opportunities. Don’t just listen to one analyst house. Argus Insights provide a different view of mindshare:

Again, industrial comes top. As with mobile apps over the last decade, the best opportunities for startups aren’t necessarily the higher profile consumer-led apps.

Posted in IoT

IoT and Mobile

I have been coming into contact with more IoT projects and have started going to IoT meetups. Whatever way I look at it, IoT seems to need custom solutions and custom software development. While platforms initially seem inter-operable via things such as MQTT or COAP, the data that sits on top of these is proprietary. Also, in a rush to create SaaS platforms, the facilities tend to be ‘lowest common denominator’ so if you want alerts, processing or dashboards specific to your particular industry then these aren’t available and you are instead usually encouraged to create your own via data available via HTTP/REST.

My conclusion has been IoT (still) needs custom development. This custom development also often involves mobile to provide for remote control, analysis, visualisation and the generation of alerts.

Posted in IoT

StackOverflow 2017 Developer Survey

StackOverflow has a new Developer Survey of over 64,000 developers. What’s surprising is that a large proportion of developers are new to software development. This is good because the industry needs more developers but it might be bad if you are looking for someone experienced to implement your project.

It’s interesting that iOS and Android now have numbers of developers of similar orders of magnitude to long time popular platforms such as Linux and Windows. There are also more Android developers than iOS developers:

Not Impressed With Android O

I have been looking into Android O and I have to say I am disappointed with the introduction of background limits. This post explains what this means for product owners, developers and the end-user experience.

Many apps, for example those that fetch data in background or scan for Bluetooth devices, do these things so that when the user gets to a particular screen, the data is already there. The most common way of doing this is using services. From Android O, services won’t be able to be run reliably in background unless they are foreground services – these are the sort that you might have seen, that have an icon permanently in the notifications bar. Google recommends services such as these be replaced by use of JobScheduler jobs.

Existing apps built against earlier Android versions aren’t affected. They will continue to be able to use background services. As with the previous permissions debacle, when updating apps (or even creating new ones), developers can avoid building against Android O. However, ‘you can run but you can’t hide‘. You will eventually need new features provided by Android O or later and have to consider what to do.

The long tail of apps, not created by large companies, don’t get updated and those that do minimise effort/cost. Developers wanting to build old apps against Android O will end up either a) promoting services to foreground causing lots of icons to become visible in the notifications bar or b) ignoring the problem or c) using JobScheduler. I suspect, due to limited development effort, most will pick a) or b). The affect of b) can already be seen in Android’ Doze mode that causes no messages to be seen when you pick up the phone and then tens of seconds later everything comes in. Expect more of this kind of ‘stuttering’ performance.

As with the introduction of the need for permissions dialogs, Google continue to make development more complex and costly while also compromising the user experience. I have to question whether Android dev team has it’s priorities right. What’s the obsession with crippling app background capability? This is one of the areas where Android is (currently) much more capable than iOS.

In real use, it has been my experience that devices with lots of apps with lots of services don’t tend to flatten the battery. It’s using the phone, causing the power-hungry screen to be turned on, that mainly flattens the battery. There will always be a mix of old (pre ‘O’) and new (‘O’ +) apps on the device so Google won’t be stopping all background activity, so what’s to be gained by all this extra complexity?

Cloud Functions

Firebase recently announced Cloud Functions that allow you to call into code running in Firebase from iOS and Android. This idea isn’t new and is similar to AWS Lambda. In fact, the idea is old in that CORBA had callable server side code decades ago. However, the subtle difference this time is that code can be run without provisioning or managing servers.

So when might you use code at the server? It tends to be used when you need one or more of:

  • More computing power than available in the smartphone
  • When there’s need to access data, for example ‘big data’, not available on the smartphone
  • To protect intellectual property to secure code so that it can’t be reverse engineered or decompiled

In an era where developers are tending to use new, usually more complex, mechanisms just because they seem fun, rather than for valid business reasons, I encourage you to not use cloud functions ‘by default’ and instead use them for a valid reasons.

Edge and Fog Computing

There’s a growing number of organisations thinking that cloud computing and the intermediate communications systems won’t eventually be able to cope with the extremely large number of IoT devices.

Computing near the IoT devices themselves, called Edge or Fog computing, will allow data to be filtered such that only pertinent data ends up in the cloud. It will also allow data to be cached when it can’t be sent yet. Also, there are classes of IoT ‘things’ that need local processing to remove the latency of otherwise using communications/cloud computing and thus provide more immediate alerts and information.

Edge devices can be the IoT devices themselves or low end devices such as Dell’s Edge gateway. They can also be intermediate gateway devices such as the Intel Edison.

An interesting prospect and opportunity for mobile developers is the use of smartphones as edge devices or even devices based on AndroidThings.

When Your App Needs Updating

Too many companies view app development as a one off activity that can be outsourced (external or internal within the company) and then, once complete, not require the developer any more. However, most non trivial apps need ongoing support of some kind.

Things break. New phones are released and new versions of operating systems cause things to break or misbehave. People, perhaps working on things that the app connects with, change things that cause the app to need to be updated.

Things need investigating. Often there’s a need for 2nd line support to work out what’s happened – even if it’s ‘user error’ and not a fault of the app.

Things need improving. Almost every non trivial app I have worked on has undergone small changes after users have fed back how it can be improved.

Review criteria evolves. What passed Apple’s tight scrutiny a year ago might not pass now. Changing your app in any way might cause it to have to be further updated to meet tighter new criteria.

Factor in time and cost to update your app after it has been initially released. Talk to your app developer before this happens so you have some arrangements in place.