Tech & AI, Explained

mobile-development-overview

13 min read

Mobile development — overview

Status: 🟩 COMPLETE (🟦 LIVING — the mobile landscape shifts annually) Last updated: 2026-06-19 Plain-English tagline: Two operating systems (iOS, Android) dominate the world’s pockets. Three main ways to build for them: native (best UX, two codebases), cross-platform (one codebase, near-native UX), or web (PWA — one codebase, capped UX).

In plain English

You have an iPhone. Someone else has an Android. You both download apps from your respective stores. The apps look mostly the same, work the same way. How does that happen — and why are some apps available on one platform but not the other?

The world of mobile apps is two platforms:

  • iOS — Apple’s, runs on iPhones + iPads. Built with Swift (or older Objective-C). Apps distributed via Apple’s App Store. Strict review process.
  • Android — Google’s, runs on Samsung, Pixel, Xiaomi, OnePlus, Motorola, hundreds of others. Built with Kotlin (or older Java). Apps distributed via Google Play (and some side-loaded).

Building for BOTH is the challenge. Three main strategies:

  1. Native — write the iOS version in Swift + the Android version in Kotlin. Two codebases. Best UX. Most expensive to build + maintain.
  2. Cross-platform — write once in a meta-framework (React Native, Flutter, Expo, .NET MAUI), which compiles or runs on both. ONE codebase. Near-native UX with some constraints.
  3. Web / PWA — write a web app; users add to home screen. ONE codebase (shared with web). Lowest cost. Limited access to device features.

For Bible Quest-style work: George’s project is a web app. Users can install it as a PWA on iOS or Android — gets a home-screen icon, runs in a window without browser chrome. For most purposes, indistinguishable from a “real” app. See PWA.

If you wanted full native features (push notifications without limits, background processing, camera with custom UI, biometric auth at the OS level, App Store presence), you’d reach for one of the other two approaches.

This entry maps the mobile landscape — what you’d choose, when, why.

Why it matters

Three reasons even a non-coder benefits from understanding mobile:

  1. Mobile is most of the internet now. 60%+ of web traffic. Designing without thinking about mobile (or worse: assuming desktop is primary) is increasingly out of step.

  2. The strategic choice is real. Building a webapp, a native app, or a cross-platform app — each is a major commitment. Knowing the trade-offs matters before starting.

  3. AI tools’ UX often differs on mobile. Claude Code is desktop-first. Reading code on a phone is suboptimal. Knowing this is just useful awareness.

The trade-off: full mobile dev is its own discipline. This entry is the conceptual map; if you actually build native mobile, you’ll need deeper resources.

The three paths in depth

Path 1: Native (Swift + Kotlin)

You write two apps. Each runs in its OS’s primary language + framework:

PlatformLanguageUI framework
iOSSwiftSwiftUI (modern) or UIKit (legacy)
AndroidKotlinJetpack Compose (modern) or XML layouts (legacy)

Tools:

  • iOS: Xcode (Mac-only)
  • Android: Android Studio (cross-platform)

Advantages:

  • Best possible UX — exactly matches platform conventions
  • Full access to device APIs (camera, sensors, file system, biometrics)
  • Best performance — animations + heavy compute work natively
  • Smaller app size + memory footprint typically
  • Latest platform features available immediately

Disadvantages:

  • TWO codebases to maintain
  • Need iOS + Android developers (or one person who knows both)
  • Releases need to go through App Store review (1-7 days)
  • Mac required for iOS development
  • Hardest path for solo developers

When to choose:

  • The app’s UX is its competitive advantage
  • Heavy use of device features
  • Performance-critical (games, AR, real-time editing)
  • You have the budget for two codebases

Path 2: Cross-platform (React Native, Flutter, etc.)

You write one codebase that runs on both platforms (and sometimes web + desktop too).

The major frameworks:

