DewLogic is officially available on the iOS App Store!

Built with a local-first philosophy, DewLogic aggregates multiple weather sources into a clean, sovereign interface designed for accuracy and privacy. No ads, no tracking just the data you need.

I started testing as a favor but I didn't really have any issue with the weather apps that were already installed on my phone. Fast forward and I've actually uninstalled the other apps, moving exclusively to DewLogic. It has everything I might need, current conditions, future forecasts, radar, etc but a lot of apps do that. DewLogic presents it in a manner that feels more intuitive to me and I appreciate that. It's very customizable and has proven to be pretty accurate with a lot of the predictions it offers up in the insights tab.

Your backyard has better weather data than the airport
The official weather observation for my town comes from an airport 23 miles away, at an elevation 600 feet lower than my house, on the other side of a ridgeline. When it says "partly cloudy, 72 F," I have no idea whether that applies to me. Half the time, my yard is in fog while the airport is in sunshine. All winter, the airport sits above the inversion layer and reports temperatures 15 F warmer than anyone in the valley actually experiences.
Meanwhile, my neighbor has a $280 Davis Vantage Pro weather station sitting on a pole in their backyard. It reports every 5 minutes. It's 400 feet from my kitchen window.
Which one do you think knows whether it's going to rain on my kid's soccer game?
The citizen weather network that already exists
There is a staggering amount of weather data being collected by non-government sources right now, and almost none of it shows up in mainstream weather apps.

• PWS networks (Personal Weather Stations): WeatherUnderground, PWSWeather, and Ecowitt.net host hundreds of thousands of homeowner-operated stations globally. Most are consumer-grade ($150 $500), some are research-grade ($2,000+).

• CWOP (Citizen Weather Observer Program): A ham radio and enthusiast network with 9,000+ quality-controlled stations feeding NOAA.

• Mesonet / IEM (Iowa Environmental Mesonet): An aggregation of 45+ regional mesonets (agricultural, university, state DOT, research) typically at 5-minute cadence with calibrated sensors.

• Soil sensors: Agricultural networks tracking soil temp, soil moisture, and leaf wetness at depth. Wildly useful for frost prediction and growing-degree-day math.

• OpenSenseMap / Netatmo: Urban citizen science sensors, often in schoolyards and parks.

Any given suburb has dozens of these within a 5 km radius. Your actual official weather station has one airport METAR every hour.
Why most apps ignore all of this
Because raw PWS data is noisy. A station in direct sun over asphalt reads 10 F high. A station under a tree reads 3 F low and never sees rain. An Ecowitt unit that lost its Wi-Fi last Tuesday is still showing last Tuesday's conditions.
The usual shortcut is "just don't use them." Mainstream apps stick with airport METARs and global models because those are uniform and predictable, even when they're uniformly wrong about your specific location.
What we actually do with it
DewLogic pulls from all of the above and then does the work of making them trustworthy:

• HardwareTier bonuses. A professional sensor (Davis, Campbell Scientific, Vaisala) gets a +5 fidelity bonus. A consumer sensor gets 0. Unknown/ambiguous gets -5. This lets the blending engine trust better equipment more without kicking out the cheap ones.

• Anomaly rejection. If your reading disagrees with the reference by more than 3 C, you're excluded from this blend cycle. No one station can hijack the answer.

• Recency penalties. Stale data gets dropped. A sensor that hasn't reported in 30 minutes doesn't vote on current conditions.

• IDW blending. What survives gets weighted by distance and tier and combined into a single Virtual Station reading at your exact coordinates.

