I want to talk about the technical challenges behind multi-platform mobile apps that never make it into the pitch deck, because the sales version of "build once, run everywhere" is doing a lot of quiet lying. I've shipped both native and cross-platform apps, and the pain never shows up where the marketing promises it won't. It shows up in the 20% of the app that touches hardware, notifications, or anything platform-specific, and that 20% eats way more time than anyone budgets for.
If you're evaluating React Native, Flutter, or a fully native approach right now, this is the stuff I wish someone had told me before the second sprint blew past estimate.
The Shared Code Promise Breaks Down Fast
Cross-platform frameworks are genuinely great for UI and business logic. Where they get shaky is anything touching the OS layer directly — background tasks, permissions, push notifications, biometric auth, deep linking. You end up writing native modules anyway, just now you're maintaining a bridge on top of two platforms instead of two clean codebases.
A simple example. Push notification payloads aren't structured the same way on both platforms, so "shared" notification handling code usually ends up looking like this:
function handleNotificationPayload(payload) {
if (Platform.OS === 'ios') {
const alert = payload.aps?.alert;
return { title: alert?.title, body: alert?.body, data: payload.data };
} else {
return { title: payload.notification?.title, body: payload.notification?.body, data: payload.data };
}
}
That branch multiplies across the codebase the moment you touch anything OS-adjacent, and it's rarely a single clean abstraction — it's dead by a thousand if (Platform.OS === ...) checks.
Background Behavior Is Where Estimates Go to Die
iOS and Android handle background execution completely differently, and this is the single most underestimated line item in most mobile budgets. Android gives you more freedom but battery optimization settings across manufacturers (looking at you, certain Chinese OEMs) can silently kill your background service anyway. iOS is stricter by design — background fetch windows are short and unpredictable, and Apple can and will throttle you if your app behaves greedily.
If your app needs reliable background sync — location tracking, offline-first data, real-time updates — budget real time for this. Not "add a background task" time. Real testing-on-actual-devices-in-actual-low-power-mode time.
State Management Gets Messier With Native Modules in the Mix
Once you're bridging to native code for camera access, file storage, or biometrics, your state management story gets more complicated because native calls are async in ways JavaScript state doesn't always expect cleanly:
async function authenticateWithBiometrics() {
try {
const result = await NativeBiometrics.authenticate();
setAuthState(result.success ? 'authenticated' : 'failed');
} catch (err) {
// Native errors here are inconsistent between platforms —
// iOS throws different error codes than Android's exception types
setAuthState('error');
}
}
That error handling comment isn't a throwaway line. I've debugged production issues where an Android-specific exception type wasn't being caught the same way as its iOS equivalent, and the failure mode was silent — the button just stopped responding on one platform, with nothing in the logs pointing at why.
Where Teams Actually Need Help
This is usually the point where an internal team, especially one that started as a web team, realizes they're out of their depth on the native side. Bringing in a specialized mobile app development company at this stage isn't giving up on cross-platform, it's recognizing that the native module layer needs people who've hit these exact bugs before, not people learning them for the first time on your production timeline.
Platform-specific expertise matters more than the marketing around "one codebase" suggests. If your user base skews Android and spans a wide range of device manufacturers and OS versions, dedicated android app development services that actually test across that fragmentation, rather than just an emulator running the latest OS version, will catch problems your CI pipeline never will.
Testing Is Where the Real Cost Hides
Unit tests don't catch most of what actually breaks multi-platform apps in production. The real bugs show up on specific device and OS version combinations, under specific network conditions, with specific permission states. A test matrix that only covers your team's personal phones isn't a test matrix, it's a guess.
// This passes in every CI run and still fails on
// a real device with battery saver mode enabled
test('background sync triggers within 15 minutes', async () => {
const result = await triggerBackgroundSync();
expect(result.completed).toBe(true);
});
That test is lying to you about production reliability, and I've shipped code that passed exactly this kind of test and then failed silently on real devices within a week of launch.
Sequencing Platforms Instead of Building Both Blind
One thing I'd genuinely change if I could redo past projects: stop building both platforms simultaneously from day one. Ship one platform properly, learn what breaks in production, then apply those lessons to the second build instead of discovering the same class of bugs twice in parallel. If your primary users are on iPhones, working with a focused iOS app development company first, then porting hard-won lessons to Android, tends to produce a more stable result than splitting attention evenly from the start.
Budgeting for the Native Layer Honestly
Whatever mobile app development cost estimate you're working with, make sure it accounts for native module work explicitly as its own line item, not folded into "cross-platform development" as if it's the same effort as writing shared UI components. It isn't. The native bridge is where most multi-platform projects quietly overrun, and pretending otherwise in the estimate just moves the cost to later, angrier conversations.
If you're not sure how much of your feature set is going to need native modules versus pure shared code, get an honest read from a mobile app development agency before locking the estimate, not after the sprint that was supposed to take a week turns into three.
Multi-platform doesn't mean one codebase and one set of problems. It means one shared layer and two separate sets of platform-specific problems that both need real, dedicated attention — and the projects that go smoothly are the ones that budgeted for that honestly from the start.
Top comments (0)