Mobile app development Study Guide

📖 Core Concepts Mobile app development – creating software that runs on phones, PDAs, or enterprise digital assistants. Hardware constraints – CPU architecture/speed, RAM size, storage limits, screen size & resolution, input methods (buttons, touch, stylus). Distribution methods – pre‑installed apps, web apps (server‑ or client‑side processing). Native vs. cross‑platform – native targets a single OS with platform‑specific languages; cross‑platform uses a single code base (HTML/CSS/JS) inside a native container. Back‑end role – routes data, handles security (auth, encryption, app‑wrapping), supports offline use and service orchestration. Design goals – understandable, user‑friendly interfaces that respect limited attention span and small screens. Usability principles – clutter‑free screens, low cognitive load, simple navigation, one‑hand reachability, accessibility. --- 📌 Must Remember Performance ↔ User Satisfaction – Faster, responsive apps lead to higher satisfaction (research‑backed). Hardware limits dictate UI – Small screens & limited RAM → keep screens simple, break long forms into multiple pages. Cross‑platform trade‑off – Reuse code across OSes but must evaluate impact on UX; native gives optimal performance per platform. Security layers – App wrapping, data encryption, client‑action monitoring, reporting. Accessibility minimums – Text ≥ 11 pt; contrast ratio ≥ 4.5:1; support voice navigation & screen readers. Notification best practice – Send at user‑convenient local time; personalize content. --- 🔄 Key Processes Choosing a Development Platform Identify target mobile platforms → assess existing infrastructure → match team’s development skills. Cross‑Platform Development Workflow Write UI in HTML/CSS/JS → embed in native container → access device features via SDK → test on multiple OS emulators. Native Development Workflow Select platform (e.g., iOS) → use official SDK (Xcode) → code in Swift/Objective‑C → leverage platform‑specific APIs → test on device/emulator. Security Integration Add app‑wrapping layer → apply data encryption → enable client‑action monitoring → configure reporting modules. UI Design for One‑Hand Use Place frequently used controls within thumb’s reach area → verify with ergonomics guidelines → test on devices of varying sizes. --- 🔍 Key Comparisons Native vs. Cross‑Platform Native: single‑OS focus, platform‑specific language, best performance, higher development cost per platform. Cross‑Platform: single code base, uses HTML/CSS/JS, reusable across OSes, may affect UX/performance. Pre‑installed vs. Web App Distribution Pre‑installed: bundled at manufacture, no download friction, limited update flexibility. Web App: runs in browser, can be updated instantly, depends on network connectivity. Hardware Constraint vs. UI Constraint Hardware: CPU, RAM, storage, screen specs, input hardware. UI: user attention span, screen size/form‑factor, one‑hand reachability. --- ⚠️ Common Misunderstandings “Cross‑platform = no performance loss.” – Reuse is great, but UI smoothness can suffer if the native container adds overhead. “More features = better app.” – Adding too many controls clutters screens, increases cognitive load, and hurts one‑hand usability. “Security is optional for internal apps.” – Even internal apps need encryption & monitoring; data breaches can still occur. “Web apps don’t need testing on emulators.” – UI still runs on mobile browsers; emulators catch layout and performance issues. --- 🧠 Mental Models / Intuition “Fit‑to‑Screen” model: Treat the mobile screen as a tiny billboard – only one clear message or task per view. “Thumb Zone” heuristic: Imagine a circle centered on the thumb; place primary actions inside it for one‑hand comfort. “Performance ≈ Happiness” – Every 100 ms of delay feels like a noticeable slowdown; aim for sub‑200 ms UI response. --- 🚩 Exceptions & Edge Cases High‑end devices may have ample RAM/CPU, but still require low‑cognitive‑load UI because user attention remains limited. Enterprise apps often need stricter security (e.g., mandatory app wrapping) even if distributed internally. Cross‑platform tools that compile to native code (e.g., React Native) can mitigate performance concerns, but still need careful UI testing. --- 📍 When to Use Which Choose Native when: Maximum performance or deep OS integration is required (e.g., AR, heavy graphics). Target platform share is high enough to justify dedicated effort. Choose Cross‑Platform when: Time‑to‑market across multiple OSes is critical. App logic is mostly UI‑driven with modest device‑specific features. Use Pre‑installed for: Core system apps or carrier‑bundled services that must be present from day 1. Use Web App for: Rapid iteration, low‑install friction, or when offline capability isn’t essential. --- 👀 Patterns to Recognize “One task per screen” → screens with a single primary CTA. “Skeleton screen before content” → placeholder UI indicating loading progress. “Contextual suggestion trigger” → location or time‑based filters appearing automatically. “Thumb‑reachable layout” → navigation bars at bottom of screen on larger phones. --- 🗂️ Exam Traps Distractor: “Cross‑platform always yields the same UX as native.” – Wrong; UI may feel less polished due to abstraction layers. Distractor: “More RAM on device means you can ignore memory optimization.” – Incorrect; efficient memory use still impacts battery and performance. Distractor: “Security features are only needed for public apps.” – Misleading; internal apps also require encryption and monitoring. Distractor: “Long forms improve data accuracy.” – Actually increase cognitive load; split into multiple screens. ---