States are the product
A demo shows the happy path. Real use is mostly everything else: empty lists, partial data, expired sessions, no connectivity, permission denied, an upload that failed halfway. Whoever designs those states determines how the app feels.
We specify every state before building a screen. It reads as pedantry in a design review and it is the single most reliable predictor of whether the app will feel finished.
Ask for permissions when the value is obvious
Requesting notification and location access on first launch is the fastest way to a permanent no. Ask at the moment the user is trying to do the thing that needs it, with one line explaining what they get.
The same principle applies to account creation. Every screen you put before someone experiencing value is a screen where a third of them leave.
Perceived speed beats measured speed
Optimistic updates, skeletons sized to the real content, cached first paints and transitions that hold context all make an app feel faster than the network allows. Getting this right matters more than shaving milliseconds off an endpoint.
Offline behaviour is part of the same story. An app that fails gracefully on the underground is an app that gets opened on the underground.
Instrument retention, not downloads
Downloads are a marketing number. The useful metrics are day-seven and day-thirty return rate, crash-free sessions, and completion rate on the one job the app exists to do.
Wire those up before launch. Retrofitting analytics means your first month — the month with the most to teach you — is unobservable.
The pre-launch fortnight nobody plans for
Two weeks before submission, stop building features and start using the app on a mid-range Android device on mobile data with the office wifi turned off. This is the single most informative fortnight of an app project, and it is almost always compressed into a weekend.
Work through the states deliberately: airplane mode mid-upload, session expiry, permission previously denied, an empty account, an account with three years of data. Each of those has a correct behaviour, and each one you get wrong will show up in a review.
Then check the store requirements that reliably cause rejection: account deletion, privacy declarations, subscription terms and any mention of external payment. None of them are engineering problems, and all of them delay launches.
Questions people ask about this
Rarely for missing features. Usually because the app was slow to become useful, asked for permissions or an account before demonstrating value, or behaved badly the first time the network dropped.
It depends heavily on category, but for a business tool with a genuine job to do, anything above 25% at day thirty is respectable and above 40% is strong. What matters more is the trend after each release.
Follow your users rather than convention. If you are shipping cross-platform with React Native, the question mostly disappears — but pick one platform to polish first, because splitting attention at launch produces two mediocre experiences.