Who Should Own App Store Connect and Play Console in an Austin App Build (2026)

The SOW is signed. Then kickoff week, someone pastes a studio login into Slack and says "we'll handle the stores." That sentence is how an Austin build loses the product before the first TestFlight. App Store Connect and Google Play Console are not vendor tools. They are the legal entity, the seller name, the agreements, the signing keys, and the right to ship. If those sit in the studio's Apple Account and Play owner, you do not have an app you can leave with. You have a listing that moves when they feel like transferring it.

This is the account-ownership gate that comes after the eight-section brief, the Austin partner shortlist, and the estimate read. Those pages already told you to write the entity on the sheet. This page is what those roles actually do in 2026 — Account Holder versus Admin versus Developer on Apple, Play owner versus identity verification versus package-name registration, and the clocks that rewrite a silent invite.

This is not a recap of how to brief a partner, how to pick an Austin shop, how to read the estimate, year-one keep-alive, or Android developer verification. The verification piece is the package-and-key inventory. The estimate piece is whether the PDF named the owner. The question here is narrower: whose legal entity must hold Apple Developer Program Account Holder + App Store Connect and Google Play Console before an Austin SOW is honest.

What does Account Holder vs Admin vs Developer actually mean on Apple?

Account Holder is the membership. Admin and Developer are invites. They are not interchangeable, and inviting a shop as Admin is not a transfer of the membership. Apple's overview of accounts and roles and the role-permissions matrix are the same sentence: the person who completes program enrollment is Account Holder, and that user is the only one who can enter legal agreements with Apple.

Program roles add the operating list: renew the membership, accept agreements, initially add Admins, approve banking. The permissions table is the same list with a sharper edge — Account Holder is also the only user who can request App Store Connect API access or create Developer ID certificates. A partner who "holds the developer login" is holding the seller name.

Admin is the honest studio seat. Apple's glossary says Admins serve as a secondary contact, have access to all apps, and can edit user roles except the Account Holder role. If the Admin sits on an organization team, they get Certificates, Identifiers & Profiles by default. That is enough to upload an Xcode 26 binary, answer Review, and manage users. It is not enough to accept the Paid Apps agreement, move banking, or take the membership with them when the SOW ends.

Developer is narrower still. The same glossary: create and revoke development certificates, submit signing requests, download provisioning profiles, upload binaries, manage internal TestFlight users. App access can be limited for Developer, App Manager, Marketing, and Sales. It cannot be limited for Account Holder or Admin. For most Austin v1s, invite the shop as Admin on a clock, or as Developer plus App Manager if you want the listing scoped. Do not invite them as Account Holder. Do not share the founder's Apple Account.

Transferring the Account Holder role is written for another employee on your team who has legal authority to bind the organization. Individual-enrollment transfers are a Support case — a minor reaching majority, or a deceased Account Holder. The transferee verifies identity in the Apple Developer app before they can accept. Admins get an email that the Account Holder changed. That is an internal officer change. It is not a vendor offboarding ticket, and it is not "we'll transfer after launch."

What does Play Console owner, identity verification, and package registration attach to?

They attach to the first registered Play account — your legal entity — not to the engineer who uploaded the AAB. Play's user-and-permissions help still treats the account owner as the first registered login: full access, the person who links the payments profile if you sell paid apps. Creating an organization account asks for a D-U-N-S number, legal name, and verified contacts. Ownership transfer is a process with identity checks, and it blocks if the prospective owner lacks admin access to the payments profiles. "We'll transfer later" is a quarter you have not bought.

Identity verification on Play is mostly already done. Google's Play Console verification guide says most Play developers need no new identity action — confirm it under Settings → Developer account. If that page is dirty, you are not ready to claim a package name. The September 2026 verification piece is the how-to. This page only needs the ownership sentence: verification lives on the owner account, not on a contractor login.

Package-name registration is the second Play bill, and it has a date. Play will not keep unregistered packages: check Home, and by September 30, 2026 register remaining apps you want to keep distributing, or Play says it will remove them globally. Google's own line is that about 99% of Play apps were registered automatically. The leftovers are the dangerous ones — a name that lived on devices before the listing, a second SHA-256, a vendor who already claimed `com.yourapp`. Registering Play package names is the console help for that form. New apps register as you create them, unless another developer already owns the name. If the studio created the listing in their console, they own the name.

