iOS App Development Services for US & EU Brands

New iOS projects start on Swift 6 with strict concurrency enabled and target iOS 17 as the deployment minimum, with iOS 18 as the build SDK. That covers roughly 92 percent of active US/EU iPhones at time of writing. For B2B apps that must run on legacy fleet devices we drop the floor to iOS 16 and isolate Swift 6 concurrency with @preconcurrency imports. SwiftUI is the default UI layer with UIKit interop where SwiftUI still lacks coverage (camera capture pipelines, advanced PDFKit, custom keyboard input).

We treat App Store Review Guidelines 2.x, 3.x, 4.x and 5.x as a hard pre-flight checklist before every submission. The most common rejection patterns we eliminate: Guideline 4.0 (incomplete metadata, missing demo account), Guideline 2.1 (crash on TestFlight build with reviewer locale), Guideline 3.1.1 (digital goods routed through Stripe instead of IAP), Guideline 5.1.1 (purpose strings missing in Info.plist for camera, photos, contacts, motion), and Guideline 5.1.2 (account deletion not in-app, required since June 2022). We also pre-fill the App Privacy nutrition labels accurately and keep them in sync with the actual SDK behaviour.

App Tracking Transparency (ATT) is mandatory since iOS 14.5 for any cross-app/site tracking via IDFA. We gate IDFA access behind ATTrackingManager.requestTrackingAuthorization, show the pre-prompt only when there is genuine product value, and design the app to function fully when the user declines (US opt-in rates are 25–38 percent). For EU Digital Markets Act compliance we support alternative app marketplaces, third-party browser engines via BrowserEngineKit on iOS 17.4+ in the EU, and the contractor-entitled NFC/contactless payment APIs where the business case requires it.

Default is SwiftUI-first with the Observation framework (iOS 17+) replacing ObservableObject, and UIViewRepresentable bridges where UIKit is still ahead — high-FPS table cells with custom layout, AVFoundation camera UI, PencilKit, and MapKit overlays at scale. We use Swift Concurrency (async/await, actors, structured tasks) instead of Combine for new code; existing Combine pipelines are kept and bridged. Navigation uses NavigationStack with type-safe NavigationPath. The Composable Architecture (TCA) is on offer for teams that want it, but we default to vanilla SwiftUI + Observation for new projects.

GDPR-aligned by design: lawful basis documented per data category, in-app consent flows separate from ATT, granular data export and account deletion (also an App Store requirement since 2022), and DPAs with every third-party SDK. For EU customers we host backend infra in eu-central-1 or eu-west-3, encrypt at rest with AWS KMS or GCP CMEK, and keep PII out of crash reports (Sentry/Firebase Crashlytics PII scrubbing enabled). For CCPA we ship the Do Not Sell/Share signal handling and a CCPA-specific privacy screen for California users detected via region (not IP geolocation, which is unreliable on iOS).

iOS projects are fixed-scope and tiered by product complexity, all-in and quoted in USD. An MVP runs from $3,500 (4–8 weeks) for the first working app with the core flow and an App Store release; a production app from $5,800 with several features, backend integration, offline persistence and analytics; a full product from $9,200 with multiple modules, roles, external integrations, CI/CD and device QA; a complex app from $11,500 with payments, offline-first sync, native SDKs, scale and A/B. The exact number depends on how many Apple surfaces you ship, integration and StoreKit complexity, and compliance scope. You see the line-item budget at the end of discovery and sign off before any code is written. There are no hidden fees and no tool surcharges. Apple Developer Program and third-party API fees are billed on your own accounts.

We prevent rejections rather than recover from them. Before every submission we run a structured pre-flight check against the five most common rejection categories: Guideline 4.0 (incomplete metadata or missing demo account), Guideline 2.1 (crash on a build with the reviewer’s locale or accessibility settings active), Guideline 3.1.1 (digital goods or subscriptions bypassing IAP — typically a Stripe checkout left in a paywall), Guideline 5.1.1 (missing purpose strings in Info.plist for every permission the app uses), and Guideline 5.1.2 (account deletion not available in-app). App Privacy nutrition labels are filled from a live audit of the actual SDK list — not a template — and kept in sync as dependencies change. For ATT we gate IDFA access behind ATTrackingManager.requestTrackingAuthorization, show the custom pre-prompt only when there is genuine product value (US opt-in rates sit at 25–38 percent so a spurious prompt costs you more than it returns), and design every downstream feature to degrade gracefully when the user declines. Our first-pass App Store approval rate sits above 90 percent across the projects we have submitted.

