MobileTechTalk At Google I/O, the Mountain View software and services giant unveiled a number of new additions to their Android and ChromeOS eco-system. One of the more intriguing was Android Instant Apps. We’ll explore what exactly that is, and what future consumption practices it might be hinting at.
Android Instant Apps
The Android Instant Apps feature was greeted with a flurry of applause and whoops of excitement by the crowd at the Mountain View Google I/O event on May 18th. The ability to be using your Android device, and access content requiring a third-party application (such as an image that links to an Etsy shop for example) seamlessly without having to download that application, or indeed without being pushed to a rendered webpage is certainly something that was demonstrated really well and further cements the embedded user experience. With similar content being consumed in many different ways, such as “shortform” videos available from Snapchat, Vine, Instagram, etc, it’s becoming an increasingly difficult and messy task of ensuring users have access to the specific application they need to consume the chosen content. This is precisely the type of problem that Google seeks to address with Instant Apps; ensuring a more integrated experience for the end-user.
https://youtu.be/cosqlfqrpFA
Why This Solution Exists
Android Instant Apps can be seen as an evolution in the delivery of the very best applications from the Google Play Store to the user in the most efficient and seamless manner. That’s one reason for Android Instant Apps. Another is content segregation and clutter.
Google now boasts over 2 million apps in their store with over 65 billion combined downloads. With those sorts of numbers, it is no wonder there are similar and competing applications (a flurry of chat, video consumption, social media and music apps come to mind) throughout the categories, all with compelling content offerings that users will need/want to be sure they have access to in order to keep up with the Jones’s and join in the communities. By delivering a platform by which these application offerings can work harmoniously, without the user having to specifically download the required applications, the user is kept within the service experience and can complete an activity or action without interruption. It’s a very strong initiative and the fact it’s being touted as being backwardly supported to the Jelly Bean version of Android is nothing to be sniffed at.
Many Questions?
We’re still to fully understand how Android Instant Apps will be deployed and the exact implications but some are already asking how this will affect the Android eco-system landscape as it stands. For example, paid applications will no doubt be exempt from this feature. Linking to content behind a pay wall, or to an application that requires a purchase would be an instant experience break point and as such I don’t expect these to be included. How big an issue could this be?
Another question being asked is how this will affect Play Store download metrics. Developers use the analytics provided by Google to understand how their application is being used and base future development and feature decisions, along with other considerations, on these metrics. How will taps launching segments of their applications be recorded and reported to developers? Could this lead to a more service orientated Play Store offering with “Instant App Integrations” being offered outwith developers’ main applications, regardless of the fact that the Instant Apps project does not require it as such? As consumption of services offered within Play Store applications are subtly altered by this feature, will it in turn alter how developers look to deliver that same experience?
A Big Question
Another question is could this feature invariably point towards a non-native application future? Android Instant Apps looks to resolve a burgeoning problem caused by application saturation. The same can be said for cross-platform utilisation also. Instant Apps is a step towards resolving this problem within the Android eco-system, however cross-platform ambiguity remains.
Canonical’s Ubuntu operating system introduced a notion called Scopes in their Touch mobile version. Scopes delivered what are essentially rendered web apps (I know they’re not…but for the purpose of this editorial, we’ll call them that) to Ubuntu phones, and allowed the same access to services and media as native applications delivered to Android and Apple app stores. Mobile Web Apps are both a thing of the past and perhaps the future. Back in Windows Mobile days, the majority of the interaction users had with internet aware applications was indeed via the built-in Internet Explorer browser. Accessing a mobile version of a desktop site provided a richer (very slightly in those days!) mobile experience. As developers looked to provide a better medium to provide their services, native applications were born and the features and encompassed services became even more pretty and seamless to consume, within that said app. Joey-Elijah Sneddon described this feature as “Ubuntu Phone’s secret weapon“ in a 2015 piece on the operating system back in early 2015, and I think that still holds true despite the struggle Ubuntu has had attempting to gain a foothold in the market.
However, the dearth of similar applications across platforms is not only causing app overload, but a confusion to a user base simply wanting to access well-worn services. This is precisely where I see non-native applications becoming a thing once more. Not only would non-native applications delivered directly by webmasters provide a richer experience than back in the old PDA and Windows Mobile days, but it would also bring developers even closer to their consumers, providing a monetary gain directly to the bottom line. Gone are the developers for Android, iOS, Windows Mobile (they are out there you know) and the like, and also gone is the App store mark up for accessing a large demographic. The middle man is essentially removed making this a viable prospect for financial and indeed user experience reasons. Let’s be honest though, the former would be the driver which is what makes Instant Apps, and the progression of seamless application/service access, compelling.
Will this happen any time soon? Perhaps not, but the fact that this is happening within isolated eco-systems (Android only currently but don’t expect other platforms to be too far behind) might just hint to a future in which applications are developed once, and consumed directly by all. That’s a future I’d be happy with and it’s an exciting one for developers, service providers and consumers alike.
