We build iPhone and iPad apps in Swift and SwiftUI, and we take over existing iOS codebases that have fallen behind the current Xcode and iOS releases. This page covers what the iOS route involves, when it beats a cross-platform build, and how we get an app through App Store review. For the wider choice across platforms, start from mobile app development.
When is a native iOS app the right call?
Choose iOS first, or iOS only, when one of these holds:
- Your paying users are concentrated on iPhone, as in many US consumer, prosumer and healthcare markets.
- The app depends on system features that cross-platform layers reach only through custom native code: Live Activities, widgets, App Intents, HealthKit, ARKit, advanced camera and audio, background Bluetooth.
- You want the interface to behave exactly like the system apps, including gestures, accessibility settings and Dynamic Type.
- You plan to ship Android later, and want to prove the product on one platform first.
If you need both stores from day one with a small team, the cost guide and our React Native vs Flutter comparison show what the cross-platform route trades away.
Which technologies do we use on iOS?
| Layer | Our default | Notes |
|---|---|---|
| Language | Swift | Objective-C only for legacy code we inherit |
| UI | SwiftUI, with UIKit where SwiftUI falls short | Mixed screens are common in older apps |
| Concurrency | Swift concurrency (async/await, actors) | Replaces callback chains and most Combine usage in new code |
| Data | SwiftData or Core Data, URLSession for networking | Chosen by the sync needs of the app |
| Packaging | Swift Package Manager | CocoaPods only if a dependency forces it |
| Quality | XCTest, Swift Testing, XCUITest | Run on every pull request |
| Release | Fastlane, TestFlight | Signing and upload scripted |
SwiftUI is where Apple directs new interface work, and we use it for new screens. We still drop to UIKit for complex collection layouts, some text editing and older deployment targets. The deployment target is a business decision: every older iOS version you support costs testing time and limits which APIs you can call, so we check your analytics before agreeing on it.
How do we get through App Store review?
Apple reviews every app and every update against the App Review Guidelines. Apple states that it reviews at least half of submissions within 24 hours and 90% within 48 hours. A rejection costs more than the wait, so we prepare the items that most often fail:
- A working privacy policy link and a support link with current contact details.
- Demo account credentials in the review notes when the app needs sign-in.
- Purpose strings for every permission, written to explain why the app needs the data.
- Screenshots that match the real app, and no placeholder content.
- In-app purchase and subscription flows that follow the payment rules.
- Regulated services (banking, healthcare, crypto) submitted by the legal entity that provides them.
We submit to TestFlight early, so reviewers see a stable build long before launch day, and we keep a separate fix-ready branch for expedited reviews on critical bugs.
How do we test an iOS app?
Unit tests cover business logic and view models. UI tests cover sign-up, purchase and the main task. Then we run the app on physical iPhones across several screen sizes and at least one older supported iOS version, with Dynamic Type at large sizes, VoiceOver on, low power mode and poor network conditions. Instruments profiles launch time, memory and scroll performance before every release candidate.
What does an iOS project cost to own?
Scope sets the price, and we give you a written estimate after a scoping call. The drivers specific to iOS:
- Supported iOS versions and devices. Each extra version widens the test matrix.
- System integrations. Push, Apple Pay, Sign in with Apple, HealthKit and widgets each carry setup, entitlement and review work.
- iPad. A layout built for large screens is a separate design and test effort, not a free by-product.
- Yearly platform changes. New iOS and Xcode releases every year require compatibility work, which belongs in the maintenance budget.
The mobile app cost guide lists ranges by app type. If the design is not done, our mobile app designers can join the team.
What does our iOS work look like?
We have not published a Swift-only case yet. What we can show is the iOS side of two shipped mobile products, built in React Native with native iOS builds, TestFlight distribution and App Store submission as part of the pipeline. For a European fitness brand we replaced two manual release processes with one Fastlane pipeline that signs and submits both apps in a single run, and a travel startup reached TestFlight builds by week seven of an 8 week plan. See the fitness app case study and the travel MVP.
How can you add iOS engineers?
You can hire mobile developers with Swift experience for your own team, or take a dedicated mobile team that owns the app. Engineers work at $50 to $150 per hour depending on seniority and role.
