Written for people responsible for an app that already exists.

What these are for

Most writing about mobile apps is aimed at somebody still deciding whether to build one. These articles assume you already did, that the app is in front of real users, and that your problem now is keeping it there. That changes what is worth saying. You don't need another argument for why maintenance matters, you need to know which Play Console screen reports what your uploaded build actually targets, and how much time a policy extension genuinely buys you.

Every deadline, version number and store rule here was checked against Apple's or Google's own documentation on the day the piece was written, and each article carries that date at the top. Store policy moves fast enough that anything more than a few months old should be treated as a starting point rather than the current rule, so check the primary source before you plan a release around a number you read on someone's blog, including this one.

They're written by Andrey Gordeev, who runs RapidLabs and works inside other people's iOS and Android codebases for a living. That is the bias worth knowing about before you read anything below: the examples come from apps that were already late, already broken, or already inherited, because that is what lands on this desk.

Where this leads

Reading is usually enough. When it isn't, this is how RapidLabs gets involved.

Plenty of what these articles describe is work you can do yourself with a free afternoon and the right console screen open. The pages below are for the situations where that stops being true, and each one says plainly what it covers and where its pricing starts.

If you would rather see finished work than service descriptions, the case studies name the client, the constraint the project was working under, and what shipped.