Apple Developer Account for Companies: D-U-N-S, Roles and Access

Publishing an app under a personal developer account is quick, but it puts a private person's name on the App Store and ties the company's app to one individual. For any business, public body or funded startup, an organization account is the right choice. Here is what you need, how enrollment works and how to set up access so it survives staff changes and agency projects.

Individual vs. organization account

Eligible nonprofit organizations, accredited educational institutions and government entities can apply for a fee waiver in supported countries; check Apple's current eligibility list.

What you need before you start

• A legal entity that can enter contracts. Trade names and DBAs are not accepted on their own.
• A D-U-N-S number for that entity from Dun & Bradstreet. Apple offers a lookup tool on its developer site; if your company has no number yet, you can request one for free through it. Issuance can take from a few days to a couple of weeks, and the record must match your legal name and address.
• A public website on a domain associated with your organization.
• An Apple Account with two-factor authentication, ideally using a company email address, for the person enrolling.
• Legal authority: the person enrolling must be able to bind the company to Apple's agreements, or have someone who can confirm this. Apple may call to verify.

Enrollment, step by step

1. Check or request your D-U-N-S number and wait until the data is visible to Apple.
2. Sign in on the Apple Developer site and start enrollment as an organization, either on the web or in the Apple Developer app.
3. Enter the legal entity name exactly as in the D-U-N-S record, plus the website and your contact details.
4. Complete verification. Apple may contact you to confirm identity and authority.
5. Pay the annual fee once Apple approves the enrollment.
6. Accept the agreements in App Store Connect, and complete tax and banking if you plan paid apps or in-app purchases.
7. Invite your team and set roles before anyone starts uploading builds.

Plan the timeline realistically: if you need a new D-U-N-S number, the whole process from request to a working account can take a few weeks. Start it as soon as an app project is approved, long before the first build is ready, so the account is not what delays your launch.

Most delays come from mismatches between the legal name or address in the D-U-N-S record and what is entered at Apple. Fix the record first rather than trying variations.

Roles: who gets what

App Store Connect works with roles, and some roles can be limited to specific apps. Role names change occasionally, so treat this as a guide to the current setup:

• Account Holder: one person, legally responsible, accepts agreements. Cannot be shared.
• Admin: manages users and most settings. Have at least two so you are never locked out.
• App Manager: manages app records, metadata, builds and submissions, optionally for selected apps only.
• Developer: uploads builds and manages TestFlight; access to certificates and profiles can be granted additionally.
• Marketing, Sales, Finance, Customer Support: access to listings, reports, payments or reviews as their names suggest.

For automation, create App Store Connect API keys with the narrowest suitable role instead of storing a person's password in your CI system. Rotate keys when people or vendors change.

Five access mistakes to avoid

1. Making a junior employee or freelancer the Account Holder. Choose a durable person such as a managing director or head of IT. Transferring the role later is possible but takes effort.
2. Using a personal Apple Account tied to someone's private email. Use company addresses so access can be recovered.
3. Letting an agency publish under its own account. Your app then belongs to the agency's account. Moving it later requires an app transfer, which has conditions. Have agencies work inside your account with limited roles.
4. Sharing one login among several people. It breaks two-factor authentication and leaves no audit trail.
5. Not reviewing access. Remove leavers and finished vendors promptly, and revoke their API keys and certificates.

Internal apps and special cases

If your app is only for employees, you have options beyond the public App Store: private distribution of custom apps through Apple Business Manager, or the separate Apple Developer Enterprise Program, which has strict eligibility requirements and is meant only for internal use. For most companies, custom app distribution is the simpler path; check Apple's current guidance for your case.

Do not forget Android: Google Play also offers organization accounts, which verify the organization and are exempt from the closed testing gate for new personal accounts described in the 12-tester rule explained.

After setup: your first release

With the account in place, the next hurdles are signing and submission. Our guides on iOS code signing and the App Store submission checklist pick up from here. If you prefer to keep ownership but delegate the work, appsubmitter.io sets up signing and CI/CD and submits builds inside your own company accounts, using the role-based access described above. For larger custom builds with SLAs, OnlineAppCreator works the same way: your accounts, your apps.