How to Make an App Like Dark Sky

Building a hyperlocal weather app is a genuinely hard engineering problem. Dark Sky made it look easy — tap a location, get a minute-by-minute rain forecast so precise it told you exactly when to grab your umbrella. Apple acquired it in 2020, shut the public API in 2023, and left a gap that developers and product teams are still trying to fill. This post walks through the actual architecture: data sources, ML models, real-time delivery, and the trade-offs that matter.

What Made Dark Sky Different From Every Other Weather App?

Most weather apps are wrappers. They call a national meteorological service, reformat the JSON, and display it. Dark Sky was something else. Its core product was hyperlocal precipitation nowcasting, meaning short-range forecasts (0–6 hours) at spatial resolutions down to roughly 1 km², updated every few minutes. That required a fundamentally different data pipeline.

The underlying technology came from Boldi Vajda and Jack Turner's work on radar-based nowcasting. The key inputs were NEXRAD (Next-Generation Radar) data in the US and equivalent radar networks in Europe, fused with NWP (Numerical Weather Prediction) model output from sources like NOAA's HRRR model. Radar gives you fine spatial resolution and near-real-time updates; NWP gives you physical accuracy beyond about 2 hours. Dark Sky's value was in stitching those two together convincingly.

The Core Data Sources You Need

Source	Resolution	Latency	Coverage
NEXRAD Level-II	~1 km	5–10 min	Continental US
ECMWF IFS	~9 km	~6 hr (model run)	Global
NOAA HRRR	3 km	~1 hr (model run)	CONUS
Météo-France AROME	1.3 km	~1 hr	France/Europe
Open-Meteo API	1–11 km (varies)	~1 hr	Global (aggregated)

If you're building for a non-US market, the radar network availability varies sharply. Europe has reasonable coverage through EUMETNET's OPERA composite. Southeast Asia and Africa have significant gaps.

How Do You Build a Precipitation Nowcasting Model?

This is the technical centre of the problem. There are two broad approaches and they produce meaningfully different results.

Optical flow extrapolation takes successive radar frames and extrapolates storm motion. PySTEPS (Probabilistic Short-Term Ensemble Prediction System) is the open-source standard here. It's fast, interpretable, and works well for 0–90 minutes. After that, extrapolation errors compound rapidly. PySTEPS can produce ensemble forecasts, which gives you probability-of-precipitation values rather than binary yes/no output, and that matters a lot for user-facing products.

Deep learning nowcasting treats the problem as spatiotemporal sequence prediction. Google DeepMind's MetNet-3 and NowcastNet architectures process stacked radar frames through convolutional-recurrent networks (typically ConvLSTM or transformer-based variants) to predict future radar reflectivity fields. Performance on CRPS (Continuous Ranked Probability Score) and CSI (Critical Success Index) benchmarks is measurably better than optical flow beyond 30 minutes, but the models are large (MetNet-3 runs at 0.1-degree resolution globally), training costs are significant, and you need GPU infrastructure to run inference at scale.

For most product teams, a pragmatic starting point is PySTEPS for the 0–60 minute window with Open-Meteo or ECMWF output blended in beyond that. This is reproducible and doesn't require training infrastructure on day one.

Converting Radar Reflectivity to Rain Rate

Radar measures reflectivity (dBZ), not precipitation. The standard conversion is the Z-R relationship: Z = aR^b, where typical values are a=200, b=1.6 for stratiform rain (the Marshall-Palmer relationship). This matters because the coefficients vary by precipitation type (convective vs. stratiform) and can introduce systematic bias. Post-processing with gauge data (from personal weather stations or government networks) can correct this but adds complexity to the ingestion pipeline.

Real-Time Data Architecture: What Actually Has to Run

The pipeline has three distinct stages with different latency requirements.

Ingestion pulls radar data from source, typically via FTP or HTTPS from national met services. NEXRAD data is on AWS S3 in near-real-time. You process this into a common grid format (usually NetCDF or Zarr) and store it. For a global product, this ingestion layer is continuously running and the storage footprint is substantial.

Nowcast generation runs your model (PySTEPS or DL-based) on fresh radar frames and produces a forecast grid for the next 0–6 hours. For a city-scale product, this can run on a single GPU every 5 minutes. For global coverage, you're looking at distributed compute with regional model instances.

API serving translates grid forecasts to point forecasts for specific lat/lon coordinates (with bilinear interpolation) and serves them at low latency. Dark Sky's API returned results in under 100ms. Achieving that with a globally-distributed grid requires aggressive caching, edge delivery (Cloudflare Workers or similar), and pre-computation of likely request coordinates.

