Hire a mobile development team that runs iOS and Android as one program, not two contracts

Mobile pod — the shape this page is about

Wins when iOS and Android are the product, web is light, and the buyer wants one team running both stores on one cadence. Six seats, USD 22K–38K/month at the steady state. Loses when there is a real Windows or desktop surface that needs its own discipline, or when both stores ship deep parallel features in the same quarter and the budget can absorb two pods.

Staff augmentation — one or two senior mobile engineers embedded

Wins when your mobile org is healthy and you need senior hands to absorb a roadmap quarter, a watch companion, or an ATT rebuild without a full pod. Loses when nobody on your side owns the mobile program: the engineers will ship code on the tickets you assign, but they will not own the platform call, the release pipeline, or the rejection runbook. If that is the gap, hire the pod.

Umbrella app team — iOS + Android + cross-platform + Windows

Wins when a Windows tablet client, a .NET MAUI desktop, or a back-office surface is part of the same product (field service, clinical operations, lab equipment companion, retail point-of-sale). Adds the Windows / .NET track and the platform routing on top of the mobile work. Loses when there is no desktop surface to actually staff for — you will pay for ownership you never use.

Two single-platform pods — iOS pod + Android pod in parallel

Wins when both stores ship deep parallel features in the same quarter (HealthKit-only on iOS, foreground-service-only on Android, non-overlapping native depth) and the budget can fund two parallel tech leads. Loses on cost (USD 44K–58K/month combined), on shared-logic drift (two implementations of the same feature drift apart by sprint six unless someone enforces it), and on the temptation to "just add a small RN module to share the screen" that always ends in tears.

Mobile tech lead

Owns the platform call, the rejection runbook, the crash budget gate, the architecture decision records, the on-call schedule, and the hard authority to refuse a "small" platform-specific request that would burn the cross-platform layer. Reads both the iOS and Android repo on day one. Writes the platform-decision memo in week one of the engagement and updates it when the analytics earn a change.

Two to three mobile engineers (native + cross-platform)

The default split is one Swift specialist, one Kotlin specialist, and one cross-platform engineer (React Native or Flutter) on the parent app. The native specialists own HealthKit, BLE, ATT, secure enclave, foreground services, Wear OS, and the surfaces a polyfill cannot honestly cover. The cross-platform engineer owns navigation, shared business logic, the design system, and the deeplink graph. A third native or cross-platform seat joins the pod when a watch, CarPlay, or tablet surface earns it.

Dedicated QA automation engineer with device lab

Owns the device matrix, the release-blocking smoke suite (the one that catches the broken IAP receipt validation before a customer does), the regression suite on the device lab, the accessibility audit (Dynamic Type and VoiceOver on iOS, TalkBack and large-text on Android), the synthetic monitors that page on a real failed login, and the device-lab refresh once a quarter from the analytics. Without this seat, store rejections and one-star reviews are the QA process.

Part-time mobile DevOps / release engineer

Two to three days a week. Owns Fastlane lanes, signing certificates, Play upload keys, Apple App Signing for iOS and Play App Signing for Android, the CI matrix, the staged-rollout policy, the force-update mechanism, the kill-switch flag, and the runbook for an emergency Apple expedited review request. Carved out as a dedicated fractional seat rather than collapsed into the tech lead, because the tech lead's calendar gets eaten by platform calls when the release train hiccups.

Mobile-first product orgs

The app is the product. Web is a marketing site that the product team treats as a brochure rather than a surface. iOS and Android are 85 percent or more of revenue and engagement. The buyer wants a pod that thinks about the app as a system — release train, crash budget, store-listing experiments — rather than a series of feature tickets. The wrong move is a generic full-stack agency that ships a mobile screen and treats the rest as someone else's problem.

Fintech and neobank app teams

The app is the bank. Identity verification, biometric unlock, payment authorisation, real-time balance updates, push reliability through APNs and FCM, fraud signals from the device, ATT prompts that do not annihilate attribution. The buyer wants senior mobile engineers who have shipped a 5.1.1 privacy review and a 5.1.2 data-collection review on production builds, not engineers reading the policy for the first time during sprint one.

Marketplaces with heavy app usage

Two-sided marketplace where 65 to 80 percent of sessions arrive through the app: rideshare, on-demand delivery, used-goods, ticketing resale, gig labour. The buyer cares about cold-start time on the lowest-end Android device, deeplink reliability, push at scale (millions per hour during a campaign), and the regression suite that catches a checkout failure before the marketing team finds it on Twitter. The pod runs against business KPIs (orders placed, GMV, retention week 4), not feature throughput.

