iOS App Development in Swift and SwiftUI

A privacy manifest is a file inside the app bundle that declares what data the app collects, which tracking domains it contacts, and the reason it calls certain system APIs that Apple treats as a fingerprinting risk. Common examples of those APIs are reading file timestamps, free disk space, system boot time and user defaults. Widely used third-party SDKs are expected to ship their own signed manifest, and your app has to account for the ones that do not. If the manifest disagrees with what the binary actually does, the upload gets flagged or the submission comes back. We generate it from the dependency list and the code rather than from good intentions, and we check it again every time a library is upgraded.

Usually one version back from current, sometimes two. iOS users update quickly compared with Android, so the tail of very old devices is thin, and every extra version you support costs design work, testing time and code paths that guard newer APIs. The decision is a business one: look at who your users are, whether they are consumers or a managed fleet inside a company, and what the oldest hardware in that group can still run. We agree a deployment target during scoping and write it into the estimate, because raising it later is trivial and lowering it later is not.

App Tracking Transparency applies when you link data about a person or a device to advertising or data brokerage across apps and websites owned by other companies. Plenty of apps never need it. First-party analytics that stay inside your own app, crash reporting and basic product measurement generally do not require the prompt, while an advertising SDK that reads the advertising identifier does. Most people who see the prompt decline it, so the honest advice is to design measurement that works without it wherever you can, and to ask only where advertising attribution genuinely pays for itself. Declaring tracking on the privacy label and then never showing the prompt is a rejection.

Not for anything that changes the compiled app. Any change to the binary goes through review, which is usually quick but is never guaranteed on a particular day. What you can change without a submission is everything the app fetches at runtime: server-side content, feature flags, remote configuration and the data behind a screen. So we build the flags in from the start, which means a broken feature can be switched off in minutes instead of waiting on a build. If a submission is genuinely urgent there is an expedited review request, which is meant for real emergencies and quietly loses its effect if you spend it on ordinary releases.

Because on iOS you do not schedule background work, you request it. Background app refresh tasks are opportunistic: the system decides when to run them from how often the person opens your app, the battery level, whether the device is charging, network conditions and low power mode. An app somebody uses daily gets far more background time than one they opened once. Longer jobs need a processing task that typically runs overnight while charging, large transfers should use a background download or upload session that the system finishes on your behalf, and anything that truly has to happen now needs a push notification to trigger it. If a feature only works when the refresh runs on schedule, that feature is designed wrong for iOS.

Only when there is a real moment of first contact away from the store. An App Clip is a small slice of the app that launches from a code, an NFC tag, a link or a place in Maps, does one job and then goes away. It suits ordering at a table, paying for parking, renting something on the spot or checking in at a venue. It is a poor fit for anything that needs an account, ongoing state or background work, and it has a strict size budget that forces you to strip the slice down to almost nothing. If nobody is going to be standing in front of a physical thing with a phone in their hand, the App Clip is decoration and the budget is better spent on the main app.