# Choose an application platform from device requirements

Canonical page: https://yishto.com/en/learn/application-platforms/choose-runtime-and-platform/

Author: [Yishto](https://yishto.com/en/about/)

Use an offline document reader to turn file access, notifications, background work, and distribution into testable requirements before choosing a runtime and application platform.

Published: 2026-11-10
Updated: 2026-11-10

An offline document reader lets a user import files, retain a reading position, and continue without a connection. Similar screens can run in very different environments. The environment determines how files become accessible, what happens when execution is suspended, and how updates reach the device. Start platform selection with these actions.

Use three synthetic inputs: a short text, a document with images, and an unsupported file. Keep the first project to a reader on a personal device. Collaboration, payments, and model services introduce separate requirements and can wait until device behavior is understood.

## Turn requirements into device actions

“Works offline” includes initial download, completed persistence, opening without a connection, and reopening after the process exits. Content held only in the current page fails the last condition. File import also needs a precise definition. A user selecting one file is different from continuously scanning a directory, with different access requirements.

Write an acceptance condition for each action. A completed import shows its title and storage state. Canceling the picker creates no empty record. Saving a position and closing the application must reopen the same paragraph. Distinguish a notification inviting someone to read from a requirement to download at a scheduled time while the device is locked. Background scheduling depends on the operating system; a timer is insufficient evidence.

Separate mandatory conditions from preferences. Required ongoing access to a directory can exclude an environment. Familiarity with JavaScript is a preference that can reduce learning cost. A high aggregate score cannot compensate for a missing mandatory capability. Record untested support as unknown.

## Distinguish languages, frameworks, and runtimes

Swift and Kotlin are languages; SwiftUI and Compose are UI frameworks. Each depends on a target system and its engineering constraints. Flutter shares substantial interface and business code written in Dart, but plugins, permissions, and platform packages still need separate investigation. The ability to display a button does not make these environments interchangeable.

A website runs through a browser. PWA features add installation and caching, with support varying by browser and operating system. Electron organizes Chromium and Node.js capabilities into desktop applications, creating responsibilities for privilege separation and updates. Shared source reduces repeated implementation without removing differences in input, access, or distribution.

A reader can share contracts for document IDs, positions, and error codes. Put file picking, storage locations, and notification authorization behind platform adapters. The interface can then consume a consistent contract without scattered system checks. Fake adapters also allow the workflow to be tested before device integrations exist.

## Filter capabilities before comparing preferences

Create rows for reopening offline, user-selected imports, resumed downloads, and the intended installation channel. Name the device and system version in each column. Mark capabilities as verified, unknown, or unmet, with official references and experiment records. An overview describing a category of capability does not establish availability in every target browser.

This offline Python example demonstrates mandatory-condition filtering. `device_api` is an invented requirement name, and `False` is a teaching assumption. It is not a verdict on the whole Web platform. Define the actual device operation before filling the structure with findings.

```python
options = {"web": {"offline": True, "device_api": False},
           "native": {"offline": True, "device_api": True}}
required = {"offline", "device_api"}
eligible = [name for name, capabilities in options.items()
            if all(capabilities.get(key, False) for key in required)]
assert eligible == ["native"]
print(eligible)
```

The output is `['native']`. Both candidates have the offline field, while only the second satisfies the assumed device-interface requirement. The assertions validate filtering. They run no browser, native build, or device API, and do not establish a universally preferable platform.

## Build a capability experiment

Start with the candidate's official starter project, recording toolchain versions and the minimum target system. Implement an import action, a document list, a body view, and position restoration. A repository parses and persists documents. The screen receives list state, the selected ID, and errors. Begin with synthetic files before accepting explicitly selected user files.

Check an empty first launch, a completed import, reading in airplane mode, reopening after forced termination, and resuming unfinished work when connectivity returns. Record observations for each step. If an environment permits only explicit selection but the requirement demands automatic scanning, stop that candidate's evaluation at this point.

Investigate background work separately. Record the task state when the application is backgrounded, suspended, and reopened. Persistence should make resumption possible. Do not promise execution timing that the operating system does not guarantee. Recovering work does not imply uninterrupted execution.

## Include maintenance and failure behavior

Compare build environments, packaging, permission explanations, platform upgrades, and plugin maintenance. URL delivery and installed packages have different update paths. A shared mobile project still produces separately tested artifacts. General fees or review durations are not estimated here because current channel policies determine them.

Failure handling can influence selection. Preserve unsupported source files and explain the format error. Insufficient space must not produce an “available offline” label. Interrupted downloads retain an operation ID and enough information to validate partial work. Removing a local copy and removing its index entry are distinct actions and need distinct interface wording.

Give each unknown a next action: check API availability, perform a device test, or narrow the requirement. Weighted arithmetic can express project preferences when its assumptions are explicit. It cannot turn missing evidence into support or create an objective industry ranking.

## Exercise: produce a reproducible decision

Compare two candidates across at least six device actions. Design a minimal experiment for every mandatory condition. Record the target system, procedure, observation, and limitations. Mark simulator results separately when physical-device behavior remains unverified.

Another reader should be able to reproduce offline restart, canceled import, and recovery from a failed download. The decision must identify satisfied requirements, postponed features, and unresolved conditions that block a particular distribution route. Add search and synchronization afterward, once the runtime constraints have been demonstrated.

## Sources & further reading

- [Progressive web applications](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps)
- [Flutter architectural overview](https://docs.flutter.dev/resources/architectural-overview)
- [Electron process model](https://www.electronjs.org/docs/latest/tutorial/process-model)
- [SwiftUI application structure](https://developer.apple.com/documentation/swiftui)
- [Compose state and architecture](https://developer.android.com/develop/ui/compose/state)

Sources checked on 2026-11-10. Examples are teaching data, not production measurements.

## Related guides

- [Turn a need into a testable prototype and interface](https://yishto.com/en/learn/product-building/prototypes-design-systems-and-assets/)
- [Trace responsibility from containers to clusters](https://yishto.com/en/learn/delivery/containers-orchestration-and-iac/)