FrameworkLanguageStyleOwner
React NativeJavaScript / TypeScriptRenders to native componentsMeta
ExpoJavaScript / TypeScriptReact Native + tooling + managed cloud buildExpo (company)
FlutterDartRenders own UI engineGoogle
.NET MAUIC#Renders to native componentsMicrosoft
CapacitorAny web techWraps a webviewIonic

React Native + Expo is the dominant choice for JavaScript developers in 2026. If you know React for web, you can build mobile apps without learning a new language.

Flutter has a passionate following — uses Dart (Google’s language) but produces beautiful UIs with custom rendering. Strong for “we want our app to look identical on iOS and Android” use cases.

Advantages:

  • Single codebase (~80-90% shared between platforms)
  • Faster development than two native apps
  • Same developer skills as web (for React Native)
  • Hot reload during development

Disadvantages:

  • UX has some constraints — feels almost native but not quite for specific platform conventions
  • Less direct access to platform APIs (need bridges)
  • Performance gap with native (small but present)
  • New OS features can take weeks-months to be supported

When to choose:

  • Multi-platform from day one (iOS + Android + web in some cases)
  • JavaScript-heavy team
  • Budget for one codebase, not two
  • Standard app shape (lists, forms, navigation, basic media)

For Expo specifically: the smoothest path for React developers. Includes managed cloud builds, OTA updates, push notifications, distribution via App Store and Play Store. Used by many production apps.

Path 3: Web / PWA

Build a web app. Use it through the browser. Optionally let users “Add to Home Screen” so it appears like an installed app.

Advantages:

  • Single codebase shared with web
  • No App Store review process
  • Instant updates (no waiting for users to update)
  • Lowest cost
  • No store fees
  • Bible Quest-style flexibility

Disadvantages:

  • Limited access to device APIs (no biometrics on iOS, no full background, limited push notifications on iOS)
  • Users may not realize they CAN install
  • App Store presence is missing (some users only discover apps via stores)
  • iOS specifically has historically restricted PWAs more than Android

When to choose:

  • Content-oriented or reading-focused apps
  • Tools that work fine in a browser
  • Solo developer / minimal team
  • Don’t need App Store discovery
  • Iteration speed matters

For Bible Quest, the PWA path is right. Users can install it; works offline (with service workers); looks like an app. Without the App Store overhead.

See PWA for the technical implementation.

A concrete example: building a “mark this verse as read” feature

The same feature in three approaches:

Native iOS (Swift)

import SwiftUI
 
struct VerseRow: View {
  let verse: Verse
  @State var isRead: Bool = false
 
  var body: some View {
    HStack {
      Text(verse.text)
      Spacer()
      Image(systemName: isRead ? "checkmark.circle.fill" : "circle")
        .onTapGesture {
          isRead.toggle()
          saveToCoreData(verse, isRead)
        }
    }
  }
}

React Native (Expo)

import { View, Text, Pressable } from "react-native";
import { useState } from "react";
import { Ionicons } from "@expo/vector-icons";
 
export function VerseRow({ verse }) {
  const [isRead, setIsRead] = useState(false);
  return (
    <Pressable
      style={{ flexDirection: "row", alignItems: "center" }}
      onPress={() => {
        setIsRead(!isRead);
        saveToSupabase(verse.id, !isRead);
      }}
    >
      <Text>{verse.text}</Text>
      <Ionicons name={isRead ? "checkmark-circle" : "ellipse-outline"} />
    </Pressable>
  );
}

Web / PWA (Next.js + Tailwind)

"use client";
import { useState } from "react";
import { Check, Circle } from "lucide-react";
 
export function VerseRow({ verse }) {
  const [isRead, setIsRead] = useState(false);
  return (
    <button
      className="flex items-center w-full justify-between"
      onClick={async () => {
        setIsRead(!isRead);
        await markVerseRead(verse.id, !isRead);
      }}
    >
      <span>{verse.text}</span>
      {isRead ? <Check /> : <Circle />}
    </button>
  );
}

