Mobile App Development

It's tempting to design and test an app exclusively on whatever phone happens to be on the desk during development — usually a recent, high-end device with a fast processor, a large high-resolution screen, and a strong, stable connection. Real users are on a much wider spread: older Android devices with meaningfully less processing power, a range of screen sizes from compact phones to large tablets, and connections that go from strong wifi to a single flaky bar of mobile signal depending on where they happen to be standing. An app that only performs well on the developer's own test device is an app that hasn't actually been tested.

I build a device and network testing matrix appropriate to the target audience early in a project — not an exhaustive list of every device ever made, but a realistic representative spread based on who will actually use the app, informed by regional device market share data where that's relevant to the business's actual users. Performance budgets get set against the lower end of that spread, not the highest end, because an app that runs smoothly on a flagship and stutters badly on a mid-range device three years old has effectively failed a meaningful share of its real audience, even if it looks flawless in every internal demo.

Interface design accounts for real-world conditions too: touch targets sized for an actual thumb rather than a precise mouse cursor, text legible in direct sunlight and not just under office lighting, and critical actions reachable one-handed, since a meaningful share of mobile usage happens one-handed while a user is walking, carrying something, or otherwise not giving the app their full physical attention. These aren't abstract accessibility nice-to-haves — they're the difference between an app real people can actually use in the actual conditions they use their phones in, versus one that only works well in a controlled demo environment.

Testing on real hardware also changes what "done" means for a given feature. A gesture-based interaction that feels natural on a large-screen flagship can be genuinely awkward on a smaller device, and a loading state that is barely noticeable on a fast connection can feel broken on a slow one. I treat the lower end of the target device and network matrix as the actual bar for acceptance, not the upper end, because a feature that only works well under ideal conditions has not really been finished.

Mobile connectivity is fundamentally unreliable in a way a desktop web app rarely has to contend with — users move between wifi and cellular, walk into elevators and parking garages, and lose signal mid-task in ways that would be unusual on a desk-bound connection. An app that assumes a constant, reliable connection breaks constantly in the real world, and that breakage reads to users as the app being unreliable or badly built, even when the underlying logic is sound and the failure is really just an unhandled network condition.

I design explicit states for every meaningful network condition during the planning phase, before development starts: what does the app show while a request is in flight, what happens if it times out, what happens if it fails outright, and critically, what can the user still do while offline or on a poor connection. For many apps, a genuinely useful offline mode means the ability to view previously loaded content and queue actions to sync once connectivity returns, rather than a blank error screen that stops the user cold the moment their signal drops for even a few seconds.

Getting this right also protects data integrity, which matters more than it might initially seem. A form submitted just as connectivity drops needs to queue reliably and retry rather than silently disappear, and a user needs clear, honest feedback about whether their action actually went through — a false "saved" confirmation that later turns out to have failed is worse for trust than an honest "this will send once you're back online" message, because the former teaches a user they can't trust the app's own confirmations, and that loss of trust is very hard to win back once it happens even a single time.

A mobile app is rarely a standalone product — it's a client to some backend, whether that's a CRM, a payment processor, a booking system, or a custom API built specifically for the product, and the quality of that integration determines how the app actually behaves under real conditions far more than any single frontend decision does. I map every dependency during scoping: what each integration provides, what its rate limits and authentication requirements are, what its failure modes look like, and what the user experience should be when a given integration is slow or briefly unavailable rather than pretending that scenario won't happen.

Where the backend doesn't yet exist, I design and build the API alongside the app itself, structured around what the mobile experience actually needs rather than a generic API shape borrowed from an unrelated project. That means efficient endpoints that return exactly what a given screen needs rather than large, generic payloads the app has to filter down client-side, and it means authentication and session handling built with mobile's specific patterns in mind — token refresh that happens transparently in the background, for instance, rather than logging a user out mid-session the moment a token silently expires while the app was backgrounded.

For apps integrating with an existing third-party system a client already uses, I do a technical audit of that system's API before committing to scope or timeline, because third-party API quality varies enormously and a poorly documented, rate-limited, or unstable external API can become the single biggest risk to a mobile project's timeline. Surfacing that risk during scoping, before a fixed price and date are committed to, is far better for both sides than discovering it three weeks into development when the schedule has already been promised to stakeholders.

