The Mobile Framework Decision Guide

Build the mental model

Every lesson so far has looked at one piece of the mobile framework decision. This lesson pulls those pieces into a single decision guide — not a strict formula, but a starting point.

Q1: Platforms

Android-only or iOS-only means native or cross-platform are both reasonable; needing both platforms makes cross-platform much more attractive.

Q2: Native Feature Depth

Apps leaning heavily on cutting-edge, platform-exclusive capabilities may benefit from native development's more direct access.

Q3: Team Size and Skills

A small team benefits from a shared codebase; React/TypeScript skill points toward React Native/Expo, Dart skill points toward Flutter.

Q4: Timeline

Needing the fastest possible working prototype points directly toward Expo's managed tooling.

Not an absolute rule

Real projects weigh several factors together, and reasonable teams can reach different answers from the exact same requirements.

text

MOBILE FRAMEWORK DECISION TREE (CONDENSED)
------------------------------------------
MOBILE FRAMEWORK DECISION TREE (CONDENSED)
-----
Q1: Which platforms are needed?
    Android only -> native Android OR cross-platform
    iOS only     -> native iOS OR cross-platform
    Both         -> continue to Q2 (cross-platform gets stronger)

Q2: Heavy platform-specific native features needed?
    Yes + large team -> native per platform often simpler
    No / small team  -> continue to Q3

Q3: What does the team already know well?
    React / TypeScript -> React Native or Expo
    Dart                -> Flutter
    Neither             -> continue to Q4

Q4: Need the fastest possible working prototype?
    Yes -> Expo-managed workflow
    No  -> evaluate Flutter and React Native directly

Connect it to a real scenario

Consider a concrete example: a five-person startup team building a habit-tracking app that needs both Android and iOS within three months, knowing React/TypeScript well but never shipping a native mobile app.

Check platform requirements

Both platforms are needed, so cross-platform is worth evaluating over two separate native codebases.

Factor in team size

The team is small, so a shared codebase significantly reduces duplicated work.

Look at existing skills

Already knowing React and TypeScript points toward React Native.

Weigh the timeline

The tight timeline and unfamiliarity with native tooling point further toward Expo's managed workflow.

This team's reasonable starting point is Expo-managed React Native — not because it's universally correct, but because it matches this team's platforms, size, skills, and timeline.

The decision guide is a starting point for reasoning, not a strict formula
Platforms, native feature depth, team size/skills, and timeline should be weighed together
Reasonable teams can reach different, equally valid decisions from the same requirements

Try the working example

javascript

function recommendMobileApproach(needs) {
  const { platforms, needsHeavyNativeFeatures, teamSkill, teamSize, needsFastestPrototype } = needs;

  if (platforms !== "both" && needsHeavyNativeFeatures) {
    return `Native ${platforms === "android" ? "Android" : "iOS"} development (single platform + heavy native features)`;
  }
  if (needsHeavyNativeFeatures && teamSize === "large") {
    return "Native development per platform (heavy native feature needs, team large enough to support two codebases)";
  }
  if (needsFastestPrototype) {
    return "Expo-managed React Native (fastest path to a working cross-platform prototype)";
  }
  if (teamSkill === "dart") {
    return "Flutter (team already comfortable with Dart)";
  }
  if (teamSkill === "react") {
    return "React Native or Expo (team already comfortable with React/TypeScript)";
  }
  if (platforms === "both" && teamSize === "small") {
    return "Cross-platform framework (small team, both platforms — shared codebase reduces duplication)";
  }
  return "Evaluate both native and cross-platform options against project requirements";
}

const habitTrackerStartup = {
  platforms: "both",
  needsHeavyNativeFeatures: false,
  teamSkill: "react",
  teamSize: "small",
  needsFastestPrototype: true
};

const arNavigationApp = {
  platforms: "ios",
  needsHeavyNativeFeatures: true,
  teamSkill: "none",
  teamSize: "small",
  needsFastestPrototype: false
};

const enterpriseDartShop = {
  platforms: "both",
  needsHeavyNativeFeatures: false,
  teamSkill: "dart",
  teamSize: "large",
  needsFastestPrototype: false
};

const largeHardwareIntegrator = {
  platforms: "both",
  needsHeavyNativeFeatures: true,
  teamSkill: "none",
  teamSize: "large",
  needsFastestPrototype: false
};

console.log("Habit-tracker startup:", recommendMobileApproach(habitTrackerStartup));
console.log("AR navigation app:", recommendMobileApproach(arNavigationApp));
console.log("Enterprise Dart shop:", recommendMobileApproach(enterpriseDartShop));
console.log("Large hardware integrator:", recommendMobileApproach(largeHardwareIntegrator));

You should see

Habit-tracker startup: Expo-managed React Native (fastest path to a working cross-platform prototype)
AR navigation app: Native iOS development (single platform + heavy native features)
Enterprise Dart shop: Flutter (team already comfortable with Dart)
Large hardware integrator: Native development per platform (heavy native feature needs, team large enough to support two codebases)

Notice the function returns four different recommendations depending on team skill, size, and timeline — none of them is a universal winner.

5-minute try-it

Model your own current project (or a hypothetical one) as a `needs` object and run it through `recommendMobileApproach` — then argue with the result: does the reasoning actually fit your specific situation, or would you weigh a factor differently?

One important caution

Treating the decision guide as an absolute lookup table and ignoring context-specific factors

Looking at only one factor (like team skill) while ignoring platforms, timeline, and native feature depth

Cross-platform software — Wikipedia — How Mobile Apps Work