iOS app development that clears review the first time

The constraint on iOS is not the hardware

Android teams spend their anxiety on devices. iOS teams spend it on review. The device range is narrow and the OS adoption curve is steep, which removes a whole category of problem — and in its place sits a gatekeeper with a published rulebook and the ability to stop your release.

That is the useful frame for iOS app development, because it changes when decisions get made. Most rejections we see were not caused by code. They were caused by a product decision taken months earlier by someone who had no reason to know it mattered: a subscription sold through a payment provider that is not in-app purchase, an account you can create in the app but not delete, an analytics SDK collecting more than the privacy label admits, a build that is essentially the website in a wrapper.

None of that is discovered by testing. It is discovered by reading Apple’s guidelines against your feature list before anyone opens Xcode, which takes an afternoon and is the single highest-return hour in an iOS project.

Swift and SwiftUI as the default

We build in Swift, with SwiftUI as the interface layer and UIKit where a specific control, performance characteristic or legacy integration genuinely calls for it. That is not a purity position: the two interoperate well, and pretending otherwise produces worse apps than mixing them sensibly.

SwiftUI earns its place for the reason declarative interfaces usually do — the interface is a function of state, so an entire class of bug in which the view and the data have quietly diverged stops existing. It also makes the system-level requirements structural rather than optional. Dynamic Type, dark mode, safe area handling and layout adaptation across device sizes come from the framework when you work with it, and have to be fought for when you work around it.

Swift Concurrency handles asynchronous work with structure, which matters more than it sounds: the majority of intermittent, hard-to-reproduce iOS bugs are ordering and threading problems, and code that makes those explicit is code that fails visibly instead of occasionally.

Designing to the Human Interface Guidelines

Apple’s Human Interface Guidelines are not a style guide, they are a description of what your users have already learned. Where a back gesture lives, how a sheet behaves, what a tab bar implies about the structure of the app, when a modal is appropriate — an app that answers these differently feels wrong in a way people describe as “cheap” without being able to say why.

Following the platform is also efficient. System components arrive with accessibility, Dynamic Type support, dark mode and localisation behaviour already correct. Rebuilding them to match a cross-platform design specification means rebuilding those properties too, usually incompletely.

Where the design problem is substantial in its own right — complex flows, dense information, a product people use daily rather than occasionally — we run it as interaction design work with the platform as a constraint, not as a decorating pass over a finished build.

iPhone, iPad and the surfaces beyond

iPad is a separate product decision. Done properly it means adaptive layouts, multitasking and split views, pointer and hardware keyboard support, and content density that suits a screen people use at a desk. Done improperly it means a stretched iPhone layout, which reviewers notice and users resent.

The same is true of a watch app: a different interaction model built around a few seconds of attention, sharing your data layer and business logic but not your interface. Both are worth building when the use case genuinely lives there. Neither is worth building because the app felt incomplete without them.

Architecture, state and the things that decay

The architecture question that matters is whether an engineer who has never met us can open the project and follow it. In practice that means one state management approach applied consistently, a clear boundary between the interface and the data layer, dependencies declared through Swift Package Manager, and no clever indirection that saves fifty lines and costs a day of comprehension.

Persistence is SwiftData or Core Data depending on the minimum OS version and the complexity of the model, network access through URLSession with a typed layer above it, and credentials in the Keychain rather than in user defaults. We review the security surface against the OWASP Mobile Application Security Verification Standard, which covers storage, cryptography, authentication, network and platform interaction — a published document you can hold us to instead of a reassurance you cannot check.

Subscriptions, purchases and StoreKit

If your app sells digital content or subscriptions, in-app purchase is not one integration among many. It is the revenue mechanism, a compliance requirement, and the part of the app most likely to fail quietly.

StoreKit’s modern API gives cryptographically signed transaction records and current subscription status directly, with the App Store Server API and server notifications available for the server side of entitlement. The engineering that repays the effort is in the unglamorous cases: a purchase interrupted by a lost connection, a restore on a new device, a family-shared subscription, a refund, a subscription that lapses and resumes, a user who bought on one platform and signed in on another.

Getting entitlement wrong is worse than most bugs because it is a billing problem as well as a technical one. We treat it as its own testable subsystem rather than as a screen.

Privacy is a build-time obligation now

