Every agency on the shortlist you’re working through will say some version of the same sentence: you own what we build. That’s usually true, and it usually means the source code and the design files, which is what most buyers picture when they hear the word ownership.

Underneath that sits a second question the code answer doesn’t reach. If the relationship ended next quarter, would your app keep existing on the App Store and Google Play, under your control, without needing anyone’s cooperation? That has very little to do with who wrote the code and almost everything to do with whose developer account the app was published under. Moving an app from one account to another is a formal process that Apple and Google run on their own published rules and their own timelines, under conditions a contract between you and your vendor can’t override.

We read through the pages ranking for this search in September 2026 to see how far any of them take the question, and none of them take it very far.

TechAhead’s “Top 10 Mobile App Development Agencies in 2026” is the sort of listicle that surfaces near the top for almost every query in this family, and to its credit it does hand you criteria: match the agency to your stage, since an MVP shop and an enterprise shop are different purchases; check that they’ve worked in your domain; look for full-cycle capability across ideation, design, development, deployment and maintenance; and verify the references and the portfolio instead of taking the logos on faith. Those are reasonable filters for choosing a partner, but ownership of the app after delivery never appears among them in any form. Developer accounts, store listing rights, source code, IP: none of it is on the list of things the article tells you to check.

W2S Solutions runs a vendor page targeting this exact search, and it’s the only page we looked at that raises ownership at all. Its IP section carries a bullet reading “Transfer Of Code Ownership,” and that bullet is the entire treatment, because the page never says when the transfer happens, what it covers, or what falls outside it. There’s no post-launch or maintenance section either, so nothing later picks the thread back up.

We’ve been guilty of roughly the same thing. Our own piece on what kind of app you’re actually buying contains a single sentence noting that the store relationship is part of the product you’re buying, that you need developer accounts and submit builds for review, and then it moves on to something else. What follows is the part that sentence skipped: what the account layer actually is, and what Apple and Google require to move an app between accounts.

An iOS app doesn’t sit on the App Store by itself. It sits inside an Apple Developer Program enrollment, and an Android app sits inside a Google Play Console developer account. That account holds the store listing, the signing keys and certificates that let a new build be accepted as an update to the app your users already have, the payments profile that revenue flows through, and the authority to submit anything at all.

Whoever holds that account controls whether the app keeps existing on the store, no matter what the contract says about the code. Apple’s own documentation makes the control structure plain: only the Account Holder role can initiate an app transfer, and the transfer goes to the recipient’s Account Holder, identified by their Apple Account and Team ID. On Google’s side, a per-app transfer is submitted from Play Console and the destination developer has to approve it. In both cases the people who can move an app are the people who hold the accounts, and that’s a different set of people from whoever holds the copyright.

None of this requires anyone to behave badly. An agency that winds down, gets acquired, or simply loses the person who originally clicked through the enrollment produces the same problem as an agency you’ve fallen out with.

Say you decide after launch that the app should move to your own account. Apple publishes the criteria, and they’re stricter than most people expect.

The app has to have at least one version that was actually released to the App Store, and it can’t currently be available for pre-order anywhere. It also can’t be sitting in any of a long list of transient states: Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release, or Pending Apple Release. In practice that means an app in the middle of a release cycle can’t move until the cycle finishes, which matters if you’re trying to separate from a vendor quickly.

In-app purchases add their own gate. Every IAP product has to be in one of a few settled states (Approved, Ready to Submit, Developer Removed from Sale, or Rejected), and the product IDs on your app can’t be identical to product IDs on any app already in the recipient’s account. That second rule is the one that catches people out, because two apps built by the same agency for two different clients, both using a house convention like com.example.app.premium_monthly, can’t both land in the same destination account until somebody renames products. Some apps can’t be transferred at all, including anything published through Apple Arcade.

Both accounts have to be clear of pending changes and current on the latest paid and free agreements before Apple will process anything. Once the transfer is initiated the app enters a Pending App Transfer status, and while it sits there the original account holder can’t touch its metadata, pricing, availability or in-app purchases. The recipient then has 60 days to accept before the request expires.

A completed transfer keeps more intact than people assume: reviews and ratings stay attached to the app, existing users keep receiving updates, and auto-renewable subscriptions keep working. The bundle ID doesn’t change either, since it was fixed back when the first build was uploaded.

Plenty of other things need handling by hand, though. TestFlight builds and testers have to be cleared before the transfer runs, and once it completes the recipient has to generate new APNs keys and a new app-specific shared secret. An Apple Pay merchant ID doesn’t come along and has to be recreated. The new owner can’t generate promo codes after the move, although codes already issued stay valid for four weeks from when they were generated. And the party sending the app loses access to App Analytics for the sales and payments that happen after the transfer, so that data goes only to the recipient from then on.

