By late August, my water-temperature project had reached a milestone I described as its first App Store version. That phrase belongs to preparation: it means a version intended for the store, with the work of releasing it still separate. It is a useful point to stop thinking like the person who built the app and start thinking like someone opening it for the first time.
The developer knows where the data comes from, what a button means and which wait is normal. A new user knows none of that. For AquaDegrees, the main interaction is deliberately small, so misunderstandings around it become especially visible. If the app exists to show water temperature, a confusing temperature screen is not a minor problem around the edges.
I think of store preparation as removing the explanations I could otherwise provide in person. A location permission request should have an understandable reason. A loading state should look like work in progress. A failed request should leave the person with a useful next action, rather than an empty space where a number ought to be.
These details also affect the promises made outside the app. A screenshot is a claim about what someone will get. A description establishes what the product is for. If the marketing implies precise conditions at a particular beach while the data represents a wider area, the mismatch starts before installation.
Test the transitions
The normal state is usually the easiest one to present: location available, network working, data returned. The transitions reveal more. Open the app before granting permission. Change a permission after using it. Lose connectivity while a request is in progress. Come back to an old value after the app has been away for a while.
Those are examples of the review I want around a release candidate, not a claim that every possible environment can be exhaustively covered. The point is to evaluate the journey between states. A stale result may be useful if it is identified as stale. The same result can be misleading if a fresh animation makes it look newly measured.
There is a similar distinction between a build and a product. A build can install and start successfully while the description, support information or privacy explanation remains incomplete. Store preparation brings those parts into the same package. They are all ways of telling the user what to expect.
A narrow app makes this work manageable, but it does not make it optional. There are fewer screens to inspect, which gives each one more responsibility. The first useful version should have a coherent answer to its main question and an honest answer when it cannot provide one.
For me, this milestone is satisfying because it gives the prototype a boundary. It does not need every possible weather feature before it can be useful. It does need to stand on its own. The goal is an app that can give someone a quick answer about the water without requiring a conversation with me first.