Thuta Learning
ExercisesMobile Developmentintermediate

Exercise: The Mobile Glossary and Decision Guide

What you'll walk away with

  • Explain the core ideas behind Exercise: The Mobile Glossary and Decision Guide
  • Read the diagram/checklist and trace how the mobile architecture or decision connects
  • Explain how this applies to a real mobile app project

Build the mental model

Every chapter in this course answered a different kind of question. Put together, they're not meant to be memorized as isolated facts — they work together as a routing table you consult whenever a real decision shows up.

  • Foundations & Framework Choice -> which development approach fits this team and app?
  • Navigation & Device & Data -> how do screens, permissions, and offline data fit together?
  • Auth & Notifications -> how do users sign in, and how do we reach them after they leave?
  • Build & Store & Production -> how does a build actually reach a real store, safely?

The actual skill this closing lesson checks is routing: given a short, messy description of a situation, can you tell which part of this course applies? That's more realistic than reciting definitions, because nobody hands you a labeled question on a real team — you get a paragraph in a planning doc, and the first job is figuring out which mental model even applies.

This lesson closes with three mixed scenarios, a full glossary of every term this course introduced, and a one-page Mobile App Decision Guide collecting the course's recurring recommendations in one place.

Keep these two nearby

Treat the glossary and decision guide as references for your next real project, not one-time reading. Their value is in being ready the moment an actual decision shows up.

text
COURSE MAP: SCENARIO TO CHAPTER
-------------------------------
COURSE MAP: SCENARIO TO CHAPTER
--------------------------------
"What should we build with?"
    -> Foundations & Framework Choice

"How do screens, permissions, and
 offline data fit together?"
    -> Navigation & Device & Data

"How do users sign in, and how do
 we reach them after they leave?"
    -> Auth & Notifications

"How do we ship a real release?"
    -> Build & Store & Production

Connect it to a real scenario

Here's how the routing works for the three scenarios in this lesson's exercise, one at a time.

Choosing a development approach

Points back to Foundations & Framework Choice — its lessons on native, cross-platform, hybrid, and Expo-managed workflows are exactly what this decision needs, plus the reminder that no single approach is universally best for every team.

Designing login and notifications

Points to Auth & Notifications — covering where to store access and refresh tokens, how an OAuth mobile flow typically works, and the difference between push and local notifications, including registering a device token before anything gets sent.

Preparing a first store release

Points to Build & Store & Production — app signing, building an APK or AAB, Google Play and App Store submission, TestFlight, staged rollouts, and crash monitoring, tied together by the release-readiness checklist.

Notice Navigation & Device & Data didn't come up this time. That's normal — not every scenario touches every chapter, and part of routing well is recognizing which chapters don't apply.

Try the working example

javascript
function routeScenarioToChapter(scenarioCategory) {
  const routingTable = {
    "choosing-approach": {
      chapter: "Foundations & Framework Choice",
      why: "Deciding between native, cross-platform, hybrid, or Expo depends on team skills and app needs."
    },
    "navigation-and-data": {
      chapter: "Navigation & Device & Data",
      why: "Covers stack navigation, deep links, device permissions, and offline data / conflict resolution."
    },
    "auth-and-notifications": {
      chapter: "Auth & Notifications",
      why: "Covers token storage, OAuth mobile flow, and push vs local notifications."
    },
    "store-release": {
      chapter: "Build & Store & Production",
      why: "Covers app signing, APK/AAB builds, store submission, staged rollouts, and crash monitoring."
    }
  };

  return routingTable[scenarioCategory] || {
    chapter: "not found",
    why: "This scenario category doesn't match a chapter in this course."
  };
}

const scenarios = [
  "choosing-approach",
  "auth-and-notifications",
  "store-release",
  "marketing-budget"
];

for (const scenario of scenarios) {
  const result = routeScenarioToChapter(scenario);
  console.log(scenario, "->", result.chapter + " (" + result.why + ")");
}
You should see
For the three matching scenario categories, the function returns the chapter and reason from the routing table: choosing-approach -> Foundations & Framework Choice, auth-and-notifications -> Auth & Notifications, store-release -> Build & Store & Production. The fourth call, marketing-budget, isn't in the table, so it falls through to the default: chapter "not found" — a reminder that not every real situation maps onto this course.

5-minute try-it

This course is closing, so here are three scenarios that could show up on any real team. For each one, name the chapter (and, if you can, the specific lesson or checklist) of this course you'd go back to, and briefly say why.

1. You're starting a brand-new app and need to choose a development approach for your team.
2. You're designing the login flow and the notification system for a new app.
3. You're preparing an app for its first submission to a store.

Write your answer for each before checking the worked routing in this lesson's practical section — and also check the glossary and decision guide below for terms or steps you're unsure about.

One important caution

Trying to memorize every term in the glossary in order, instead of using it as a lookup you return to when a real term comes up.

Assuming every scenario needs every chapter — most real situations only touch one or two, and forcing the rest in adds confusion, not accuracy.

Apple App Store Review GuidelinesHow Mobile Apps Work

Mobile App Glossary — Common Terms

