Native App, Conceptually

Build the mental model

A native app is built specifically for one target mobile operating system, using that platform's own SDK, languages, and frameworks.

On Android that generally means Kotlin or Java on top of the Android SDK; on iOS it generally means Swift with SwiftUI or UIKit on top of the iOS SDK.

Conceptually, going native buys you a few real advantages. You get direct access to the platform's full API surface the moment it ships, with no framework layer waiting to catch up.

Integration with the platform's own ecosystem -- its widgets, notification system, background execution rules, and design conventions -- tends to feel native because it is native. Performance potential is generally at its ceiling, since there is no cross-platform abstraction layer translating your calls underneath.

The tradeoffs are just as real. Building for both Android and iOS natively usually means maintaining two separate codebases in two different languages, doubling the implementation and testing work for every feature.

It also demands platform-specific knowledge on the team: a Kotlin developer's skills do not transfer directly to Swift, and vice versa. Native is a strong choice when a product depends heavily on cutting-edge platform features or deep OS integration, and a harder sell when a small team needs to ship the same feature set on both platforms quickly.

Native App

An app built specifically for one target mobile operating system using that platform's own SDK and language -- Kotlin/Java on Android, Swift on iOS -- rather than a single shared cross-platform codebase.

NATIVE APP STACKS: ANDROID AND IOS, IN PARALLEL
-----------------------------------------------
ANDROID NATIVE
  Kotlin / Java
      |
      v
  Android SDK
      |
      v
  Android OS

IOS NATIVE
  Swift
      |
      v
  iOS SDK
      |
      v
  iOS

Connect it to a real scenario

When a stakeholder asks "should we go native," resist answering with a single yes or no. Instead ask three narrower questions and let the pattern of answers guide you.

• Does the app need a platform feature the moment it ships -- a new camera capability, a new widget type, a new background API -- rather than waiting for a cross-platform framework to catch up?
• Does the product depend on deep OS integration, such as a heavy background service, a complex home-screen widget, or tight system-level permissions?
• Does the team already have separate Android and iOS specialists, or would going native mean hiring or training for two stacks at once?

If most answers point toward "yes, and we have the skills," native is a strong fit. If the team is small, timelines are tight, and the feature set is mostly shared UI and business logic, that combination usually favors a cross-platform approach instead, which the next lesson covers.

Treat this as a fit check, not a verdict on which approach is better in general.

• A native app uses each platform's own SDK and language -- Kotlin/Java for Android, Swift for iOS.
• Native gives direct platform access and top performance potential, at the cost of two separate codebases.
• For hands-on native development, continue to the Android Development or iOS Development tutorial.

Try the working example

function isNativeAGoodFit(requirement) {
  const {
    needsLatestPlatformFeature = false,
    needsDeepOSIntegration = false,
    teamHasPlatformSpecificSkills = false,
  } = requirement;

  const signalsForNative = [
    needsLatestPlatformFeature,
    needsDeepOSIntegration,
    teamHasPlatformSpecificSkills,
  ].filter(Boolean).length;

  if (signalsForNative >= 2) {
    return {
      goNative: true,
      reason:
        "Multiple signals point to native: platform depth and/or team skills favor building on each OS's own SDK directly.",
    };
  }
  if (signalsForNative === 1 && teamHasPlatformSpecificSkills) {
    return {
      goNative: true,
      reason:
        "The team already has the platform-specific skills, which removes native's biggest practical cost.",
    };
  }
  return {
    goNative: false,
    reason:
      "Too few signals for native's extra cost to pay off -- a cross-platform approach is worth evaluating instead.",
  };
}

const cuttingEdgeCameraApp = isNativeAGoodFit({
  needsLatestPlatformFeature: true,
  needsDeepOSIntegration: true,
  teamHasPlatformSpecificSkills: false,
});

const smallStartupMvp = isNativeAGoodFit({
  needsLatestPlatformFeature: false,
  needsDeepOSIntegration: false,
  teamHasPlatformSpecificSkills: false,
});

const experiencedPlatformTeam = isNativeAGoodFit({
  needsLatestPlatformFeature: false,
  needsDeepOSIntegration: false,
  teamHasPlatformSpecificSkills: true,
});

console.log(`Cutting-edge camera app: goNative=${cuttingEdgeCameraApp.goNative} -- ${cuttingEdgeCameraApp.reason}`);
console.log(`Small startup MVP: goNative=${smallStartupMvp.goNative} -- ${smallStartupMvp.reason}`);
console.log(`Team with existing platform specialists: goNative=${experiencedPlatformTeam.goNative} -- ${experiencedPlatformTeam.reason}`);

Cutting-edge camera app: goNative=true -- Multiple signals point to native: platform depth and/or team skills favor building on each OS's own SDK directly.
Small startup MVP: goNative=false -- Too few signals for native's extra cost to pay off -- a cross-platform approach is worth evaluating instead.
Team with existing platform specialists: goNative=true -- The team already has the platform-specific skills, which removes native's biggest practical cost.

Wikipedia: Mobile app development — How Mobile Apps Work