When one test device is no longer enough
The most useful bugs appear when an application stops running only on the developer's own devices. Different hardware quickly exposes optimistic assumptions.

At some point, MyDeskViewer stopped being an application tested on one familiar set of devices. That was an important milestone because different hardware and operating-system configurations quickly reveal how many assumptions are only true in a development environment.
On one phone, the application returns from the background exactly where expected. On another, the system is more aggressive about limiting background work. One Android version shows a particular permission dialog, while another changes its appearance or adds a new step. Notifications require their own consent as well, and a user may skip, deny or later change that permission.
Similar differences appear on computers. Network configuration, operating-system updates, sleep, interface changes and temporary connectivity loss create situations that are difficult to reproduce in a single test environment.
That is why many later MyDeskViewer releases contained improvements without a dramatic feature name. They were fixes for reconnecting, refreshing state, returning to the foreground, presenting better messages and recovering when the operating system denied a requested permission.
We also added notifications where they can be useful, but without turning the application into another source of unnecessary alerts. Users should be able to decide whether they want them, and refusing notifications should not block the core features of the application.
This phase made one thing very clear: public testing is necessary. Even a large amount of internal testing cannot reproduce the variety of real devices, networks and usage patterns.
The closer MyDeskViewer gets to wider availability, the less important the question becomes, “does this feature work once?” The better question is, “does it behave predictably often enough to be trusted in normal use?”