Will We See Android-Like Instant Apps on iOS?

A couple of days ago, at its I/O conference, Google introduced Android Instant Apps. Long story short, we'll be able to use an app without installing it first. In Google's example, tapping on a link to BuzzfeedVideo opens, after a short loading time, the native app instead of a website. To me (and not only me!) this feels like magic future.

There's a good demo of this in the video below.

I like this concept because it lessens the friction of using native apps. I'm sure it'll be beneficial both to users and developers. As a person working on iOS apps on a daily basis I started to think: would this be even possible on iOS?

I came up with the conclusion that three objectives have to be met for this feature to see the light of day on iOS. Let's analyze each of them.

1. Modularization

The documentation of Instant Apps is sparse at this moment. Luckily, we can learn a thing or two from the FAQ (emphasis mine):

Q: Do developers need to build two different Android apps now?

A: Developers only need to maintain one project with one source tree. Developers simply configure the project to create two build artifacts: the installable APK and the instant version. (...)

Q: What Android APIs and functionality can Instant Apps use?

A: Android Instant Apps functionality complements an existing Android app, but does not replace it. Android Instant Apps uses the same Android APIs, the same project, the same source code. Android Instant Apps restricts some features that might not match users' expectations of an app that is not installed. For example, an Instant App can't use background services, do background notifications, or access unique device identifiers.

Does that ring a bell? It sounds like app extensions on iOS to me! As a reminder, an extension is a separate binary that runs in a different process than the app that contains it. What Apple needs to do is add a new extension type for instant apps. As for code sharing, we can keep it in an internal framework that's used both by the extension and the app. So, nothing new here.

As hard as it is to admit, iOS apps aren't modular by the default. I think it's the case because of the current UIKit architecture and recommendations, such as the use of storyboards. I don't expect a sudden introduction of techniques allowing the app to be split into independent modules that can be downloaded separately to the device. That's why I think extensions fit this use case quite well for now.

2. Discovery

To be able to use an instant app we have to first hit its entry point. Google showed us three types of them but let's focus on the most important one only: an instant app opens instead of a website.

We already have an infrastructure on iOS for mapping URLs to apps in the form of Universal Links. There are two changes needed here, though. First, we need a possibility to map a given path to an app extension. Second, these mappings should be available for all apps, not only those installed on the device.

(This would also solve a long-standing problem of passing data through the App Store. It had to be solved by third parties.)

3. Distribution

If we assume that Apple will indeed go with the proposed solution, distribution won't be a big issue. Extensions are separate binaries, so they can be downloaded independently of the app binary itself.

What's more app slicing and Bitcode, introduced in iOS 9, will become really important. Short loading times are a selling factor here.


It looks like we can see a version of instant apps on iOS sooner rather than later. I don't know about you but I can't wait for WWDC16.