Healthcare and IoT companion apps

The app is the bridge between a regulated workflow and a hardware device. HealthKit and Health Connect, BLE pairing with chest straps, glucose monitors, hearables, weighing scales, smart locks, or matter-protocol gateways. Apple Watch and Wear OS companions for the moments the user does not have a phone in hand. The buyer wants senior mobile engineers comfortable with both stores' privacy nutrition labels and the small but unforgiving differences between BLE on iOS and BLE on Android.

Rescue an unstable mobile app

Crash-free sessions are below 98 percent, the App Store rating has slipped under 3.5, the last five releases all needed a hotfix in the first 48 hours, and the previous vendor handed back a build process that only one person on the team can run. The first three sprints produce a crash budget plan, a release pipeline the pod owns, a regression suite on the device lab, and a written rejection runbook. Feature work resumes only after the bleed stops — we have stopped buyers from approving feature roadmaps before the bleed actually stopped, more than once.

Modernise for iOS 18 and Android 15

The app still targets an old SDK, the privacy nutrition label is out of date, the data-safety form was last touched two years ago, photo picker has not been adopted, foreground services are not classified for Android 14, and the app will be flagged for an old target API level next cycle. Sprint zero produces the modernisation plan; the next four sprints retire the deprecations on the schedule the platform owners actually published, not the schedule the marketing team wishes existed.

Add Wear OS, watchOS, CarPlay, or Android Auto

The roadmap earns a wearable or in-vehicle surface. The pod requires a one-page brief before the work starts: what surface, what minimum viable feature, what data the surface reads or writes, what happens when the parent app is not installed, what the launch-week message is, and which engineer on the pod owns it. Watch and Wear OS surfaces stay native; CarPlay and Android Auto follow the driver-distraction templates we will not improvise around.

App Tracking Transparency / Privacy Manifest rebuild

SDK inventory, Required Reasons API report, IDFA flow rewrite, deferred-deeplink rebuild, Privacy Manifest authored as YAML, data-safety form regenerated from the same YAML, attribution dashboards calibrated against the pre-rebuild baseline so the marketing team learns the cost was real before the cost is invisible. The same pattern applies to the next privacy regulation; the rebuild is the rehearsal for the next one.

Store rejection cascading recovery

The app shipped, then got rejected on a 3.1.1 IAP guideline change. The team patched. It got rejected again on 5.1.1 privacy. The team patched. It got rejected on Play for Background Location and a marketing campaign launched without the app on Android. The pod arrives with a runbook, reads reviewer notes inside the first business hour, ships a second build off a pre-built release branch, and resubmits inside 24 hours when the policy fix is small enough.

Mobile-first redesign

The web team owns the brand and the apps inherited a five-year-old design system that no longer matches the marketing site. The pod runs the redesign as a four-sprint program: design tokens shared with the web team, a new shared component library on the parent app, a screenshot-test baseline for regression, a Product Page Optimization test on Apple and a Custom Store Listing test on Google, and a written stop-criterion for the test before the test launches.

Release-train cadence

Internal builds weekly on TestFlight and Play internal testing. Closed beta every two weeks (TestFlight external, Play closed track of 50–200 testers). Production submission on the agreed release window. Staged rollout on Play at 10 / 25 / 50 / 100 percent, phased release on App Store Connect over seven days. Pause the next stage if the crash budget breaks. Kill-switch flag and rollback build sit on the same release branch from the day the branch is cut.

Crash budget & on-call

Crash-free sessions above 99.5 percent on the latest two releases is the default budget. ANR rate under 0.5 percent on Play. p95 cold start on the lowest-end Android device under 2.0 seconds on the parent screen. The pod runs a 24/5 on-call rotation through major release windows and a written paging policy the rest of the time. We refuse to be paged on code we did not write or a release pipeline we do not own.

Device lab makeup

Last three iOS major versions plus the lowest-end Android device that produces 5 percent of sessions. Top eight Android OEMs by your install base (Samsung A-series and S-series at minimum), every iPad model your B2B users actually carry, real BLE / NFC handsets when the surface needs them. BrowserStack or Sauce Labs for the long tail; a small in-house rack for the surfaces emulators cannot honestly cover. Refresh once a quarter from the analytics, not from a vendor catalogue.

