Mobile, Desktop and Embedded Application Development

01Purpose and scope

• This manual supports the course Mobile, Desktop and Embedded Application Development. It describes how application software is planned, built, tested and released for three kinds of targets: handheld devices running a mobile operating system, personal computers running a desktop operating system, and embedded controllers with limited memory, processing power and direct hardware access.
• The manual is written for working developers, technical leads, test engineers and learners who move between these targets. It covers the common activities and decisions, the deliverables each one produces, the people who need to be involved, and the standards that shape the work. It does not teach a specific programming language or framework, since those change faster than a working process does.
• Practice differs a great deal across contexts. A consumer app with frequent store updates, an accounting tool used inside one company, and a sensor controller installed in a factory for a decade each carry different costs of failure. Where this manual names a regulation or standard, treat it as a pointer to the current authoritative source, since requirements depend on jurisdiction, product class and contract.

02Core principles

• Start from the device and the user, not the framework. A mobile app is judged on battery use, network interruption, screen size and background execution limits. A desktop tool is judged on installation, file handling, update behavior and recovery from a crash in the middle of a task. An embedded application is judged on timing, memory footprint and what happens when power is cut during a write.
• Keep the platform boundary thin. Put business rules and data logic in portable modules where that is reasonable, and keep user interface code and hardware access in layers that can be replaced. The trade-off is that a thick abstraction layer adds indirection and can hide platform behavior that matters, so draw the line where the team can explain it.
• Treat failure as a normal state. Networks drop, storage fills, operating systems suspend processes, and sensors return bad values. Design each feature with a defined fallback, a clear error that a user or operator can act on, and logs that a support engineer can read without help from the author.
• Make every release reproducible. A build should trace to a source revision, a toolchain version and a list of dependencies. For firmware this includes the bootloader and any calibration data that ships with the image.

03Planning and preparation

• Begin by writing down the target matrix. List operating system versions, device classes, processor architectures, screen sizes, input methods and, for embedded work, the exact board revision and peripherals. Support decisions made here drive almost every later cost, so get the product owner and support lead to sign off on the list.
• Choose the technology stack against the constraints, not against familiarity. A cross platform framework can cut effort for a form based app but may limit access to native sensors, background tasks or fine timing. A native toolchain gives more control and more duplicated work. A real time operating system or bare metal approach may be required where interrupt latency is specified.
• Define deliverables early. Typical outputs are a requirements list with acceptance criteria, an architecture note showing module boundaries and threading model, a test plan covering each target in the matrix, a release plan with signing and distribution steps, and a hazard list for anything that could harm a person or corrupt data.
• Set up the environment before the first feature. This means a version controlled repository, a build pipeline that runs on each target toolchain, automated unit tests, a bench of representative hardware or a device farm, and a way to capture logs from devices in the field. For embedded work, a debug probe setup and, where practical, a hardware in the loop rig belong here too.

04Recommended workflow

1. 1
   : Confirm requirements against the target matrix. For each requirement, note which targets it applies to and any target specific behavior, such as a permission prompt on mobile or a background service on desktop.
2. 2
   : Write the architecture note. Identify the threading model, the persistence approach, the error handling policy and the hardware abstraction layer. Review it with one engineer from each target before coding starts.
3. 3
   : Build a thin vertical slice. Implement one user path or one control loop end to end on the least capable target first. This exposes memory, timing and packaging problems while changes are still cheap.
4. 4
   : Add features in small increments behind tests. Keep each change small enough that a reviewer can read it in one sitting, and run the target build on every merge request.
5. 5
   : Test on real hardware at each milestone. Emulators miss battery drain, camera and sensor behavior, display scaling, input latency and timing jitter. Record device model, OS version and firmware revision with every result.
6. 6
   : Run soak and fault tests. Leave the app running for long periods, cycle the network, rotate the device, suspend and resume it, pull power during writes, and fill storage. Record what breaks and whether recovery is automatic.
7. 7
   : Prepare the release candidate. Freeze scope, build signed artifacts with reproducible settings, check store or installer metadata, and verify the update path from the previous version on each target.
8. 8
   : Release and watch. Roll out in stages where the platform allows it, monitor crash and error rates, and keep a rollback or recovery image ready. For embedded devices, send firmware to a small set of units before fleet deployment and hold the rollout if boot failures appear.

05Quality checks, risk controls and compliance

