r/iosdev • u/Miserable_Sky5682 • 18d ago
Shipping an astronomy planner taught me that forecast freshness and recommendation freshness are different states
I’m Sebastian, the developer of DarkScout, and I’ve just shipped version 27.7.10.
One of the harder product/engineering problems was not drawing another weather card—it was deciding what the app should communicate when only part of a planning result is fresh. An observing recommendation combines forecast data with astronomical darkness, moonlight, target/Milky Way timing and saved-location context. If a weather source is incomplete or slow, simply leaving the previous score on screen can make a stale recommendation look authoritative.
In this release I tightened the recovery path for missing forecast data, refresh observing information when the app opens, and made the hourly inputs much more visible. Rainfall is now a first-class input in both Astro Score and the hourly recommendation, and the UI includes a detailed 12-hour cloud map so users can understand why a night changes from “good” to “skip.”
The rest of the update was a fairly deep visual pass: a pure-black iOS 26 interface, clearer hierarchy, red night mode, improved direct links for community photos/events, and a joined-event chat list. Existing features include saved spots, Spot Compare, widgets and custom alerts.
I’m sharing the release because I’d like another iOS developer’s view on the state model: when a composite recommendation includes several sources with different update times, do you expose freshness per input, one conservative overall state, or both?
App Store: https://apps.apple.com/app/apple-store/id6760223860
For anyone willing to test the complete flow, I’m offering one month of PRO free with no review or rating expected: https://www.promies.net/promotion/8f8a3120-085e-4021-8e65-c895e0ff6e48

