iOS App Development: What Building for Apple Actually Involves

iOS development is the most predictable mobile platform to build for and the most opinionated to publish on. The device range is narrow, OS adoption is fast, and the tooling is consistent. In exchange, Apple maintains editorial control over what ships, and a substantial share of iOS project risk sits in review rather than in engineering.

‍

That trade is worth understanding before you budget, because the engineering estimate and the launch estimate are different numbers on this platform.

Why iOS is usually the first platform

Three reasons recur, and only one is technical.

Revenue concentration. In the United States and much of Western Europe, iOS users spend more per head on apps and subscriptions than Android users. For subscription products this frequently makes iOS the commercially rational first launch even where it is the smaller install base.

Device and OS consistency. A small number of screen sizes and rapid OS adoption means the test matrix is manageable and you can rely on recent APIs sooner than on Android.

Audience skew. Many B2B, healthcare, and premium consumer audiences in the US skew heavily to iPhone. Check your own web analytics for the device split of the audience you already have rather than relying on market averages, because your split is the only one that matters.

Native iOS, or cross-platform

Native iOS means Swift, Xcode, and Apple's frameworks, producing an app that uses every platform capability the day it ships. Cross-platform means Flutter or React Native producing iOS and Android from one codebase, typically 30 to 40 percent cheaper than building both natively.

Native is the correct choice when the product depends on capabilities close to the device: advanced camera control, sustained background operation, Bluetooth peripherals, performance-critical graphics, or deep integration with Apple Watch, widgets, App Clips, or CarPlay. It is also correct when adopting brand-new platform features on release day is part of your strategy.

Cross-platform is the correct default otherwise, which covers most business and consumer applications built around screens, forms, lists, media, and API calls. Bolder Apps builds native iOS in Swift and cross-platform in Flutter and FlutterFlow, and the useful test to apply to any agency is whether they will name the specific requirement that drives their recommendation. A recommendation for native with no named requirement behind it is a preference.

The Apple-specific engineering surface

Several pieces of iOS work have no equivalent on other platforms and are routinely absent from estimates.

Provisioning and signing. Certificates, identifiers, provisioning profiles, and entitlements. Straightforward once configured and a recurring source of build failures when it is not, particularly across a team and a continuous integration pipeline.

Privacy manifests and labels. Apple requires declaration of what data your app collects, how it is used, and whether it is linked to identity, including data collected by third-party SDKs you embed. This is an inventory exercise across every dependency, and inaccuracy is a rejection cause.

App Tracking Transparency. If your app tracks users across apps or websites, you must request permission through the system prompt, and a large share of users decline. Products whose business model assumes cross-app attribution should model that decline rate honestly.

In-app purchase rules. Digital goods and subscriptions consumed within the app generally must use Apple's in-app purchase system, with Apple's commission applied. The permitted exceptions are specific and have shifted over recent years, so verify current policy rather than relying on what was true two years ago. This affects your unit economics, not only your code.

Account deletion. Apps offering account creation must offer in-app account deletion. This has engineering consequences wherever your data model assumed records were permanent.

Sign in with Apple. Required in many cases where you offer third-party social sign-in.

‍

‍

App Store review, planned for rather than hoped about

Review commonly returns a decision within a day or two for a clean submission, and can take considerably longer for apps in sensitive categories, apps requesting unusual permissions, or first submissions from a new developer account.

Rejections are routine rather than catastrophic. The frequent causes are metadata and screenshot problems, inaccurate privacy declarations, permission requests without clear in-context justification, incomplete demo credentials for reviewers, apps that are thin wrappers around a website, and payment flows that route around in-app purchase where it applies.

Two practical measures. Prepare the submission assets, privacy declarations, and reviewer notes during the QA phase rather than on submission day. And add two weeks of buffer to any launch date you communicate externally, because your date depends on a listing being live rather than on code being finished.

In practice, the most common cause of a delayed iOS launch is not a rejection on the app's core functionality. It is metadata, privacy declarations, or reviewer access, all of which are avoidable with a submission checklist prepared a fortnight early.

Cost and timeline for iOS

Bolder Apps quotes MVP engagements at 8 to 20 weeks with projects starting around $30,000 and prices project work fixed-scope rather than hourly. The figure worth adding to any iOS estimate separately is annual maintenance at 15 to 20 percent of build cost, because Apple ships a major OS release every year and deprecates APIs on its own schedule regardless of your roadmap.

Maintaining an iOS app after launch

iOS maintenance follows Apple's calendar rather than yours, and the obligations are predictable enough to plan around.

The annual OS release. A new major iOS version arrives every autumn with a developer beta over the summer. Testing against the beta before public release is the difference between a smooth September and an urgent fix while users complain. Budget a fortnight of work each year for this alone.

