Native iOS
application development
in Gaithersburg

Before an app appears in the App Store, the developer answers a questionnaire about data. Apple turns those answers into the privacy section of the product page. Users see which data the app collects, whether it is linked to their identity and whether it is used to track them. It looks like paperwork. In practice it is an engineering task.

The answers must cover all code in the app, including third-party SDKs. An analytics library, a crash reporter, an advertising network and a chat widget each collect something. The team has to find out what, for what purpose and whether the vendor links it to a user. Vendors publish documentation for this. Read it rather than guessing.

Categories are specific. Contact info, location, identifiers, usage data, diagnostics, purchases and more. Each item has a purpose such as analytics, app functionality or third-party advertising. Precise location and coarse location are separate entries. So are crash data and performance data. A spreadsheet that maps every SDK to every category makes later updates much easier.

The privacy manifest adds a second layer. It is a file named PrivacyInfo.xcprivacy inside the app bundle and inside each SDK. It declares collected data types, tracking domains and the use of certain system APIs. Apple calls those the required reason APIs. They include UserDefaults, file timestamps, system boot time and available disk space. Each use needs a declared reason from an approved list.

This catches teams off guard. Plenty of code touches UserDefaults or reads a file date without any tracking intent. Without a declared reason, the upload gets a warning or a rejection. Commonly used third-party SDKs must also ship their own manifests and signatures. An old version of a popular library may lack them. Updating dependencies is often the first step of a privacy review.

Tracking has its own rule. If the app links data with data from other companies for advertising, or shares it with data brokers, that is tracking in the sense Apple uses. The app must then show the App Tracking Transparency prompt and receive permission before doing it. Without permission, the advertising identifier returns zeros. Features must not be locked behind consent.

The tracking domains listed in the manifest matter at runtime. If the user declines tracking, the system blocks network connections to those domains. A misconfigured list can therefore break unrelated functions that happen to share a domain.

Permission dialogs need text too. Each sensitive capability requires a purpose string in the Info.plist file, such as the reason for camera or photo library access. Missing strings crash the app the moment it asks. Vague ones, such as needed for the app, can lead to rejection. Write one honest sentence per permission.

Keep all of this under version control and review it at every release. When someone adds a new SDK, the pull request should include the updated manifest and a note for the questionnaire. Privacy details that drift out of date are a quiet liability.

Sign in with Apple often arrives in a project because of a rule. If an app offers login through a third-party social account, Apple asks it to offer an equivalent privacy-focused option as well. Sign in with Apple is the obvious way to satisfy that. Implemented properly, it is also one of the fastest sign up flows on an iPhone.

The first surprise is data. Apple returns the name and email of the user only on the first authorization. Later sign ins return a stable user identifier and nothing else. If the backend fails to save the name the first time, perhaps because of a network error, it will not get another chance through the normal flow. Store those fields immediately and retry the upload from the device if needed.

The second surprise is the email itself. Users can choose Hide My Email. Apple then gives the app a random relay address on the privaterelay.appleid.com domain and forwards mail to the real inbox. Mail to that address is delivered only from domains and addresses the team has registered in the Apple developer account. Transactional email systems must also pass SPF and, ideally, DKIM checks. Skip the registration and receipts, password notices and newsletters vanish without an error.

Duplicate accounts follow. The same person may have signed up earlier with email and password, then tap Sign in with Apple and hide the address. The backend sees two strangers. Offer account linking inside settings, where a signed in user can connect other login methods. Do not try to merge accounts automatically by name.

The server must verify every login. The app receives an identity token, a signed JWT. The backend checks its signature against the public keys Apple publishes, then checks the issuer, the audience, the expiry and a nonce the app generated for this request. Trusting the token without these checks lets anyone forge a login.

Credentials can change outside the app. A user can stop using Sign in with Apple for the app in their Apple account settings. On launch, the app should call getCredentialState for the stored identifier. If the state is revoked, sign the user out locally. Apple can also send server notifications about such changes to an endpoint the team configures.

Deleting an account adds one more call. When a user who signed in with Apple deletes their account in the app, the backend should revoke the tokens through the Apple REST API. Keep the refresh token from the initial exchange for that purpose.

The same identity works beyond the iPhone. A web version or an Android app can use Sign in with Apple through a web flow with a Services ID and a registered return URL. Plan that setup together with the iOS work, so that one person has one account on every platform.

Design the button by the rules. Apple provides official styles in black, white and outlined versions, with fixed wording options. Custom buttons are allowed within its guidelines, but the simplest path is the system control.

Sooner or later somebody asks whether the iPhone app should also run on Apple Watch. The question sounds small. A watch app is a separate product with its own screen, its own limits and its own reasons to exist. For many apps the honest answer is no. For some it is the best part of the product.

Start with what people do on a wrist. They glance for a few seconds. They tap once or twice. They act on something that arrived without being asked for. Tasks that fit that pattern suit the watch: a timer, a reminder, a delivery status, a door code, a quick reply, a workout.

Tasks that need reading, typing or comparison do not. A banking app can show a balance on the watch. Nobody wants to review a statement there. If the core action needs more than a glance, a watch app will feel like a cramped copy of the phone.

Notifications may be enough. The watch already shows notifications from the phone, with actions attached. Rich notifications can carry an image, a map or buttons. For many products this delivers most of the value without a separate app, and it costs a fraction of the effort.

Complications are the other small entry point. A complication is a piece of data on the watch face, visible every time the wrist is raised. A next appointment, a streak, a battery level for a connected device. Since watchOS moved to WidgetKit, complications share code and concepts with iPhone widgets, so work on one helps the other.

A full watch app makes sense when the watch is the natural place for the job. Fitness and health tracking, where the sensors live on the wrist. Hands-busy work, such as a warehouse picker or a cook. Situations where taking out a phone is awkward or unsafe.

The build brings its own questions. Should the watch app work without the phone nearby? Modern watch apps can run independently and reach the network directly, but sign-in, data sync and battery use then need careful design. Data has to stay consistent when the phone and the watch both change it.

Testing needs real devices. The simulator does not show how a screen reads outdoors, how a crown scroll feels or how quickly the battery drains. Watches also stay in use for years, so check which older models and watchOS versions still matter to your users.

Measure after release. Watch usage is easy to overestimate in planning. If only a small share of users open it, keep it lean and put the effort back into the phone.