Even as the salty old guy at BrianMadden.com, I still find myself surprised when old approaches to problems pop up in new ways. The latest instance of this is with regards to Android phones and a feature called Android Instant Apps, which I learned about when Jack came to me a few weeks ago and asked me to "check out this Android thing because it sounds a lot like app streaming."
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
At the risk of over-simplifying it, he was right…Android Instant Apps looks like App-V for Android. To be clear, there's no isolation happening, and this isn't a new way to manage applications for Android devices. The messaging around Android Instant Apps is actually closer to that of SoftGrid, the precursor to App-V, rather than the way we think of App-V today.
In a nutshell, Android Instant Apps are delivered to mobile devices (running Android 5.0 or higher) without having to be fully-installed first. This saves space on the mobile device, and allows users to get up and running faster on new devices. And though I'm taking a look at it from an enterprise perspective, it could very likely have a huge impact on consumer app adoption, too.
Digging a little deeper
Users access an Instant App by tapping a URL that prompts Google Play to check for an Instant App version of the app. If it finds one, it's launched automatically (provided Instant Apps are allowed in the device's Settings) without having to go to the Play store, searching for the app, and installing it.
While the high-level description of what's happening sounds familiar, creating an Instant App is quite different. There is no sequencing process to go through in the classic sense. Instead, developers must engineer the app in a specific way while taking advantage of the Instant App APKs. Essentially, this means refactoring the application into individual modules for each feature that you want to be able to deliver separately. Each app must have a single base feature, on top of which other features can be downloaded and executed.
When a URL is tapped and an Instant App version of the app is found, the base feature of the app is downloaded and run on the device. Then, as the app is used, other features are downloaded as needed. There are methods exposed in the APK that allow you to let the user choose whether to fully install an Instant App, if you choose to let them. They can also install the app directly from Google Play.
Google uses the example of an application that uses a map to help you find your current location, search for restaurants, and share your location with friends. In this example, the map feature would be the base feature, and the other features would download as-needed. You can easily picture this same approach applying to an expense tracking system, where the login screen might be the base feature, with other features (or modules) for travel, approval, and expense entry available on-demand.
A few weeks ago, Instant Apps was extended with a feature called Configuration APKs. These Configuration APKs allow you to further compartmentalize what is delivered to the user based on the capabilities of their device. Right now, the capabilities that can influence an app are limited to display density, CPU architecture, and language. With these you can deliver, for example, just the English language to devices that use English, rather than all the other supported languages your application might have.
The most obvious difference here (besides the lack of isolation) is that it's not your in-house MDM admin that is packaging apps up anymore. To do it, you'll need a developer, which if your app is made in-house is one thing, but if it's in the public app store you'll have to talk to the ISV to get this done. If this catches on, though, that might not be a big deal, especially since the result of the refactoring is a better-designed piece of software.
I guess you can call this "Modern App Streaming" or something to that effect. It's cool to see these old-ish concepts applied to modern use cases, but still solving a similar problem. The size of mobile apps grows the more we use them, so being able to deliver just the features a user needs on-demand is sure to be valuable to anyone from both a device storage and a bandwidth consumption perspective.