Building for iOS, Android, and Tablet from One Codebase

Key facts, with sources

• In the Stack Overflow 2024 Developer Survey, Flutter was used by 9.4% of developers versus React Native's 8.4%, and among professional developers the gap nearly vanishes at 9.21% versus 9.14%. (Nomtek (citing Stack Overflow Developer Survey))
• Among developers who build cross-platform, Statista-based figures put Flutter at about 46% adoption versus 35% for React Native, with the two frameworks together dominating the cross-platform market. (Tech-Insider)
• Instagram shares 85 to 99% of its code between iOS and Android using React Native, and Shopify reports 86% unified code across its app portfolio. (CatDoes)
• According to Flutter.dev data, nearly 30% of new free iOS apps submitted to the App Store in 2025 were built with Flutter, up from roughly 10% in 2021. (Droids on Roids (citing Flutter.dev))
• The official React Native showcase lists production apps from Meta, Microsoft, Shopify, and Amazon, including desktop targets like Messenger Desktop and Microsoft apps on Windows and macOS. (React Native Showcase)

Think in size classes, not devices

The foundational mistake is branching on 'is this a tablet'. Devices no longer sort cleanly: big phones, small tablets, foldables, iPad split view where your 'tablet' app suddenly gets a phone-width window, and Android multi-window doing the same. Device checks answer the wrong question.

Instead I branch on the current window width, bucketed into a few named classes — compact, medium, expanded — mirroring how both Apple and Google frame adaptive design. Every layout decision keys off the class of the window right now, which automatically handles rotation, split-screen, and foldables posture changes, because useWindowDimensions re-renders on every change. The entire mechanism is a small hook, and the discipline is that no component anywhere reads Dimensions directly or checks the device model.

import { useWindowDimensions } from 'react-native';

export type LayoutClass = 'compact' | 'medium' | 'expanded';

export function useLayoutClass(): LayoutClass {
  const { width } = useWindowDimensions();
  if (width >= 900) return 'expanded';
  if (width >= 600) return 'medium';
  return 'compact';
}

// Usage: reflows automatically on rotation, split view, and foldables.
// const layout = useLayoutClass();
// return layout === 'expanded' ? <SplitInbox /> : <StackedInbox />;

Adaptive navigation: the biggest visible win

Nothing says 'phone app stretched to a tablet' like a bottom tab bar spanning a thirteen-inch screen. The adaptation users expect: bottom tabs on compact widths become a sidebar or navigation rail on expanded widths, and stack-based drill-down flows become master-detail split views — list on the left, detail on the right.

With React Navigation this means driving the navigator structure from the layout class: conditionally rendering a tab navigator or a custom sidebar shell, and for master-detail, rendering the detail screen inline on wide layouts instead of pushing it. The subtle part is state preservation across class changes — rotating a tablet must not lose the user's place. I keep the selected-item state in a store outside the navigators so both layout modes read the same source of truth, and the transition between them is just a re-render, not a navigation reset.

Layouts that reflow instead of stretch

Full-width list rows and forms that look right on a phone become absurd at tablet widths. Three patterns cover most screens. Constrained content: forms, articles, and settings get a maxWidth (typically around 600 points) and center themselves, rather than stretching inputs edge to edge. Reflowing grids: card lists compute their column count from window width — floor the width by a minimum card width — so phones get one column and tablets get two or three without any device logic. Progressive disclosure: metadata hidden behind taps on phones can display inline on wide layouts.

The anti-pattern to avoid is scaling — multiplying font sizes and paddings by screen width so the phone UI simply zooms. It photographs well in demos and feels wrong in use; tablet users expect more content, not bigger content. Fixed type scale, generous whitespace, more columns.

Platform obligations: rotation, multitasking, and inputs

Tablet support carries platform-specific obligations that phone-only apps skip. On iPad, App Review expects proper behavior across orientations and multitasking modes — an app claiming iPad support but breaking in split view is a rejection risk, and supporting all four orientations is the standard expectation. On Android, multi-window and foldables mean your activity can be resized at any moment, which window-driven layouts handle automatically but any cached dimension breaks.

Tablets also bring input diversity: external keyboards and pointers are common on iPads and Android tablets. At minimum, verify that focus order is sane, that your primary flows work with a keyboard attached, and that nothing traps hover states incorrectly. None of this is exotic work, but it must be scheduled — I estimate roughly a fifth of the original build effort to take a phone-designed app to genuinely good tablet support, mostly in navigation and the top ten screens.

A test matrix that catches tablet regressions

Tablet layouts rot fast when nobody looks at them, because developers live on phone simulators. My minimum matrix: one small phone, one large phone, one small tablet portrait, one large tablet landscape, plus iPad split view at one-third and two-thirds widths and one Android foldable profile. Component-level screenshot tests render key screens at those fixed window sizes on every pull request — cheap to run, and they catch the classic regression where a phone-focused change breaks the expanded layout.

For manual passes, rotation during every core flow and a split-view drag while a form is half-filled find most state-loss bugs. I also add a CI check that any file importing the breakpoint hook has a corresponding wide-layout screenshot test; it is a blunt instrument, but it keeps tablet support from becoming the codebase's unwatched corner again.

When to hire senior help

The framework decision is a one-way door worth a short senior consultation, because switching stacks after a year of development is effectively a rewrite. A senior cross-platform engineer can also audit whether your planned feature set has hidden native-heavy corners, like payments hardware or background location, that change the cost math before you commit. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Cross Platform Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Picking the framework by hype rather than team composition, such as a React web team adopting Flutter and forfeiting years of transferable JavaScript expertise
• ✕Budgeting for 100% code reuse and zero platform-specific time, then discovering payments, background tasks, and widgets all require per-platform native work
• ✕Recreating navigation and interaction patterns generically so iOS swipe-back gestures and Android back-button behavior both feel wrong to native users
• ✕Ignoring the maintenance tail: never budgeting for framework major-version upgrades, so the app rots on an unsupported runtime within two years

Frequently asked questions

Sources

• Nomtek (citing Stack Overflow Developer Survey)
• Tech-Insider
• CatDoes
• Droids on Roids (citing Flutter.dev)
• React Native Showcase