AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
6–10 wks
Typical iOS MVP
One core workflow, App Store submission included
100%
Senior engineers, US-based
No offshore handoff mid-build
Every sprint
A build you can install on a device
Not a status deck between milestones
100%
Code and Apple Developer account yours
From the first commit
The platform decision
Native Swift, or a cross-platform framework that reaches iOS
This page is about the iOS-specific case for going native. If you're weighing native against React Native or Flutter as a general question, /mobile covers that decision in full — the short version for iOS specifically is below.
Swift and SwiftUI
Full access to whatever ships on iOS first — ARKit, HealthKit, widgets, Live Activities, a watchOS companion — with no bridge layer to work around. The cost is a codebase that only targets Apple's platforms, so it's the right call when the product's value depends on something the OS exposes, not a feature bolted on afterward.
React Native for a shared iOS/Android codebase
One JavaScript codebase reaching both stores, with a native-module escape hatch for the pieces that need it. The right trade when the interface matters more than squeezing the last frame out of the GPU, and when the team is already React-fluent. See /mobile for the fuller comparison against Flutter and native.
Objective-C in an existing codebase
Older iOS apps still run substantial Objective-C, and a full Swift rewrite isn't always the right first move. Swift and Objective-C interoperate in the same project, so the more common path is incremental — new features in Swift, legacy code migrated file by file as it's touched anyway.
Universal apps: iPhone, iPad, and beyond
SwiftUI's layout system makes a genuinely adaptive iPhone-and-iPad interface realistic rather than a phone screen stretched wider. Whether Mac Catalyst or a visionOS build is worth adding depends on whether those platforms are actually part of the product's audience, not on Apple offering the checkbox.
None of these are free to reverse. Moving from a cross-platform build to native — or discovering mid-project that a required capability isn't reachable from React Native without a custom native module — is closer to a second build than a refactor, which is why the decision belongs before the first sprint, not after the first blocker.
What's involved
iOS engagement types
The variable that moves an iOS build's scope isn't screen count — it's how much of the app depends on a platform capability (HealthKit, ARKit, StoreKit, a Watch companion) versus a straightforward CRUD interface, and whether it needs to work offline.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| iOS MVP | Fixed scope | 6 – 10 weeks | One core workflow, Swift/SwiftUI, backend integration, and App Store submission for the first release. |
| Full iOS build | Fixed scope | 12 – 18 weeks | Multiple workflows, offline sync, push notifications, and platform integrations like Sign in with Apple or StoreKit subscriptions. |
| React Native to native migration | Fixed scope | 8 – 14 weeks | Rebuilding the iOS side natively once a cross-platform build hits a ceiling a bridge layer can't clear. |
| App Store rescue or resubmission | Fixed scope | 1 – 4 weeks | A rejected or stalled submission diagnosed and fixed against Apple's actual review notes. |
| Apple ecosystem integration | Fixed scope | 3 – 8 weeks | HealthKit, ARKit, a watchOS companion app, or a widget added to an existing iOS codebase. |
| Ongoing iOS maintenance | Ongoing retainer | Ongoing | Yearly iOS upgrades, deprecated API replacement, crash monitoring, and SDK version bumps Apple eventually requires. |
Ranges assume US-based senior engineers and include QA, device testing across current iPhone models, and App Store submission rather than quoting them separately. A quote well under these bands is usually missing offline handling or the maintenance year that follows launch — that cost doesn't disappear, it just shows up later as a change order.
App Store review
Apple's review is a real gate, not a formality
Treating a launch date as fixed before an app has actually cleared review is how a finished build becomes a missed date — and review isn't a one-time event, since every update after v1 goes through the same gate.
Review timing and rejection resets
Apple's review typically clears in 24 to 48 hours, but a rejection resets the clock, and reasons range from a broken login flow to subscription-language guidelines that have nothing to do with the code itself. A buffer week ahead of any date promised to a stakeholder isn't padding — it's the honest schedule.
Privacy nutrition labels are checked against real traffic
Apple's privacy label asks you to declare exactly what the app collects and why, and reviewers spot-check that declaration against the network traffic the build actually generates. A third-party analytics SDK collecting device identifiers nobody remembered is the kind of mismatch that gets a build rejected on the second look.
In-app purchases are a second review track
Any subscription flow gets reviewed against pricing display rules, restore-purchase requirements, and Apple's external-payment-link policy — stricter than most first-time submitters expect. Budget it as its own pass, not something bundled into the main submission.
TestFlight is how you find the crash before Apple does
A TestFlight beta ahead of the public release catches the issue that only shows up on a specific iPhone model or iOS version. Skipping it to save a week is the most common cause of the one-star reviews that show up in the first week after launch.
Where iOS earns its own codebase
Apple ecosystem APIs a cross-platform layer can't reach cleanly
This is the specific case for native iOS, not a general argument against React Native or Flutter — /mobile covers the framework decision on its own terms.
HealthKit and health data
Reading or writing to Apple Health requires entitlements and user consent flows that are iOS-specific by design. A health or fitness product built around HealthKit is a native iOS decision from the start, not an integration bolted on later.
ARKit
Augmented-reality features — object placement, body tracking, scene reconstruction — run through ARKit's native APIs. Cross-platform AR libraries exist, but they trail ARKit's capability on iOS specifically by a meaningful margin.
Apple Watch companions
A watchOS app is its own target with its own interface constraints, built alongside — not instead of — the iPhone app. It's a native-only surface; there's no cross-platform path onto Apple Watch.
Sign in with Apple and StoreKit
Sign in with Apple is required by App Store guidelines whenever another third-party login is offered, and StoreKit governs in-app purchases and subscriptions. Both are well-supported in React Native via native modules, but they're iOS platform requirements either way.
Widgets and Live Activities
Home-screen widgets and Dynamic Island Live Activities run as separate app extensions built in SwiftUI, regardless of what the main app is written in. A React Native app can ship a native-Swift widget extension alongside it.
Universal iPhone and iPad layouts
SwiftUI's adaptive layout system makes a genuinely different iPad experience — not a stretched phone screen — realistic within one codebase. Getting this right is one of the more common places a first iOS build under-scopes the design work.
After launch
iOS maintenance is a yearly commitment, not a one-time cost
Apple ships a major iOS version every September, and it deprecates APIs on a schedule outside anyone's control. Shipping v1 is roughly half the lifetime cost of an iOS app; the maintenance that follows is the other half.
Target SDK requirements are enforced, not optional
An app that stops building against a current iOS SDK within roughly a year gets flagged for developers, then can be removed from the App Store. Maintenance isn't a nice-to-have on iOS — it's a requirement for staying listed.
Device and OS coverage narrows the testing matrix
iOS has less device fragmentation than Android, but a device lab still matters more than a bigger simulator fleet — thermal throttling, real GPS drift, and background app-refresh behavior only show up on physical hardware a couple of OS versions behind current.
Battery and frame-rate issues are the reviews you actually get
Users rarely leave a review about a missing feature; they leave one when a screen stutters or the battery drains faster than expected. Profiling on a mid-range iPhone, not just the newest model, is what keeps that review from happening.
Related
Related services
What iOS projects usually connect to.
Questions
Common questions about iOS development
What teams ask before a first call.
It depends on whether the app is a single-workflow MVP, a full build with several platform integrations, or an ongoing maintenance engagement after launch — an iOS MVP is the smallest of these, and a build with HealthKit, ARKit, or a Watch companion is larger. Integration count and whether the app needs to work offline move a quote more than screen count does.
A scoping call produces a real figure faster than any range on a page would, and it's the fastest way to find out which category your project actually falls into.
Native Swift and SwiftUI when a platform capability — HealthKit, ARKit, a Watch companion, a home-screen widget — is central to the product rather than a feature bolted on. React Native when the team already knows React, the interface matters more than squeezing the last frame out of the GPU, and both iOS and Android need to ship from one codebase.
Switching from one to the other after launch is closer to a second build than a refactor, so this decision belongs before the first sprint. /mobile covers the full comparison, including Flutter.
A single-workflow MVP is the fastest path to the App Store. A full build with multiple workflows, offline sync, and platform integrations takes longer, and a React Native app being migrated to native iOS is its own timeline again, since it's effectively a second build for the iOS side.
App Store review adds its own buffer on top of development time — budget a week for it, more if the first submission gets rejected.
A rejection resets the review clock, and the reason can be anything from a broken login flow to subscription-language guidelines unrelated to the code. We diagnose against Apple's actual review notes and resubmit — most rejections are fixable within days once the specific guideline is identified.
A TestFlight beta ahead of the public submission catches most of what would otherwise trigger a first rejection, which is why it's part of every build rather than an optional extra.
Yes — SwiftUI's adaptive layout system makes a genuinely different iPad interface realistic within one codebase, rather than a phone screen stretched wider. Whether a Mac Catalyst build or a visionOS version is also worth adding depends on whether those platforms are actually part of your audience, which is a scoping question we'll work through with you rather than assume.
Yes. Source code and the Apple Developer Program account should be registered under your own organization from day one, with us added as a member — not the other way around. That's the only arrangement that doesn't lock you to a vendor to publish your own updates or move to a different team later.
Android natively in Kotlin, React Native for a single codebase covering both stores, and Flutter for graphics-heavy custom interfaces. /mobile covers that framework decision in full, and /android covers what's specific to building for Google's platform and Play Store review.
Apple ships a major iOS version every September and deprecates APIs on its own schedule — an app that stops targeting a current SDK within roughly a year gets flagged, then risks removal from the App Store. Ongoing maintenance covers yearly OS upgrades, deprecated API replacement, and crash monitoring, budgeted as a retainer rather than discovered as a fire once the App Store flags an outdated build.