Apple and Google both require the app to live in an account owned by the business that owns the app. That is you. You open the two accounts below and let us in. If you open them in your own name, Google also needs 12 tester emails from you; if you open them in your business's name, it needs a D-U-N-S number instead. Most people go with their own name, and never touch the D-U-N-S part at all. After that we do everything else: the listing, the screenshots, the uploads, the review process.
Free, about ten minutes, and it is the step everybody gets stuck on.
Google, Apple and Stripe all lock the account behind a second code before they will let you finish. Do this part first and the rest of the page goes smoothly.
Go to myaccount.google.com, open Security, then 2-Step Verification, and follow the prompts. If it tries to send a tap-to-approve prompt to your phone and nothing happens, tap Try another way and pick the text message code instead. That is the fix if you are stuck on "it won't verify my device" while signing in. If it is Play Console itself refusing to verify your device, that is a separate check with its own fix: see The Android phone check.
Apple requires it too, and it is built into the enrollment below. When Apple asks, use the same phone. Nothing extra to install.
Do not go looking for a way to add Apple to the authenticator app. There isn't one. Apple does not accept codes from Google Authenticator, Authy or anything like them. It sends its own code to an Apple device you are already signed in on, or texts it to a trusted phone number you give it. If you are sitting in the authenticator app hunting for Apple, stop: nothing is wrong with your account and there is nothing to add.
Stripe asks for a code every time you log in. If the app code is not working for you, click "Use a different authentication method" on the login screen and switch to a text message instead.
Free, about five minutes, and it is the one decision on this page we cannot make for you.
Both stores ask for the name on the first screen of the listing, so nothing can be created until you have picked one. The two stores then treat it very differently, and knowing which rule is which saves you throwing away a good name for no reason.
Several apps can carry the same title on Google Play at the same time, and plenty do. The only hard limit is 30 characters. So a name already in use over there is not a reason to drop it.
Apple reserves a name to a single app, first come. If somebody already has the exact name you want, App Store Connect simply refuses it when we create the record and you pick another one on the spot. Nothing is lost and nothing is delayed by more than a minute.
Similar is fine. Identical is not. Names that share a word with yours, or read like yours with something on the end, are no obstacle at all on either store.
Search the exact name in the App Store and on Google Play, then search the word on its own at tmsearch.uspto.gov, which is the free US trademark register.
What you are looking for is not a resemblance. It is a company trading under that name in your own line of work. That is the one that can cost you something later.
Send us the name and we take it on Apple the moment we create your app record. You can still change it later, right up until the app goes live, and after that with any new version.
The one thing that is permanent is the ID underneath it, which nobody but us ever sees. That is set on the first upload and can never be changed on either store, so the app is only ever renamed, never rebuilt.
$25, paid once to Google, and that is it forever. Two-factor first, or step 1 will stall.
Go to play.google.com/console/signup and sign in with the Google account you want your app to live under. Pick yourself or your organization, whichever owns the app. Pay the $25.
That one choice on the signup screen changes your whole launch, so read this before you click it.
Personal starts today, and it comes with two rules: you have to prove you own an Android phone, and your app has to run a closed test with 12 testers for 14 days in a row before it can go public. We run the test, but the 12 people have to be yours, so start thinking about who they are now rather than on launch day.
Organization skips both of those. The trade is up front: Google verifies the business first, and asks for business documents and a D-U-N-S number, which takes weeks rather than minutes. It is free, and one number covers Apple too. It also wants an email address at a domain you own, which is where most people find out this route has homework of its own. The whole organization route is below.
Personal if you want to move now. Organization if you have the paperwork and would rather wait once at the start than test at the end.
And if you cannot field twelve Android people, organization is not the slower road, it is the only one. Twelve is a floor Google does not move, so a personal account with nine friends on it never publishes at all. A registered company you already own turns that from a wall into a wait. It does not need to share a name with your app.
Pick it before you pay. Google asks this once, on the signup screen, and there is no switch in settings afterwards. Decide, then click.
Signing up, Google asks for An email address for your developer profile, and its own line under that field is "This will be shown on Google Play as part of your public developer profile." That is you, in public, on your app's page. Your address goes in it.
There is nowhere to put us on this screen, and that is not something you have missed. We cannot be added to an account that does not exist yet. Letting us in is step 5, on a Users and permissions screen the console does not show you until the $25 is paid.
Our address here would not let us in, it would lock you out. Google verifies that profile address with a code before it will finish your account, and the code goes to whoever owns the mailbox. Put ours in and you are waiting on a code you cannot read, on an account that never opens, and nothing on the screen tells you that is what happened.
Same rule on Apple. Enroll with your own Apple ID and your own details, all the way through. Every address we ever give you is pasted after an account exists, never while you are making one.
Google asks for an ID check and confirms your phone and address. Do it right away; the account is limited until it clears.
Personal accounts get one more task: proving a real Android phone belongs to you. It is the step that traps everybody, so it has its own section below. Do it there, then come back.
Personal accounts cannot go public until 12 people have tested the app for 14 straight days. We run the test; you supply the 12 email addresses. It has its own section below, because getting this wrong is what pushes a launch back by a fortnight.
In the Play Console, open Users and permissions, choose Invite new user, and invite both of these with Admin (all permissions). Admin is the word to look for; the lesser roles cannot publish.
david@davidfrench.io
luke@davidfrench.io
Two people, one screen. Luke runs the store work day to day and Google, unlike Apple, gives us no way to add him ourselves afterwards, so doing both now saves us coming back to you a second time.
Same panel, one more address. Users and permissions, Invite new user, and this time paste:
play-publisher@tayw-store-507320.iam.gserviceaccount.com
It is not a person and no mail ever goes to it. It is the account our build machine signs in as to push your app into your console, and inviting it is the only way it gets in.
Give it Admin (all permissions), the same as the two above. Then tap Invite user at the bottom, same as before.
Free, about five minutes, and it is the one that cost a client three days.
Google makes every new personal developer account prove it owns a real Android phone. Being signed into your Google account in a browser does not count, no matter how many times you sign in again. Google wants the phone itself to check in.
Search Play Console. The right one is published by Google LLC. Install it.
Sign in with the exact Google account that owns the developer account and paid the $25. Not a second work account, not your spouse's, not whichever one the phone was already using.
The app lists the developer accounts it can see. Choose yours and tap Verify. That is the phone checking in with Google.
Go back to Play Console on the computer and reload the page. The task clears itself. It does not clear until you refresh, so a stale page is not a failed check.
Free, but it is the one that decides your Google launch date, so read it early. Apple does not ask for this.
Google will not let a new personal developer account publish to the public until the app has been through a closed test with at least 12 testers, opted in for 14 days without a break. Google writes the rule for personal accounts only, so an organization account skips it entirely. If you picked personal, this applies to you, and the fourteen days do not start until the twelfth person has joined. If twelve Android people is not a list you can actually write down, do not grind at it: the organization route is the way past it, and it works with any registered company of yours whatever it is called.
Every one has to be a Google account, which in practice means a Gmail address or a work address signed up with Google.
The fast way: send them a link and let them enter their own. You have a signup page of your own for this. Text it, put it in a group chat, post it, say it out loud. Whoever opens it gets told what the fourteen days involve, is told plainly if the phone they are holding cannot do it, and puts in their own address. Nothing is ever emailed to them from that page.
Ask us for yours and we will send it over.
It saves the part that actually costs people days: asking twelve people one at a time and then chasing each of them for the exact spelling of an address you cannot check.
Or send them to us. If you already have the addresses written down, put them in one message to david@davidfrench.io and we will load them.
Either way, Google never emails your testers, so nothing reaches them at this point. The only thing that ever lands with them is the join link in step 2, which is why a heads-up from you now saves chasing them later.
We load them into the closed test in Play Console and send you back one join link to forward to all twelve.
This is the part that costs people two weeks. Being on the list is not enough. Each person has to open the link, tap to become a tester, and install the app on an Android phone. Anyone who never taps accept does not count, and the clock does not start until the twelfth one has.
Fourteen consecutive days with twelve or more testers on the list. If somebody opts out or uninstalls partway through and it drops to eleven, the count resets. Tell your twelve to leave it installed and forget about it for two weeks, that is the whole ask.
Most people never do this. Only for an app going out in a registered business's name.
If you open your developer accounts in your business's name instead of your own, both stores drop the personal checks and ask for two things instead: a D-U-N-S Number for the legal entity, and an email address at a domain you own. No 12 testers, no Android phone check, no photographing your driver's license for Apple. The number is free and covers both stores. Before either of them, though, there has to be a registered legal entity to name: an LLC or a corporation, not a business name you trade under. It does not have to be called what your app is called, and reading that rule the other way is how people rule themselves out of this route by mistake. The email address is what stops people on the very first screen, and the entity is what stops them on the second, so read the callouts below before you start anything.
This is the first wall on the business road, it has nothing to do with the D-U-N-S number, and it is the reason most people give up here. Both stores want a work email on a domain you own, like you@yourbusiness.com.
Apple is a hard stop. Apple's own line on the enrollment page: "Your work email address needs to associated with your organization's domain name." The field refuses gmail.com, yahoo.com, hotmail.com and the rest. It just turns red and will not validate, and it never tells you why. If that is what you are looking at, this is it, and no amount of retyping the address fixes it.
Google is nearly as strict. Google wants a developer email that is "an official email address associated with your organization" and says it "should not be a generic or personal email address". Google also asks for an organization website, and verifies that you own it through Search Console, so a domain is coming either way.
The domain is not an errand for you. Text us two or three names you like, we check what is actually available, tell you the exact price and register it once you say go, then put your app on it: that is how it works for your web address too. It is step 5 below, and it is a text message rather than an errand.
The mailbox on it costs nothing either. Zoho Mail gives you one free mailbox on your own domain, and the DNS records it needs are ours to add. Google Workspace, at roughly $7 a month per address, is the paid version of the same thing, and nothing on this route requires it. So the price of clearing this wall is a text message with a few names in it.
Apple wants a legal entity, not a business name. On the organization route Apple requires an organization that can enter into a contract, and it does not accept a DBA, a fictitious business name, a trade name or a branch. Trading under a business name is not enough. If there is no LLC or corporation registered, the Apple business route is shut whatever address is in that field, and a domain will not open it.
Then the waiting starts. The D-U-N-S number is free and it is also the slowest thing on this page: up to 5 business days for Dun & Bradstreet to issue it, up to 2 more before Apple can read it, and Google's own figure is up to 30 days, with Google's business verification running after that.
So weigh it against what you are avoiding. The worst the personal route costs you is Google's 12 testers for 14 days, and you can start collecting those today. For a business that is already registered, the organization route often takes longer than that. For one that is not, it does not start at all. If you picked business for speed, it is the wrong road.
Unless the twelve are the thing you cannot get. Then the arithmetic turns over: weeks of waiting beats a requirement you never meet, and the organization route is the way onto Google Play rather than the slow way onto it. Weigh it against twelve real people you can name, not against fourteen days.
This is the sentence above read backwards, and it costs people the whole route. The entity name and the app name are two different fields on two different screens.
Apple says where it goes. Apple's own line, in the same breath as the DBA rule: "The legal entity name will appear as the 'seller' for apps you distribute. Example: Seller: ABC Company, Inc." Seller is one gray line under your app. It is not the name on the icon, and nobody arrives at your app by reading it.
The app keeps the name you picked. Whatever you settled on in your app's name is what is on the store, the icon and the search results, exactly as it would be on the personal route. Google works the same way: the developer name is your publisher profile, the title is set per app, and Google lets you change the developer name later anyway.
So what Apple refuses is enrolling AS a trade name. It will not take Suite Space as the entity if Suite Space is only what you trade as. It will happily take Your Real Holdings LLC as the entity and put an app called Suite Space under it. One registered company can carry any number of differently named apps, and most of the ones on your phone do.
Which means the question is only whether a company is registered, never whether it shares a name with the app. If you have an LLC or a corporation at all, this route is open to you.
Nothing makes you pick the same route twice. You can be an organization on Google Play and an individual on Apple, or the other way round. Neither store knows or cares what the other one says.
So if the domain email is what is stopping you and you want to move today, go personal on both with the address you already have. Apple takes any Apple ID on the individual route, Gmail included. Google takes any Google account. What that costs you is Google's 12 testers for 14 days and Apple's ID photo check, both of which are on this page and both of which are survivable.
The other thing it changes is the name printed under your app in the stores: the business on the organization route, your own legal name on the personal one.
They get mixed up constantly, and having one does not get you the other.
The EIN is nine digits from the IRS, for tax. Neither store asks for it.
The D-U-N-S Number is nine digits from Dun & Bradstreet, for identity. It is what Apple and Google both read, and it is free.
Plenty of businesses already have one without knowing, because a bank, an insurer or a supplier filed for it years ago. Look yours up before you request one.
Use Apple's free lookup, even if Google is the only store you care about: developer.apple.com/enroll/duns-lookup. It searches Dun & Bradstreet and requests a number in the same form if there isn't one.
Have ready the legal entity name exactly as it is registered, the headquarters address, the mailing address, and your work contact details. If D&B already holds your business, the number comes back on the spot and you are done with this step.
If a name you recognize comes back but it is not the entity you are enrolling, do not take it. The lookup matches on name and address, so a church you pastor, a nonprofit you sit on, a former employer or an older business at the same address can surface instead of yours. That number belongs to that entity: enrolling on it puts their name on the App Store, and both stores ask you to certify you have authority to sign for whoever the record names.
Request one for your own entity instead. If Apple's form keeps returning the wrong match and will not let you past it, go straight to Dun & Bradstreet at dnb.com/duns/get-a-duns.html and open a new record there. They will ask for your formation document, the articles of organization for an LLC or the articles of incorporation for a corporation, and your EIN. This is the one place the EIN is any use on this road, and it is only to prove the entity exists, not as the number the stores read.
Same form. Apple's own numbers: up to 5 business days for D&B to issue the number, and paying anyone to expedite it does not shorten that. Then up to 2 more business days for Apple to receive it from D&B before an organization enrollment will go through.
Google's side runs longer. Google says obtaining a D-U-N-S number can take up to 30 days, and its own business verification runs on top of that. If you are past two weeks with nothing, contact D&B directly and ask where the request is.
A representative often rings to confirm details before issuing the number: what the business does, how many people work there, when it started. Keep your registration documents to hand and take the call. An unanswered callback is the most common reason one of these sits for a month.
No call at all is the good outcome, not a skipped step. If what you filed matched cleanly, D&B issues the number without ever speaking to you, and that is the fastest version of this. Plenty of people get the number in a few days having heard from nobody. It does not mean the record is unverified, it does not mean something is still coming, and there is nothing to chase.
What it does mean is that nobody has dialled your business number yet. The phone on your record came off the form, and a silent issuance is the case where no human ever tested it. Apple rings that same line later, so read it back and make sure it reaches you.
This is the trap on this route, the way the ID photo is the trap on the personal one. The legal name and address you give Google and Apple have to match your D&B record exactly. LLC against L.L.C., Street against St, a suite number on one and not the other: any of those reads as a different business.
If Google finds a mismatch it emails you a deadline to fix it and restricts the account if you miss it. Fix the D&B record or the store record so they agree, and do it before you submit anything.
Read your own record before you type it anywhere. D&B keeps a free self-service portal for exactly this: iupdate.dnb.com. Sign in, find your business, and look at the legal name, the trading name, the street address and the phone as D&B actually holds them. Those characters are what Apple and Google read. If a number was just issued off your formation document, the record is whatever was typed off that document, and a wrong suite number or a dropped LLC is easier to correct here, now, than after a store account is restricted.
A brand new number is not visible to the stores the same day. Apple and Google both read a copy of the D&B file rather than asking D&B live, and that copy refreshes on its own clock. Apple's own figure is up to 2 business days after the number is issued. So an enrollment that answers we cannot find that D-U-N-S a day after you got it means wait and try again, not that the number is wrong and not that you should request a second one. Two records for one business is its own week of untangling.
Both stores want an address at a domain you own, and that field is the first wall on this route. It is also the one thing on this page you do not go and get for yourself. Do not shop for a domain, and do not pay anybody for a mailbox.
What we need from you is a name. Text us two or three you like. We check which are actually free, tell you which one we would take and why, and once you say the word we register it, point the DNS at us and put a free Zoho mailbox on it. You get a login and an address that reads you@yourcompany.com. The domain itself is yours and you pay for it, at the exact price we quote you before anything is bought. The mailbox and all the setup are on us, and it is the same domain your app's web address runs on.
Name it after the company, not the app. Apple is reading that address against your organization, so a domain that matches the entity on your D&B record is the version of this nobody asks a question about. Your app keeps its own name either way, and one company can carry as many differently named apps as you like.
Start it while the D-U-N-S is baking. This takes us about a day, against weeks for the number, so the two run side by side and neither waits on the other. The signup screens in the next step will not let you past without the address, though, so it cannot be left until you are sitting on them.
Then put that mailbox on your phone. It is a brand new address you have never used, and the email that finishes your Apple enrollment can land in it rather than your normal inbox. An unopened work mailbox is how people wait a month for something that arrived on day three.
Google Play. At play.google.com/console/signup pick Organization, pay the $25, and have ready: the D-U-N-S number, your business registration or incorporation document, proof of the business address, a website for the organization, and a developer email at your own domain rather than a Gmail. Google also texts or emails one-time codes to the business phone and the contact addresses, so use ones you can answer. None of that finishes on the signup screen: the account goes into verification straight afterwards and cannot hold an app until it clears. Then invite david@davidfrench.io and luke@davidfrench.io, both as Admin.
Apple. Enroll at developer.apple.com/programs/enroll as an organization with the same number, $99 a year. Use your work email at your own domain on the enrollment form; Apple will not accept a Gmail on this route and will not say so. Instead of the ID photo, Apple checks the D-U-N-S record and that you have the authority to sign for the business, which is its own step below and does not finish the day you submit. Then invite davidfrench.me@gmail.com as Admin, and do the API key step exactly as written.
Paying the $25 does not open the account. Google puts a new organization account straight into verification, and while it sits there no app can be created in that console at all, by you or by us. So this is not a tidy-up task to come back to. It is the wall, and everything on the Google side is behind it.
It lives on Account details in the Play Console, and two things on that page hold it: your organization's website, and your phone numbers. Both are the account owner's to do. Admins we sit on cannot do either one for you, which is the one part of this page we genuinely cannot take off your hands.
This is the whole step, and it is the reason it reads as broken. Play Console only asks you for the address and then sends a request. The proof that the site is yours happens somewhere else entirely: Google Search Console, a separate free Google product you have probably never opened.
Do it there first, then send the request. In the other order there is nothing for the request to land on, and it simply fails with nothing on screen telling you why.
Sign in to Search Console with the same Google account that owns the developer account. Google's rule: if the account that owns the site in Search Console is the account that owns the Play account, the request is approved automatically. If it is a different Google account, the owner of the site in Search Console gets an email asking them to approve or deny, and the request sits until somebody clicks it. Two accounts is how this turns into a week.
The way that always works is a DNS record at your registrar, which is where you bought the domain, not where the site was built. In Search Console pick Domain as the property type, type the bare domain with no https and no www, and Google hands you a TXT record. If Search Console recognizes your registrar it may offer to sign you in and add it for you: take that, it is two clicks and you are done.
Otherwise add it by hand. At GoDaddy: Domain Portfolio, the domain, Domain Settings, DNS, Add New Record, type TXT, put @ in Name, paste Google's string into Value, leave the TTL alone, Save. Then go back to Search Console and press Verify. Other registrars use the same three words in a different order.
Pick Domain, not URL prefix. A Domain property covers www, every subdomain and http and https all at once. A URL prefix property covers exactly the address you typed, so a property on https://www.yourbusiness.com/ does not cover https://yourbusiness.com/, and finding that out costs an afternoon.
The other way is an HTML tag, and it only works if something lets you edit the head of your pages. Most website builders do not. GoDaddy's Websites + Marketing does, under Settings, Site-wide code, in the Head box rather than the Body one. Wix and Squarespace have the same box somewhere else again. If you cannot find it in ten minutes, stop looking and use the DNS route, which does not care what built the site.
If Verify fails once, wait and press it again. A new DNS record is usually live in minutes and is occasionally an hour. A failure straight after saving means the internet has not caught up, not that you typed it wrong, so do not go and change a record that is already correct.
Google's own screen says phone numbers, plural, and that is not a typo. An organization account holds two, on separate fields, each verified on its own with its own code. Doing one and seeing the task still open is what makes people think it did not work.
The contact phone number is private. It is how Google reaches you about the account.
The developer phone number is not. Google's words: it is "publicly displayed on Google Play to identify you or your organization". It goes on your store listing where any stranger who opens your app's page can read it, so put your business line there on purpose rather than whichever number was in the box.
They are allowed to be the same number. Google's rule is that any number from within the organization will do "as long as the person verifying it is able to receive texts or voice calls". Same number twice is fine; it is still two verifications.
Type it in international format, the plus sign and the country code first, like +18655550123, no spaces, brackets or dashes. A number typed the way you would write it on a letter is the most common reason the code never comes.
If the text does not arrive, choose the voice call. Google offers a six digit code by text message or by voice call and lets you pick, and switching to the call is the fix nearly every time, especially on a business line or a landline that cannot receive a text at all. Ask for the call rather than requesting the text a fourth time.
Then send the request and let it run. Once the site is verified in Search Console, put the identical address on Account details and send the verification request. Nothing here is a rejection and nothing on it needs chasing; tell us the moment both items go green and we create the app the same day.
Submitting the organization enrollment does not open an account. Apple answers with an email headed "Your program enrollment has been received", carrying an Enrollment ID and its own words for what happens next: "Once we verify that you have the authority to bind your organization to Apple Developer Program legal agreements, we'll email you with instructions on how to complete your enrollment." That email is the right one. Nothing has gone wrong, and there is nothing on your screen to fix.
The $99 has not been charged. On this route Apple verifies first and takes the money at the end, so there is no payment page to go looking for and no receipt coming yet. Google took its $25 up front and Apple does not, which is the part that reads as something being broken.
Apple may telephone you, and that call is the whole delay. It rings the business number on the enrollment, the one that is on your D&B record, and asks whether you have the authority to sign for the entity. An unanswered call is what turns two days into a month. Take it, and if you miss it, call the number back.
It is not the number you typed into Apple, and that is the trap. Apple dials what D&B holds. On a number issued this month that line was typed off your formation document and may be an office you have moved out of, a landline nobody sits at, or a digit wrong, and if D&B never rang you then nothing has tested it. Open iupdate.dnb.com, read the phone on the record, and if it is not a line you answer, change it there. Changing it on Apple's form does not change it, and this is a five minute job now against a month of silence later.
Watch both mailboxes, not one. Look at the enrollment email again: it lists an Email, which is your Apple ID, and a Work Email, which is the address at your own domain. Apple has both, and the instructions that finish this can land at either. On this route the work mailbox is usually the one set up a week ago for exactly this and never opened since, so put it on your phone next to the other one before Apple writes.
Keep the Enrollment ID. Star that email or screenshot it. Until an enrollment becomes an account it is the only handle Apple has on it, and without it you cannot ask anybody about your own application.
Do not start a second enrollment. Silence is not a refusal, and submitting again leaves two applications for one entity to be untangled, exactly the way two D-U-N-S records do. Watch the inbox, and check the status at developer.apple.com/account signed in as the Apple ID you enrolled with. If it has gone quiet for more than about two weeks, ask through developer.apple.com/contact and quote the Enrollment ID, not the 1-800 line, which cannot see an enrollment at all.
When it clears, Apple emails the link that finishes the enrollment and takes the $99. The invite and the API key step in step 5 come after that, not before: there is no App Store Connect account to invite anybody into until this is done.
$99 a year, paid to Apple. Two-factor first here too.
Go to developer.apple.com/programs/enroll and sign in with your Apple ID. Two-factor authentication has to be on; Apple will walk you through it if it is not. Enroll as an individual unless you have an incorporated business you want it under, then pay the $99.
Before Apple takes the $99 it checks who you are, by photographing a government ID in a separate app. Which documents it will take depends on the country you are in, and the screen that asks never tells you. You do not need a passport, and if that check will not pass there is a documented way around it entirely. That check is the Apple side's version of the Android phone check, it traps people the same way, and it has its own section below. Read it before you start, not after it has failed.
Individual enrollment does not open with a card. Apple signs you in, hands you off to the Apple Developer app on an iPhone or iPad to photograph your ID, and only asks for the $99 after that has gone through. So a run at developer.apple.com/programs/enroll that ends without ever showing you a price is not a payment that failed. There is nothing to pay yet.
Starting the enrollment again does not produce one either. If you have been round that loop more than once looking for where the money goes, the thing standing in front of the $99 is the ID check, and that is the page to read.
Where you actually stand is on one page: developer.apple.com/account, signed in as the Apple ID you started with. It tells you whether Apple is waiting on you or you are waiting on Apple.
Apple usually approves within a day or two. Nothing to do here but watch your inbox.
Open App Store Connect → Users and Access, tap the +, and invite davidfrench.me@gmail.com with the Admin role. Same word as Google, same reason.
Apple lets the Account Holder turn on API access and nobody else, not even an Admin like us. It is what lets us do your listing, screenshots, uploads and the review back and forth without you in the middle. This step and step 5 are the only two on Apple that have to be you.
Four clicks, about two minutes, once. Open the keys page on Apple, signed in as the Apple ID that paid the $99, and a computer is easier than a phone here because Apple hands you a file.
1. Tap the blue Request Access button and agree to the terms. No button means you are signed in as the wrong person; it has to be the Apple ID that enrolled and paid.
2. Tap the +, name it The App You Want, and set Access to ADMIN. Not Developer. Apple locks that setting in when the key is made and it cannot be changed after, so a Developer key means doing this step again.
3. Tap Generate, then Download API Key. You get a file ending in .p8. Apple gives it to you once, and if you lose it you delete that key and make another.
4. Copy the Key ID off the row you just made, and the Issuer ID from the top of that same page. Then send all three to us in the form below.
Apple keeps a license agreement that the Account Holder has to accept in person, and it is separate from everything you have already signed. Until it is accepted, Apple refuses every upload and every listing change we make on your behalf, with an error that only ever names the agreement. It is the last thing on Apple that is yours.
On a computer, open App Store Connect → Business, signed in as the Apple ID that paid the $99. Anything on that page marked as needing your action gets opened, read and accepted. When the page shows nothing outstanding, you are done.
There is one state where accepting the agreement correctly changes nothing, and it is Apple's, not yours. Look at the top of your Apps page in App Store Connect for a yellow banner headed Developer Information Update In Process. Apple's own wording under it: "Your developer information update is currently in process. Until it's complete, the updated Program License Agreement may not go into effect."
That is Apple telling you it is holding the agreement you just signed. It happens after a change to the details on your account, and it clears when Apple's own team finishes reviewing it, on Apple's clock. Signing it again does nothing, because it is already signed. There is no button anywhere that speeds it up.
If you see that banner, you are done and the wait is Apple's. The one thing worth doing is contacting Apple Developer Support and asking them to complete the developer information update on your account, because they are the only people who can move it. Tell us the banner is there and we stop asking you about the agreement.
Straight from this page. You do not need a link from us and you do not need to text anybody: confirm the email you use with us, and send it.
Free, about five minutes when it works, and weeks when it does not.
Apple verifies your legal identity before it will let you finish enrolling, and it does that by having you photograph a government ID. This part does not happen on the website: it happens in the Apple Developer app on an iPhone or iPad, and the website hands you off to it.
Apple's own words: "We accept passports in most regions, and some regions can accept additional types of government-issued ID, like a driver's license."
So a passport is the document the check is built around and a driver's license is the conditional one. The app never tells you which it will take from you, it just fails, so if you have both, photograph the passport.
If you do not have a passport, you are not stuck. A license is accepted in the United States and in plenty of other places, and if it still will not go through, the photo check is not the only way Apple can verify you. See no passport, and the license will not go through below. Do not go and apply for a passport over this.
Apple checks all of them, and any one of them being off shows up later as a plain "error" with nothing to tell you which.
Use one device start to finish. Begin and end the enrollment on the same iPhone or iPad. Swapping to another device partway is not supported.
Be signed into iCloud on it, with Face ID, Touch ID or a passcode turned on.
Give your legal name, exactly as it is printed on the ID. Not the name people call you, not a shortened first name, not your business name. This is the single most common reason an enrollment stalls.
Your address has to be a street address. Apple does not accept a P.O. box.
From the App Store, on the iPhone or iPad you are going to finish on. It is published by Apple.
Sign in with the exact Apple ID the app is going to live under. It can be a different Apple ID than the one the device itself is signed into, but it has to be the one you enrolled with.
Passport if you have one, license if you do not. Flat surface, no glare, all four corners in the frame, and both sides if it asks for both. Then you pick Individual, agree to the license, and pay.
The exact wording is "An error occurred. The photo of your ID didn't upload. Please restart your enrollment." and it is the Apple trap. It does not name a cause and it does not clear itself.
Trying again is not the fix. Not different lighting, not a different photo, not a different Wi-Fi network, not a newer iOS. If it has failed a few times it will keep failing, and people lose weeks on the retry.
A different document is not trying again. If you have been fighting a driver's license and you own a passport, photograph the passport instead. Apple accepts passports in most regions and a license only in some, and it is the one change worth making before you go anywhere near support. If you do not own a passport, skip straight to the next part; that is a solved problem too.
Check your name before you check anything else. Apple reads your name and address off the photo and compares them to your Apple Account. If the account says Jim and the license says James, or the address on the account is the last place you lived, the comparison fails and the message you get is the upload error. It never says that is what happened. Fix that first.
Apple has a second route, and asking is the only way to get it. Apple's own help page says that to verify by a method other than the Apple Developer app, contact support. So stop retrying and go ask for it.
Go to developer.apple.com/contact. It will make you sign in first, with the same Apple ID you are enrolling under; that is expected. Pick the membership and account topic, and tell them plainly: the ID photo will not upload, the error says to restart enrollment, you have tried it repeatedly, and you are asking to verify your identity by a method other than the Apple Developer app.
Support comes back to you with another way to submit the ID, usually a link that takes the upload in a browser instead of the app. Keep the case number they give you. Give it a few days; this queue answers by email and it is not fast.
The 1-800 line, the Genius Bar and the support app are AppleCare. They handle devices and Apple IDs, and they cannot see a Developer Program enrollment at all, so a call there ends in a shrug no matter how long you spend on it.
Developer Support is a separate team behind that signed-in form and nothing else reaches it. If you have already "called Apple" and got nowhere, this is almost certainly why, and it does not mean you have run out of options.
This is the corner most people end up in, and every one of these is something you can do today. Work down the list; stop when one of them works.
Apple pulls your name and address off the photo and checks them against the account. This is the single most common silent failure, and it costs nothing to rule out.
On the same iPhone, open Settings, tap your name at the top, then Personal Information. Your first and last name there have to be your legal name, character for character as it is printed on the license. Not the name you go by. Then go into Payment & Shipping and make sure the address on file is the address printed on the license, as a street address, not a P.O. box.
Fix anything that differs, then try the photo once more. Once.
This is not the same as retrying the photo, and it is the step almost nobody takes. A stuck enrollment holds its own failed state, and reshooting the ID a hundred times never clears it. Withdrawing throws the whole attempt away and gives the check a clean start.
In the Apple Developer app, Account tab, open the enrollment and choose to withdraw it. Then begin enrollment again from the start, on the same device, after the fixes in step 1.
This is the part that is not advertised, and it is the answer for anyone who does not have a passport. Apple's own help page, in these words: "If you do not want to provide a photo of your government ID, and it is not required by law, you may contact Apple for an alternative method of identity verification."
So the photo is not the requirement. The photo is the default, and Apple will verify you another way if you ask them to. Use the same form as above, developer.apple.com/contact, signed in, and ask for an alternative method of identity verification in those words. They are Apple's words and the people reading the form know them.
Only if you already have a registered business, and only if the three above have failed. An organization enrollment does not use the photo check at all: Apple verifies a D-U-N-S Number for the legal entity instead, which is free to request, plus a check that you have authority to sign for it.
It is a slower road and it puts the business name on the App Store instead of yours, so it is not where to start. But it is a real door, and it does not care whether you own a passport. The steps are in the organization route above, and one D-U-N-S number covers Google Play at the same time. Talk to us before you take it.
The moment both invites land, we take it from there: your listing copy, your screenshots, the builds, the review back-and-forth, and the day it goes live you hear it from us first.