• Quality checks should cover functional behavior, performance budgets, security, accessibility, localization and recovery. Set numeric budgets where you can: cold start time, frame time on the slowest supported device, memory ceiling, flash size, interrupt response time and maximum battery draw during typical use. Measure against these on real hardware rather than on a workstation.
• Security needs its own review. For mobile apps, the OWASP Mobile Application Security Verification Standard gives a widely used list of requirements covering storage, authentication, communication and code protection. Desktop applications should be checked for insecure update channels, unsigned libraries and privilege escalation through installer or service components. Embedded devices need secure boot where the hardware supports it, signed firmware images, and a documented plan for key storage and revocation.
• Accessibility is often skipped on desktop and embedded panels. The Web Content Accessibility Guidelines are a common reference for contrast, text scaling and keyboard operation, and mobile platform accessibility features follow similar principles. Apply the guidance that fits the product and document any exceptions with a reason.
• Store and platform rules change. Check the current app store review guidelines and developer policies for each platform you ship on, including privacy disclosures and permission justifications. Sensitive categories such as health, finance, children and location usually trigger additional review.
• Regulated and high-risk fields need extra care. Medical device software, automotive and industrial safety functions, and aviation or rail controls may fall under standards such as IEC 62304 for medical device software or ISO 26262 for road vehicle functional safety. This guidance does not replace qualified professional judgment, approved procedures or required authorization. For safety related products, involve the safety engineer and any certifying body early, and confirm the applicable standard with the current authoritative source for your market.
• Export control, encryption rules and data residency also depend on jurisdiction. Confirm them with legal or compliance staff before distribution, and keep a record of what was confirmed.

06Collaboration and documentation

• Roles need to be explicit. A typical team includes a product owner who sets priorities, a technical lead who owns the architecture note, platform engineers who own target specific layers, a test engineer who owns the device matrix, a release manager who owns signing and distribution, and a support engineer who reads field logs. Small teams may combine roles, but the responsibilities should still be written down.
• Hardware and firmware teams often sit apart from app teams. Agree on interface documents that describe message formats, timing budgets, error codes and version negotiation. Keep these under version control with the code they describe, and review changes to them as carefully as code changes.
• Documentation should be short and close to the work. Keep a device matrix that lists tested configurations and known issues, a release log with build identifiers, a decision record for major architecture choices, and runbooks for signing, rollback and field diagnosis. An outdated document misleads people, so assign an owner to each one.
• Use code review and pair testing on the parts most likely to fail on a device, such as background tasks, storage migrations, interrupt handlers and update logic. A second reader catches lifecycle assumptions that the author has stopped questioning.

07Measures and continuous improvement

• Track indicators that reflect the real product. Useful ones include crash-free session rate by device model, cold start time at the 90th percentile on the slowest supported device, update adoption over a fixed window, rollback frequency, defects found after release by target, and elapsed time from a field report to a reproduced defect. Choose a small set and review it at each release rather than tracking everything.
• Use the indicators to change the process. If most defects appear in one target's storage layer, add a test that exercises that layer on that target. If update adoption is slow, examine the update prompt, installer size and staging plan before blaming users.
• Hold a short retrospective after each release. Record what the device matrix missed, which fault tests caught real problems, and which steps took longer than planned. Adjust the matrix and checklist based on evidence rather than on the most recent incident alone.
• Limits apply. Field telemetry depends on users opting in and on privacy rules, and embedded devices may have little bandwidth for logs. Plan for sampling, and for local log buffers that upload later when a connection is available.

08Common mistakes and how to prevent them

• Testing only on the developer's own phone. Prevent this by fixing a device matrix with at least one low memory device, one older operating system version and one current device per platform, and by lending hardware to every engineer who ships code.
• Assuming the emulator matches hardware. Timing, sensor noise, thermal throttling and display behavior differ on real devices. Keep a bench of physical hardware and treat emulator passes as partial evidence only.
• Ignoring background and suspension rules. Apps that work in the foreground can fail when suspended or killed by the operating system. Test each lifecycle transition explicitly and confirm that state is saved and restored correctly.
• Writing to storage without considering power loss. Use atomic write patterns, journaling or double buffering for settings and logs on desktop and embedded targets, and test by cutting power during writes.
• Shipping firmware without a rollback path. Keep the previous image in a recoverable slot and test the failure case where the new image does not boot.
• Letting the abstraction layer grow until it hides everything. Review the layer at each major release and confirm that it still delivers the portability it was built for, removing indirection that no longer pays for itself.

09Practical checklist

• Confirm the target matrix and get sign off from product and support leads.
• Write the architecture note and review it with one engineer per target.
• Set numeric performance, memory, storage and battery budgets for each target.
• Maintain a bench of physical devices that covers the oldest and newest supported configurations.
• Run soak, network cycling, suspension and power loss tests before each release candidate.
• Verify signing, update paths and rollback or recovery images on every target.
• Check the current store policies, accessibility guidance and security requirements for each platform.
• Confirm applicable safety or medical standards with qualified staff and the current authoritative source where the product is regulated.
• Record build identifiers, device configurations and known issues in the release log.
• Review indicators and retrospective findings and update the matrix and checklist.

★Learning sources

• Micro Degree: Mobile, Desktop and Embedded Application Development
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics