Mobile Application
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| Mobile Application Developer | Implement mobile applications for a specific mobile OS, handle touch-based interaction, manage app lifecycle, integrate device capabilities, test on real devices and emulators | Build browser-based UIs, design backend architectures, manage server infrastructure | Google Maps mobile app, WhatsApp mobile app |
| UX-focused Mobile Developer | Design and implement mobile-friendly interactions, support one-hand usage, handle orientation changes, ensure accessibility on small screens | Conduct formal UX research, produce marketing visuals, or define product strategy | Instagram mobile UI, Spotify mobile app |
| Full-Stack Developer (mobile-leaning) | Implement mobile UI, connect to backend APIs, handle authentication on mobile, debug client-server interaction | Optimize backend performance at scale, manage cloud infrastructure | Airbnb mobile app, Uber rider app |
Affected SDLC Phases
If a team chooses this advanced topic, the system design, implementation, and testing phases are most strongly affected, as the focus shifts toward mobile platforms, device constraints, and hardware integration. Planning emphasizes platform choice and device capabilities. Testing must include both emulator and real-device verification. Deployment is minimal and focuses on running the application on the chosen target device.
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined at least six mobile application features that are usable on the chosen target device. Teams must clearly state the selected mobile platform (e.g. Android or iOS) and target hardware, and define each feature in terms of user interaction on a mobile screen.
Technical Details
Before defining features, the team must choose exactly one mobile platform (e.g. Android or iOS) and one target device or device class. This choice must be stated clearly in README.md and applies to all features.
Use a consistent feature issue template. Each feature must include:
- User interaction flow on mobile (gestures, taps, navigation)
- Main screens or views involved
- Device-specific capabilities used (if any), such as GPS, camera, or sensors
- Done criteria expressed in observable mobile behavior
Features must be end-to-end from the mobile user perspective. Avoid vague items like “build app” or “add mobile support”.
Quality
High-quality feature definitions are concrete, mobile-specific, and testable on the chosen device. Each feature clearly explains how a user interacts with the app using touch and gestures. Platform and hardware choices are applied consistently. Feature scopes are realistic, independently implementable, and clearly observable on the device.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working mobile application running on the chosen target platform. The demo must show at least one feature working end-to-end on a real device or emulator, including user interaction and visible UI updates, without crashes.
Technical Details
The demo must be performed on:
- The selected emulator, and
- The selected real target device (or equivalent hardware owned by the team)
Show at least one complete mobile user flow:
- Touch-based user action
- App logic execution
- UI update or navigation
If device sensors (e.g. GPS) are used, demonstrate real or simulated sensor input. The demo steps must be repeatable and documented in README.md.
Quality
High-quality demos show a stable and usable mobile app. The UI adapts correctly to orientation changes (portrait/landscape), interactions are smooth, and the flow is easy to follow with one hand. Extra quality comes from showing correct handling of permissions, sensor input, and basic error cases.
Bug fixing
Minimum Viable Product (MVP)
During development, your team must report and fix one reproducible mobile-specific bug (e.g. broken gesture, orientation issue, sensor misuse, or accessibility problem). The bug must be reproducible on the target device or emulator and demonstrated before and after the fix.
Technical Details
The bug report must include:
- Platform, OS version, and device or emulator used
- Steps to reproduce using concrete touch interactions
- Expected vs actual behavior on the device
- Evidence (screenshots, screen recording, or logs)
The fix must be implemented after the bug is reported. After fixing, repeat the same steps on the same device or emulator and show that the issue no longer occurs.
Quality
High-quality bug fixing shows a clear mobile bug lifecycle: device-specific reproduction, correct diagnosis, and verified resolution. The report focuses on user-visible behavior. The fix respects mobile constraints and does not introduce regressions in other orientations, devices, or accessibility modes.