TermMeaning
Mobile AppA software application designed to run directly on a phone or tablet, rather than inside a web browser.
Mobile App ArchitectureThe overall structure of how an app's screens, data, networking, and platform integrations fit together.
Native AppAn app built with a platform's own language and tools (like Swift or Kotlin), giving it direct access to platform features.
Cross-Platform AppAn app built from a single codebase that runs on both Android and iOS, trading some native-only access for shared code.
Hybrid ApproachA mobile app that wraps web content (HTML, CSS, and JavaScript) inside a thin native shell to reach an app store.
ExpoA managed toolchain built on React Native that simplifies building, testing, and shipping cross-platform apps.
Stack NavigationA navigation pattern where screens are pushed onto and popped off a stack, like pages in a physical stack of cards.
Deep LinkA URL that opens an app directly to a specific screen instead of just the home screen.
Secure StoragePlatform-provided storage (like Keychain or Keystore-backed storage) meant for sensitive values, protected by the OS.
Conflict ResolutionThe strategy an app uses to reconcile data changed both offline and on the server before the two are back in sync.
Access TokenA short-lived credential an app sends with requests to prove the user is authenticated.
Refresh TokenA longer-lived credential used to obtain a new access token without asking the user to log in again.
OAuth Mobile FlowA standard pattern for letting a user sign in through a third party (like Google) without the app ever seeing their password.
Push NotificationA message delivered to a device from a server, even while the app is closed, via the platform's notification service.
Local NotificationA notification scheduled and triggered entirely on the device itself, with no server involved.
Device TokenA unique identifier a platform's push service assigns to one app install, used to target push notifications to it.
App SigningCryptographically signing an app build so the platform and users can verify it hasn't been tampered with.
Signing CredentialThe key or certificate used to sign an app build, which must be kept private and consistent across releases.
APKAndroid's installable app package format, used for direct installs and sideloading.
AABAndroid App Bundle — the format Google Play requires for publishing, used to generate optimized APKs per device.
Google PlayGoogle's official app store and distribution platform for Android apps.
App StoreApple's official app store and distribution platform for iOS apps.
TestFlightApple's official platform for distributing beta builds to testers before an App Store release.
Staged RolloutReleasing an update to a small percentage of users first, expanding gradually if no problems appear.
Feature FlagA toggle that lets a team turn a feature on or off remotely without shipping a new app build.
Force UpdateA mechanism that blocks a user from continuing to use an app until they install a required newer version.
Crash MonitoringTooling that automatically collects and reports crash details from real user devices after release.
Mobile Secret ManagementThe practice of deciding which credentials an app binary can safely hold and which must stay on a server.
Never Trust the ClientThe principle that any check performed only inside the app can be bypassed, so the server must re-verify anything that actually matters.

Mobile App Decision Guide

If you needChoose
Only targeting Android for nowNative Android or a cross-platform framework can both work well here — the deciding factor is usually team skills and how much native-only access you'll need, not the platform itself.
Targeting Android and iOS with a small teamA cross-platform framework usually reduces the duplicated work of maintaining two separate native codebases with a small team.
Team is strong in React / TypeScriptReact Native or Expo may feel the most familiar to build in, since the component model and language carry over from web React.
Team wants simplified tooling and the fastest prototypeAn Expo-managed workflow can fit well, since it handles much of the native build tooling for you out of the box.
App needs deep native or hardware integrationNative development may offer the simplest, most direct access to platform-specific hardware and APIs.
Designing login for a new appPlan where tokens will be stored (secure storage, not plain local storage) early, and consider an OAuth mobile flow if you want social sign-in.
Adding push notificationsRegister each device's token with your backend first — sending anything before that registration exists has nowhere to go.
Preparing for Google PlayBuild an AAB (not a plain APK), complete the store listing, and choose a testing track before a full public release.
Preparing for the App StorePrepare a properly signed build well ahead of time, and use TestFlight for beta testing before submitting for review.
Handling any API keys in the appAssume the app binary is inspectable by anyone who downloads it, and keep privileged secrets on your backend instead.
Planning any releaseRun the full release-readiness checklist before submitting, not after — catching a problem beforehand is far cheaper than catching it in review or production.

Easy traps

  • Trying to memorize every term in the glossary in order, instead of using it as a lookup you return to when a real term comes up.
  • Assuming every scenario needs every chapter — most real situations only touch one or two, and forcing the rest in adds confusion, not accuracy.
  • This course does not re-teach the Android Development, Flutter, iOS Development, or React Native tutorials -- continue to those for hands-on framework depth. This course teaches the framework-neutral mobile architecture, decision-making, and build/deployment/security concepts that sit above all four.

Exercise

This course is closing, so here are three scenarios that could show up on any real team. For each one, name the chapter (and, if you can, the specific lesson or checklist) of this course you'd go back to, and briefly say why.

1. You're starting a brand-new app and need to choose a development approach for your team.
2. You're designing the login flow and the notification system for a new app.
3. You're preparing an app for its first submission to a store.

Write your answer for each before checking the worked routing in this lesson's practical section — and also check the glossary and decision guide below for terms or steps you're unsure about.

You'll know it worked when: For the three matching scenario categories, the function returns the chapter and reason from the routing table: choosing-approach -> Foundations & Framework Choice, auth-and-notifications -> Auth & Notifications, store-release -> Build & Store & Production. The fourth call, marketing-budget, isn't in the table, so it falls through to the default: chapter "not found" — a reminder that not every real situation maps onto this course.

Exercise: The Mobile Glossary and Decision Guide | Thuta Learning