SwiftUI-first with the Observation framework (iOS 17+) is our default for all new projects starting in 2026. The Observation macro replaced ObservableObject, eliminating a large class of unnecessary re-renders. We use NavigationStack with a type-safe NavigationPath for deep-link routing, SwiftData for local persistence (backed by Core Data on older targets), and Swift Concurrency (async/await, actors, structured tasks) throughout — no new Combine code. UIKit stays in the picture for a specific set of cases where SwiftUI is still thin: AVFoundation camera capture pipelines, high-FPS table cells with fully custom layout (Collection View Compositional Layout outperforms LazyVGrid for very large data sets), PencilKit annotation layers, and MapKit overlays with thousands of annotations. We bridge these with UIViewRepresentable and UIViewControllerRepresentable so the SwiftUI navigation graph stays intact. For projects that need it, The Composable Architecture (TCA) is available; otherwise we default to vanilla SwiftUI + Observation, which is leaner and easier to onboard onto.

StoreKit 2 (introduced in iOS 15, now the production standard) replaces the callback-heavy StoreKit 1 with an async/await API and a server-side transaction model that makes receipt validation dramatically simpler. We implement the full purchase flow: product fetching via Product.products(for:), purchase via product.purchase(), transaction listener as an async sequence running from app launch, and a server-side verify endpoint that calls the App Store Server API (the new REST endpoint replacing the legacy verifyReceipt). Subscription state is driven by Transaction.currentEntitlements rather than local receipt parsing. Offer codes, promotional offers, win-back offers (iOS 18), and family sharing are handled where the product requires them. For apps that need a web checkout path alongside IAP — common for SaaS tools that also have a web tier — we implement the EU DMA-compliant link-to-external-website entitlement carefully to avoid a Guideline 3.1.1 rejection. Subscription analytics (conversion, trial-to-paid, churn) are instrumented from day one via RevenueCat or a custom backend, not guessed from App Store Connect aggregate numbers.

Yes. We scope companion Apple Watch apps, iPad-native apps, and Apple Vision Pro experiences as distinct workstreams within the same engagement. Apple Watch apps run on watchOS with SwiftUI and WidgetKit complications; they communicate with the iPhone via WatchConnectivity and run their own independent logic for workout, health, and notification scenarios where the watch must function without the phone. iPad apps get a proper adaptive layout — not a stretched iPhone layout — using SwiftUI’s size class system, NavigationSplitView for multi-column layouts, Stage Manager support, and Apple Pencil input via PencilKit where relevant. Apple Vision Pro apps on visionOS use the same SwiftUI code with volumetric and immersive space extensions. Each additional Apple surface is scoped explicitly at discovery: it adds design and QA work and we size it honestly rather than bundling it into a fixed price that later slips. We test on real devices across the target device matrix, not only in Simulator.

App Privacy labels on the App Store (the “nutrition label” visible on the product page) must accurately reflect every category of data your app and every SDK it ships collect, link to identity, and use for tracking. We start with an automated SDK audit using a privacy manifest scan (Apple mandates PrivacyInfo.xcprivacy files for required-reason APIs from iOS 17) to enumerate every third-party library’s declared data practices. We then map the SDK list to App Privacy categories — Data Used to Track You, Data Linked to You, Data Not Linked to You — and fill the labels against that map, not against a template. Common traps we avoid: analytics SDKs (Firebase, Amplitude, Mixpanel) declare data linked to identity if a User ID is sent; crash reporters (Sentry, Crashlytics) declare performance data; advertising SDKs declare tracking data. If a label category is selected, the corresponding purpose string in Info.plist must be present and the runtime permission must be requested before access. For EU clients, GDPR lawful basis is documented per data category and the consent management platform is wired so ATT and GDPR consent are two separate, sequenced prompts — not combined into one screen that satisfies neither.