iPhone and iPad Apps in Swift, With the Apple Paperwork Handled
The engineering is the straightforward half. The half that catches UK companies out is everything around it: the developer account your finance team has to approve, privacy disclosures that have to survive both Apple and the ICO, and a review process with opinions about how your app behaves. We run all of it.
What Your Finance Team Needs Approved First
An iOS project has a small number of recurring costs and account obligations that belong to your company rather than to us. Raising them at the start avoids the awkward discovery that nobody can approve a card payment in week three.
| Item | What it actually is | Who holds it | Rhythm |
|---|---|---|---|
| Apple Developer Program | The membership that permits distribution through the App Store and TestFlight. Billed in US dollars, so the sterling figure moves with the exchange rate. | Your company, as an organisation enrolment | Annual, auto-renewing |
| D-U-N-S number | A business identifier Apple requires for organisation enrolment. Free to obtain, and it must match the entity registered at Companies House. | Your company | Once, with occasional updates |
| Account holder | A named person with authority to bind the company, who accepts agreements and approves new terms. Apple changes its agreements periodically and releases stall until somebody accepts them. | A director or nominated employee | Ongoing |
| Signing keys and certificates | Cryptographic material proving builds came from you. Losing control of these is a serious incident; losing access to them delays releases. | Your company, stored in your secret manager | Renewed periodically |
| Mac hardware | Required to compile and submit iOS builds. It is our hardware, not a cost to you, and no, you do not need to buy a Mac to own an iPhone app. | Us | Not your concern |
The line worth repeating to finance is the consequence of lapsing. If the membership expires, your app is removed from sale until it is reinstated. It is not a project expense that ends at launch; it is a small annual licence with a large failure mode, and it belongs in the same budget line as your domain names and TLS certificates.
Swift, SwiftUI, and the UIKit That Refuses to Retire
Written in the language Apple writes its own frameworks in, using its own components wherever they exist, so the app stays maintainable by anybody who knows the platform.
Swift End to End
No bridging layers, no abandoned cross-platform runtime underneath. Swift concurrency for anything asynchronous, which removes an entire category of race conditions that used to make network-heavy apps flaky. Swift Package Manager for dependencies, so the project opens and builds without a custom toolchain.
SwiftUI, Mixed With UIKit Where It Earns It
Declarative, less code for the same screen, and it inherits Dynamic Type, dark mode and VoiceOver behaviour rather than requiring them to be rebuilt. Where a specific control genuinely works better in UIKit — some complex text handling, certain camera and media flows — we mix the two, which Apple supports properly in both directions.
Apple Frameworks Before Libraries
The Keychain for secrets, the system network stack, Core Data or SwiftData for local storage, the built-in authentication and biometric APIs. Every third-party dependency is a future privacy manifest obligation and a future maintenance liability, so each one has to earn its place rather than arrive by habit.
Building to Apple Conventions Rather Than to Your Brand Book
The Human Interface Guidelines are not a style preference. They describe what an iPhone user already knows how to do, and every departure from them is a small tax on every user, forever.
The Conventions Worth Keeping
Navigation where people expect to find it, with the back gesture working from the left edge. Content respecting safe areas rather than sliding under the notch or the home indicator. Dynamic Type honoured so a user who has enlarged their text does not lose half your interface. Dark mode as a supported appearance, not an afterthought. Standard sheets, alerts and share behaviour, because the muscle memory is already there.
Where Brand Guidelines Have to Give Way
Brand books written for print and web routinely specify things that do not survive on an iPhone: fixed type sizes that break under large text settings, a colour pairing that fails contrast in daylight, tap targets designed for a mouse pointer. We resolve those during design with your marketing team rather than during build. The brand survives in colour, typography, tone and imagery; the interaction model belongs to the platform.
If you already have brand guidelines or an existing designer, the design and prototyping page explains how we work alongside them rather than around them.
Nutrition Labels and Tracking Consent, Read Through UK GDPR
Apple asks you to declare what you collect. UK law asks you to justify it, tell people about it, and let them change their mind. These are different obligations, and satisfying the first does not discharge the second.
The Privacy Label Is a Public Statement
The label on your listing says what data your app collects, whether it is linked to a person, and whether it is used to track them. It is visible to every prospective user and, more to the point, it is a public assertion about your processing. If it contradicts what the code does, you have an App Review problem and a transparency problem under UK GDPR at the same time. We complete labels from a dependency audit, not from a marketing summary, and re-check after every SDK upgrade.
Two Consents, Not One
The App Tracking Transparency prompt governs the device advertising identifier and cross-app tracking under Apple policy. UK GDPR and PECR govern your processing and your access to information on a user device, and they need a lawful basis, clear information, and a real route to withdraw. An app that shows the Apple prompt and nothing else is relying on a store policy to do a regulator job. We build a consent layer that is stored, honoured everywhere in the app, and reversible from settings.
What we do about it during a build
- Audit every SDK for what it transmits, and drop the ones whose value does not justify the disclosure
- Produce the privacy manifest and required-reason declarations from the actual dependency tree
- Write permission strings that say why, in plain English, because a vague one is both a rejection risk and bad practice
- Build in-app account deletion that genuinely deletes, which Apple requires and a UK erasure request will test
- Hand you a written record of what is processed and where it is stored, which feeds straight into your records of processing
- Use UK or EU regions for storage where residency matters, and sign a data processing agreement
We are developers rather than solicitors, and we will say so. What we can do is make sure the technical reality matches whatever position your privacy adviser takes, which is the half that usually goes wrong.
The Route From Finished Build to Available Download
Each stage has a failure mode. Knowing them in advance is the difference between a two-day review and a fortnight of correspondence.
Review commonly returns within a day, though Apple makes no promise and we do not either. A rejection is correspondence rather than a verdict: most are resolved the same day with an explanation or a small change.
The Ones That Catch UK Teams Out
Not the exotic cases. These are the ordinary, repeatable ones we check for before anything is submitted.
TestFlight, and Getting a Build to People Who Are Not Developers
The most useful thing about TestFlight is that non-technical colleagues can install a build by tapping a link, which means feedback comes from your operations manager rather than only from us.
Internal Before External
Internal testers are people on your Apple team and get builds within minutes of upload. External testers can be invited in far larger numbers, including through a public link, but an external build passes a Beta App Review first. We use internal for the working build and external for the pilot group, which usually means a branch, a depot or a friendly client.
Feedback With the Screenshot Attached
A tester can take a screenshot in the app and send it with a note, and crash reports arrive automatically. This is considerably better than a forwarded email saying it did not work, because it arrives with the device, the build number and the state of the screen already attached.
A Rehearsal for the Real Thing
Beta review exercises the same signing, entitlements and metadata as a full submission, so problems surface on a week when they cost nothing. Builds expire after a set period, which is a useful discipline: it stops a stale version drifting around the business for months.
iPad, Widgets, Notifications and Paying for Things
Decisions that are cheap to make at design time and expensive to revisit once the interface exists.
How Far to Go on iPad
Three honest options. Phone only, which is fine for a consumer product. Compatible, where the phone layout runs enlarged, which costs almost nothing and looks like it cost almost nothing. Or a genuine iPad interface using the extra space with split views and multitasking, which is real design and build work. The middle option is the right one more often than people admit; the third is worth it for apps used seated, on a desk, all day — clinical notes, site surveys, sales presentations.
Widgets, Notifications and Live Activities
A home screen widget is a second, much smaller product with its own data path and refresh budget, not a shrunken screen. Push notifications need a reason to exist: an operational instruction earns an interruption, a marketing message usually does not, and a badly judged notification strategy is the fastest route to being uninstalled. Live Activities suit genuinely live things — a delivery in progress, an engineer en route — and look absurd on anything else.
In-app purchase, in one paragraph
Digital goods and services consumed inside the app go through Apple in-app purchase at the applicable commission, with reduced rates for smaller developers and for subscriptions past their first year. Physical goods and real-world services do not — those go through Stripe or your existing processor at ordinary card rates. Subscriptions bring their own engineering: receipt validation on your server rather than on the device, handling of grace periods and billing retries, restoring purchases on a new handset, and a clear route to manage or cancel. Get the server side right and renewals look after themselves; get it wrong and you will be reconciling by hand at every month end. The mobile overview goes further into how commission affects a UK price list.
iOS Questions UK Clients Raise
How do we justify the Apple developer account to our finance team?
Present it as a recurring licence rather than a one-off project cost. The Apple Developer Program is an annual membership billed in US dollars, so the sterling amount moves slightly with the exchange rate, and it renews automatically on the anniversary of enrolment. The important line for finance is what lapsing costs: if the membership expires, your app is removed from sale and stays unavailable until it is reinstated. It belongs in the annual software budget alongside your domain and your certificates, owned by a named person with a calendar reminder, not on somebody’s personal card.
Does an App Tracking Transparency prompt satisfy UK GDPR consent?
No, and treating it as though it does is a common and avoidable mistake. App Tracking Transparency is Apple policy governing access to the device advertising identifier and cross-app tracking. UK GDPR and PECR are law, and they require their own lawful basis, their own clear information, and a genuine ability to refuse and to change your mind later. In practice a UK app needs both: the Apple prompt where tracking is involved, and a consent mechanism of your own covering analytics, advertising and any third-party SDK that processes personal data. We build the second one properly, with the choice stored, respected across the app and reversible from settings.
Our Apple account is in a former director’s name. How do we move it?
This is more common than you would think and it is worth resolving before it becomes urgent. The clean route is enrolling the company itself in the Apple Developer Program as an organisation, which needs a verifiable legal entity, a D-U-N-S number matching your Companies House record, and somebody with authority to bind the company, then transferring the app across accounts. Apple has conditions on transfers relating to bundle identifiers, in-app purchases and account standing. Where the previous holder will not cooperate, the fallback is a new listing, which costs you the reviews and the ranking, so try the cooperative route first.
We are an FCA-authorised firm. Does that change the submission?
It adds a stage rather than changing the mechanics. Apple applies extra scrutiny to financial services apps and will generally expect the listing to be published by, or demonstrably on behalf of, the authorised firm rather than a developer or a marketing agency, with your authorisation details verifiable. Your own financial promotions and disclosure obligations then apply to what the app screens actually say, and those obligations are yours rather than ours. Practically, we build the app, provide the reviewer with working demo credentials, and align the listing with your compliance team before submission rather than after a rejection.
What is a privacy manifest and does it apply to our app?
It is a file inside the app that declares what data the code collects, which of a specific set of sensitive platform APIs it uses, and the reason for each. Apple also requires several common third-party SDKs to ship their own manifest and a signature. If your app or any of its libraries touches things such as file timestamps, disk space, user defaults or system boot time, a declared reason is expected. We generate these from an audit of the actual dependency tree rather than from memory, and we check them again whenever a library is upgraded, because a manifest that stops matching the code is a submission failure waiting to happen.
If something is badly broken in production, how quickly can we ship a fix?
Faster than most people expect, but not instantly. A fix has to be built, tested and submitted, and it then queues behind App Review, which commonly returns within a day although Apple gives no guarantee. For genuine emergencies you can request an expedited review, which should be reserved for real user-impacting faults rather than a missed marketing date. The real protection is architectural: server-controlled feature flags let us disable a broken feature without a release at all, and a forced-update check lets you require the fixed version once it is live. We build both into apps where downtime genuinely costs you money.
Read Next
Android App Development
The other half of most mobile projects, written for the handsets UK field teams actually carry.
Learn moreMaintenance & Support
A yearly iOS release, an expiring certificate and an evolving review guideline all have to be somebody’s job.
Learn moreOur Process
Sprints, demo builds and the written daily update, from scoping call through to the weeks after launch.
Learn moreTalk to People Who Have Been Through App Review
Send us the idea or the existing build. You get a scope, a delivery window and a sterling range excluding VAT within two working days, plus a straight view on anything in your feature list that Apple will object to.