All three are similar in spirit. The native is more verbose (Swift conventions); the React Native is between; the web version is shortest. The native has direct access to native iOS features (haptics, etc.); the others access them through bridges or polyfills.

For most app needs, all three deliver an acceptable UX. The differences accumulate at the margins.

App Store vs Play Store — the distribution gatekeepers

If you build a native or cross-platform app, you submit it to:

Apple App Store

  • $99/year developer account
  • App must pass App Store review (1-7 days typical)
  • Apple takes 15-30% of in-app purchases / subscriptions
  • Strict guidelines on UI, content, monetization
  • Pre-built apps (PWAs that haven’t gone through review) can’t be in the store

Google Play Store

  • $25 one-time developer account
  • More lenient review process (often hours)
  • 15-30% revenue share (same as Apple)
  • More flexibility on content + monetization
  • Allows side-loading (users can install APKs directly)

Web apps + PWAs bypass both. Users install via “Add to Home Screen.”

For Bible Quest: not in any store. Users visit the URL, optionally install as PWA. Zero distribution friction; zero store presence.

The “marketing problem” for PWAs

The honest downside of PWA-only strategy:

  • Users SEARCH the App Store / Play Store for new apps. PWAs aren’t there.
  • Users don’t always know they CAN install a PWA.
  • Adding to home screen on iOS especially is a 3-step process that most users don’t discover.

For known users coming to a known URL, this is fine. For broad discovery, the App Store presence matters.

Mitigations:

  • Promote PWA installation explicitly on first visit
  • Use Web Share API to leverage native share menus
  • Get organic search traffic (SEO)
  • Add to TWA (Trusted Web Activity) — wraps a PWA as an Android app for Play Store

Apple has been slowly improving PWA support on iOS but historically restricts it more than Android.

React Native vs Flutter — the cross-platform decision

If you’re going cross-platform, the choice is usually React Native vs Flutter:

AspectReact NativeFlutter
LanguageJavaScript / TypeScriptDart
UI renderingNative components (UIKit, Android Views)Own engine (Skia)
Look + feelPlatform-native (iOS feels like iOS)Identical on all platforms
Web supportVia React Native Web (good but rough)Stable but heavy bundle
Community / ecosystemLarger, more librariesGrowing fast
Hot reloadYesYes (some say Flutter’s is smoother)
Best forReact developers; UX that should match each platformDesigners who want consistent visual identity
Adoption examplesDiscord, Tesla, Shopify, PinterestGoogle products, Reflectly, BMW

For JavaScript-heavy developers (most webapp developers): React Native + Expo. Same React skills; gentle learning curve; mature ecosystem.

For people starting fresh + valuing visual consistency: Flutter is excellent.

When to NOT build a mobile app at all

A common mistake: assuming “we need a mobile app.”

Often the right answer is:

  • A great mobile-optimized website (which works everywhere)
  • A PWA (adds home-screen install + offline)
  • Both

Reasons to actually build a NATIVE app:

  • You genuinely need OS features unavailable on web (rich push, background processing, deep biometrics, AR, advanced camera)
  • You need App Store presence for discovery
  • The app needs to work fully offline
  • You’re targeting a market where app stores are critical (China, much of Asia)
  • The competitive product is native and beats your web version

Reasons NOT to:

  • A website would work fine
  • Your team has no mobile expertise
  • You’d rather iterate fast (web wins)
  • You don’t want to share 30% revenue with stores

For Bible Quest: zero native need. PWA covers everything. The mobile-first design + PWA installation is the right choice.