We run the AI on-device so your weather never leaves your phone
A lot of apps have bolted on "AI weather insights" in the last year. Almost all of them work the same way: the app sends your location, your recent queries, and the weather context to an OpenAI or Anthropic endpoint, then prints what comes back.
That's fine for a novelty. It's not fine for a tool you check every morning, in every room of your house, with your location pinned to your exact coordinates.
DewLogic takes the opposite approach. The primary LLM path is local inference running inside the app. Cloud providers are a fallback, not the default.
What that actually means
When you ask DewLogic "should I cover my tomatoes tonight?" the question, your location, and your forecast never leave the device. A quantized language model (GGUF format, running on llama.cpp via Rust) reads the weather context and writes the answer on your own CPU or GPU.
No API bill. No account sign-up. No telemetry on what you asked. Works on a plane.
The stack
Dart (Flutter UI)
|
| flutter_rust_bridge FFI
v
Rust (dewlogic_core)
|
| momusdev_bridge
v
TaskEngine -> InferenceEngine -> llama_cpp (GGUF)
The model loads at startup through an asset manager we built specifically to handle multi-gigabyte downloads, integrity checks, and swapping between models without restarting the app. You can pick which model runs. Smaller ones (1 to 3B params) are fast enough for live conversation on mid-range phones. Larger ones (7 to 13B) run on desktops and newer flagships.
Why go through the trouble
Three reasons, in order:
1. Privacy. Weather data is location data, and location data over time is behavior data. We don't want that pipe, and we don't want to be the company that eventually sells that pipe to someone else.
2. Availability. The places where specialty weather apps matter most (farms, trails, boats, backcountry, construction sites, remote properties) are the places with the worst cell coverage. A weather assistant that stops working when LTE drops is worse than no assistant.
3. Cost to the user. Cloud LLM calls add up. A free app that silently costs a cloud provider $0.02 per query is either going to serve you ads, limit your usage, or raise a subscription wall. Local inference removes that entire category of decision.
Trade-offs, honestly

• App size is larger because models have to live somewhere. We keep the base install reasonable and let you download your preferred model on first run.

• First-token latency is worse than a server with an H100. It's fine in practice, but if you're used to ChatGPT's speed on a data-center GPU, set expectations.

• Quality ceiling is lower than a frontier cloud model. A 7B quantized model is not GPT-5. For weather reasoning tasks (summarizing a forecast, scoring conditions for an activity, explaining what a pressure trend means) it's more than enough, and we can feed it structured context from the Decision Engine so it doesn't need to invent facts.

Cloud as fallback
If you want to use Claude, GPT, or Gemini, you can plug in your own API key. Some tasks (long narrative summaries, complex multi-factor analysis) genuinely benefit from a larger model. That path exists. It just isn't the default, and we aren't in the middle of it.
Running local inference in a consumer app has more footguns than it looks. Happy to go deeper on model selection, quantization trade-offs, or how we handle model switching without restarting.

