May 28, 2020
Making Mobile Work
In my previous article, I discussed how Moore’s Law is no longer providing the regular exponential increase of processing power that we’ve grown accustomed to, but that there are plenty of cycles of power available on mobile devices, if a way can be found to make use of them. To establish the possibilities for this, we first need to look at the current state of mobile development.
Modern Mobile Development
The vast majority of Smartphones today run one of two operating systems, Google’s Android and Apple’s iOS. Native applications are written for one or the other (in Java/Kotlin or Objective-C/Swift respectively), with little in the way of code sharing. They are both capable of performing the kind of work that a server typically performs, but nobody wants to write data processing code twice, so this kind of work is almost always done on the server with the results delivered over the network.
Efforts at cross-platform development have had some success, and broadly boil down to using one of two approaches:
The first involves creating a single UI and building a framework to run it on multiple platforms. Typically this involves creating an app that runs in a web browser and packaging it up to run on both platforms (e.g. Cordova/PhoneGap/Progressive Web Apps). These techniques involve a pretty severe performance hit, and a Google technology called Flutter aims to improve on this and is beginning to gain traction. It follows a similar approach, though it forgoes browser tech in favour of a custom UI model (that can be run on multiple platforms) based on Dart.
I’ve personally been monitoring and trying out various cross-platform strategies over my 15 years as a mobile developer and what has become clear is that the pareto rule very much applies. Cross platform tech can get you to 80% of the functionality of a top quality app but getting to 90% is hugely challenging and 100% is often simply out of reach. A decision that makes sense in the beginning of a project, that lets you get off the ground quickly can become a massive tech debt down the line that is difficult to overcome. Airbnb for example championed React Native for many years before deciding that it was more hindrance than help.
With these drawbacks in mind, a third approach to mobile development is emerging, the move from cross-platform development to native multi-platform development. It is characterised by the sharing of native code where possible and – unlike all other cross-platform efforts to date – leaves UI development to the native languages and frameworks of the two target platforms. iOS and Android are different, and attempting to write a single UI for both is challenging and arguably counter-productive. What you gain by giving up the idea of sharing the majority of UI code is a solution that is without compromise when it comes to user experience. This practice is enabled by the rise of a new technology called Kotlin MultiPlatform (KMP).
What Kotlin Multiplatform means is that there is a possibility of sharing code between iOS and Android that is performant and already familiar to many mobile developers. There is no third language, no middleware. Just two native platforms and two native languages that share many similarities.
So with the possibility of writing modern, performant code that works on both platforms, what are the possibilities for running it? The majority of tools available on mobile are unsurprisingly to do with user actions and UI, but it is possible to do background work on both platforms, and signs indicate that the two platforms are converging as well.
iOS has always been quite strict on background processes. Until recently background execution was exclusively meant to support tasks initiated by the user, such as allowing extra time after a user action for a task to complete. There is also some possibility of using background fetch, usually triggered by a background push message from the server. This capability is aimed primarily at downloading data, and has a strict 10 minute time limit. However, with iOS 13 they are introducing BackgroundTasks which is a framework designed to allow tasks to run in the background when the system judges it is a good time – typically while the device is charging and/or idle. A Background Processing Task has been introduced with the intention of allowing data maintenance operations. These are allowed to run for “several minutes” – which seems intentionally vague – and they even have the capability to turn off the CPU monitor to allow for full performance of the processor, so it certainly seems they are aiming for non-trivial work.
Android on the other hand has historically been less restrictive when it comes to background processes. It still is, though efforts at battery life optimisation has led it down a similar path to iOS. The broad thrust of these is that background processing shouldn’t happen unless there is a visual indicator of the action, e.g. if the app has its UI in the foreground, or a notification showing. Like iOS, push messages can also be used to wake the app to do work, and the inspiration for iOS’s BackgroundTasks is almost certainly Android’s WorkManager class which makes it easy to schedule jobs to happen at opportune times, such as while charging or connected to unmetered internet.
Putting it all together
So the pieces are in place to make use of the mobile devices for crunching data. What kind of data? Machine learning has emerged as one of the most exciting and important areas of software development. Gartner predicts that by 2022, 80 percent of smartphones shipped will have on-device AI capabilities, up from 10 percent in 2017. There is no greater source of contextual data than that available to the device that we all carry with us. This includes user actions in the app, sensor data, location data, activities, steps, etc. It should be assessed whether it makes sense to push all this to a cloud server when the processing could all occur locally to the user while they sleep at a negligible cost. And aside from cost benefits there is also an argument on privacy grounds. Keeping all data on-device ensures greater data protection, something Apple clearly believes in, as the world-wide debate on COVID-19 contact tracing apps has shown.
Google’s MLKit is a very capable machine learning platform and is made available to both iOS and Android devices via Firebase. Optical character recognition and natural language processing – these are technologies that only a year or two ago were only available in the cloud but are now available on-device, often without any need for cloud connectivity.
2020 is likely to be a turning point in this area. KMP is still quite arguably in the realm of bleeding-edge technology. While Kotlin is fairly mature, KMP has not yet reached version 1.0 though it is expected to arrive there (as part of Kotlin 1.4) later in 2020. That said, it is already being used in production by multiple major tech companies.
Want to learn more about KMP? Touchlab – a mobile development consultancy in New York has become KMP’s biggest standard bearer, doing all of their development using KMP. Their blog is a good place to start. For a constantly growing collection of technical articles, kotlin academy is also a crucial resource.
Exponential growth in processor capability is slowing down as an engine of growth for data intelligence. There are great opportunities for those who can learn to intelligently use the latent supercomputing capability we carry in all of our pockets.
Elliot has been developing apps for mobile devices since 2005. Originally from Silicon Valley, he attended university in Birmingham, UK and has worked with various startups and SMEs in the UK, Spain, and Germany. Since 2018 he’s been overseeing all aspects of mobile software development for Snowdrop Solutions.