Almost every mobile app development company tells the same story about how a build goes, and the story ends in the same place. Discovery, design, architecture, a run of agile sprints, QA, then launch and post-launch support. We read three of the pages ranking for this search in September 2026, and all three finish on some version of that last phrase without ever saying what it covers.

If what you’re buying is a web app, “done” is close to honest. You ship it, you keep an eye on it, and you change it when you decide it should change. Mobile carries two mechanics the web doesn’t, and both of them put work on your calendar that nobody on your side asked for. Neither one shows up on a vendor’s service page, which means the question of who handles them usually gets settled after you’ve signed, by whoever notices first.

TechAhead’s mobile application development page walks through a six-stage process running from discovery into design, architecture, agile development, and QA, and ending at “launch & post-launch support.” It’s a substantial page, carrying compliance claims covering SOC 2, ISO 27001, and HIPAA alongside a long run of case studies with metrics attached. It also states that ongoing app maintenance is included, and then never defines what that maintenance consists of. There’s no pricing, no ownership terms, no service-level commitment, and no timeline you could hold anyone to.

ScienceSoft’s page is the outlier of the three, because it actually publishes cost bands by complexity tier, which is more than most companies in this market will put in public. Even there, the part of the engagement that comes after launch stays unspecified: nothing on how long maintenance runs, nothing on what it covers, no service levels, and no criteria you could use to compare one company’s support against another’s.

10Pearls goes furthest in naming the work: its page lists ongoing support and maintenance as updates and issue resolution, and treats app store optimization as a line item inside launch strategy. What that page still doesn’t touch, and what none of the three touch, is where most of the post-launch work actually comes from: the store review that every update has to clear, and the operating-system release that lands every year whether or not your app is ready for it.

We’ve said a version of this ourselves, once, in a single sentence inside a piece about how vendor directories rank companies. We wrote there that the app store release is the middle of the work, since OS versions move and somebody has to be around in month fourteen when a platform change breaks a screen. That was a flag we dropped in a piece about something else and never came back to, so here’s what it actually involves.

The first submission gets all the attention, because it’s the one with a date attached and a launch plan built around it, so review is easy to think of as a launch-day hurdle you clear once and then forget about. That impression is worth correcting before you agree to a support arrangement, since the gate stays exactly where it is every time you ship.

Google Play reviews app changes and updates before publishing them, so the first version you send is only your first trip through the process, and the processing window runs from a few hours out to as long as seven days. Apple’s App Review works on the same basis for apps already on the App Store, where updates are reviewed on an ongoing footing. Apple published a policy note saying that bug-fix updates would no longer be held up over guideline violations that aren’t legal issues, and a carve-out like that only makes sense if updates are otherwise reviewed as a matter of course.

Set that against a typical support arrangement and you can see where the work hides. A fix that lands in the repository on a Tuesday still has to clear review before a single user has it, and that queue belongs to a company that isn’t yours, moving on a schedule you don’t set. Someone has to prepare the build, send it, watch for the response, and answer if the response is a rejection. That’s a standing job for as long as the app is live, and it should belong to somebody by name in whatever agreement you sign.

The second mechanic is the annual platform release, and it runs on a calendar neither you nor your development company controls. Apple introduces new operating system versions at its Worldwide Developers Conference every year, and WWDC26 covered updates across iOS, iPadOS, macOS, tvOS, visionOS, and watchOS. Google shipped Android 17 on June 16, 2026 as its major release for the year.

Android 17 shows how much a release like that can change for an app whose owner asked for nothing. It made large-screen resizability mandatory for apps targeting API level 37 or higher, which means the system now ignores an app’s declared orientation lock, along with the equivalent request made in code, on screens that qualify, though games are exempt. Google also moved a set of legacy user-interface components into maintenance-only status, including the classic android.widget views, Fragments, RecyclerView, and ViewPager, and added new permission requirements such as one covering local network access.

Follow each of those through to what it does to a shipped app. An app that locked itself to portrait because that was the right call for a phone-first design in 2024 now behaves differently on a tablet or a foldable, and nobody changed a line of its code. The maintenance-only status is quieter and slower to bite, but it means the foundation a large number of Android apps are built on has stopped moving forward, so the cost of catching up accrues in the background while the app looks like it’s working fine. A new permission requirement can take a feature that worked last month and stop it until someone declares the permission and ships an update, and that update goes back through review like everything else.

None of that came out of a conversation with your users or a line on your roadmap; it arrived because Google shipped its annual release, and Apple runs the same cycle on its own schedule. Somebody has to read the release notes, work out which parts touch your app, test against the beta while it’s still a beta, and get the work scheduled before the public version reaches your customers’ phones.

All of this gets easier to handle if you carry it into the sales conversation as a short list of questions, asked before you sign, while the answers still cost them something.

Ask who submits updates, and what happens when review takes the long end of the window rather than the short end. You’re looking for a named owner and a release cadence, since “we’ll handle it” leaves the queue unattended the first week that everyone is busy.

Then find out who reads the annual platform releases, and when. A good answer names the developer beta period over the summer, because testing against a new OS after it has already reached your users means you find out about the problem from a support ticket.

The target API level is worth asking about by name: which one the app sits on at handoff, and who owns raising it over time. Android’s resizability change is scoped to apps targeting API 37 and above, so the target level is the switch that decides when a platform requirement becomes your problem, and somebody has to be watching it.

It’s also worth asking what happens when a component the app depends on moves to maintenance-only, because migrating off a deprecated foundation is real work and you want to know now whether it sits inside the support arrangement or arrives later as a separate engagement.

Finally, ask for the maintenance definition in writing, as a list of activities with an owner against each one. “Ongoing support” in a proposal doesn’t survive contact with a real platform change, but an answer saying the company submits every release, tests against each platform beta before the public version lands, and moves the target API level on a stated timeline gives you something you can hold them to.

This piece assumes you’ve already worked through two earlier decisions. If you haven’t settled who holds the repository, the hosting, the domain, and the third-party accounts, that belongs in the agreement at signing and not in a conversation after launch, and we wrote up the whole checklist in Outsourcing Web App Development. If you’re still building the shortlist, how vendor directories decide who sits at the top covers what a ranking can and can’t tell you about a company.

When you’re ready to talk about a specific app, tell us what it does, who uses it, and which platforms it has to live on, and we’ll walk you through where the post-launch work is going to land and who should be carrying it. If that’s useful, you can book an intro call.