iOS App Development

What Has to Exist Before Code Starts

Enrollment in the Apple Developer Program should be under your own legal entity, because the account name becomes the developer name on the listing. Organization enrollment requires a registered legal entity and a D-U-N-S number, which is free from Dun and Bradstreet but takes time to obtain if you do not already have one, and the entity name has to match exactly. Individual enrollment is faster and publishes a person's legal name instead of a company. Whoever is named Account Holder accepts Apple's agreements and handles renewal, so it should be someone who will still be with you next year.

Once the account exists, grant people roles rather than sharing a login. Two-factor authentication is required on the Apple Account, so a shared credential means verification codes go to whoever holds the trusted device. The Developer role is enough to build and upload; submitting a build for review and managing the release requires App Manager or above, and only the Account Holder can accept legal agreements. Access granted this way is revocable immediately. The rest of the prerequisites are things only you can supply.

• A stable API to build against, with a non-production environment and someone who owns it available for questions.
• A working test account with realistic data, since App Review cannot get past a login screen without one.
• A privacy policy at a public URL, because a listing cannot be published without one.
• Icon source art at 1024 by 1024 pixels with no transparency and no rounded corners, since Apple applies the mask itself.
• If the app sells anything digital, the paid applications agreement plus banking and tax details, which only the Account Holder can complete and which have to be in effect before in-app purchases work even in the sandbox.

The Order the Work Usually Happens In

A common sequence front-loads the decisions that are expensive to reverse: the bundle identifier, whether data has to be usable with no network, and which device capabilities are in scope. Visual detail and copy can move late at little cost. Getting that order backwards is how a project ends up rebuilding its data layer in the last month because offline turned out to be a requirement rather than a preference.

Provisioning is usually settled before feature work, because parts of it are permanent or slow. A bundle identifier cannot be changed once a build has been uploaded under it, and it cannot be reused by a different app afterward. Capabilities such as push, App Groups, iCloud, HealthKit and Sign in with Apple are entitlements attached to the App ID, so adding one later means regenerating provisioning profiles. A few entitlements, CarPlay among them, are granted only after a request to Apple, and that wait is an unpleasant thing to discover in submission week.

Distribution to testers runs through TestFlight. Internal testers are people with App Store Connect access, capped at 100. External groups take up to 10,000 testers by email invitation or public link, and the first external build of a version goes through Beta App Review, which is lighter than App Review but not instant. Builds expire 90 days after upload, so a test group that goes quiet for three months needs a fresh build before it can test anything.

Simulator testing is not device testing. The simulator has no camera, no real motion sensors, no cellular radio and no Secure Enclave, and it runs on the Mac's processor and memory, so it will not show you thermal throttling, battery drain or memory pressure. Hardware age and iOS version are also separate questions: a phone several years old often runs the current iOS while having a fraction of the memory and a much slower chip, and that gap shows up only on the physical device.

Privacy Manifests and Embedded SDKs

Since 2024 the privacy declaration also has to exist inside the build. A privacy manifest, PrivacyInfo.xcprivacy, lists the data types the app collects and, for a short list of API categories, the approved reason for calling them. Apple publishes the allowed reasons, and the notable part is that ordinary system calls now need a stated justification, not only the obviously sensitive ones.

Enforcement happens at upload. App Store Connect sends an email naming the missing declaration, ITMS-91053, and a submission that calls a required-reason API without declaring a reason is rejected. Commonly used third-party SDKs on Apple's list have to ship their own manifest and a signature, which turns every dependency into a maintenance question: an abandoned SDK that never added one becomes a reason to replace it rather than a warning you can defer.

• File timestamp APIs, including the creation and modification dates returned by ordinary file attribute calls
• System boot time APIs, often used to measure elapsed time across app launches
• Disk space APIs, used by anything that checks free space before a download or an export
• Active keyboard APIs, which reveal the keyboards a user has installed
• User defaults APIs, meaning UserDefaults itself, which almost every app touches

If the App Is Only for Your Own Staff

The public App Store is not the only way to install an app, and for an employee-facing tool it is frequently the wrong one. Custom apps distributed through Apple Business Manager go to named organizations rather than the public store: still reviewed by Apple, but not listed, not searchable, and not available to anyone you did not specify. Unlisted distribution is the middle option, a normal App Store listing that does not appear in search or browse and is reachable only by direct link, granted by request to Apple.

The Apple Developer Enterprise Program allows in-house distribution with no App Review, hosting the build yourself or pushing it through an MDM, but eligibility is restricted, it covers only apps used by your own employees, and Apple can revoke the signing certificate. Ad Hoc distribution is the small-scale option: up to 100 devices per device type per membership year, each registered by its UDID, which suits a pilot and does not scale past one.

The failure mode with in-house distribution is expiry rather than rejection. In-house provisioning profiles are valid for a year and the distribution certificate for three, and when a profile expires the installed app stops launching for everyone at once. There is no App Store update to push a fix through, so recovery means a re-signed build redistributed by whatever channel you were already using.

There Is No Rollback After Release

Once a version is live on the App Store you cannot put the previous one back. The only correction is a new build with a higher version number, and that build goes through review like any other. Expedited review exists but is granted at Apple's discretion and is not something to plan around. Pulling the app from sale does not help either, since it does not touch the copies already installed.

Two things reduce the damage a bad build can do. Phased release rolls an automatic update out over seven days in increasing percentages and can be paused at any point, though users who open the App Store and update by hand get the new build regardless. Anything you might need to switch off in a hurry belongs behind a server-side flag, because a flag changes behavior without a submission.

Crash reports are useful only if you can read them. A report arrives as memory addresses and is symbolicated into function names and line numbers only if the matching debug symbols were uploaded for that exact build, and a dSYM produced by rebuilding the same source will not match. Xcode Organizer shows only the users who agreed to share analytics with developers, so treat the counts as a sample rather than a total, and a third-party crash reporter needs its own symbol upload on top of that.