Store-rejection runbook

The runbook covers Apple's most-cited grounds (3.1.1 IAP, 4.0 design, 5.1.1 privacy, 5.1.2 data, 2.5.13 background modes) and Google's (Families Policy, Background Location, Permissions Declaration, Foreground Service classification on Android 14 and 15, Repetitive Content). On a rejection, the pod reads notes inside the first business hour, drafts the response same-day, ships the second build off a pre-built release branch, and resubmits inside 24 hours when the policy fix is small enough.

A/B store-listing tests

On Apple, Product Page Optimization tests up to three variants of the icon, screenshots, and promo text against a control. On Google, Custom Store Listings or Store Listing Experiments. The pod owns the full loop: hypothesis, asset production, store-listing draft, test launch, weekly readout, written stop criterion in the same git repo as the code, and the decision (keep, kill, or rerun) recorded next to the data. The most expensive store-listing tests we have inherited from prior vendors were the ones with no written stop criterion.

Onboarding (3 weeks to first deploy)

Discovery 3–5 days (read-only repo walk, analytics audit, device-matrix proposal, written platform-decision memo). Team assembly 5–10 days (paired technical sessions; tech-lead candidates run a live store-rejection review on an anonymised sample, not a coding kata). Sprint zero (week 2–3): CI access, signing certificates, store-account roles, TestFlight + Play internal tracks wired, Fastlane templates merged. Sprint one (week 3–4): first quick wins land — cold-start regression closed, weekly TestFlight building, data-safety form drafted from YAML.

Apple: Privacy Manifest density

Third-party SDK manifests and Required Reasons APIs are now part of every submission audit we run in sprint zero — UserDefaults, disk-space, system-boot-time, and active-keyboard patterns included when your analytics or crash SDK touches them. We author the manifest as YAML beside the build so the nutrition label, reviewer notes, and Play data-safety answers stay one edit away from each other.

Android: foreground services and back behaviour

Android 14 enforced foreground-service types; Android 15 tightened predictable-back and killed long-lived data-sync foreground services after six hours unless the work moved to WorkManager. Apps that "just wake the service" for marketing campaigns now fail review unless the classification matches how the code actually behaves.

Play: 16 KB page size for native binaries

If you ship NDK code — ML Kit, media codecs, legacy RN modules, OpenCV, anything with a .so — the November 2025 Play deadline for 16 KB pages forced rebuilds across toolchains we used to treat as "vendor homework". We schedule an ABI audit before we promise a date on those roadmaps.

Cross-platform: New Architecture hiring bar

Greenfield React Native work now assumes Fabric + TurboModules for modules we control; Flutter teams see heavier Impeller conversations on iOS for animation-heavy surfaces. Vetting screens for "RN fluency" without native readability checks stopped working in 2025 — we still pair Swift and Kotlin specialists into the pod for the bridges that cannot be faked.

Hiring senior mobile engineers in-house

Wins on long-term retention, deep domain ownership, and lower run-rate cost beyond year two. Loses on time-to-first-deploy (six to nine months in most US metros for a senior Swift or Kotlin hire), on the device-lab and Fastlane infrastructure that comes free with a pod, and on the bench depth that absorbs an unexpected resignation in week eight without slipping a release. Most of our pods sit alongside a small in-house mobile team that owns the long arc; we own the device lab and the rejection runbook.

Freelance crew assembled from marketplaces

Wins on hourly rate and on the speed of the first contract signature. Loses on the seven artefacts a mobile pod actually owns: nobody on a freelance crew owns the release pipeline, the rejection runbook, the device matrix, or the crash budget. The screens ship; the program does not. We have inherited two engagements where the freelance crew shipped twelve sprints of feature work and the pipeline was still owned by a single contractor on a personal AppleID.

Single-vendor mobile agency

Wins on speed of project setup and on the polished pitch deck. Loses when the agency's bench is shallow on the platform that earns the depth (most generalist agencies are deep on the platform their senior partner happens to know), when the engagement is structured as a fixed-bid project rather than a long-running pod, and when the rejection runbook is a Confluence page nobody updated since 2023. Pick an agency for a fixed-bid launch; pick a pod for the program after launch.

Two single-platform pods (iOS pod + Android pod)

Wins when both stores ship deep parallel features in the same quarter and the budget can absorb USD 44K–58K/month combined. Loses on shared-logic drift (two implementations of the same feature drift apart by sprint six unless someone enforces a shared backend contract and a shared design system) and on the meeting overhead of two tech leads, two QA seats, two Fastlane configurations, and two on-call rotations. Right answer for a few apps; expensive answer for most.

