Getting an app onto the App Store is mostly paperwork, and the paperwork is where it stalls — D-U-N-S Numbers, organization enrollment, signing certificates, review queues. I have taken seven apps through it. If your app is built and nobody on your side wants to own the Apple half, that is this.
A free 30-minute call. If you already have a developer who handles your Apple account, you do not need me for this and I will say so on the call.
Coding assistants have made the building part dramatically faster, which is exactly why this part now looks so slow by comparison. None of it is code. It is identity verification against a Dun & Bradstreet record, a human reviewer in a queue you cannot see, and a set of forms where a wrong answer on export compliance or data collection is a rejection rather than an error message. No model shortens a five-day D&B investigation or moves you up Apple's queue. What it does change is the arithmetic: when the build takes weeks instead of months, three weeks lost to enrollment stops being a rounding error and starts being most of your timeline.
Seven published iOS apps, enrolled, signed, submitted, reviewed and released — plus the unglamorous parts around them: expired certificates, rejected builds, privacy questionnaires that changed between submissions, and the occasional rejection that needed an argument rather than a fix.
Requested August 31st, issued September 9th, D&B profile updated September 11th, accepted by Apple's enrollment form September 12th. Those are four separate milestones and most of the confusion in this process comes from assuming they are one: the number arriving by email does not mean Apple can see it yet.
One app sat fifteen days in the queue, then went to In Review and was approved the same day — the reviewer's whole session took nine minutes. The useful part was knowing it was queue position rather than scrutiny, because the common reaction to a long wait is to resubmit, which moves you to the back of the queue.
Enrollment is done in your company's name against your legal entity, with the certificates and keys in accounts you control. An app published under a contractor's personal account is a problem you discover at the worst possible moment, which is usually when you want to change contractors.
Yes, for an Apple Developer Program Organization membership. Sole proprietors and single-person companies in countries where they are not recognized as legal entities can enroll as an individual instead, but the listing then carries the enrollee's personal legal name rather than the company's, which is rarely what a business wants.
Plan on one to two weeks for a D-U-N-S Number before Apple will accept it, a few days for enrollment once it does, and roughly 24 hours for review — though the queue is not a guarantee and one of mine sat fifteen days. If you are starting from no developer account at all, three to four weeks before your first submission is realistic. If you already have an account, days.
Click the link in that error. It submits a request on your behalf and Dun & Bradstreet contact you to confirm your details. D&B quote five business days; in our case it resolved in under a day and took another day to reach Apple's form. The mistake to avoid is re-entering the details repeatedly in the meantime, which changes nothing while the record propagates.
Almost certainly not. Waiting for Review means no reviewer has opened it yet, so it is queue position rather than scrutiny. Do not resubmit — swapping the build or rewriting the review notes puts you at the back of the queue, which makes the single most common reaction to a long wait the one that lengthens it. The App Store Connect API can tell you whether review has actually started, which beats guessing.
Yours. The developer account is enrolled against your legal entity, the certificates and keys live in accounts you control, and you keep them if we stop working together. Publishing a client's app under a contractor's personal account is common and it is a trap, because the listing, the reviews and the subscribers are then attached to someone who is not you.
Usually not. A developer who already holds your signing certificates and submits your builds is doing this job, and paying someone else to duplicate it would be waste. This is for the cases where there is no such person — the build was outsourced and handed over, the developer left, or the app was built in-house by someone who has never shipped to a store.
I bill new work at $95 to $125 an hour, against $150 to $300 for a typical agency blended rate. A first publication from nothing — enrollment, certificates, listing, submission — is usually a small number of hours spread over the weeks the paperwork takes, because most of that time is spent waiting on D&B and Apple rather than working. Apple charge $99 a year for the Developer Program and Google charge a one-time $25; those go to them, not to me.
Yes, and it is a common way this starts. The first pass is an inventory: who holds the Account Holder role, which certificates and keys exist, what expires when, and whether anything critical is tied to an individual who has left. That audit is worth doing before you need it, because certificate expiry is discovered at the worst possible time by default.
Tell me what you're trying to fix — I'll reply the same day.
Want the reasoning rather than the pitch? How to get a D-U-N-S Number for an Apple Developer account.
Tell me a bit about what you're trying to build. I'll reply the same day, and we can hop on a call if it makes sense.
Or reach me directly — support@techefficientllc.com or (480) 359-2485.