The App You Need Once Should Disappear

The QR code on the parking meter does not open the barrier.

It opens a funnel, and its a funnel I never asked to be a part of.

I just want to park my car.

But parking my car is looking more and more like:

Download the app.

Accept its terms.

Create an account.

Get a call from the missus that i’m late.

Verify an email address.

Add a card.

Decide whether a car park transaction really needs notifications and precise location.

Close App.

Open App.

Try remember which of the six parking apps owns this particular patch of asphalt…

I wanted fifteen minutes of parking.

I’m being pushed more and more to permanent software relationship.

‘Ease of use’.

Bike hire.

Event check-in.

Guest Wi-Fi.

A laundromat.

A door lock for a Airbnb.

A door lock for a Office building.

An airport locker.

A restaurant waitlist.

The local sushi shop (shout out soy & ginger).

These all exist on my phone, and I have used them all, once. Each task may need software, for ‘convenience’. I challenge that very few need an installed app.

Disposable Apps

To my surprise, I dived into this and found out apple, the creator of ‘apps’, actually, knows this is a problem.

They solved it, but no one uses it and it seems to suffer from low adoption.

App Clips are the cleanest working version of the idea that, actually, you don’t need to keep 40 apps you will never use downloaded.

Apple describes an App Clip as a small part of an app for completing a task quickly, with examples including renting a bike, paying for parking and ordering food.

A person can invoke one through a QR code, NFC tag, Safari, Maps or Messages.

Supported clips can use Sign in with Apple and Apple Pay. Apple’s iPhone guide to App Clips

At this point someone will quite reasonably ask why I have spent all this time describing a website.

For a form, menu, ticket or ordinary checkout, the web is probably the answer.

Internet is good enough that you really, don’t need a app…

Calling the same page a micro-app does not create a company.

There may still be a job for a trusted host where the task goes beyond an ordinary website.

Think of services that need a trusted interaction with a physical object, a regulated identity check, a wallet, a temporary device permission or a receipt that must remain available after the interface disappears.

Permissions should expire with the task unless the customer deliberately extends them.

Camera access for a parcel label ends when the locker opens.

Location for parking ends when the session closes.

Notification permission lasts long enough to warn that the meter is expiring, not long enough to market airport parking next summer.

The receipt and support history are easy to miss. Disposable software cannot mean disposable responsibility. A customer still needs to find the charge, cancel the booking, prove they returned the bike or reopen the support case.

The interface can vanish. The contract cannot.

The merchant gives up a home-screen icon, push channel and a pool of customer data it may have treated as compensation for building the service.

In return, more people may complete the task instead of abandoning it at the app-store redirect.

That being said, a bank, delivery marketplace or fitness product has reasons to want a durable, high-capability app. Frequent use can repay installation.

Personalisation and offline operation may require local state. Some services need background location or Bluetooth connections that Apple explicitly withholds from App Clips.

The boundary is frequency and depth, and the fear is AI will eat both of these, for the sake of ‘I built a app for it’.

If the customer expects to return weekly and the product improves with accumulated state, install the app.

If the relationship is created by standing beside a machine, entering a venue or completing one transaction, make the software earn permanence instead of assuming it.

A host needs a business model that does not reward turning every micro-app into an ad. A transaction fee is at least aligned with completion.

There is a tempting demo here: scan a code and watch a tiny interface appear instantly. It would look finished long before the difficult product exists.

What would make me use it is knowing who took the payment, what I allowed them to access, and where to go if the locker doesn't open. I don't particularly care whether the interface was streamed or downloaded.

If it can do that, the “app for apps” becomes very useful.

The host is carrying the durable trust while the service stays temporary.

If it cannot, the renderer is just another browser tab with a better entrance animation.

Shout out to all the legends I've ripped info from for this piece:

Apple | Android Developers | MDN | WebKit | web.dev