Third-party API risk deserves particular attention because it is the one dependency a mobile team usually cannot fix directly when something goes wrong. If a booking platform's API has an outage or changes its response format without notice, the app has to degrade gracefully rather than crash outright, and users need an honest, clear message rather than a generic error screen that gives no indication of whether the problem is temporary, on their end, or something the business needs to be told about directly.

Getting an app approved and live on the App Store and Google Play is its own process with its own risks, and I manage it as a distinct phase rather than an afterthought tacked onto the end of development. Apple's review process in particular can reject a submission for reasons that range from genuine policy violations to inconsistent enforcement of guidelines that read as ambiguous even to experienced developers, and a first-time rejection with no plan for it can add a week or more of delay right before a launch date a business has already been promoting. I build store guidelines review into the project early, checking planned functionality against current policy before development locks in a feature that would later cause a rejection.

Release management also means planning for updates, not just the initial launch. Both major platforms increasingly require regular updates just to stay compliant with evolving SDK and privacy requirements, separate from any new feature work — an app left completely untouched for a year or more risks being flagged, restricted, or in extreme cases removed from a store entirely, independent of whether the app itself still works fine for existing users. I build this into the ongoing relationship with a client explicitly, rather than letting it become a surprise emergency months after launch when a routine platform requirement change suddenly breaks something that used to work.

For apps handling any kind of sensitive data — health information, payment details, precise location — the relevant privacy and security requirements get scoped as real, load-bearing requirements from day one, not a checkbox filled in right before submission. That includes the privacy disclosures both stores now require in detail, appropriate data encryption at rest and in transit, and a genuinely accurate accounting of what data the app actually collects and why, because both platforms have become considerably stricter about mismatches between an app's declared data practices and its actual behavior, and that mismatch is an increasingly common cause of otherwise-avoidable rejection or removal.

An app that ships and is then left completely alone degrades faster than most business owners expect, for reasons that have nothing to do with the original code quality. Both iOS and Android update their operating systems roughly annually, and those updates periodically change behavior in ways that can affect an app built against an older SDK version — sometimes a minor visual glitch, occasionally something that breaks a core feature outright. Backend dependencies age too: third-party SDKs get deprecated, APIs the app depends on change their contracts, and security patches for underlying libraries need to be applied on a reasonable cadence rather than left indefinitely.

I scope ongoing maintenance honestly with clients rather than let "the app is done" create an expectation that no further work will ever be needed. For most apps, a light quarterly maintenance pass — dependency updates, a check against the current OS versions, a review of crash reports and any recurring user-reported issues — is enough to keep an app healthy without turning into an ongoing expense disproportionate to what the app is actually worth to the business. Apps with a larger active user base or that handle sensitive data typically warrant a somewhat more frequent cadence, scoped specifically to that app's actual risk profile rather than an arbitrary standard schedule.

Crash reporting and basic analytics get set up from day one specifically so this maintenance is informed by real data rather than guesswork — knowing which screens actually crash on which device and OS combinations, and which features get used heavily versus barely at all, focuses maintenance effort and future development on what genuinely matters to real users instead of spreading limited budget evenly and somewhat arbitrarily across every part of the app regardless of its actual real-world importance.

Store rejections are also worth planning a buffer for on the calendar rather than treating the review period as a guaranteed fixed number of days. Apple in particular can take anywhere from under a day to over a week depending on current review volume and whether the submission gets flagged for manual review, and building a realistic buffer into the launch timeline avoids the awkward position of having promoted a specific launch date publicly before store approval is actually confirmed.

A meaningful share of the mobile work I take on isn't a brand-new app — it's an existing app that's become slow, hard to update, or built on a framework or SDK version that's now genuinely obsolete, where the business needs a path forward that doesn't necessarily mean discarding everything and starting over. My first step in that situation is always a technical audit: how much of the existing codebase is genuinely reusable, where the real architectural problems are, and whether a targeted modernization can address the core issues at meaningfully lower cost and risk than a full rewrite would carry.