Apple’s privacy requirements have shifted from a disclosure exercise to a supply chain one, and they are worth understanding before you choose your third-party SDKs.

App privacy details — the nutrition labels shown on your listing — must cover not only what you collect but what every third-party SDK embedded in your app collects, whether that data is linked to the user’s identity, and whether it is used for tracking. Alongside that sit privacy manifests and signatures for third-party SDKs, which exist precisely because “we did not know what the analytics library was doing” stopped being an acceptable answer.

App Tracking Transparency is the other half. Tracking a user across apps and websites owned by other companies requires explicit permission before the advertising identifier is available. The product consequence is that attribution and retargeting need designing around first-party and aggregated measurement, and the design consequence is that where and when you ask for permission materially changes whether anyone says yes.

We build the label from an inventory rather than from memory, and where a declaration cannot be evidenced, we remove the collection rather than soften the wording.

Accessibility and profiling

VoiceOver and Dynamic Type are the two tests that find nearly everything. Navigating a screen with VoiceOver running exposes unlabelled controls and nonsensical focus order in seconds. Rendering the app at the largest accessibility text sizes exposes every layout built on the assumption that text has a fixed height — which is most layouts, until someone checks. Apple’s accessibility guidance and the underlying WCAG success criteria give a common vocabulary for that work, including contrast and target size expectations.

Performance follows the same principle of measuring rather than guessing. Instruments shows where time, memory and energy actually go, profiled on the oldest device you have committed to supporting, because launch time and scrolling smoothness on last year’s flagship tell you almost nothing about the phone your customer is holding.

The submission, rehearsed

Before we submit, we run our own review against the guidelines. Metadata matches the app; every link works; the demo account signs in and reaches the functionality being demonstrated; permission prompts carry purpose strings a human wrote; account deletion exists where accounts do; purchase flows use in-app purchase where required; the privacy declarations match the SDK inventory.

TestFlight comes before that, and is more useful than most teams make it. It supports up to 100 internal testers and up to 10,000 external testers, with external builds passing a Beta App Review first — which is, conveniently, a cheap early signal about anything obviously non-compliant. Build notes that say what changed and what to look at turn testers into a source of specific feedback rather than a source of “seems fine”.

Once approved, the listing becomes its own discipline: App Store optimisation determines whether the app is found at all, and it is a different skill from building it.

Testing before the testers

TestFlight is the last line, not the first. Underneath it sit unit tests around the logic that would be expensive to get wrong — pricing, entitlement, date handling, anything with a state machine — and UI tests covering the small number of journeys the business depends on. Exhaustive UI test suites tend to rot faster than they catch things, so we keep them narrow and reliable rather than broad and ignored.

The cases worth writing tests for are usually the ones nobody demonstrates in a review meeting: the app resumed after the system terminated it in the background, a token that expired while the phone was in a pocket, a push notification tapped from a cold start, a form half-completed when a call arrived. On iOS these are the defects that reach production, because the happy path is comfortably covered by the person who built it.

Maintenance runs on Apple’s calendar

An iOS app has an annual fixture whether or not there is a budget line for it. A major OS version arrives each year, and with it behaviour changes, deprecated APIs, altered system control rendering, and third-party SDKs that need updating before they work again.

The sensible response is to treat the beta period as scheduled work. Apple publishes developer betas months before public release, which is the window in which layout regressions and framework changes should be found — on your device, deliberately, rather than on a customer’s device on the day the update lands. Compatibility work goes in first; adopting genuinely new capabilities is a separate decision made on merit rather than on novelty.

The rest of maintenance is unglamorous and predictable: certificate and provisioning renewals, dependency updates, crash triage from the reports that actually arrive, and periodic re-verification that the privacy declarations still match what the app and its SDKs do after a year of changes. None of it produces a feature, which is precisely why it gets dropped from budgets and then reappears as an emergency. We map it against the calendar at the start of an engagement so it stays visible.

Where iOS sits alongside everything else

If both platforms are in scope, the Android side has an entirely different centre of gravity — device fragmentation, store vitals thresholds and target API deadlines — and it deserves its own plan rather than a translation of this one. Where the feature set does not demand platform-specific depth, a shared codebase may be the better commercial answer, and the trade-offs are set out on our mobile app development page.

If you have an app already and mostly want to know whether it will survive the next iOS release, an audit is a sensible first conversation and does not commit you to anything further.