Mobile & App Development

Welcome to Mobile & App Development at Kaern Schools. I'm Ada, your tutor. I've shipped apps that landed on the home screen of paying customers and apps that died quietly in a TestFlight build nobody opened. The difference was almost never the code.

Who this is for: You're a founder building a Kaern startup. You have users, or soon will, and a phone-shaped question: do we need an app, and if so, what kind?

What you'll walk out with: the judgment to decide between PWA, native, and cross-platform; the skills to design navigation people don't get lost in; a working grasp of offline data, notifications, and device APIs; and a release plan that survives app-store review and turns installs into retention.

We work the way real product teams do: start from the user's job, ship the smallest thing that proves value, then harden it. Six modules, each with teaching, worked examples, hands-on exercises, and checks. We finish with a capstone you could pitch.

Let's build.

Module 1 — Mobile Fundamentals & When to Build an App

Learning objectives

• Distinguish a mobile-friendly experience from a native app and articulate when each is warranted.
• Map a user job-to-be-done onto the right delivery channel (web, PWA, native).
• Identify the three capabilities that genuinely require leaving the browser.
• Estimate the true cost of an app: build, two platforms, review cycles, and maintenance.

Lesson 1.1 — The home-screen test

Teaching script (Ada): Picture your phone's home screen. It's prime real estate — the digital equivalent of a shelf at eye level in a shop. People put apps there they open without thinking: messages, banking, maps. Now ask honestly: is your product a habit, or an errand? An errand — checking a delivery, booking a wash slot once a month — doesn't earn a permanent spot. People will tolerate a website for it. A habit does.

This matters because building an app is the most expensive way to reach a phone. You pay twice (iOS and Android), you wait on app-store review, and you ask users to commit before they've seen value. Every install is a small act of trust you have to earn before you've delivered anything.

So before a single line of code, run the home-screen test. Would your user genuinely want this one tap away, daily or weekly? If yes, an app may pay for itself in retention. If no, you're adding friction and cost for a button that a good mobile website already gives you for free.

Which of your features would a user actually want one tap from their lock screen?

Worked example: A Kaern startup runs a bike-wash booking service. Two features: (1) book a one-off wash, (2) track a monthly subscription's remaining washes + get reminders. Feature 1 is an errand → mobile web suffices. Feature 2 is a recurring habit with notifications → candidate for an app or PWA. Decision: ship mobile web first, instrument how often subscribers return, and only build an app once weekly active use is proven.

Hands-on exercise: List your product's top 5 user jobs. For each, label errand or habit, note required frequency, and mark whether it needs camera, push, or offline. Write one sentence: "We should build an app when ___ ."

Lesson 1.2 — What only an app can do

Teaching script (Ada): Here's a trap I see constantly: founders build native apps for features the browser already does. Modern mobile web can take payments, use GPS, access the camera, store data offline, and even send push notifications. So the honest question isn't "can the web do this?" — it's "what's the short list it can't?"

Think of the browser as a well-behaved guest in someone's house: it can use most rooms, but the host keeps a few doors locked for safety. Behind those doors: deep background processing, certain Bluetooth and NFC hardware paths, tight OS integrations (widgets, Siri/Assistant, advanced biometrics), and the marketing surface of an App Store listing itself.

If your killer feature lives behind one of those locked doors, native earns its keep. If it doesn't, you may be paying native prices for web-achievable results. The skill is knowing exactly where the line sits today — because it moves every year, and last year's "you need an app for that" is often this year's web API.

Which capability does your product truly need that the browser can't reach?

Worked example: A team wanted an app "for offline use and push." Audit showed both are PWA-capable. The only hard requirement was reading an NFC maintenance tag on equipment — Web NFC is Android-only and flaky on iOS. Conclusion: PWA for everyone, plus a thin native wrapper only for the field technicians who scan tags. Two builds, scoped by real need, not by default.

Hands-on exercise: Take your feature list from 1.1. For each capability, search whether a current web API covers it. Produce a two-column table: "Web can do" vs "Needs native." If the second column is empty, you have your answer.

Common mistakes

1. Building native because it "feels more serious" — paying a 2x cost for a perception.
2. Assuming push and offline require native; both work in PWAs on modern OSes.
3. Ignoring maintenance cost — an app is a subscription you pay forever in OS updates and review re-submissions.

Check for understanding

1. Give one feature that genuinely requires native today and one that does not.
2. Why is an install a higher-friction ask than a website visit?
3. Apply the home-screen test to a product you use weekly — does it pass? Why?