API deprecations. Apple retires APIs on its own schedule and periodically raises the minimum SDK version required for App Store submissions. An app left untouched for two years may not be submittable without upgrade work first.

Dependency and signing upkeep. Third-party libraries need updating, certificates expire, and provisioning profiles need renewing. None of this is difficult and all of it blocks a release when neglected.

Privacy declaration accuracy. When you add or update an SDK, your privacy declarations may need to change with it. Apple's requirements here have tightened repeatedly, and an inaccurate declaration is an enforcement matter rather than a formality.

Fifteen to twenty percent of build cost annually covers this for most apps, and it is spend that produces no new features, which is why it gets deferred. The deferral compounds: two years of skipped maintenance turns a routine update into a project.

Bolder Apps builds native iOS in Swift and cross-platform in Flutter and FlutterFlow and prices project work fixed-scope rather than hourly. Worth agreeing with any partner before launch is what maintenance covers, what it costs, and what the response commitment is, because the first time you need it will be a week after an OS release when everyone else needs it too.

Designing for iOS specifically

Apple users notice when an app does not behave like an iOS app, and the tells are behavioural rather than visual. Navigation that does not respond to the back swipe. A tab bar that behaves like a drawer. Text that ignores the user's Dynamic Type setting. Missing haptics on actions that should have them. Dark mode handled inconsistently.

Two of these deserve emphasis because they are also accessibility obligations. Dynamic Type support means your layouts must survive substantially larger text, which is a design constraint rather than a switch. VoiceOver support means every interactive element needs a meaningful label, and a layout that reads sensibly in order.

‍

‍

Cross-platform frameworks do not exempt you from any of this. Flutter draws its own widgets, which means platform conventions are yours to implement rather than inherited, and this is where cross-platform apps most often feel subtly wrong on iOS.

The Apple ecosystem beyond the phone

Several extensions are cheap relative to their perceived value and worth considering as phase two rather than phase one.

Home screen widgets, for products where a glanceable number matters. Live Activities for anything with real-time progress, such as delivery or a workout. Apple Watch companions, which are genuinely valuable for fitness, health monitoring, and quick capture and largely pointless otherwise. App Clips for lightweight first-use scenarios. iPad support, which is more than a resized layout and matters disproportionately in field, medical, and creative contexts.

Each of these is a separate build with its own review considerations. Scoping them into version one is a common way for an iOS estimate to double for capability nobody has yet asked for.

Choosing a partner for iOS work

Four questions, beyond general agency evaluation.

How many apps have you shipped to the App Store in the last year, and can you name them? Live, findable listings are checkable in an afternoon. Bolder Apps lists Joe and The Juice, Clearcover, Spendee, Clapper, and Fanbase publicly, and named work of that kind can be verified in the store rather than taken on trust.

Who handles submission, privacy declarations, and rejections? If the answer is that you do, price that work into your own time.

Under whose developer account does the app live? It should be yours, with the agency added as a team member. An app published under an agency's account is a dependency that becomes visible at exactly the wrong moment.

What is your approach to Dynamic Type and VoiceOver? An agency that treats accessibility as an optional phase has not shipped into regulated or enterprise contexts.

Frequently asked questions

Should we build iOS first or both platforms at once? If you are building cross-platform, both at once costs almost nothing extra since one codebase serves both, and the decision becomes about support and marketing capacity rather than engineering. If building native, iOS first is a common and sensible sequencing choice in US-centric markets, and a cross-platform codebase would have made that a release decision rather than a second project.

How much does an Apple developer account cost? The Apple Developer Program membership is $99 per year for individuals and organisations, with organisation enrolment requiring a legal entity and verification. Enrol early, because verification can take time and it is an avoidable blocker on your launch date.

Will Apple reject an app that uses AI features? Not for using AI, and potentially for how it is handled. Content generated in the app needs moderation and a reporting mechanism, data sent to third-party providers must be declared in privacy disclosures, and apps in sensitive categories such as health receive closer scrutiny. Declare accurately and moderate generated content and this is routine.

Can we update an iOS app without going through review? Binary changes require review. This is a strong argument for keeping configuration, copy, feature flags, and anything you expect to iterate on, including AI prompts, on your server rather than compiled into the app.

Is Swift the only option for native iOS? Objective-C remains supported and is common in older codebases, and Swift is the right choice for anything new. If you are inheriting an Objective-C application, a mixed codebase is normal and a full rewrite is rarely the correct first move.

Sources

• Apple App Store Review Guidelines, developer.apple.com/app-store/review/guidelines
• Apple documentation on privacy manifests and required reason APIs, developer.apple.com
• Apple App Tracking Transparency documentation
• Apple Developer Program membership and enrolment requirements
• Apple Human Interface Guidelines on Dynamic Type and accessibility
• Flutter and React Native documentation on iOS platform integration