The iOS app
We write native iOS apps in Swift and SwiftUI. Features ship inside the app, and the app uses only Apple's public interfaces (APIs).
iOS app development company
An iOS app built to your spec — and to Apple's review rules.
We build native iOS apps in Swift and SwiftUI, plus the server side each app needs. Several of Apple's App Store Review Guidelines decide how an app is built, not just how it is listed. So before any code is written, we settle four things: what ships inside the app and what comes from your server, how people delete their accounts, what third-party SDKs (code from other companies) collect, and how Apple's reviewer signs in.
- We build the server side too
- Reviewer access ready before submission
- We reply within one working day.
- Guideline 2.1
- Guideline 2.5.1
- Guideline 2.5.2
- Guideline 5.1.1(v)
- App privacy details
In brief
- What it is
- Native iOS app development in Swift and SwiftUI, Apple's own programming language and interface toolkit, with the server side the app needs.
- Why it matters
- Some of Apple's review rules decide how the app is built. Find one late and you rework code, not just the store listing.
- What you get
- An app and server designed around those rules from the start: features that ship inside the app, account deletion built in, each SDK's data collection checked before it is added, and a way in for Apple's reviewer.
What we do
The app, the server behind it, and a build ready for Apple's review.
We plan all three together, because Apple's rules cut across them.
The server side
We build the server the app needs. It sends the data that can change without a new build, and it carries out account deletion.
Ready for Apple's review
We check what each SDK collects before it is added, so your privacy label can account for it. A demo account for Apple's reviewer is in place before the build goes to Apple.
Not sure native iOS is right? Compare the options on cross-platform app development. Before release, our mobile app security assessment checks the finished build against OWASP MASVS (the Mobile Application Security Verification Standard).
Decided before the code
Two rules decide how your app's features are built.
Under guideline 2.5.2, features ship inside the app. Under guideline 2.5.1, the app uses only the parts of iOS that Apple makes public.
Apple's App Store Review Guidelines are easy to leave until submission week. Several cannot wait, because they shape the build itself. These two come first.
- Guideline 2.5.2: features ship in the bundle. Apple wants an app self-contained in its bundle, the package that goes to review. It may not "download, install, or execute code which introduces or changes features or functionality of the app". Your server can still send the app new data, but not a new feature. So we decide the split between server and bundle while the product is still on paper.
- Guideline 2.5.1: public APIs only. Where the app meets iOS itself, it may use only Apple's public interfaces (APIs). A feature that would depend on a private interface is dropped or redesigned while it is still an idea, because nothing later in the build can make that interface public.
Code or data
What a live iOS app can change without a new build.
Read against guideline 2.5.2, a change is one of two things: data the shipped app already knows how to show, or a new feature that needs a new build.
| The change | How it reaches users | Why |
|---|---|---|
| New prices, stock levels or articles | As data from your server | Shipped code already knows how to show it |
| A discount rule or a spending limit | As an answer your server works out | The app shows a result and runs nothing new |
| Wording and images on an existing screen | As data, if the screen was built to fetch it | Text fixed in the bundle changes only in a build |
| A new screen or a new step in a flow | In a new build, sent to Apple for review | It adds functionality the bundle lacks |
Account deletion
An app that creates accounts has to delete them as well.
Guideline 5.1.1(v) ties account creation in an app to account deletion in the same app. So we design deletion alongside sign-up.
List where an account lives
Sign-up writes to more than a login record: a profile, uploaded files, push tokens (the addresses notifications are sent to), and outside services that received an identifier. Deletion is designed from that list.
Put the control in the app
The guideline places deletion within the app, so the control sits on the screen where people already manage their account.
Delete on the server
The app only asks. The server removes records and files, ends sessions on other devices, and tells outside services to drop what they hold.
Leave the device clean
After the server confirms, the app clears its local cache and shows the signed-out state, instead of failing on a request for an account that is gone.
Third-party SDKs
Settle what an SDK collects before it is added.
Apple's app privacy details page asks you to declare what other companies' code in your app collects, as well as what you collect yourself.
Apple calls those companies third-party partners, and an analytics or advertising SDK is one of them. What it collects belongs in your App Store privacy label, even data your app itself never reads, unless that data meets all of Apple's criteria for optional disclosure.
What we check before adding an SDK
- What it sends. The data that leaves the device, as the SDK's vendor documents it.
- When it starts. At app launch, or only when the app calls it.
- Whether it can be narrowed. Settings in the app's configuration that switch the collection off or limit it.
- Whether you need it. The app's own back end may be able to do the job without a third party.
- Which version. The label describes one SDK version, and a later one can collect more.
The reviewer's way in
Apple's reviewer needs a working login and a server that answers.
Guideline 2.1 expects Apple's reviewer to be able to sign in and use the app, so we design that access alongside sign-in.
Guideline 2.1 wants demo account details sent with any app that has a login, and a back end that is running during review. Whatever server the submitted build points at has to be up when the reviewer opens the app.
In place before the build goes to Apple
- Demo credentials. Supplied with the submission, for an account nobody else uses.
- Every screen reachable. Sample data, roles and plan settings that open everything behind the login.
- No real customer data. The reviewer sees only records that belong to the demo account, never a real customer's.
- A way past blocked sign-in steps. Where sign-in has a step a reviewer cannot complete, such as a texted code, the demo account skips it. No other account does.
Find the right page
Related questions, and the page that answers each.
Choosing a platform, adding Android, checking security and keeping the app current each have their own page.
- Should our app be native iOS at all, or one codebase for iPhone and Android?Cross-platform or native
- We need an Android version that meets Google Play's current requirements.Android app development
- Can someone check the finished build's security against OWASP MASVS before release?Mobile app security assessment
- Who keeps the app patched and current as iOS and Apple's rules change after launch?App maintenance and support
- The app has to connect to systems we already run.API development and integration
- We need iOS and Android, including store review, offline use and updates.Mobile app development
FAQ
Questions about iOS builds and Apple's rules.
The server side, updates, iOS versions, account deletion, privacy labels and review access. For anything else, ask us directly.
SecWiz does, and on iOS that server carries part of Apple's App Store Review Guidelines. Guideline 2.5.2 bars downloaded code that changes features, so anything changed without a new build arrives from the server as data. Account deletion under guideline 5.1.1(v) runs there, and guideline 2.1 needs the back end up during review.
Not by downloading them. Apple's App Store Review Guideline 2.5.2 does not let an app fetch and run code that adds or alters its features, apart from a narrow exception for educational apps. Server data can still change what existing features show. A new feature needs a new build, which goes to Apple for review.
Apple's App Store Review Guideline 2.5.1 sets one fixed point: an app must run on the currently shipping version of iOS. How many older releases it also supports is the owner's call, and an early one, since each release kept is another version every feature has to work on.
Yes, if the app lets people create an account. Apple's App Store Review Guideline 5.1.1(v) says an app that supports account creation must also offer account deletion within the app. Deletion therefore joins the feature list when sign-up does: a control inside the app, and server work behind it that removes the account.
Yes. Apple's app privacy details page says the answers cover data that third-party partners collect as well as the developer's own, unless it meets all of Apple's criteria for optional disclosure. An analytics or advertising SDK is such a partner, so its collection belongs in the label, including data the app itself never reads.
Apple's App Store Review Guideline 2.1 expects demo account details and a running back end for any app with a login. The same guideline also allows a built-in demo mode in place of a demo account, with Apple's agreement in advance. Either way, the reviewer's route in is designed alongside sign-in.
Let's talk
Start with the feature list.
Send the feature list and say whether people sign in. Project work is delivered remotely from India during business hours. We reply within one working day.