Mobile App

There was a stretch where most people were already online on a phone and the only thing waiting for them was a shrunken version of a desktop screen. Text was small enough to need pinching, and buttons sat close enough together that the wrong one got tapped. The bigger problem was the act of opening the product at all. Launch a browser, type an address, sign in again — three steps for a thing you only wanted to glance at, so the glance got postponed. A product nobody glances at is a product nobody builds a habit around.

Pagedeck heard the same sentence in interview after interview. People wanted to know on the commute whether a new comment had landed on a document, and they checked once they reached the office instead. When Mia asked why, the answer was plain. Opening it was a chore, and nothing told them a comment had arrived, so the only way to find out was to go and look.

An app removes both of those at once. An icon stays on the home screen and opens on one tap, and the company can reach the user first instead of waiting to be visited. Being installed on the device also means the product can use what the device has.

It solves the problem of not being reopened. A product used in a browser opens only when the user thinks of it, while an app sits on the home screen and catches the eye several times a day. Add push notifications, the alerts an app sends straight to the device, and the company can pull the user back rather than wait. That is why retention — how reliably existing users keep coming back — splits by form factor for what is otherwise the same product. At Pagedeck, users who installed the app came back at close to twice the 30-day rate of users who stayed in the browser.

It also takes on the work that needs the device itself. Responsive design, where the layout shifts with the size of the screen, handles a narrow display well enough, but a browser can't reach everything.

1. Camera and photos. Snapping a receipt and attaching it to a document without leaving the app.
2. Location. Showing something based on where the user happens to be standing.
3. Fingerprint and face recognition. Unlocking without typing a password.
4. Being offline. Reading a downloaded document on a plane, then syncing the edits once the connection returns.

The app store's rules come with all of it. Every new version waits for review, so even an urgent fix sits for a day or two, and somewhere between 15 and 30 percent of anything charged inside the app goes to the store as commission. Updates apply only when the user taps them, which means a share of people are always running a build from six months ago. A bug you fixed is still there for everyone who hasn't updated.

Three routes reach the same goal without an app. None of them fully replaces one; what differs is what you give up.

1. Mobile web. A web app, which runs in the browser, built to fit a narrow screen. Nothing is installed, so a single link brings someone in, and the moment you ship a fix everyone is on the new version. No review, no commission. What you give up is notifications, device features, and the spot on the home screen.
2. A progressive web app (PWA). A website built so it can be installed to the home screen and receive some notifications, picking up part of an app's behavior without passing through a store. How much of it works depends on the device and the operating system, so the same code may get notifications on one phone and not on another.
3. Hybrid. Build an app shell and load web screens inside it. You maintain one set of screens, and the shell handles the camera and notifications. It's the smallest amount of building, but if scrolling or the back gesture behaves differently from what a hand expects, users notice quickly.

Which one fits is decided by where the user does the work, not by preference. If nine out of ten sessions arrive from a desktop browser, there is little reason to build the app first. When the call is genuinely unclear, counting where current users come from settles it faster than arguing. That count also moves as the product grows, so it is worth redoing rather than deciding once.

"This fix can't go out Thursday because of app review. Let's say Monday."

An app release waits for the store to look at it, so its schedule is kept separate from the web one.

"It's fixed on web, but some people are still on the old app build."

Users who never tapped update are still hitting the same bug.

"Let's ship this to the app first. It only means anything with a push."

The same feature is worth different amounts on different form factors, so the release order should change.

Pagedeck shipped the web product first and added the app two years later. Since then Theo has run releases on two tracks: web goes out the day it's fixed, the app goes out the day review clears, and one feature opens on different days in the two places.

Noa draws the app screens separately, because a fingertip covers more area than a mouse pointer and the rules for button size and spacing differ from the web. Mia now asks whether a feature is needed in both places before it gets scheduled. Each added form factor adds places to fix and places to test.

The most common belief is that shipping an app brings more users. With an icon on the screen and notifications available, that's a natural thing to expect. But an app isn't an acquisition device; it holds on to people who already arrived. A new user has to go to the store, install, and sign in, where the web puts a screen in front of them one tap after the link. Miss that and install count becomes the goal, ad money goes behind it, and half the people who installed never open it once.

The other frequent mistake is assuming that wrapping existing web screens makes an app. Technically it works, and plenty of apps are built that way. Stores do reject submissions that amount to a website in a shell, and even an approved one reads differently to users, because anyone who went as far as installing expects app-like speed and gestures. Low ratings pile up, the listing sinks in store search, and at that point even work on app store optimization (ASO) struggles to pull it back.