Common gotchas

  • Apple’s App Store review is famously strict. Apps get rejected for tiny UI violations, vague guidelines, sometimes inconsistently. Plan for back-and-forth.

  • Google Play is more lenient but still has rules. Especially around privacy disclosures, content categorization, and security.

  • Push notifications differ wildly. iOS strictly limits background; Android is more permissive. Web push notifications work on Android but are limited on iOS (only since iOS 16.4 for PWAs added to home screen).

  • 30% store cuts are non-negotiable for in-app purchases. Apple + Google both. EU rulings in 2024 are slowly changing this. Plan revenue accordingly.

  • Web doesn’t have access to App Store reviews / discoverability. A serious limitation if discoverability matters.

  • window.matchMedia('(pointer: coarse)') detects touch. Useful for adapting UI between mobile and desktop on the web.

  • Mobile browsers behave subtly differently from desktop. iOS Safari especially has historical bugs + limitations.

  • 100vh is wrong on mobile Safari. Address bar height changes; viewport size shifts. Use 100dvh (dynamic viewport height).

  • Tap target size matters. 44×44px minimum for tappability (Apple HIG and Material Design agree). Smaller buttons get mis-tapped.

  • Mobile data is variable. Test on a real device on cellular, not just on WiFi.

  • Battery and performance matter more on mobile. Heavy JavaScript drains batteries; users notice. Profile.

  • Network conditions vary. Mobile users may hit 3G, dropouts, switching networks. Plan for graceful degradation.

  • The PWA installation prompt is buried on iOS. Add Safari → Share → Add to Home Screen. Most users won’t find this; an in-app prompt explaining “tap share, then add to home screen” is needed.

  • Android’s “Install App” prompt is automatic (browsers offer it when criteria are met). iOS has nothing equivalent.

  • App Store optimization (ASO) is its own discipline. Keywords, screenshots, descriptions affect downloads. Treat as separate from “building the app.”

  • navigator.userAgent for mobile detection is unreliable. Browsers spoof it. Feature detection > UA sniffing.

  • Offline support requires a service worker. PWAs without service workers don’t work offline. Service worker registration + cache strategy is required.

  • Background sync on PWAs is limited. Web apps mostly can’t run when the user isn’t actively using them. Native apps can. For “send a push at 8am tomorrow,” native usually wins.

  • iOS Safari’s quirks change with each major release. What works in iOS 17 might break in iOS 18. Test across versions.

  • Android fragmentation is real. Different OEMs (Samsung, Xiaomi, etc.) tweak the OS. What works on Pixel may break on Samsung. Common in low-budget Android devices.

  • iPad has its own gotchas. Larger screen, different layout requirements. Some apps look great on iPad with minimal effort; some need separate design work.

  • Apple’s silicon transition + iOS evolution means current iOS apps need recent Xcode, recent SDKs. Old iOS apps gradually stop working.

  • App reviews matter. A 3-star app gets fewer downloads. Solicit reviews carefully (not too aggressively; Apple’s HIG has rules).

  • TestFlight + Google Play Internal Test let you beta test. Use them before broad release.

  • Crash reporting is essential. Sentry, Crashlytics, Bugsnag. A native crash without telemetry = blind debugging.

  • Mobile-specific features (haptics, biometrics, AR) require native code. React Native + Expo provide bridges; pure web cannot access most of these.

  • App size matters. Apps over 100MB face download warnings on cellular. Optimize assets, lazy-load resources.

  • Privacy labels are mandatory now. Apple’s App Store and Google Play both require disclosure of data collection. Plan ahead.

  • Don’t build native unless you have a real reason. Web + PWA covers 80%+ of “I need an app” use cases. Native is for the 20% where it really matters.

  • AI agents help mobile dev too. Claude Code + Expo / React Native works smoothly. Cross-platform AI-assisted mobile dev is a real workflow in 2026.

A practical decision tree

For “should I build a mobile app?”:

  1. Does it WORK as a website? → Yes → Web first. Add PWA features.
  2. Is the website constrained by missing native features? → Yes → Cross-platform (React Native / Flutter).
  3. Does it need EXTREME native UX or features? → Yes → Go native (Swift + Kotlin).
  4. Are you targeting App Store discovery primarily? → Probably native or cross-platform.

For Bible Quest, the answers were: Yes (1), so web + PWA. Done.

See also

Sources

Graph View

Backlinks