The mobile app layer is relatively straightforward by comparison. The interesting engineering is in the backend.

What Does the Mobile App Architecture Look Like?

The user-facing product requires a few specific capabilities that generic weather apps often skip.

Minute-by-minute precipitation chart. Dark Sky's signature feature. This is a 60-bar chart (one bar per minute for the next hour) showing precipitation intensity. Rendering this requires your API to return 60 data points per request, which is a larger payload than most weather APIs serve. You pre-compute these arrays on the backend.

Push notifications for imminent rain. This requires geofencing logic server-side: you monitor a user's last known location, check the nowcast for that point, and trigger a push notification (via FCM for Android, APNs for iOS) when precipitation is forecast to start within the next 20 minutes. The false positive rate here is critical to user retention.

Background location and data refresh. iOS has strict background execution limits. The practical approach is a combination of significant-location-change events (which wake the app on cell tower changes, not continuous GPS) and silent push notifications from the server to trigger a nowcast fetch. This avoids draining the battery while keeping the forecast current.

For the frontend, React Native works at this level of complexity. A native Swift/Kotlin implementation gives you better control over background execution behaviour, which matters specifically for the notification feature. The choice depends on how central that feature is to your product.

Accuracy, Calibration, and Managing User Expectations

Nowcasting is probabilistic. A model that says "70% chance of rain in the next 30 minutes" is correct if it rains 70% of the time in those conditions, not if it rains every time. This is a calibration problem, and it's separate from raw accuracy.

Dark Sky was not always right. Its hyperlocal framing set high user expectations that the underlying physics couldn't always meet, especially for convective summer storms that are inherently chaotic at 1 km resolution. Users remembered the misses.

The honest product decision is whether to show probability (more accurate representation of uncertainty) or binary forecasts (simpler, but misleading). Showing "light rain likely in 12 minutes" is more engaging. Showing "40% chance of rain in the next 15 minutes" is more honest. Most successful weather products now lean toward probability ranges, particularly for the 30-minute-plus window.

Conclusion

Building a Dark Sky-style app is tractable with open data and open tools. The data is available, PySTEPS is well-documented, and the mobile patterns are established. The hard parts are operational: keeping the ingestion pipeline reliable, managing model latency at scale, and calibrating user expectations against the limits of nowcasting physics.

If you're at the point of evaluating whether to build this in-house or work with a team that has done it, the right question is whether your core product differentiation is in the weather layer or above it. If it's above it, the weather layer is infrastructure and should be treated as such.

Sodio has built data-intensive real-time systems across a range of domains. If you want to talk through the architecture for your specific use case, get in touch.

---

FAQ

What is the best open-source alternative to the Dark Sky API? Open-Meteo is the closest like-for-like replacement. It aggregates multiple NWP models (ECMWF, GFS, HRRR), provides hourly and sub-hourly forecasts, and is free for non-commercial use. For nowcasting specifically, it doesn't fully replicate Dark Sky's minute-by-minute radar-based precision, but it covers most app use cases adequately.

How much does it cost to run a weather nowcasting backend? For a regional product (single country), a self-hosted PySTEPS pipeline on a mid-tier cloud instance (4 vCPUs, 16 GB RAM) runs comfortably within $200–400/month in compute. GPU inference for deep learning models adds cost; a single A10G instance on AWS runs around $1.50/hour. Storage for historical radar archives grows quickly and is often the dominant cost at scale.

Can I use NEXRAD data commercially? Yes. NEXRAD data is a US government product in the public domain with no licence restrictions on commercial use. EUMETNET OPERA data for Europe has varied terms by country. Always check the specific data provider's terms before building a commercial product on their feed.

How accurate is minute-by-minute precipitation nowcasting? Within the 0–30 minute window, modern nowcasting models achieve a Critical Success Index (CSI) of roughly 0.4–0.6 for moderate precipitation thresholds. Beyond 60 minutes, skill drops sharply and a climatological baseline often performs comparably. Convective storms are significantly harder to forecast than frontal precipitation systems.

What data is needed for a global weather app versus a regional one? For a regional app, you can use a single national radar network and one NWP model, which keeps the pipeline simple. Global coverage requires aggregating multiple radar composites with inconsistent formats, handling gaps in radar coverage with satellite-derived precipitation estimates (e.g., GPM IMERG), and running NWP at global resolution. The operational complexity is roughly an order of magnitude higher.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.