clock menu more-arrow no yes mobile

Filed under:

The Dynamically-Delivered Future of Mobile Apps

When can we expect to see truly contextual, on-demand delivery of apps to our phones?

The fundamental state of apps hasn’t changed in the past five years. They are smarter, faster, and there are definitely more of them. However, the basic story remains the same. You go to an app store, browse for an app and tap “install,” then it pops up on your home screen some time shortly after.

Downloading an app is a long process with several disconnects, not to mention the challenge of discovering and choosing which apps you want to download in the first place. I know that I often forget what I was doing and why I wanted the app by the time I’m actually in it. While we’re used to this process, to be frank, it’s terrible.

I’m going to outline another way of thinking about app delivery that I think will be possible in the near future; one which makes discovery faster, installation transparent and the home screen close to redundant. This concept, called “dynamic delivery,” involves delivering an app to your phone, not directly because you told your phone to install that app, but rather in response to a request for some content or action that is best delivered by installing that app.

Spotify did a similar thing for music

Do you remember the first time you used Spotify?

Where is my music? The music I downloaded … ?!

Spotify moved our understanding of music from a model where music was installed on your devices to a model where you had access to everything, but no ownership relationship with anything. Over time, Spotify has honed the product to help people understand and feel reassured, while also feeling connected to the music they consume frequently on Spotify.

This shift in the model of how we own and access content is the beginning of a trend that will extend to the apps that provide us with access to that content. Why does a user care if they own the New York Times application? The NYT app is simply the best way to get access to the content that the user wants. If I want to view an NYT article, why not show me that article in the NYT app, whether or not I currently have that app installed?

What is installation, anyway?

Installing an app is something of a misnomer from our Windows days, where the process of making software run was a lengthy one that required files and data in many, many different places, but it’s the term that users understand. On iOS, for example, installing an app is (pretty much) just dropping a zipped-up folder into an applications directory.

Web pages aren’t “installed.” At the core, both apps and Web pages are collections of text, images and styling information, along with a computer program that handles anything more fancy — dynamic content, transitions, etc. In both cases, this program is run on your phone and manipulates the text and images. The only difference is how the application gets to your phone, and there’s a pretty big experience gap here.

A Web page triggers the download of all of the images, text and application logic simply by browsing to a Web address. Once it’s downloaded and available, it begins to interpret and run the code it downloaded. This is clearly superior from an ease-of-use perspective for the consumer, so why do mobile apps follow the much more involved convention of installation, when we had a better way of doing things before we even invented the current generation of mobile apps?

The fear of dynamic delivery all comes back to security; specifically, our fear that people could run programs that do pretty much anything on our phones (Arbitrary Code Execution, if you’re interested in reading more). In the old world, a feature like this would allow malicious app developers to access your personal information, delete files and even render your phone unusable.

The Web (and Web browsers) were built from the ground up with the assumption that no outside party could be trusted. It’s almost true to say that the Web browser’s primary goal is isolating the Web page from your computer in a way such that it is safe to allow the Web page to do clever things on the page while leaving your computer totally untouchable. The program on the Web page can only read or modify information that belongs to the page itself. This concept is called “sandboxing.”

Mobile apps employ sandboxing, too, but for software installed on your computer or phone, it’s much more difficult to completely isolate the installed app from the overall functionality of the device. The software is more powerful, has direct access to the hardware of the device and is (by design) able to access your file system (so that you can open your files), your Internet connection (so that it can load data), etc.

Sandboxing + review = safety

Apple took a very hard line on application sandboxing from the beginning. It’s rare that we talk about Apple’s sandboxing and review process in a positive light, but in this case, it may truly be a gift. Apple’s rigorous review process and aggressive application Sandboxing Policy create an environment where providing some complex functionality can be difficult or even impossible, but as a trade-off, downloading unknown apps isn’t very risky at all; just like downloading Javascript on the Web.

If I download an app at random from the App Store, there is (theoretically) no risk to me, my data or my phone. This is a very powerful statement.

