Project: The Mobile Framework Selection Lab

Build the mental model

This project is the checkpoint for everything the Basic and Intermediate chapters built about choosing a mobile framework. Native vs. cross-platform explained the fundamental tradeoff between platform-specific code and a shared codebase. Android vs. iOS ecosystem showed how the two platforms differ in tooling, review process, and user expectations. Expo and React Native, and the fair comparison between Flutter and React Native, gave you two concrete cross-platform options and their real tradeoffs. The mobile framework decision guide tied all of that into a repeatable, need-flag-driven process instead of a gut feeling.

Native vs. cross-platform — the core tradeoff between one shared codebase and two platform-specific ones
Android vs. iOS ecosystem — how tooling, review process, and user expectations differ per platform
Expo and React Native — one concrete, fast-to-start cross-platform option
Flutter vs. React Native fair comparison — a second cross-platform option and its real tradeoffs
Mobile framework decision guide — the need-flag process that turns all of the above into a decision

Here you apply that process to four scenarios that never appeared in the earlier lessons: a simple internal company tool needed only on Android, a consumer social app that needs both platforms fast with a small team, an app needing deep native camera and AR integration, and a team already strong in React and TypeScript building a content app.

Scenario	Right approach category
Internal tool (Android only)	Native Android (Kotlin) — one platform means the cross-platform tradeoff never triggers.
Consumer social app (both platforms, small team, fast)	Cross-platform with Flutter or React Native — small team, tight timeline, two platforms.
Deep camera / AR integration	Native (or cross-platform + custom native modules) — hardware depth is a hard filter.
React/TypeScript team, content app	React Native — existing team skill transfers directly.

None of these scenarios has one single correct product name. The goal is to name the right approach category, such as native Android, cross-platform with Flutter or React Native, or a native-module deep dive, and justify it using the actual need-flags from the decision guide: platform count, team skill, timeline, and how deep the app must reach into device-specific APIs.

A wrong answer here ignores a hard constraint

A wrong answer here does not look like a bad app. It looks like reasoning that ignores a hard constraint, for example recommending a cross-platform framework for an app that needs low-level camera and AR APIs the frameworks do not expose well, or recommending separate native Android and iOS builds for a two-person team with three months and no iOS experience. The decision guide's flags exist precisely to catch cases like these before a team commits months of work to the wrong stack.

text

SCENARIO TO FRAMEWORK APPROACH MAP
----------------------------------
1. Internal tool, Android only
   -> Native Android (Kotlin)

2. Consumer social app, both platforms, small team, fast
   -> Cross-platform (Flutter or React Native)

3. App needs deep camera / AR hardware access
   -> Native (or cross-platform + custom native modules)

4. Team strong in React/TypeScript, content app
   -> React Native (existing skill transfers)

Connect it to a real scenario

Scenario 1 — Internal tool, Android only

Platform count is one, so the cross-platform tradeoff never activates. Plain native Android with Kotlin is the simplest true answer, since there is no second platform to share code with.

Scenario 2 — Consumer social app, small team, tight timeline

Platform count is two, team size is small, and timeline is tight. Those flags together point straight at a cross-platform framework such as Flutter or React Native, whichever the team already knows.

Scenario 3 — Deep native camera/AR integration

This flag overrides the platform-count and timeline flags from the decision guide. Deep hardware access is a hard filter, not a preference, so native development, or a cross-platform app with substantial native modules, becomes the only safe choice even if it costs more time.

Scenario 4 — React/TypeScript team, content app

Existing team skill is the deciding flag here. React Native lets that skill transfer directly, avoiding months of learning a new language just to hit two platforms.

Run and compare

Run the recommendation function across all four scenarios and compare its output to your own reasoning before reading the justification it prints.

A mobile framework decision is a category choice (native, cross-platform, or native-module hybrid), not a single mandated product.
Hard filters like deep hardware access override preference-level flags like timeline or team size.
Existing team skill in React/TypeScript is itself a legitimate deciding flag, not just a bonus.

Try the working example

javascript

function selectMobileApproach(scenario) {
  if (scenario.needsDeepHardwareAccess) {
    return {
      scenario: scenario.name,
      approach: "Native development (or cross-platform + custom native modules)",
      justification:
        "Deep camera/AR hardware access is a hard filter in the decision guide - cross-platform frameworks expose these APIs poorly or not at all, so native code wins even at higher cost."
    };
  }

  if (scenario.platformCount === 1) {
    return {
      scenario: scenario.name,
      approach: "Native Android (Kotlin)",
      justification:
        "With only one target platform, the cross-platform tradeoff never activates - there is no second codebase to share, so plain native is the simplest true answer."
    };
  }

  if (scenario.existingSkill === "react") {
    return {
      scenario: scenario.name,
      approach: "React Native",
      justification:
        "The team's existing React/TypeScript skill transfers directly, avoiding months learning a new language just to reach two platforms."
    };
  }

  if (scenario.teamSize === "small" && scenario.timeline === "tight") {
    return {
      scenario: scenario.name,
      approach: "Cross-platform (Flutter or React Native)",
      justification:
        "A small team on a tight timeline needing both platforms cannot afford two parallel native codebases - a shared cross-platform codebase is the only way to hit the deadline."
    };
  }

  return {
    scenario: scenario.name,
    approach: "Native per platform (Kotlin + Swift)",
    justification:
      "No hard filter applies and the team has capacity, so dedicated native codebases give the best long-term platform fit."
  };
}

const scenarios = [
  {
    name: "Internal company tool",
    platformCount: 1,
    teamSize: "small",
    timeline: "flexible",
    needsDeepHardwareAccess: false,
    existingSkill: "none"
  },
  {
    name: "Consumer social app (both platforms, small team, fast)",
    platformCount: 2,
    teamSize: "small",
    timeline: "tight",
    needsDeepHardwareAccess: false,
    existingSkill: "none"
  },
  {
    name: "App needing deep native camera/AR integration",
    platformCount: 2,
    teamSize: "small",
    timeline: "flexible",
    needsDeepHardwareAccess: true,
    existingSkill: "none"
  },
  {
    name: "Content app, team strong in React/TypeScript",
    platformCount: 2,
    teamSize: "small",
    timeline: "flexible",
    needsDeepHardwareAccess: false,
    existingSkill: "react"
  }
];

scenarios.map(selectMobileApproach).forEach((result) => {
  console.log(`${result.scenario}\n  -> ${result.approach}\n  (${result.justification})\n`);
});

You should see

Running selectMobileApproach across all four scenarios prints: the internal tool maps to "Native Android (Kotlin)", the consumer social app maps to "Cross-platform (Flutter or React Native)", the camera/AR app maps to "Native development (or cross-platform + custom native modules)", and the React/TypeScript team's content app maps to "React Native" — each with the one-line justification shown above.

5-minute try-it

Write a fifth scenario of your own — for example, a two-week hackathon prototype with no existing team framework experience — and run it through selectMobileApproach. If none of the existing branches fit cleanly, extend the function with one more need-flag check and justify the new branch in one sentence, the same way the existing branches do.

One important caution

Naming a specific product (e.g. "use Flutter") without listing which need-flags — platform count, hardware depth, team skill, timeline — actually drove that choice.

Treating a hard filter like deep camera/AR access as just one more factor to weigh, instead of a constraint that overrides everything else.

React Native — Architecture Overview — How Mobile Apps Work