I hate apps.
(I know “hate” is a politically incorrect word, but in this case it is correct.)
More precisely, I hate the assumption that every company, service, restaurant, retailer, bank, airline, media outlet, random business interaction, and game needs an “app.” I also think we are reaching peak app fatigue. People already have too many installed programs, too many accounts, too many passwords, too many subscriptions, too many permissions, too many notifications, and too many little digital obligations that somebody else decided we should accept because it made their business model easier.
My objection is not to native software. Native programs absolutely have legitimate uses. My objection is to unnecessary native software, especially when the user bears most of the cost and the business receives most of the benefit.
The principle is simple: Use only the amount of complexity the problem actually deserves.
1. An App Should Have to Justify Itself
There are perfectly good reasons to build a native program. Some games need serious graphics performance. Some software depends heavily on local hardware, sensors, Bluetooth, or substantial offline capability. Some workloads genuinely work better in a native environment.
Fine. Build the program.
But the first question should be: What does this program need to do that a good website cannot?
Too often, the process seems to start somewhere else: “We need an app.” Why? “Because everyone has an app.”
That is not a requirement. It is fashion.
And sometimes the real reason is less flattering. Sometimes it means: We didn’t build the website well enough. Sometimes it means: This is easier for us. Most often it means: We want more of your information.
None of those are automatically good reasons to impose software on the customer.
2. The Web Can Already Do Most of This
A good website can maintain a persistent login. It can identify returning users and browsers well enough for many business purposes. It can store local state, gather telemetry, track navigation, measure clicks, follow conversion paths, remember preferences, and support highly interactive software. It can even place an icon on a home screen.
A good web programmer can do an enormous amount without asking the user to install anything.
I know because I’ve done it. In 2010, I wrote a JavaScript role-playing game designed to run in a browser on an iPhone 3G. It had a 120,000-position persistent world, up to 1,000 persistent monsters, combat, inventory, line-of-sight calculations, boats, and eventually a pilotable submarine.
In a browser. On an iPhone 3G. In 2010.
So when a modern business tells me I need to install native software to view a menu, check an account, make a reservation, read some information, or perform some other fairly ordinary task, I get skeptical.
The web is not some crippled fallback for “real” software. For a huge class of business problems, it is the appropriate solution.
3. The Cost Is Paid by the Customer
Companies tend to talk about apps as though installation is free. It is not.
An installed program takes storage, requires updates, introduces another codebase onto the device, may add another set of permissions, and often adds another account. And how many damned accounts do we each have these days? Do you really need another one?
Every business thinks it is asking me to create one account. I experience all of them.
I once resisted using a doctor’s portal simply because I did not want another username, password, recovery process, and login to manage. From the doctor’s perspective, it was one account. From mine, it was account number God-knows-what in a lifetime already full of them.
Security matters too. Every additional installed program potentially increases the device’s attack surface. That program may have vulnerabilities of its own, rely on third-party libraries or SDKs with vulnerabilities, mishandle credentials or local data, or introduce another update chain that has to remain secure. Websites can absolutely be insecure too, but there is still a meaningful difference between interacting with code inside a browser environment and permanently installing another codebase on your device with whatever privileges you granted it.
Software you never installed cannot have a vulnerability on your device.
There is also the background-behavior problem. Some programs continue permitted activity after you have returned to the home screen and reasonably think you are finished with them. Social-media programs are some of the worst offenders, genuinely abusing background functions. And while some other programs may have legitimate reasons to do certain work in the background, “I stopped looking at it” and “the program stopped doing things” are not necessarily the same thing.
Sometimes you have to explicitly quit the program to make it stop. And how many of you do that on any regular basis?
4. Follow the Money and the Data
Native software is often easier to monetize. App stores already have payment systems. They make it easy to charge $0.99, $2.99, or $4.99. They make subscriptions easy. They make in-app purchases easy. They reduce friction between the company and the customer’s wallet.
I understand why businesses like that. But again: Convenient for whom?
If what you offer is valuable, an easy payment system is not what makes it valuable. Frictionless payment can improve convenience and encourage impulse purchases. But when the strategy is to make buying effortless while relying on forgetfulness, inertia, or inattention to keep the charges flowing, the business is taking advantage of behavioral manipulation.
The fact that a platform makes it extremely easy to charge me is not an argument for why I need your software. It is an argument for why you want me to install it.
The data argument works the same way. I am not anti-data. I have spent more than 20 years working with data and analytics. I once built an implementation that could infer useful demographic information and cultural purchasing patterns from little more than a name and ZIP code by creatively combining available information.
That kind of work interests me because it requires thought.
There is a big difference between intelligently analyzing information a customer has legitimately given you and saying: We can collect this from the device, therefore we should.
A good website can already tell a business plenty about what users do inside the site. It can track which pages they visit, how they navigate, what they click, where they abandon a process, whether they return, and where they came from. You do not need privileged access to a person’s device to perform competent analytics.
Facebook made an entire generation painfully aware of just how much modern software and advertising infrastructure can track behind the scenes. It is hardly the only example. The lesson should not have been that this is simply how software works now. The lesson should have been: Companies should have to justify the information they collect.
More data is not automatically better. More is just more.
5. The Web Has an Important Structural Advantage
Native software also puts a platform owner into the relationship between the developer and the customer.
Apple can decide to change a development requirement, deprecate something, alter platform behavior, or stop supporting some older assumption. It is not required to get every other vendor on Earth to agree first.
The web works differently. Browser vendors can certainly make changes, but they operate inside an ecosystem where interoperability matters. If one browser decided to ignore major standards and break a large part of the existing web, the rest of the web would not obediently reorganize itself around that decision. The browser would have a problem.
Web standards tend to change more slowly because many companies, developers, standards bodies, and existing systems have to continue working together. That can be irritating for developers. It is often extremely valuable for users.
The web has no single owner.
That matters.
6. I Hate the Word Itself
Somewhere along the way, the word “app” became trendy. It sounded smaller, friendlier, less intimidating, more modern, and more fun than “program.”
Then it became so broad that it stopped telling us much of anything.
Write a native program? App. Build a website? App. Create a report or some analytics in Salesforce? App. Put together an Excel workbook that performs some calculations? Somebody will call that an app too.
Some corporate people love words like that. Engineers should not.
Those are different kinds of work. They involve different architectures, deployment models, security concerns, skills, costs, and maintenance requirements. Calling all of them “apps” strips away useful information about what was actually built, and it cheapens the work of the people who built it.
It also encourages bad thinking.
“We need an app” sounds like a requirement. It isn’t. “We need customers to perform these six tasks” is a requirement. “We need employees to see these three metrics” is a requirement. “We need users to make reservations and change them later” is a requirement.
Those statements describe problems.
“We need an app” prematurely chooses a solution.
And when everything is an “app,” installing another “app” starts to sound trivial.
It is not trivial.
7. We Have Reached App Fatigue
I think we are near, or already past, peak saturation. Every company sees only its own request: One more account, one more subscription, one more rewards program, one more permission, one more notification, one more program to update.
The customer experiences all of them.
If I sit down in a restaurant and they require me to install an app to see the menu, order, pay, or otherwise interact normally with the restaurant, I leave. Every time. I will be out the door before the water arrives.
If the restaurant merely says I need the app to join its rewards program, fine. I will stay. But I will never join the rewards program. And the more they pressure me about it, the faster they move toward losing my business.
I think we have hit the same kind of saturation point with apps that eventually happened with tipping. Individual asks seem small until the accumulated burden becomes obvious. Then people stop evaluating each request in isolation and start reacting to the total annoyance.
Businesses should pay attention because this can change actual purchasing behavior. I literally changed banks because its app was buggy and its website did not make up for it. My current bank has an app too. I do not use it. Its website does everything I need.
That is the point.
Build What the Customer Actually Needs
My objection is not to native software. My objection is to unnecessary software.
If your product genuinely needs native capabilities, build the program. If installation creates meaningful value for the person installing it, build the program.
But if your customer simply wants to check something, buy something, reserve something, read something, manage an account, or interact with your business, start with the web. Build the website well. Collect the information you actually need. Charge for something that provides actual value. Use the amount of complexity the problem actually deserves.
And remember that asking someone to install your software is not nothing.
You are asking for space on someone else’s property. You are also asking for attention, permissions, data, maintenance, security exposure, subscription commitments, and another dependency on a platform the user does not control.
And if you’re asking for all of that, you should have a very good reason.
I delete more apps than I install these days. That is not because I use less technology. It is because I have become much less willing to install software that has not earned its place on my device.
If your service works perfectly well in a browser, asking me to install your app is not a feature. It is a favor you are asking me to do for you.
Your app should have to earn the right to exist.