Build the mental model
The previous two lessons introduced native and cross-platform apps separately. This lesson puts them side by side across nine dimensions that actually matter in practice.
The comparison table below folds each dimension into one honest sentence rather than a scorecard with a winner circled.
| Dimension | How They Compare |
|---|---|
| Code sharing | Native keeps separate codebases per platform; cross-platform shares one codebase, usually 80-95% of it, with a smaller platform-specific slice. |
| Performance | Native sits at the platform's performance ceiling with no abstraction layer; cross-platform is very close for most apps, with a small gap mainly in graphics-heavy or highly animated work. |
| Development speed | Cross-platform is typically faster to build and ship for two platforms at once; native requires building and testing the same feature twice. |
| Platform API access | Native gets new platform APIs the moment they ship; cross-platform frameworks usually add support soon after, sometimes with a temporary gap or plugin workaround. |
| UI behavior / fidelity | Native UI automatically matches each platform's own look and feel; cross-platform UI can match closely but sometimes needs manual tuning to feel fully native on both. |
| Team skills required | Native needs separate Kotlin/Java and Swift expertise; cross-platform needs one language (Dart for Flutter, JavaScript/TypeScript for React Native) shared across both targets. |
| Long-term maintenance | Native means maintaining two codebases indefinitely; cross-platform means maintaining mostly one, plus a smaller platform-specific layer on each side. |
| Native integrations | Native has the most direct path to deep, cutting-edge OS integrations; cross-platform can reach most integrations through native modules/platform channels, with more setup. |
| App complexity | Simple, mostly-UI apps rarely show a meaningful difference either way; highly complex, hardware-heavy apps are where the native-vs-cross-platform gap tends to matter most. |
The single most important habit for this lesson is refusing to let any of these dimensions collapse into a blanket claim like "native is always better" or "cross-platform is always better." Both claims are false as general statements, because each dimension pulls in a different direction depending on the specific product.
A banking app with heavy security requirements and deep OS integration leans native. A content-driven app for a two-person team on a tight budget leans cross-platform.
The decision framing that actually works moves through four questions in order: what does the product genuinely require, what skills does the team already have, how deep do the native integrations need to be, and how much long-term maintenance capacity exists for two codebases versus one. Only after walking through all four does a real choice emerge -- and it can legitimately be different for two apps that look similar on the surface but differ on team or maintenance capacity.
THE DECISION FRAMING (NOT A VERDICT)
------------------------------------
REQUIREMENTS
|
v
TEAM SKILLS
|
v
NATIVE INTEGRATION NEEDS
|
v
MAINTENANCE CAPACITY
|
v
CHOICE (native or cross-platform, per product)Connect it to a real scenario
Run the four-step decision framing as an actual exercise the next time a "native or cross-platform" question comes up, instead of debating it in the abstract.
Requirements first
Write down the product's genuine requirements first, before anyone in the room states a preference -- preferences tend to anchor on whichever technology someone already knows.
Actual team skills
List the team's actual current skills, not the skills you hope to hire for.
Rate integration depth
Rate how deep the native-integration needs really are, from "standard UI and network calls" to "background services, custom hardware, or bleeding-edge platform features."
Be honest about maintenance
Decide whether this team can realistically keep two native codebases healthy for years, or whether one shared codebase is the only sustainable option.
Only after all four are written down should the group compare notes. Most teams find the decision becomes close to obvious once biases are separated from requirements. When it still is not obvious, that itself is useful information: it usually means the product genuinely sits in a gray zone, and either choice can work if the team commits to it.
Try the working example
function suggestStartingApproach(team) {
const {
hasNativeSkills = false,
needsHeavyDeviceIntegration = false,
prioritizesDevSpeed = false,
smallTeam = false,
} = team;
let nativeScore = 0;
nativeScore += hasNativeSkills ? 2 : -1;
nativeScore += needsHeavyDeviceIntegration ? 2 : 0;
nativeScore += prioritizesDevSpeed ? -2 : 0;
nativeScore += smallTeam ? -1 : 0;
const suggestion = nativeScore > 0 ? "native" : "cross-platform";
return {
suggestion,
disclaimer:
"A starting point only, not an absolute rule -- re-check this against the four-question decision framing before committing.",
nativeScore,
};
}
const largeTeamHeavyIntegration = suggestStartingApproach({
hasNativeSkills: true,
needsHeavyDeviceIntegration: true,
prioritizesDevSpeed: false,
smallTeam: false,
});
const twoPersonStartup = suggestStartingApproach({
hasNativeSkills: false,
needsHeavyDeviceIntegration: false,
prioritizesDevSpeed: true,
smallTeam: true,
});
const mixedSignalTeam = suggestStartingApproach({
hasNativeSkills: true,
needsHeavyDeviceIntegration: false,
prioritizesDevSpeed: true,
smallTeam: true,
});
console.log(`Large team, heavy device integration: ${largeTeamHeavyIntegration.suggestion} (score ${largeTeamHeavyIntegration.nativeScore})`);
console.log(`Two-person startup, dev speed matters most: ${twoPersonStartup.suggestion} (score ${twoPersonStartup.nativeScore})`);
console.log(`Mixed signals -- native skills but small and speed-focused: ${mixedSignalTeam.suggestion} (score ${mixedSignalTeam.nativeScore})`);Large team, heavy device integration: native (score 4)
Two-person startup, dev speed matters most: cross-platform (score -4)
Mixed signals -- native skills but small and speed-focused: cross-platform (score -1)5-minute try-it
Run suggestStartingApproach for your own team's actual situation. Then flip just the smallTeam flag and see how much that single input changes the nativeScore.
One important caution
Declaring one approach universally superior instead of re-running the decision framing for each new product.
Letting whichever technology a senior engineer already knows silently decide the outcome, instead of writing requirements down first.
Native or Cross-Platform: Absolute Claims?
Wikipedia: Mobile app development — How Mobile Apps Work