Google runs two different processes here, and buyers conflate them constantly. The rules and the failure modes aren’t the same, so it’s worth working out which one you’d actually be doing.

Moving a single app to a different developer account is the common case. You submit the request from Play Console, the destination developer approves it, and Google’s support team reviews it and replies within two business days. If the app is paid or sells in-app purchases, the receiving account needs an active payments profile in place first, and an app with in-app purchases generally has to be republished by hand afterward once the currency changes. Users, install statistics, ratings, reviews, subscriptions and the registered package name all come across, but bulk export, payout and earnings reports don’t, and closed testing groups have to be recreated on the other side. Orders placed before the transfer stay with the original account, so if one of them ever needs refunding, the refund has to be issued from that account or through the Google Play Developer API.

The manual reconfiguration list on the Google side is longer than most people budget for. Firebase has to be unlinked from the old account and relinked to the new one, Google Analytics needs permissions added for the destination, and AdMob and other ad SDK identifiers need updating inside the APK so ad revenue credits to the right place. Play App Signing has its own wrinkle: the target account can request a new upload key, but the app signing key itself can’t simply be swapped, and changing it means a key upgrade that applies to new installs. Private apps distributed through managed Google Play have to be temporarily unpublished and reassociated with the destination organization before the transfer completes.

Transferring the whole developer account is the other path, and Google has built some deliberate friction into it. Once initiated, the transfer sits on a seven-day hold that any user on the account can cancel, which exists to stop an account changing hands quietly. The prospective owner then walks a setup wizard covering the payment profile, contact details verified by one-time password, and organization details where they apply, and Google may ask for identity documents before anything completes. There are also eligibility limits worth knowing before you plan around this path: individual developers who monetize their apps are currently ineligible for the direct account transfer and have to create a new account and move their apps across separately, and the transfer is blocked outright if either account is out of compliance, has pending changes in flight, or if the prospective owner already holds another Play Console account.

We’ve written before about settling ownership before you sign, in the general checklist for outsourced app work, which covers the repository, the hosting account, the domain and DNS, and the third-party accounts, all named in the agreement. That checklist is the right frame for a web application, where who owns an account really is a matter of who created it and what the contract says, and where you can hand a hosting account or a domain over the same afternoon you agree to it.

Mobile adds a layer a contract can’t reach into. You can have a signed agreement stating in plain language that you own everything, and an app sitting In Review still can’t move today. Colliding in-app-purchase product IDs will block a transfer until somebody renames them, an Apple Arcade title can’t be transferred on any timeline, Google’s seven-day hold runs its full seven days, and the account transfer stays unavailable to a monetizing individual developer no matter what both parties want. Your agreement binds you and your vendor to each other, but Apple and Google aren’t party to it, and their rules are the ones that decide when an app actually moves.

So the account question belongs at the start, before the first build gets submitted. Settling it on day one is a conversation and a line in the agreement, while undoing it later means running one of these platform processes on gates and timelines that neither you nor your vendor sets.

Four questions, and the answers belong in writing rather than on a call.

• Whose developer accounts will the app be enrolled under from day one, ours or yours? If the answer is yours, why, and what would it take to change that later?
• Who holds the Apple distribution certificate and the Google Play App Signing key, and where are they stored?
• If your account is used, what are the exact conditions under which the app gets transferred to us? Write them into the agreement now rather than negotiating them at the moment we need them.
• If a transfer ever happens, what happens to our reviews, ratings, install base and subscribers?

The documentation answers that last one for a transfer run properly through the formal process, where reviews, ratings, installs and subscribers all carry over. A vendor who offers to “just give you the login” instead is describing a shortcut around a process both platforms built on purpose, and it gets you none of those protections while leaving the enrollment in someone else’s name.

We’re a Ruby on Rails consultancy based in Coronado, California, founded in 2015, and we build mobile apps along with the backends they run against. AI writes the code now, with senior engineers directing and reviewing every change, and we hold client projects at 80 to 90 percent test coverage. On the account question, we’d rather you put it to us in the same words you put it to everyone else on your list, and get the answer into the agreement either way.

If you’re still assembling the shortlist, a few other pieces on the site cover ground this one doesn’t. What vendors actually mean by the word agency unpacks whether “agency” signals a real growth practice or is being used as a synonym for company, which helps if you keep bouncing between these near-identical searches. How firm size changes what you get works through large shop versus small shop, and what actually puts a name at the top explains how the directories ranking for this search decide their order. Once you’re live, what post-launch support really involves covers who submits routine updates through the developer account and how App Review and OS releases shape that cadence.

Tell us what the app does, what’s already shipped, and whose accounts it currently lives under, and we’ll tell you what building or taking over the work involves, and what a transfer would require if one is in your future. You can book an intro call.