Mobile App Development

The Build Decisions That Bind Earliest

Once an app is the right answer and the store accounts and keys sit with your entity, the build has an order of its own, and it is not the order a design-first plan assumes. The API contract comes first, because it fixes what the client is able to do at all. A single workflow slice running against a real environment comes next, not against mocks. Breadth comes last. The risk in a mobile project sits in authentication, sync, and network behavior, and none of that shows itself until real data moves over a real connection. Layout is the cheapest thing in the project to change, which makes it the wrong thing to spend the first weeks on.

A few choices have to be settled before that slice can be built, and each one is expensive to revisit once code depends on it.

• The identity provider and the token lifetime. A session that expires while a user is out of coverage, with a queue of unsent work behind it, is a different problem from one that expires at a desk, and the refresh strategy has to be chosen with that case in mind.
• The sync direction for every entity: read-only on the device, write-through, or write and reconcile. Screens that mix all three without saying so are where most sync defects start.
• The minimum OS versions in scope, which decides how many compatibility paths the code carries and which platform APIs are available at all.
• The distribution channel: a public store listing, internal-only distribution to a company-owned fleet, or both. Managed distribution changes enrollment, configuration, and how updates reach devices, so it is not a packaging decision left to the end.
• Who tests it. A small group who will run their actual work through the beta build, rather than a scripted QA pass, because scripts rarely reproduce the connectivity, data volume, and interruptions that break a mobile client.

What Offline Sync Has to Decide, Record by Record

Idempotent writes stop a retry from creating duplicates, but they say nothing about what to do when the same record changed in two places. That answer belongs to each entity, not to the app as a whole. A price list only the server edits needs nothing beyond a refresh. A work order edited by a technician in a basement while a dispatcher edits it at a desk needs a rule, and the rule has to be one the business will accept on the day it silently discards somebody's edit.

Device clocks are user-settable and they drift, so ordering edits by device time produces reconciliation bugs that are close to impossible to reproduce. Order by server-assigned versions or a monotonic sequence, and treat the device timestamp as data the user entered rather than as a fact about when something happened.

• Client-generated UUIDs for new records, so a row has a stable identity before the server has ever seen it and a retried write can be recognized as the same row.
• A per-record version counter or ETag, returned on read and sent back on write, so the server can reject a write made against a stale copy instead of overwriting blindly.
• A conflict rule chosen per entity: last write wins, per-field merge, or hold the conflict for a person to resolve. The third is the honest option and the most work, and some records deserve it.
• Tombstones for deletes, because an absent record and a record that has not synced yet look identical from the client.
• Batch sync endpoints that return per-item results. One bad record in a batch of 200 should not fail the other 199, and the client has to be told which one failed.
• An outbound queue in durable storage, usually SQLite, that survives the OS terminating the app in the background. A queue held in memory loses exactly the work the user could not afford to lose.

What App Review Actually Rejects

Rejections cluster around a small number of guideline sections rather than around code quality. Among the most common is minimum functionality: an app that wraps a website, or that offers nothing a browser tab already does. Another frequent one is asking for data or permissions with no visible feature behind them, such as a location purpose string that does not describe something the user can actually do, or a permission prompt fired at launch instead of at the moment the feature needs it.

Account handling carries its own rules. An app that lets users create an account has to let them delete it from inside the app, and pointing at a support address does not satisfy that. On Android, restricted permissions such as background location and all-files access need a declaration form and often a demonstration video before an update is accepted.

Third-party code brings review obligations you inherit. Apple requires privacy manifests declaring collected data and the reasons for using certain APIs, and expects commonly used SDKs to ship signed with manifests of their own, so an attribution SDK, a push provider, a support chat widget, or a session-replay library can hold up a submission on its own timetable. Google Play's Data safety form has to match what the app and everything inside it actually collects. Both declarations are made per submission, which is why an app that passed last year can be rejected this year against a rule enforced since.

Managed Devices Change the App, Not Just How It Is Delivered

Deploying to a company-owned fleet through device management is more than a different download path. Both platforms let an MDM push a configuration dictionary into the app at install time: on iOS the app reads it from the managed configuration key in UserDefaults, on Android through Android Enterprise managed configurations. That one feature removes the worst pattern in enterprise mobile work, the separately built binary per customer or per site, because the server URL, tenant, and feature switches arrive as configuration instead of as code.

Management also reaches into behavior the app does not control. A work profile separates business and personal data on an employee-owned Android device, and policy can block copy, paste, and screenshots in ways that surprise a team that assumed those worked. A per-app VPN can route only this app's traffic to the internal network, which is often how a mobile client reaches a system with no public endpoint. Corporate TLS inspection and certificate pinning conflict directly, so if you pin, you need to know whose certificate is actually terminating the connection.

Keep credentials in the platform key stores rather than in app storage: the iOS Keychain, and Keystore-backed keys on Android. Gate sensitive actions by having biometric authentication unlock a key rather than return true or false, since a boolean result is trivial to defeat on a rooted or jailbroken device and an unreleased key is not.

The Release Controls to Build Before the First Release

A mobile fix reaches users on the store's schedule and then on each user's, so the controls worth having are the ones that let you slow a bad release down and change behavior without shipping a build. Staged rollout is the first. Google Play can release to a percentage of users and halt, and the App Store's phased release spreads automatic updates over seven days and can be paused, though anyone who visits the listing can still pull the new version by hand.

Server-side switches are the second. A feature that can be turned off from the server, or a configuration value the client reads at launch, converts a store round trip into a support action. It is the same reason to put anything likely to change, such as endpoints, limits, and thresholds, in configuration rather than hard-code it into the binary.

Two mechanics are easy to skip and painful to add later. Crash reports are only readable if the symbols were uploaded when the build was made: dSYM files on iOS, the R8 or ProGuard mapping file on Android. And a client version check against a server-published minimum lets you tell an old client to update. Android's in-app update API can prompt or force that in place, while on iOS the app has to detect the condition itself and send the user to the store listing.