The first steps

We’re beginning to see a reduction in the friction to find an app. In iOS 8, Apple removed one step from the installation process with the introduction of Spotlight-based app discovery. Now, search results for app names, related terms (and sometimes seemingly-unrelated terms) will display a section titled “App Store,” which, when tapped, will take you to that app in the store.

Beginning an app search has moved from two taps to one swipe in a piece of screen real estate that we’re all very familiar with. A win, but a small one. If I want to read an article from the NYT, I can search for “NYT” in Spotlight, then find the app in the search results and tap it to be taken into the App Sore. From here, I can download the app and then go and find the content I was looking for.

Now with dynamic delivery

This is one less step, but there’s still a clear disconnect; the discover and installation of the NYT app was totally unconnected with the content that I ultimately want to consume. I had to know by myself that the NYT was a good place to find that content, download the app and then open it.

It can be assumed that a company’s app is their preferred way for users to consume their content, and we’ve already established that installing an app is risk-free. It then makes sense to extend Spotlight search to discover app content and deliver the right app to “view” it, in the same way that a website instantly delivers the correct page and Google indexes the content of websites.

In a world with dynamically delivered apps, searching for a relevant news term could return a result from within the NYT app. When you tap the result, the NYT app would be seamlessly downloaded to your phone and the application deep-linked to the content you wanted. Or searching for an address would provide an Uber result which would download Uber and present you a ride-confirmation screen. Subsequent content from these apps would be available instantly, as the app would be “cached” on your device.

In this model, your home screen is considered to be your favorites. These favorites will never be deleted from your app cache for quick access, but all apps are always accessible, and will be loaded from the App Store as needed.

It’s still early days; right now, the average install time for a utility app is around the 30-to-60-second mark. This was true of Web page load times just 10 years ago, though, and if this paradigm becomes successful, apps will move to a model of minimum upfront install size with follow-up background downloads for additional functionality. LTE gets faster every day, too — this doesn’t seem crazy in the near future.

What about purchasing apps? Today, 46 of the 50 top-grossing apps in the Apple App Store are free and supported by in-app purchases, functionality or content that can be purchased from within the app. This number has been growing over time, and none of the Top 10 apps (by total gross) are charged for upfront. This week, Apple removed the price tag from free apps and replaced it with the word “Get.” There were legal motivations to make this change (there have been multiple court cases about “Free” apps causing hundreds of dollars in in-app purchases), but removing the price tag from free-to-download apps reduces one of the barriers between where we are and apps being invisibly delivered on demand.

Why do this? App discovery is down. A recent comScore report showed that roughly two-thirds of smartphone users don’t download a single app in an average month. We have app fatigue; most users have solved their basic needs with apps already on their phone and see no need to add more, despite the increasing amount of time they spend in apps.

While we’re making parallels to the Web, imagine if you had to have every Web page that you ever visited on your home screen. That’s essentially the case with apps right now. The favorites model makes far more sense, and will help usher in an age where the average user can interact with hundreds of apps rather than just 30 to 40 that stagnate, which is where we are now.

When do apps become dynamically delivered?

When can we expect to see truly contextual, on-demand delivery of apps to our phones? There’s only one company that can do this in the Apple ecosystem, and that’s Apple. The pieces are in place, we just need the glue.

Moving to dynamic delivery of apps increases discovery, reduces friction to download and gets users to the point that they’re actually spending money in 2014 — in the app, once they’ve actually used it. I wouldn’t be surprised to see us take significant steps toward dynamic app delivery in iOS 9 and 10. This will bring mobile apps closer to the vast interconnected graph of content and applications that has emerged on the Web. With it comes richer experiences, greater discovery and collaboration creating a better mobile experience for everyone.

Chris Maddern is co-founder of Button, the leading customer acquisition and retention platform for the on-demand mobile economy. Prior to Button, he headed up mobile engineering at Venmo. Follow him @chrismaddern.

This article originally appeared on