iPhone and iPad Apps Built in Swift, Shipped Through Review
Native iOS development for US startups and small businesses — SwiftUI screens that feel like the platform, TestFlight betas for your testers, and an App Store submission we handle for you.
Swift and SwiftUI, With UIKit Where It Still Wins
Modern, boring, maintainable choices. The kind an iOS engineer you hire in two years will recognise immediately.
Swift, not bridged anything
The whole app in Swift, using structured concurrency for anything asynchronous rather than a tangle of completion handlers. Strong typing catches a large class of bug at compile time, which is cheaper than catching it in TestFlight.
SwiftUI for the interface
Less code per screen, consistent behaviour across device sizes, and Dynamic Type, dark mode and accessibility largely for free instead of as a retrofit. We drop to UIKit deliberately for complex custom layouts, camera work and controls SwiftUI does not yet cover.
Apple frameworks first
Core Data or SwiftData for local storage, Keychain for secrets, StoreKit for purchases, MapKit, AVFoundation, Core Location. Fewer third-party dependencies means fewer things that break the week a new iOS version lands.
Why the Human Interface Guidelines Matter Commercially
Not aesthetics. An app that ignores platform convention feels subtly wrong, and users blame the product rather than the pattern.
What following them looks like
- Navigation that behaves the way iPhone users already expect, including the swipe-back gesture
- System typography with Dynamic Type, so text scales when someone has larger text turned on
- Safe areas respected, so nothing hides under a notch, a Dynamic Island or the home indicator
- Standard controls where a standard control will do — share sheets, date pickers, alerts
- Dark mode supported properly, not as an inverted afterthought
- Haptics and animation used sparingly and consistently with the system
What ignoring them costs
- An app that reads as an Android layout ported across, which reviewers and users both notice
- Broken layouts on the smallest supported iPhone and on the largest Pro Max
- Text clipped or overlapping the moment accessibility text sizes are enabled
- VoiceOver that reads a screen as a meaningless list of unlabelled buttons
- Extra rounds of redesign after launch, paid for twice
- Occasionally, a rejection for an interface that is confusing or incomplete
How Submission Actually Goes
We run this for you under your developer account. You approve the listing; we handle the mechanics and any correspondence.
1 — Developer account and identifiers
Apple Developer Program membership in your company name, renewed yearly on your card. Organization enrolment needs a legal entity and a D-U-N-S number, and verification can take longer than people expect, so we start it in week one rather than week twelve. App ID, certificates and provisioning are set up once and then automated.
2 — The listing
Name, subtitle, promotional text, description, keywords, category, age rating, support URL and privacy policy URL, plus screenshots at each device size Apple still requires. We draft it, you edit the words that are about your business.
3 — Privacy labels and manifests
The privacy nutrition label declares what data you collect, whether it is linked to identity and whether it is used for tracking. Apple also requires privacy manifests declaring reasons for certain system APIs, and signed manifests from common third-party SDKs. We fill these in from what the code actually does, because a mismatch is a rejection.
4 — TestFlight first, always
The build goes to internal testers, then to your external beta group, before it ever goes to review. Nothing is submitted for sale until real people have used it on real devices for at least a few days.
5 — Submit, with the reviewer in mind
A working demo account and any codes a reviewer needs, notes explaining anything unusual, and every feature reachable without a hidden step. Review is often a day or two, but that is a pattern rather than a promise, and it stretches around major OS releases.
6 — Rejections, if they come
A rejection is a message in the resolution centre, not a ban. Most are answered the same day with an explanation or a small change. We reply, resubmit and keep you informed — you never need to learn guideline numbering.
7 — Release on your terms
Release immediately on approval, hold for a date you pick, or use phased release so the update reaches users gradually over several days while we watch crash rates.
The Ones That Catch People Out
Specific, common, and every one of them avoidable before you submit.
Private or undocumented APIs
Calling anything Apple has not published, or reaching a system behaviour through a back door. Static analysis catches it at submission, and the fix is usually a rewrite of that feature, so it is a very expensive shortcut. It also turns up inside careless third-party SDKs, which is why we audit dependencies.
Privacy labels that do not match the code
You declare that you collect nothing, then an analytics SDK sends a device identifier. Reviewers check. The same applies to privacy manifests and required-reason API declarations: they describe the binary, not your intentions, so we generate them from the dependency list.
Missing Sign in with Apple
If your app offers account sign-up through a third-party social login, Apple generally requires Sign in with Apple as an equivalent option. It is a small piece of work if it is planned and an annoying one if it is discovered at submission, so it goes in the scope document.
Subscription and purchase rules
Digital goods must use in-app purchase. The purchase screen has to state price, duration and renewal terms before the user buys. A Restore Purchases control is required, and links to terms and privacy must be present. Steering users to an outside payment page is the single fastest route to a rejection.
Minimum functionality
An app that is a thin wrapper around a website, or that could plainly have been a web page, gets turned down. If you genuinely want a web view inside the app, it has to be part of something that also does device-native work worth installing.
No in-app account deletion
If the app lets people create an account, it must let them delete it from inside the app — not by emailing support. It is a backend endpoint plus a confirmation flow, and it is routinely forgotten until the rejection arrives.
Incomplete build
Placeholder copy, dead links, a feature behind a login with no demo credentials, or a crash on the reviewer device. This is the most common rejection of all and the easiest to prevent, which is why TestFlight always comes first.
Permission prompts without context
Every permission needs a usage description string that explains, in plain English, why your app wants location, camera, contacts or notifications. Vague or missing strings get flagged, and users deny permissions they do not understand anyway.
TestFlight, and What It Is Good For
Internal and external testers
People on your developer account get every build immediately. External testers — invited by email or a public link, and there can be a lot of them — get builds after a lightweight beta review, which is normally quicker than full App Store review.
Feedback with screenshots attached
Testers can send feedback and a screenshot straight from the TestFlight app, so you get the actual screen rather than a description of it in a group chat. Crash reports come back to us automatically.
Practice for the real submission
Beta review uses the same pipeline as App Store review, so problems with signing, entitlements, privacy manifests or missing metadata surface here — days before they would have cost you a launch date.
Builds expire after a set period, so a beta group needs regular releases. That suits the two-week sprint cadence rather than fighting it.
iPhone, iPad, and Deciding How Far to Go
iOS fragmentation is mild compared with Android, but it is not zero. There is a meaningful gap between the smallest supported iPhone and a Pro Max, and a much bigger one between any iPhone and an iPad in split view with a keyboard attached.
So we make it a decision rather than a discovery. During scoping we agree the oldest iOS version you support, whether iPad is in or out, and whether anything else in the ecosystem is in scope. Each of those has a design cost and a testing cost, and both appear in the estimate.
- Supporting one extra older iOS version costs testing time, not usually rewriting
- Real iPad support means new layouts, not a stretched phone screen
- Landscape, multitasking and external keyboards are iPad table stakes
- The App Store needs screenshots for every size class you declare support for
- An iPhone-only app still installs on iPad, which is a legitimate v1 choice
The Apple Features Worth Building
Most of these are small pieces of work individually. Chosen deliberately, they are also the difference between an app that sits in a folder and one that stays on a home screen.
Home screen and Lock Screen widgets
A glanceable summary of the one number your user opens the app to check. Cheap to build and unusually good at pulling people back in.
Push notifications and Live Activities
Standard pushes, rich pushes with images and actions, and Live Activities for anything with a real-time status — a delivery, a match, a job in progress.
In-app purchase and subscriptions
StoreKit for one-off purchases, subscriptions, free trials and introductory offers, with server-side receipt validation so entitlements cannot be faked.
Sign in with Apple, Face ID and Shortcuts
Fast sign-up, biometric unlock for anything sensitive, and Siri Shortcuts for the repeated action power users perform every day.
When Native iOS Is the Wrong Choice
We would rather say this on the estimate call than six weeks into a build.
Look at cross-platform instead if
- You need Android at launch too, and the budget is fixed
- The app is screens, lists, forms and notifications rather than device-heavy work
- A small team will maintain it and cannot staff two platform specialists
- Shipping changes quickly after launch matters more than the last few frames of animation
Native iOS is the right call if
- iPhone is genuinely where your users are, and Android can wait
- The app depends on the camera, Bluetooth, background location or heavy offline storage
- You want new Apple platform features the week they ship
- You plan to hire in-house iOS engineers and want a codebase they can own immediately
Where People Go From Here
Android App Development
Kotlin, Jetpack Compose, Play Console staged rollouts and the device fragmentation problem.
Learn moreMVP Development
How a first iOS version gets scoped down, priced as one number and shipped in 8 to 16 weeks.
Learn moreUI/UX Design & Prototyping
Designing to the Human Interface Guidelines before a line of Swift gets written.
Learn moreiOS Questions We Get Asked
Do I need a Mac to have an iOS app built?
Not to have one built. Building and signing an iOS app requires a Mac and Xcode, and those are ours. What you do need is an Apple Developer Program membership in your own name, since that is what the app is published under and what your ratings and reviews attach to. An iPhone or iPad is also worth having so you can install TestFlight builds and try the app as it is being made.
What actually gets apps rejected from the App Store?
Almost always something ordinary. A missing demo account so the reviewer could not get past the login screen. Privacy labels that do not match what the code collects. Selling digital content without using in-app purchase. Offering Google or Facebook login without also offering Sign in with Apple. A subscription screen that does not state the price and renewal terms before purchase. No way to delete an account from inside the app. Or a build that simply crashed on the reviewer device.
Should the app be built in SwiftUI or UIKit?
SwiftUI for new work, with UIKit brought in for the specific screens that still need it. SwiftUI is faster to write, much easier to keep consistent across iPhone and iPad, and it is where Apple is investing. UIKit remains the better answer for very complex custom layouts, some camera and media work, and any control that needs behaviour SwiftUI does not yet expose. The two mix in the same app, so this is not an either-or decision.
How do my testers try the app before it is public?
Through TestFlight, which is Apple official beta system. Internal testers on your developer account get builds immediately. External testers, up to a large group invited by email or a public link, get builds after a lightweight beta review that is usually quicker than a full App Store review. Builds expire after a fixed period, testers can send feedback and screenshots from inside the app, and crash reports come straight back to us.
Does my iPhone app have to support iPad?
No. You can ship an iPhone-only app and it will run on an iPad in a scaled window. Whether that is acceptable is a business decision, not a technical one. Proper iPad support means designing for a wider layout, split views, keyboard and trackpad input and multitasking, which is real additional design and test effort. We price it as an explicit line item rather than quietly assuming it either way.
Do I have to use Apple in-app purchase for payments?
It depends on what you are selling. Digital goods and services consumed inside the app must go through in-app purchase, and Apple takes a commission. Physical goods and real-world services, such as ordering food, booking a room or paying a tradesperson, use a normal payment processor with no Apple commission. Getting this wrong is one of the quickest ways to be rejected, so we settle it during scoping rather than at submission.
Talk to Someone Who Has Shipped Through App Store Review
Send over what the iPhone app needs to do. You get a written scope, a timeline and a budget range back within two business days.