The buyer profile was a US personal-lines insurer (auto and home) selling direct-to-consumer; roughly nine in ten policyholder interactions ran through the mobile app only: digital ID cards in Apple Wallet and Google Wallet, photo-based first-notice-of-loss claims, a Bluetooth OBD-II dongle programme that fed telematics-based discounts, premium payments, renewal push, and a roadside-assistance flow that had to keep working when the user's data plan was throttled at the side of a highway.

The app had drifted. Crash-free sessions had dropped to 97.8 percent on Android over four quarters. The combined store rating slipped from 4.4 to 3.1 over the same window. The OBD-II BLE pairing flow was crashing about 1.6 percent of session starts. The marketing team had launched an ATT prompt rebuild that broke deferred-deeplink attribution and was rejected twice on Apple for 5.1.2 data-collection language. Play submitted a rejection on Background Location classification ahead of an Android 14 deadline. The internal team of one mobile engineer plus one full-stack engineer who shipped to mobile occasionally was burned out.

A six-seat Siblings mobile pod was placed alongside the internal engineer: a mobile tech lead, one Swift specialist, one Kotlin specialist, one cross-platform engineer on a React Native parent app the previous vendor had introduced, a dedicated QA automation engineer running the device lab, and a part-time mobile DevOps engineer two and a half days a week on Fastlane and the store accounts. Charter: stop the bleed in the first three sprints, then ship the ATT rebuild and the OBD-II BLE rewrite, then rebuild the Wallet pass pipeline so the renewal flow stopped relying on a one-off cron job.

Sprint zero produced the rejection runbook, a device matrix cut from real-user analytics (last three iOS, top eight Android OEMs, two specific Samsung A-series handsets that produced 6 percent of sessions and 19 percent of crashes), the Privacy Manifest authored as YAML, and a Fastlane configuration that took the release pipeline off the only laptop in the office that could ship a build. Sprint one through three closed the BLE pairing crash, rebuilt the ATT prompt and the deferred-deeplink path, and re-submitted under 5.1.2 with the new data-collection language. Sprints four through eight rewrote the OBD-II native bridge as a Swift/Kotlin TurboModule on the React Native parent. Sprints nine through twelve rebuilt the Wallet pass pipeline and shipped a Product Page Optimization test that lifted install-to-first-quote conversion by a measured percentage with a written stop criterion.

Headline numbers across the first twelve sprints. Crash-free sessions on Android 97.8 percent → 99.6 percent. Combined store rating 3.1 → 4.5 over six weeks after the first stable release. OBD-II pairing crash rate 1.6 percent → 0.04 percent. ATT consent re-presented with the rewritten copy and post-rebuild attribution within 4 percent of the pre-rebuild baseline (compared to a 38 percent loss in the first failed rebuild). Both stores cleared on first re-submission after the runbook was written. Cold start on the lowest-end Android device that produced five percent of sessions 4.6s → 1.8s. Engagement cost ~USD 31K/month for the six-seat pod across the twelve sprints; the internal engineer stayed and shipped against the ride-along feature roadmap throughout.

What we'd do differently next time: spend two extra discovery days on the deferred-deeplink test plan before any ATT prompt copy was rewritten. The first ATT rebuild the team inherited had been deployed on a Friday with no rollback path; the second one shipped on a Tuesday with a kill-switch flag on the new prompt and a rollback build queued on the release branch. The kill switch was used twice in the staged rollout. We would have caught the data-loss in the first rollout if the kill switch had existed when the prior vendor shipped.

Offline-first sync

The truck is on a dirt road, the cruise ship is twelve miles off the coast, the warehouse is a Faraday cage. Offline-first is not a flag on a fetch; it is a queue with conflict resolution, a write-ahead log, a backoff strategy, and a UI that shows the user which pieces of state are local and which are server-confirmed. Every mobile pod we ship has shipped at least one offline-first surface, because the alternative is a screen that lies to the user about whether their input was saved.

BLE companions and native bridges

BLE on iOS and BLE on Android are not the same surface, despite the marketing slides. State machines, background reconnection, GATT timeouts, peripheral pairing on Android 12+ permission changes, location-permission entanglement on Android 11 and below — these are senior-mobile-engineer-grade work. The native specialists on the pod own this. We have rebuilt three BLE companions in the last eighteen months that the previous vendor had built on a polyfill and then shipped a release that crashed on Samsung A14.

Push at scale, deeplinks for marketing

Push is not "send a notification". At scale (millions per hour during a campaign) it is APNs and FCM token rotation, silent push for state pre-fetch, deferred-deeplink reliability after the ATT rebuild, foreground service classification on Android 14 and 15 for the campaigns that need a wake, and notification-summary entitlements on iOS so the marketing message lands inside Focus mode rather than getting delayed for two hours. The pod owns the deliverability dashboard, not the marketing team.

Biometrics, secure enclave, and large media caches

Biometric unlock is platform-specific surface area. LocalAuthentication on iOS, BiometricPrompt on Android, fallback flows when the user has wiped face data, secure enclave key storage that survives a reinstall, and the small rules around Class 3 biometrics on Android that keep an authentication legal. Large media caches are platform-specific too: NSCache versus DiskLruCache, edge-cache strategies for low-end Android where 64 GB phones run out of space halfway through the year, and media eviction policies that do not nuke the user's offline downloads on a cold morning.

Build-pipeline drift between platforms

iOS releases on schedule, Android slips a sprint, then iOS slips. The mitigation is one Fastlane configuration that owns both lanes, one CI matrix that runs both on every PR, one release branch that holds the rollback build for both stores, and a mobile DevOps seat that refuses to let the iOS lane diverge from the Android lane in private. Cheap to enforce in week one; impossible to recover six sprints later.

Store rejection cascading delays

One rejection becomes three because the second build was rushed and the third build broke a different policy. Mitigation: written rejection runbook on standby in sprint zero, reviewer-notes drafted as YAML next to the build so the response is ready before the rejection arrives, a pre-built release branch waiting for hotfixes so the second build does not require a fresh commit on a Friday evening, and a cooldown rule that the second build is not submitted before the runbook entry has been written.

OS-version deprecations and target API churn

Target API levels move every year on Play. iOS deprecates a framework on a release we did not budget for. Mitigation: a quarterly modernisation review that reads the platform owners' published deprecation calendars (not the marketing schedule) and a written modernisation budget allocated as a constant percentage of every sprint rather than a one-off project. The buyers we have inherited from a prior vendor were the buyers who treated modernisation as optional.

Performance regression on low-end Android

The team tests on Pixel 7 and a 2024 iPhone Pro. The actual lowest-end device that earns the budget is a Samsung A14 with 4 GB RAM and a 64 GB partition that is two-thirds full. Mitigation: the device matrix carries the lowest-end device that produces 5 percent of sessions, the cold-start budget is measured on that device on every release, and the regression suite runs on a real handset in the device lab before the build leaves the closed beta. Without it, the one-star reviews on the lowest-end OEMs become the QA process.

Native dependency rot

The CocoaPods spec the previous vendor pinned in 2022 stops resolving. The Gradle plugin breaks on AGP 8. The React Native version is two majors behind and the New Architecture migration is now a quarter of work. Mitigation: a quarterly dependency review that produces a written upgrade plan, a fixed budget for keeping the parent app within one major of the current cross-platform release, and a rule that a sprint may not start if the build is broken on either platform's CI.

ATT and Privacy Manifest churn

App Tracking Transparency, the Required Reasons API, the Privacy Manifest, and Google data-safety classifications change cycle to cycle. Mitigation: the Privacy Manifest, the data-safety form, the privacy nutrition label, and the consent prompt all live as YAML in source so a single edit re-generates all four. The YAML is reviewed every minor release. The marketing team learns the cost of an attribution change before the change ships, not after.

Feature parity drift between stores

An iOS-only feature ships because HealthKit was easier than Health Connect; an Android-only feature ships because foreground services were easier than BackgroundTasks. Six months later the marketing site lists features that exist on one store and not the other. Mitigation: a written platform-parity log per release, a tech-lead veto on platform-specific feature work that does not have a written exception, and a quarterly review that closes the drift before the parity gap reaches the analyst report.

Wear / CarPlay / Android Auto scope creep

"We could just add a watch complication" is the most expensive sentence in mobile. Mitigation: a one-page written brief required for any wearable or in-vehicle surface, a tech-lead refusal until the brief is signed, a launch-week marketing message agreed before any code is cut, and the rule that watch and Wear OS surfaces are scheduled inside a release window, not inside a roadmap quarter.