We see five major problems with the concept of “installing” native apps.

1. Allocates local resources too rigidly

“Shrink-wrapped software” is what we call ’90s-era desktop applications sold as cardboard boxes on store shelves. Shrink-wrapped software is the precursor to today’s native apps.

A shrink-wrapped software application has to set itself up to work 100% offline. It uses a lot of local storage space and computational resources (and requires a lot of up-front installation time on your local machine).

Web apps usually do their computational heavy lifting on server farms in the cloud, so your device only has to provide a tiny fraction of the local storage and computational resources needed to run a web app – often less than 1%.

Are native apps like the 100%-locally-running shrink-wrapped software that originated the concept of installation, or are they more like 1%-locally-running web apps? Actually, both options are overly rigid resource allocations.

A native app can be located anywhere on the local-to-remote spectrum, depending on how it splits the work between its remote servers and your local device. There might even be multiple points on the spectrum for a single app. In principle, every app’s local-to-remote ratio can be in constant flux, dynamically adjusting its local device footprint (e.g. to populate a local cache using predictions about what data the user will want to access next).

2. Has an outdated concept of “updating”

In the age of shrink-wrapped software, when a user wanted to update their version of an app, they had to get their hands on a newer CD-ROM and repeat the whole installation process.

On the web, updates are automatic and completely transparent to users – users don’t have to think about the whole concept of “updating”, nor make decisions about when to update – it just happens silently over the internet. And on the web, updates happen incrementally – users only download the updated code and data necessary for rendering their current page within a web app.

Today’s native apps have the technology to update automatically like websites do – they have access to an internet connection most of the time. And today’s native apps have the technology to update incrementally – they’re often architected as a hierarchical combination of functional components (e.g. a payment-processing component, a map-rendering component, etc), and in principle the individual components of an app can update incrementally just like the individual pages of a web app.

But in many cases, updating native apps is neither automatic nor incremantal today. There’s no technical reason for this, but there is a conceptual reason. Our outdated concept of installing apps is responsible for our outdated concept of updating apps.

3. Is device-specific

It’s nice that you only have to install an app once per device (until an update becomes available, that is). But if you install an app on one of your devices, chances are you’ll also end up installing it on your other devices. And if you want to use your app when you’re at a friend’s house, you might end up installing it on your friend’s devices too.

You’re bound to encounter lots of app-enabled devices in your life. Why should you have to worry about installing your apps on every device you encounter? Device-specificity is just an arbitrary limitation of installation.

Web apps don’t have that limitation because they’re prepared to be launcehd from a state of zero local resources. If you use the OkCupid web app on your laptop, you can go to your friend’s house who has never used OkCupid, and instantly log into your OkCupid account by typing"www.okcupid.com" into their browser.

It’s a good bet that native apps will eventually drop the concept of device-specific installation. They can copy web apps’ incremental downloading solutions, and they can even go a step farther.

For example, one day you might be able to configure the device in your pocket to constantly signal your presence to the other devices in the vicinity that you might be able to use. The nearby devices will silently make predictions about which apps you’re most likely to want to use on them, and preemptively download relevant resources to be ready to run these apps quickly.

4. Adds up-front wait time

Shrink-wrapped software taught users to expect long wait times for mysterious progress bars called “installers”. A shrink-wrapped software installer might take a few minutes to copy an application’s files from a CD-ROM onto your computer’s hard drive, and then run configuration scripts to register it with your operating system.

Nonzero up-front wait times are a fact of life for any kind of app, but at least web apps address the problem proactively. Web developers routinely think about incremental downloading - programming their web apps to always download the smallest fraction of code and data necessary to provide the current user experience.

The web has taught us to expect instant gratification. Point your browser to a web app and you might have a bit of up-front wait time, but the web’s progress bars fly by at warp speed compared to shrink-wrapped software’s.

Today’s native apps have brought back the installation process.

On the plus side, the native app installation process makes life easy for app developers; it saves them the work of figuring out incremental downloading solutions. But developers can’t afford to comporomise user experience for their own convenience.

Just look at how much work Instagram‘s developers put into making a snappy experience for their users. Their native app has a clever scheme for uploading a user’s photo while they’re writing a caption and tweaking various options, so they never have to wait on a progress bar.

Apps like Instagram, with that level of focus on user experience, would do anything to minimize their users’ up-front wait time. Their installation step seems out of place in today’s world of instant gratification.

5. Breaks linking

Web apps have an extremely useful feature that shrink-wrapped software never had: linking. On the web, we take it for granted that Instagram photos and OkCupid profiles have URLs and are linkable.

Native apps installed on your device also have the ability to open certain links, but the installation requirement makes it risky to send around links to apps. For example, if you have one of IMDB’s apps installed on your device, then a link to imdb:///title/tt0114709 will launch it and go directly to its Toy Story entry.

But if you don’t have an IMDB app installed on your device, that same link will take you to a screen like this:

That’s why people share links to web apps all the time, but rarely share links to native apps. Native app platforms have weakened the concept of linking while strengthening the concept of installation. They really should be doing the opposite.

Conclusion

Developers will always try to maximize monetizable value for users. That’s what drives the long-term trend toward a web of high-level functions – the Functional Web.

Native app installation forces users to think about low-level concepts – which device they’re installing on, how much storage space it has, and when to upate. Plus, it makes users wait longer for apps up-front and it breaks in-app linking. In the Functional Web model, native app installation is a low-level implementation detail that gets abstracted away from users.

In a previous post, we saw how the Functional Web abstracts away the native-to-web app spectrum. In the first section of this post, we saw how the Functional Web can potentially abstract away the local-to-remote app spectrum. It’s also a good bet that the Functional Web will abstract away the installed vs. not-installed app dichotomy.