Modernization projects commonly involve migrating from an older cross-platform framework version to a current one, replacing deprecated third-party dependencies that have accumulated security or compatibility risk, and re-architecting the specific parts of the app that have become genuinely unmaintainable — while deliberately leaving well-functioning parts of the codebase alone rather than rewriting working code purely for the sake of consistency. This targeted approach is almost always faster and considerably cheaper than a ground-up rebuild, and it carries meaningfully lower risk, because a full rewrite reintroduces every bug that had already been found and fixed in the original version, along with whatever new bugs the rewrite itself inevitably introduces.

A full rebuild is the right call, and I'll recommend it directly, when the existing codebase is built on a framework that's been fully discontinued with no viable migration path, or when the accumulated technical debt has genuinely made even small changes prohibitively expensive and risky — the same signal that indicates a rebuild is warranted for a website. In both situations the decision should come from an honest technical assessment of the actual codebase, not from a default assumption in either direction, and I make sure that assessment happens and is shared clearly before either option gets quoted or committed to.

Feature-flagging infrastructure set up during the initial build also makes future rollouts safer, letting a new feature ship to a small percentage of users first and expand gradually once it is confirmed stable, rather than pushing every change to the entire user base simultaneously and hoping nothing breaks at scale.

Push notifications are one of the most powerful retention tools available to a mobile app and one of the fastest ways to get an app uninstalled, and the difference between the two outcomes comes down almost entirely to relevance and restraint. I design notification strategy as a deliberate part of the product, not a marketing afterthought bolted on after launch — what actually warrants interrupting a user, how frequently, and what value that specific notification delivers in the moment someone taps it. A notification that doesn't clearly earn the interruption trains users to dismiss or disable notifications entirely, at which point the feature has lost its value for every future message, including the ones that would have genuinely mattered.

Opt-in timing matters more than most teams initially assume. Asking for notification permission the instant an app opens for the first time, before a user has any context for why they'd want notifications from this specific app, reliably produces a lower opt-in rate than asking at a moment when the value is obvious — right after a user books something, for instance, when a reminder notification clearly serves them. I design that request moment deliberately as part of onboarding rather than defaulting to whatever the platform template suggests, because the difference in long-term opt-in rate between a well-timed and poorly-timed permission request is often dramatic.

Segmentation and frequency capping are part of the technical build, not just a policy decision made verbally and hoped for. That means the backend is architected to send notifications based on real user behavior and preferences rather than blasting every user with every message, and it means giving users real, granular control over what categories of notification they receive rather than a single all-or-nothing toggle. An app that respects a user's attention earns the right to occasionally ask for more of it; an app that doesn't tends to get uninstalled the first time it becomes annoying enough to be worth the two taps it takes to remove it.

Mobile apps face a meaningfully different security threat model than web applications, because the app binary itself lives on a device outside the developer's direct control and can be decompiled, inspected, and in some cases modified by anyone with the right tools and enough motivation. That means secrets — API keys, credentials, encryption keys — cannot be safely hardcoded into the app in a way that would be reasonably safe on a server, and I architect around that constraint explicitly: sensitive operations happen server-side behind proper authentication, and anything that must live client-side is treated as inherently exposed rather than assumed to be private just because it isn't immediately visible in the interface.

Local data storage gets the same scrutiny. Anything sensitive stored on-device — authentication tokens, cached personal data, payment-related information — uses the platform's proper secure storage mechanisms rather than a plain local database or file, and I minimize what's cached locally at all wherever the product's offline requirements allow it, on the reasoning that data that was never stored on the device can't be compromised if the device itself is lost, stolen, or compromised by other means. Session and token handling follows the same minimize-and-protect logic: short-lived tokens with proper refresh flows rather than a single long-lived credential that becomes a much higher-value target if it's ever extracted.

For apps handling regulated data — health information, financial details, anything with specific legal compliance requirements attached to it — I scope the relevant compliance framework explicitly at the start of the project rather than trying to retrofit it after the fact, because compliance requirements frequently affect fundamental architectural decisions: where data can be stored, how long it can be retained, what needs to be encrypted and how, and what audit logging has to exist from day one. Discovering a compliance requirement after an app is already built and in the app stores is a considerably more expensive problem to solve than designing for it from the very first architecture decision.