Building a weather app in Flutter + Rust
DewLogic is a Flutter app on the outside and a Rust engine on the inside. The UI, state management, networking, and platform plumbing are all Dart / Flutter. The hot-path work (IDW blending, isopleth contour generation, model inference, asset management) is all Rust, called over FFI via flutter_rust_bridge v2.
This post is about why, how, and the footguns.
Why two languages
Flutter is exceptional at one thing: a single UI codebase that actually ships to every target (iOS, Android, Windows, macOS, Linux, Web). For a weather app that wants to be on every device you check weather on (phone in the morning, tablet at the barn, desktop in the home office), that's non-negotiable.
Rust is exceptional at a different thing: tight numeric loops, predictable memory layout, and frictionless FFI. When your app is doing IDW blending across dozens of observations per render, generating thousands of isopleth segments per map update, and optionally running a local LLM, you want that code in a language built for it.
Dart is fast enough for most app work and notably improved with WasmGC and AOT compilation, but "fast enough for app work" is not the same as "fast enough for numerical inner loops at 60 fps." Rust is.
How Flutter Rust Bridge works
FRB scans rust/src/api/*.rs for exported functions and generates matching Dart files in lib/src/rust/api/. Every exported function gets a sequential funcId in the generated dispatcher. When the Dart side calls the generated binding, it passes that funcId over FFI to a Rust dispatcher, which looks up the correct function and invokes it.
Our current surface:

• asset.rs, Dart binding: asset.dart; Purpose: Model catalog, download, integrity check, swap

• chat.rs, Dart binding: chat.dart; Purpose: Local LLM chat completion

• idw_engine.rs, Dart binding: idw_engine.dart; Purpose: IDW blending, anomaly detection, Virtual Station math

• isopleth_engine.rs, Dart binding: isopleth_engine.dart; Purpose: Contour generation for snow, ice, and future overlays

All calls go through a Dart-side facade (DewlogicBridge) that implements an abstract interface (AgentBridgeFacade), which means the rest of the app never touches the generated bindings directly. This matters for testing: we can swap in a pure-Dart mock bridge in tests without touching a single Rust line.
The footgun we hit hardest
If you add, remove, rename, or change the signature of any Rust API function, all existing function IDs can shift. The generated Dart bindings will compile fine. Your app will run. Every FFI call will hit the wrong Rust function.
The fix is a rigid ritual:
1. Edit Rust API. 2. Run flutter_rust_bridge_codegen generate. 3. Immediately rebuild the Rust binary (flutter run -d windows triggers cargo build).
If you skip step 3 and hot-reload the app, chat completion will dispatch to the IDW engine, the model download will try to execute contour math, and nothing will make sense. The symptoms are nonsense values, panics in unrelated code, or silent wrong answers. We learned this the hard way.
This rule now lives at the top of our CLAUDE.md for any agent touching the repo.
Feature flags across four build systems
The Rust crate uses Cargo features to gate heavy optional dependencies:

• inference pulls in llama_cpp for local LLM

• vectordb pulls in LanceDB and fastembed for RAG

From weather data to decisions
"72 F and partly cloudy" is data. It is not an answer to the question you actually asked.
The question you actually asked was one of these:

• Should I spray the orchard today?

• Is tomorrow good for a long run?

• Will the wedding ceremony be comfortable outdoors at 4 PM?

• Is it safe to take the boat out Saturday morning?

• When is the golden-hour light going to be worth driving an hour for?

• Should I cover the tomatoes tonight?

• Is this a migraine-risk day for my kid?

None of those are answered by a temperature and an icon. They're answered by a small model that takes the weather context and applies a domain rule set. That's what the DewLogic Decision Engine is.
The modules
We ship several first-party decision modules, each with its own scoring logic:

• Activity scoring. Running, cycling, hiking, tennis, golf, pickleball, kayaking, skiing, dog walks, and more. Each activity has a different comfort envelope and different blocking conditions.

• Agriculture. Spray windows (wind, humidity, rain proximity), growing-degree-day accumulation, frost risk windows, evapotranspiration, leaf wetness duration.

• Hazard analysis. Heat index, wind chill, lightning proximity, flash flood risk, wildfire smoke, ice events.

• Health advisory. UV exposure, pollen count, air quality, pressure swings (migraine risk), humidity effects, user-configurable sensitivities.

• Marine analysis. Small craft advisory thresholds, sea state, wind direction vs. fetch, fog risk.

• Photography planning. Golden hour timing, cloud cover quality at sunrise and sunset, atmospheric clarity, storm chase windows.

• Recommendation generation. Combines the above into a ranked list of "good for" and "avoid" suggestions tailored to the day.

Forecasting snow and ice as contours, not icons
Most weather apps tell you it's going to snow with a small snowflake icon and a number of inches. That's fine when you only care about your own address. It's almost useless when you care about a route, a region, or a point on a map that isn't where you are.
The meteorology community has always visualized precipitation as isopleths: contour lines and fills that show how a quantity varies across space. Snow totals, rainfall, wind speed, pressure, all of it. The problem is that isopleth maps have traditionally lived on TV weather graphics and government products, not in consumer apps.
DewLogic renders them live, anywhere on Earth, with a user-adjustable time window.
What you see
Open the map, tap "Snowfall Forecast" in the Winter section, drag the hour slider to whatever window you care about (anything from 6 to 72 hours). Within a second or two the map fills in with colored contours showing expected snow accumulation over that window.
levels (cm): [0.5, 1, 2.5, 5, 10, 20, 40]
Areas below 0.5 cm are fully transparent so the contours only appear where meaningful snow is expected. Same interaction for the Ice Forecast toggle, with a purple / magenta scale and smaller thresholds (0.1 to 15 mm), because a tenth of a millimeter of glaze on a road is already a hazard.
The pipeline
This is not a tile-server product. We're generating the isopleths client-side from primary hourly forecast data, which is the only way to make the time window user-configurable.
Open-Meteo hourly (free, no key, global 72-hour data)
-> HourlyForecast { snowfallCm, iceMm }
-> MapDataProvider tile cache
-> getSnowfallForecastPoints(hours:)
-> IsoplethEngine (Rust IDW contour generator)
-> MapLibre GeoJSON fill layer
For each tile we've already cached for the Virtual Station, we already have 72 hours of hourly forecast data in memory. Summing snowfall across a user-selected window is a Map lookup plus an addition, per-tile. We cache those sums keyed by tile ID and hour window so re-rendering the same window on the same tiles is nearly free.
The contour generation itself runs in Rust through flutter_rust_bridge. IDW interpolation across the tile's forecast points, then marching-squares contouring at the preset levels, then back to Dart as GeoJSON. MapLibre renders the GeoJSON as a fill layer on top of the basemap.
Ice: derived from WMO codes
Ice is the subtle one. Open-Meteo doesn't give us a direct "ice accumulation" field, but it does give us hourly weather_code and precipitation mm. WMO codes 56 and 57 are freezing drizzle. 66 and 67 are freezing rain. When those codes are active, we treat the hour's precipitation as ice accumulation at a 1:1 liquid-to-ice ratio (a deliberately conservative assumption).
It is not a frontier-lab ice model. It's a fast, global, good-enough approximation, and it visualizes better than staring at a list of WMO codes in a forecast.
Why not just use the NOAA WMS tile?
NOAA has a perfectly good ice accumulation WMS layer (ndfd.conus.iceaccum). We support it as an overlay. But it has three limitations that drove us to build our own:
1. CONUS only. Doesn't exist outside the US. 2. Fixed time window. NOAA decides the aggregation, not you. 3. Server-side colors. The legend has no gradient control because the tiles arrive pre-colored.
Our isopleth version works globally, respects whatever hour window you choose, and uses a color ramp consistent with our snow visualization. We enforce mutual exclusion with the WMS layer so you don't end up with two ice overlays stacked on top of each other.
The slider behavior is intentional
When you drag the hour slider, the label updates live but the contours do not. Only when you let go (on onChangeEnd) do we trigger a recomputation.
This is a small UX decision with a noticeable effect. Recomputing contours on every drag event is possible but visually noisy. Deferring to release feels more deliberate and keeps the map stable while you're still choosing a value.
If you want to nerd out on the IDW parameters, the marching-squares implementation, or why we landed on these specific accumulation levels, ask.

Why every weather app is giving you a different forecast
Open three weather apps right now. The temperature will disagree. The rain chance will disagree. Tomorrow's high will disagree.
This isn't a bug. It's a business decision. Every mainstream weather app picks one data source, usually whichever global model their provider happens to resell, and hands you that answer with confidence. Apple ran on Dark Sky, then The Weather Channel, then their own blend. Google uses weather.com. AccuWeather uses AccuWeather. Each of them is looking at a different grid cell from a different model and rounding to a different decimal.
The honest answer is that no single source is right. Global models (GFS, ECMWF, ICON) are optimized for a 10 to 30 km grid cell, so the forecast for your zip code is an interpolation, not a measurement. Regional models do better locally but worse globally. Personal weather stations are precise but can be miscalibrated, in a shaded corner, or sitting on an asphalt roof. Airport stations are well-calibrated but miles away.
What we do instead
DewLogic blends 25+ sources at your exact coordinates and produces what we call a Virtual Station: a single set of values that represents the weighted truth from every sensor and model in range.
The blending is Inverse Distance Weighting with a twist: every source has a DataTier weight that reflects how authoritative it is for that measurement.
PWS 10.0 // backyard stations (nearby + high cadence)
CWOP 4.0 // ham radio weather network
Soil sensor 3.0 // agricultural/ground truth
Surface station 1.5 // airport METAR
Gov regional 1.2 // HRRR, NAM, national mesoscale
Global model 0.8 // GFS, ECMWF, ICON
Closer and higher-tier sources pull the blend toward themselves. A PWS 400 meters away will dominate the ECMWF grid cell it sits inside. An ECMWF cell 10 km away will dominate when there's no other ground truth.
Handling bad data
Individual stations lie. A sensor in direct sun reports 110 F on a 75 F day. We run a sanity check against a reference (nearest well-sited station plus nearest model). Anything more than 3 C off gets dropped as an anomaly. Sources that disagree catastrophically with everyone else don't get to vote.
We also damp model weight as local density increases: max(0.1, 1 / (1 + localCount)). One nearby PWS already tells us more than ECMWF. Ten nearby PWS make ECMWF almost irrelevant for current conditions (forecasts are a different story, since models still rule those).
The result
Your Virtual Station knows things no single-source app can know. It knows your backyard is 4 F warmer than the airport because two PWS next door both agree. It knows the rain gauge that just reported 2 inches in 5 minutes is broken because no other nearby source saw it. It knows the ECMWF grid cell has you in a valley even though the actual valley is two ridges over.
This is what weather data should look like when you stop asking one source to be right.
Curious about the blending math, anomaly detection, or how we weight specific networks? Ask below.