Play App Signing is why auto-registration is that high: Google already holds the app-signing key for most listings. You hold the upload key. New Play apps use Play App Signing. A studio that signs with a keystore that never left their laptop, or that created the app in their console so Google bound the signing key to their owner account, has made the listing theirs. Resetting an upload key is an owner action. Recovering a vendor-held keystore is a forensic project. Write who holds both keys on the SOW — the verification inventory is the table, not this page.

Two more Play clocks sit on the same owner, and they are not identity. Every Play app must complete a Data safety form and link a privacy policy — for your code and every third-party SDK. New phone apps and updates that miss Android 16 (API 36) fail the upload floor from August 31, 2026. Those are launch labor. They still fail if the only login that can submit the form is a studio owner you cannot reach. The estimate read prices the labor. This gate prices the login.

Which of the three ownership shapes is honest for an Austin SOW?

Your operating entity holds Account Holder and Play owner from day one; the studio is invited. The other two shapes — studio holds "temporarily," and a hybrid of split consoles or a shared personal login — fail the leave test. An Austin SOW that does not pick a shape is already picking the studio login.

Shape one is the default for CodeCross's Austin app development company work and for any shop you should still be talking to. An officer enrolls the organization. The studio works as invited Admin. Cloud bills, Firebase, analytics, and the signing keys follow the same rule: you can leave with them. Dated studio proof lives on the proof dashboard. Do not trade a clickable listing for a vendor-held console.

Shape two is the sentence that sounds helpful. The studio already has a developer membership. They will "set it up and transfer." Apple's transfer is to your employee with binding authority, after identity verification, not to a client logo. Play's transfer is blocked without payments-profile admin. If the listing was created in their console, the package name is already theirs. You are not buying speed. You are buying a hostage with a nicer Slack.

Shape three is the split: you hold Apple, they hold Play, or the inverse, or someone shares a personal Apple Account so "we can just upload." A written, dated hybrid can be honest for one clock — a founder who already has an individual Apple membership and needs weeks for an organization D-U-N-S, with a dated cutover before first store review. It is not honest as a standing model. A shared personal login has no audit and no revoke. Treat it as a reject.

Which clocks rewrite ownership after you sign?

The clocks that rewrite a silent ownership line are already live or dated on the vendor calendars. If the SOW says "we'll handle the stores," the first blocked agreement, the first D-U-N-S hold, or the first leftover package is an unpriced change order. Apple moved the upload floor first. Play's identity and package clocks share a September date and are not one Gradle integer.

Since April 28, 2026, App Store Connect uploads must be built with Xcode 26 using an iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26 SDK. Existing live versions stay. That is an upload gate — and an account gate. The person who accepts agreements and the person who uploads are different seats. If Account Holder is still "the studio," you cannot accept the agreement that lets the Admin upload.

Organization identity has a lead time on both sides. Apple's identity-verification help is explicit that organization enrollment includes a D-U-N-S number and a binding-authority check. Enrollment will not take a DBA, trade name, or branch as the legal entity. Apple's D-U-N-S page is where you look up or request the number. Play's organization account asks for the same identifier. Google's verification path, documented on the Android side, says a new D-U-N-S request can take up to 28 days. That is the only item on this page with a multi-week vendor clock you cannot buy your way out of. Start it before you staff a build.

Play's leftover-package clock is September 30, 2026. First-wave verified-developer installs in Brazil, Indonesia, Singapore, and Thailand share that date; Play also threatens global removal of unregistered Play packages. If your users or a partner store sit in that wave, the package name and who holds the signing key belong on the ownership sheet — not in a kickoff parking lot. The verification article is the inventory. This page only asks: is the name registered to your owner account?

What has to be true before first TestFlight or a Play internal track?

Your entity is enrolled, the agreements are accepted, the studio is invited — and nobody has uploaded under a login you cannot revoke. TestFlight and a Play internal track feel like "just a build." They are how a package name, a bundle ID, and a signing identity get claimed. If those claims land in the studio console, the first store review is already late.

Write the checklist as a table a PM can read. One row per console: legal entity, Account Holder / owner, invite list, bundle ID or package name, who holds the distribution certificate or upload key, whether Play App Signing is on, who files Data safety, and the date the first internal binary is allowed. If two rows disagree on the entity, you have already picked the studio login. You cannot keep a listing alive that you do not own — year-one TCO still assumes you hold the console.

A store binary without this loop is a demo. App Review and Play Console will eventually ask for a demo account, a deletion path, or a Data safety edit at 2 p.m. US Central. The person who can accept an agreement has to be reachable the same afternoon. Overlap is a product. Ownership is why that product can act.

Whose legal entity must hold the stores before we sign?

The operating company that will be the seller — from day one. Not the studio. Not a personal Apple Account you share. Not a Delaware shell nobody can sign for at 2 p.m. Central. Enrolling an organization requires a legal entity that can enter contracts and a person with binding authority. Play's organization account is the same shape. If counsel has not picked the entity, you do not have an Austin SOW. You have a discovery gate.

Can we invite the studio as Account Holder and transfer after launch?

No. Invite them as Admin. Apple's transfer is not a vendor offboarding tool. Account Holder transfer moves the role to another employee on your team who can bind the organization, after identity verification. Play's ownership transfer is a separate identity process and can block on the payments profile. A SOW that says "we'll transfer after launch" is pricing a legal process the vendors did not write for this job.

What should the studio hold instead of the membership?

An Admin or Developer invite you can revoke, plus the certificates and upload access those roles already grant. That is enough to produce an Xcode 26 binary, run TestFlight, and push a Play internal track. It is not enough to accept agreements, move banking, or take the package name. A shared password is not an invite. If they will not work from Users and Access, they are asking for the company.

Who owns signing keys and Play App Signing when we leave?

You do — or you do not have a leave path. On Apple, distribution certificates and the private keys that sign them should live in the organization team and a founder-controlled CI, not only on a contractor laptop. On Play, Play App Signing means Google holds the app-signing key and you hold the upload key; resetting the upload key is an owner action. If the studio created the app, Google bound those keys to their owner account. The verification inventory is how you list every SHA-256. This page is who is allowed to hold the row.

How long can D-U-N-S and identity verification slip the first TestFlight?

Long enough to idle a staffed sprint — Google cites up to 28 days for a new D-U-N-S number, and Apple will not enroll an organization without it. Identity verification also covers the officer and a binding-authority check. That is why the ownership gate sits before first TestFlight, not in week six. If the entity is not enrolled, the honest next spend is a fixed-fee wait plus invites — not a build squad watching a Dun & Bradstreet ticket.

What does "we'll handle the stores" cost when the partnership ends?

It costs a product you cannot take with you — plus the weeks of transfer, re-enrollment, and leftover package names illustrated below. The sentence sounds like launch support. It is a standing lien on the seller name. Recovering a vendor-held Apple membership is not a Support chat: Apple will not transfer Account Holder to a client the way a domain registrar transfers a DNS record. Recovering a vendor-held Play listing is an ownership-transfer case that can fail on payments. Rebuilding both consoles under your entity means new bundle IDs or a fight over a package name they already registered.

What does CodeCross open on an Austin ownership call?

The entity, the two consoles, the invite list, and whether the next spend is enrollment, a build, or a stop. CodeCross is an Austin-registered product studio — CodeCross LLC — with engineering on hours that overlap US Central. We work as invited Admin. We do not become Account Holder. We do not create your Play organization. The ownership conversation is how we tell a readable SOW from a login we would have to steal back later.

What we will actually open in that conversation:

• The legal entity on the brief and the estimate — or a rewrite of the entity before anyone talks compilers.
• Account Holder for Connect and account owner for Play: your entity, from day one.
• The Admin / Developer invites we need, and the date you can revoke them.
• Bundle ID, package name, Play App Signing, and who files Data safety.
• Whether D-U-N-S and identity verification are done, or whether the next spend is a wait.
• Whether leftover Play packages sit on the September 30 clock.
• Dated proof you can click on the proof dashboard.
• A written no, if we are the wrong shape: no walk-in lab, no staff-aug bench, no studio-held membership.

We will tell you whether the next spend is enrollment, a store binary, or a stop. Directional ranges already live on the estimate page. The brief is how you keep those numbers attached to assumptions. The shortlist is how you keep them attached to a bench you can reach. The estimate read is how you keep the PDF from becoming fiction. This article is how you keep Connect and Play from sitting in someone else's login.

The ownership conversation is a booking — not a homepage form that invents your seller name. Bring the entity, the two consoles, and the invite list. Do not send the studio password.

An honest Austin store-account line is shorter than the Slack thread you already have. Name the entity. Invite the shop as Admin. Start D-U-N-S before you staff a sprint. Treat "we'll handle the stores" as a reject. Then sign the two pages that survived the sheet — or stop before the wrong login has a TestFlight and no leave path.