The Apple Developer Program account belongs in your name or your company’s, whoever wrote the code. A builder gets a role inside it and can do every technical step from there, and only the Account Holder or an Admin can create the distribution certificate that signs an update.
That is the decision sitting underneath a phrase that looks purely navigational. People type apple app store developer account on the way to Apple’s sign-up page, and the questions attached to it in autocomplete are all consequential: individual or organization, whose legal name, D-U-N-S Number or none, what access to give the person doing the work. Apple answers each on a different help page and never says what the choice costs you a year later.
The whole publishing sequence once the account is yours is a separate subject, and nothing below repeats it. This page starts one step earlier: which account, in whose name, with whom holding what inside it.
Every requirement, role name, permission and screen name below was read from Apple’s and Google’s own developer documentation on 16 August 2026, and each is named the way its owner names it. No developer account was opened or operated to produce this article.
Individual or organization: which Apple developer account should you open?
Two enrollment types exist, and the difference the public sees is the seller name. An individual enrollment puts your personal legal name on every listing you ever publish. An organization enrollment puts the entity’s name there, and asks for a D-U-N-S Number registered to that entity before it will start.
| Apple, individual or sole proprietor | Apple, organization | Play, personal | Play, organization | |
|---|---|---|---|---|
| Who signs | You, personally | A person with the legal authority to bind the entity | You, personally | The organization |
| What the public sees | Your personal legal name as the seller name | The organization’s legal name as the seller name | A developer name that can differ from your legal name | The organization’s developer name |
| What it asks for | Legal name, address, an Apple Account with two-factor authentication | Legal entity, a D-U-N-S Number registered to it, a website on your own domain, a work email on that domain | Legal name, legal address, identity verification | D-U-N-S Number, an organization website, organization details |
| What people miss | Your own name goes on the listing | No DBAs, trade names or branches | Testing requirements before a first release | No D-U-N-S Number, no account |
Apple’s enrollment page sets the individual bar low: “If you’re an individual or sole proprietor/single person business, you’ll need an Apple Account with two-factor authentication turned on and be the legal age of majority in your region.” Then it states the consequence in the next breath. “Your personal legal name is needed so that you can enter into contracts with Apple. Your name will be displayed as the seller name of your apps on the App Store.”
The seller name is chosen once, at enrollment, and it is your own legal name unless a legal entity is the thing enrolling.
That is not cosmetic and it is not easy to undo. If the entity exists already and you intend to sell the app or raise money on it, enroll the organization. If there is no entity yet, the individual route is the honest one, and Apple is blunt about dressing it up: “Using an alias, nickname, or company name as your first or last name will cause a delay in the approval of your enrollment.” The same page adds a small trap for anyone working out of somewhere that is not a street address. “P.O. boxes are not accepted.”
On the organization side, the person who signs up is the person Apple treats as able to sign, which is why the sign-up should never go to whichever contractor is closest to a keyboard. Whether your builder can produce a store build at all is a separate question. This one comes first, because the account outlives the builder.
What an organization enrollment actually asks you for
A D-U-N-S Number is the part that surprises people, and it is not an Apple product. Apple’s D-U-N-S page describes it as “a unique nine-digit number that identifies business entities on a location-specific basis,” issued by Dun and Bradstreet. Apple’s rule on who needs one is exact: “Companies and educational institutions must provide a D-U-N-S Number registered to their legal entity. A D-U-N-S Number is optional for government organizations. If you’re enrolling as an individual, you don’t need a D-U-N-S Number.”
Look yours up before applying for a new one, because an entity that has filed anything anywhere often already has a number attached to it. If it does not, plan around Apple’s stated allowance: “After requesting a D-U-N-S Number, please allow up to 5 business days to receive your number from D&B.” That wait sits in front of the enrollment rather than inside it, so start it first. How long the account side takes next to everything else is worth reading before you promise anyone a date.
The two requirements that catch pre-launch founders are the website and the work email, and Apple wants both on the company’s own domain. It names the shortcuts it rejects: “Your organization’s website must be publicly available and functional, and its domain name must be associated with your organization. Links to social media webpages or websites that contain minimal content or display a message from a domain registrar won’t be accepted.” A parked domain and a Gmail address will not get an organization enrollment through. The website does not have to be the app. It has to exist, work, and sit on the domain in your email.
Then the naming rule, which rules out a whole category of arrangement: “We do not accept DBAs, fictitious business names, trade names, or branches. Your organization’s name will be displayed as the seller name of your apps on the App Store.” Customers see the registered entity, whatever name is on your invoices.
There is a recurring shape to this that has nothing to do with code. A founder owns a US company while living somewhere else, has an iOS app and a desktop app finished and ready for testers, and cannot move, because every blocker is operational: developer program registration, US banking, all of it handled as an owner who is not resident. The build is done. The paperwork around it is what the launch is waiting on, and it wants starting weeks before the build is ready.
Apple states its own requirements and stops there. How a particular country’s company paperwork maps onto them is a question for whoever set the company up.
What about Google Play, personal or organization?
Google runs the same fork with different stakes. An organization account on Play cannot be created without a D-U-N-S Number, and a personal account lists a developer name that can differ from your legal name. Apple gives an individual enrollee no such separation.
Play’s account-type page states the D-U-N-S requirement as a hard blocker: “You will not be able to create a developer account for an organization without one.” A personal account supplies a legal name and legal address and completes identity verification, and its public developer name “can be different from your legal name”. Two stores, two answers, and only one of them puts a solo founder’s own legal name on a listing.
The other Play difference is who controls the money. On Google’s permissions page, the account owner “Is the only person who can have a linked payments profile to sell paid apps” and “Is the only person who can access and edit information on the Payments settings page in Play Console.” That is Play’s version of the same rule Apple applies to agreements and renewals: the owner is the payments relationship, and no role hands that over.
Registering the Play account and everything Google asks for after it, including identity verification and the testing requirement a new personal account has to clear before a first production release, is its own long subject. The only question this page answers about Play is which account type, in whose name.
How do I give a builder access without giving away the account?
Roles are how you do this. Apple grades access into eight of them, and two lines decide the choice: only the Account Holder and Admin can create distribution certificates, and a reserved list of actions belongs to the Account Holder alone however senior anyone else looks.
Invite the person in with a role rather than sharing a login. Apple’s role permissions reference names the Account-Holder-only set in one sentence. The Account Holder “is the only user that can sign legal agreements, renew membership, request access to the App Store Connect API, remove auto-renewable subscriptions from sale, submit Safari Extensions, or create developer ID certificates.” Call that the reserved list. The Account Holder seat is the one you keep. The four roles that decide the rest:
| Role | What it lets a helper do | What it still cannot do |
|---|---|---|
| Account Holder | ”The person who completes program enrollment is assigned the Account Holder role. This user is responsible for entering into legal agreements with Apple.” | Nothing. |
| Admin | ”Serves as a secondary contact for teams and has many of the same responsibilities as the Account Holder. Admins have access to all apps.” | The reserved list. App access cannot be limited to one app. |
| App Manager | ”Manages all aspects of an app, such as pricing, App Store information, and app development and delivery.” | The reserved list. Create distribution certificates. Remove users. App access can be limited to named apps. |
| Developer | ”Manages development and delivery of an app.” | The reserved list. Create distribution certificates. Add or remove users. App access can be limited to named apps. |
Finance, Marketing, Sales and Customer Support are narrower again, and Apple’s own lines cover them: financial information and tax forms; marketing materials and promotional artwork; sales, downloads and other analytics; customer reviews on the App Store.
The mechanics are ordinary. Adding a user needs the Account Holder, Admin or App Manager role, and “The new user receives an email with a link to activate their account.” Send it and forget about it and you will be sending it twice: “User invitations expire 3 days after the invitation is sent. An invitation can be resent after expiration.” Removing somebody needs the Account Holder or Admin role and is not instant, because “Caching may take up to 10 minutes to complete, fully revoking access.” Apple also names the roles that cannot be narrowed to specific apps: Admin and Finance “can view all app info and can’t have access limited”, along with anyone holding reports access or Certificates, Identifiers and Profiles.
One note breaks this whole plan for a solo founder. Apple’s program roles page says: “If you’re enrolled as an individual and add users in App Store Connect, users receive access only to your content in App Store Connect and are not considered part of your team in the Apple Developer Program.” A founder on an individual membership who believes they have added a developer to the account has added them to App Store Connect and to nothing else. On an organization membership, the same page states that “the Account Holder for your team manages the account and is the person who needs to renew your annual program membership, accept legal agreements on behalf of your organization, initially add Admins to the team, and approve banking changes in your account.”
If a build never appears in App Store Connect after someone says they uploaded it, a role split is one of the ordinary explanations and worth checking before anyone starts guessing at screens. When a developer is taking over the app rather than helping with it, what you hand them is a longer list than one invitation. Getting a build to testers once the account exists is a separate step again.
Distribution certificates, in plain English
A distribution certificate is the identity the store checks a build was signed under. It belongs to the account, and the account decides who can make one, whatever laptop it was generated on. That fact explains most of the ugly situations founders reach when a working relationship ends.
Apple’s certificates overview states the control rule directly: “Only the Account Holder or Admin role can create distribution certificates (if you’re enrolled as an individual, you are the Account Holder).” So whoever holds those two roles decides whether a future update can be signed at all. Give away Admin casually and you have given away that.
The second rule is about supply. “Distribution certificates belong to the team and only one type of each distribution certificate (with the exception of Developer ID certificates) is allowed per team.” Development certificates work the other way: “Development certificates belong to individuals.” That is why “just make another one” is not how signing works, and why revoking one to tidy up can stop somebody else’s build in the middle of their week.
Profiles are the piece people confuse with certificates. Apple’s provisioning-profile page settles it in a sentence: “An App Store provisioning profile contains a single distribution certificate.” The profile is the wrapper. The certificate is the identity inside it.
Two boundaries, so you do not go looking for the wrong answer. Android signing keys are a different mechanism, and an Android signing key that changes under you is a different problem with a different fix. When a builder generates a new certificate on every build until it hits the per-team limit, that is a builder-specific error rather than something about your account.
The app is already in somebody else’s developer account. Now what?
An app transfer has a gate in front of it. Apple moves an app only if it has had at least one version released to the App Store, and it will not move one sitting in any review state. An app your contractor submitted but never released cannot be transferred at all.
Apple’s transfer criteria put the first condition plainly: “The app must have at least one version that was released to the App Store.” On top of that, the app cannot currently hold any of these statuses, as the page read on 16 August 2026:
- Processing for Distribution
- Waiting for Review
- In Review
- Accepted
- Pending Developer Release
- Pending Apple Release
It also cannot be available for pre-order in any country or region, and both accounts have to be out of any pending or changing state with the latest paid and free agreements accepted on each side.
So the worst case is also the common case. An app a contractor submitted that stalled in review, or was rejected and never released, is not transferable. The two honest options are to get a version released from that account first and then transfer, or to publish a fresh listing from your own account and lose the ratings and download history. Knowing which one you are in takes about two minutes in App Store Connect.
When a transfer is available, Apple’s transfer overview sets the actors: “Your membership Account Holder initiates the app transfer” and “The receiving Account Holder accepts the app transfer.” One more condition catches AI-built apps in particular, because generated identifiers repeat: In-App Purchase product IDs on the app being moved cannot match product IDs on any app already in the receiving account. Getting every account back when the person who set them up has gone is a far wider job, and store listings are one row on that list. An app a contractor built for you has the same shape whether or not they are still answering email.
There is a market for shortcuts here, and it is louder than you would expect. A Google Autocomplete run on 16 August 2026, four seeds and four hundred live requests, returns completions for buying, sharing and generating Apple developer accounts, including named marketplaces. What that demand buys is an app published inside an identity somebody else controls, with a stranger in the seat that signs agreements and renews the membership. It is the contractor problem with one more party in it and nobody to appeal to.
Settle it before anybody pays
Three lines cover it. The developer account is opened in your name or the company’s, by you. The person doing the technical work gets a role inside it, limited to named apps where the role allows that. Nothing gets published under anybody else’s membership, at any stage, for any reason.
The account is the first step and the one that is expensive to change afterwards. Everything downstream, the listing, the signing identity, the ratings, the right to ship an update, follows whichever account publishes. Settling the account and the roles before the first submission takes an afternoon. Undoing the wrong choice takes a transfer, a released version, and somebody else’s cooperation.
What publishing costs once you add up both stores is a separate calculation, and it is worth doing before the enrollment rather than after. Whether the rest of the app is ready for the store at all is a different question again.
Common questions about the Apple developer account
Can I enroll in the Apple Developer Program for free?
Registering as an Apple developer is free and joining the paid program is not. Apple’s registration page is explicit: “Sign in using your Apple Account and accept the Apple Developer Agreement to register for free.” That gets you beta software, the developer forums, Feedback Assistant and developer news. Distributing an app on the App Store needs the paid Apple Developer Program membership.
How long is Apple Developer enrollment?
Apple does not publish an approval time. As of 16 August 2026, Apple’s enrollment support page gives no processing estimate for either account type, and only tells you to contact Apple if a membership confirmation has not arrived within 24 hours of purchase. The one published wait in the sequence belongs to Dun and Bradstreet: Apple asks you to allow up to five business days for a D-U-N-S Number.
Why can’t I enroll in the Apple Developer Program?
Three stated rules block most stalled enrollments. Apple says an alias, nickname or company name in the first or last name fields “will cause a delay in the approval of your enrollment”, that “P.O. boxes are not accepted” for the address, and that it does “not accept DBAs, fictitious business names, trade names, or branches” as an organization name. Organization enrollments also fail the website rule, which wants a publicly available, functional site on the organization’s own domain rather than a social page or a registrar placeholder.
Who is eligible to join the Apple Developer Program?
An individual or sole proprietor needs an Apple Account with two-factor authentication turned on and has to be the legal age of majority in their region. An organization has to be a recognized legal entity, and the person enrolling has to hold the legal authority to bind it to agreements, because Apple makes them the Account Holder. Companies and educational institutions also need a D-U-N-S Number registered to the legal entity.
Can I use an LLC for an Apple developer account?
Yes, as an organization enrollment. An LLC is a legal entity, so it takes the organization route: a D-U-N-S Number registered to the LLC, a work email on the LLC’s domain, a functional website on that domain, and a person with authority to sign for it. The registered name appears as the seller name on your listings, never a trading name.
Can I change from an individual account to an organization account later?
Apple documents the change and handles it manually. Its enrollment support page says: “If you have enrolled as an individual and need to convert your individual account to an organization account, please contact us.” There is no self-service switch in the account settings, and the same page states that a sole proprietor or single-person business joins as an individual with their legal name as the seller. Expect to supply what a fresh organization enrollment needs, starting with a D-U-N-S Number.
Who should be the Account Holder if a contractor set everything up?
You, or someone inside your company. The Account Holder signs Apple’s legal agreements, renews the membership, adds the first Admins and approves banking changes, and on an organization enrollment Apple expects that person to have authority to bind the entity. If a contractor completed the enrollment, they hold that seat, and the app reaches your account through an app transfer their Account Holder initiates and yours accepts, subject to the released-version rule above.
Do I need a Mac to hold the account?
No. The developer account is a web relationship with Apple: enrollment, App Store Connect, Users and Access, and Certificates, Identifiers and Profiles all run in a browser. A Mac belongs to the build and upload step, which is a different question about who compiles the app and how the binary reaches App Store Connect, including whether the Mac-free routes to a shipped iOS app hold up for your particular build.
When every fix and release still depends on you
AxonBuild can trace the failure, repair the broken workflow, and ship the next change without rebuilding the parts that already work.