For a focused business app — the kind built around one or two core user journeys, integrated with one or two backend systems — discovery and technical scoping typically takes the first one to two weeks: mapping user flows, confirming the technical approach, auditing any third-party APIs the app will depend on, and producing wireframes for the core screens before any code is written. This stage is where the framework decision, the offline strategy, and the notification strategy all get settled, because each of those decisions meaningfully shapes the architecture that follows and is expensive to reverse once development is well underway.

Design and the first development milestone typically run over the following three to five weeks, usually structured around building and validating the highest-risk piece of the app first — the specific integration or interaction pattern most likely to reveal an unexpected complication — rather than starting with the easiest screens simply because they're the fastest to show visible progress on. Getting an early, honest read on the hardest part of the build is worth more to the schedule's real reliability than early visible progress on the parts that were never going to be genuinely risky.

The final phase covers QA across the real device and network matrix defined during discovery, app store submission and any resulting review cycles, and a soft launch to a small user group before a full public release where that's practical for the product. A straightforward cross-platform business app following this sequence typically launches in eight to twelve weeks from the first discovery call; apps with heavier custom backend work, complex offline requirements, or native performance demands extend proportionally, with the same underlying sequencing logic — hardest, highest-risk pieces first — applied at whatever scale the project actually requires.

Launching an app is the start of learning what actually works, not the end of the design process, and I build analytics infrastructure into the app from day one specifically to support that ongoing learning rather than adding it later as an afterthought once someone asks how the app is performing. That means event tracking on the actions that actually indicate whether the app is achieving its purpose — completed bookings, finished onboarding, repeat opens within a meaningful window — rather than vanity metrics like raw download counts that say very little about whether the app is genuinely useful to the people who installed it.

For apps with enough traffic to support it statistically, I set up the infrastructure for lightweight A/B testing on key flows — onboarding sequence, paywall placement and framing, a critical conversion step — so decisions about what to change next are grounded in real user behavior rather than internal opinion about what should work better. This doesn't need to be an elaborate experimentation platform for most business apps; often a simple feature-flag system that can route a percentage of users to a variant and measure the outcome is enough to settle genuine disagreements about a design or flow decision with actual evidence.

Post-launch iteration works best as a standing, lightweight cadence rather than a single big "version two" effort planned far in advance. I typically recommend a short, regular review of crash reports, key funnel metrics, and user feedback — weekly at first while an app is finding its footing, tapering to monthly once things stabilize — so small issues and small opportunities get addressed continuously instead of accumulating into a large, disruptive update that takes months to ship and inevitably tries to fix too many things in the same release.

Ownership for a mobile app involves more moving pieces than a website, and I make sure every one of them is explicitly transferred to the client rather than left ambiguous. That includes the full source code repository, but also the developer accounts the app is published under — the Apple Developer Program and Google Play Console accounts — because an app published under a developer's personal account rather than the client's own account leaves the business dependent on that individual indefinitely for even routine updates, with no real recourse if the relationship ends on bad terms.

I set up client-owned developer accounts from the very start of a project wherever possible, and where a client already has an app live under a different developer's account, migrating ownership to the client's own account is one of the first things I help resolve, even though that process can be slower and more bureaucratic than either side would like, involving both platforms' account transfer procedures. It's worth doing properly regardless, because an app trapped under someone else's developer account is a genuine business risk — a lapsed relationship, a lost password, or simply someone becoming unreachable can put continued access to the app's own store listing at risk.

Signing certificates and keys used for release builds are handled with the same discipline: securely stored, properly backed up, and accessible to the client independent of any single individual, because a lost signing key on some platforms can mean losing the ability to publish updates to an existing app under its established identity ever again, forcing a fresh listing that loses all existing reviews, ratings, and install history. This is a genuinely serious risk that's easy to overlook amid the more visible parts of a mobile project, and I treat it as a first-class deliverable rather than an operational detail handled casually.