Target Selection

A handheld product's user base does not sit on one platform version, and it never will. Three separate mechanisms hold that spread open, and none of them is under the team's control. Understanding them is what turns a target list from a habit into a decision. ## Why the installed base will not move - **The update is the user's decision.** On a handheld the platform update is offered, not applied. It is large, it wants power and a good connection, it takes the device out of use while it installs, and a meaningful share of people decline it indefinitely — often because a past update left their device feeling slower. - **Hardware runs out of updates.** Every device has a support window. Once it closes, the device is frozen on whatever line it last received. It never becomes current again; it leaves the field only when it is replaced, and inexpensive hardware is kept for a long time. - **The path to a device is not direct.** Platform releases are frequently rebuilt and staged for particular device families by intermediaries, so two devices bought in the same week can be offered the same line months apart, and some are never offered it. The effect is cumulative. Each year adds another cohort of devices that stall where they stopped, so the longer a product ships, the wider its tail grows and the smaller the share of real usage the newest line represents. ## This is unlike most software you deploy | Where the code runs | Who chooses the version | How long an old version survives | | --- | --- | --- | | A service the team operates | the team | until the rollout finishes | | A client that updates itself | the client, usually silently | days to weeks | | A handheld app's underlying platform | the user, bounded by the hardware's support window | years, sometimes the life of the device | The middle row is the one that misleads people. An engineer whose instincts were formed where old versions age out on their own carries the assumption that the tail is temporary. On a handheld it is permanent, and it is a property of the field rather than a backlog item. ## What actually differs between version lines A version row is not bureaucratic box-ticking; it is a different program environment. Across lines you will find changes to: 1. **The permission model** — when a prompt appears, how often it may be asked again, and whether a grant is permanent or lasts only while the app is in use. 2. **Background execution** — how much work an app may do once it is no longer in front of the user, and how aggressively it is stopped. 3. **Notification handling** — grouping, priority, and whether the user must opt in before anything is delivered. 4. **Storage access** — what an app may read outside its own area, and what it must ask for. 5. **System-drawn interface** — dialogs and pickers the app does not draw but must react to, whose shape and callbacks change. 6. **Accessibility and display defaults** — default text size, contrast and animation settings that shift what a layout receives. On platforms that gate behaviour changes on the version a build *declares it targets*, the same physical device can behave differently before and after that declaration is raised — so the version axis moves for two independent reasons, one of them entirely inside your own release. ## What the target list does about it - Name the lines and give each a role: the newest shipped line, the line carrying the largest share of real usage, and the oldest line the product still supports. - Treat the oldest supported line as an ordinary row, not a favour done when there is spare time. It is where the permission and background-execution differences bite hardest. - Keep the version line visible on every result, so a failure that only happens on one line is not filed as an intermittent one. - Do not let new cases land only on the newest line. A case that has never executed on the oldest supported line is not covering it, no matter what the list says. ## Common mistakes - Reasoning from the team's own devices, which skew new, fast and recently updated. - Assuming an aggressive release cadence on your side moves users — your release cadence and their platform version are unrelated. - Reading a single line's pass as coverage of the family, when the lines differ in behaviour rather than only in version number. - Planning to "catch up later", which ignores that the tail grows rather than shrinks as the product ages.