Designing and building Climate for iOS

Why build another weather app?

Most weather apps lead with data and ask people to decode it. I wanted Climate to lead with a feeling. The interface changes with the temperature, moving from icy blues through greens and yellows to deep heat reds, so the shape of the day is visible before anyone reads a number.

That idea became the product rule: dense forecast data should feel immediate, not clinical. The visual system had to carry an hourly timeline, a 10-day outlook, cities in different time zones, severe-weather context, and the practical question people ask before leaving home: what should I wear?

What did I own on Climate?

Everything from the first frame to the TestFlight build. I set the product direction, designed the interaction model and visual system in Figma, created the light and dark experiences, illustrated the onboarding, produced the App Store campaign, and wrote the iOS app in SwiftUI.

Owning both sides made the loop unusually tight. A spacing, contrast, or state problem found in the simulator went back into the design system; a promising interaction in Figma was tested against real WeatherKit data before it became precious. There was no handoff gap because the design and the implementation evolved together.

How does temperature become the interface?

Climate uses a continuous temperature spectrum rather than a handful of decorative themes. Each forecast row receives its color from the actual temperature, with a deliberately tuned stop for every degree across the useful range. The foreground treatment responds to luminance so text stays legible as the palette moves from deep blue to bright yellow to saturated red.

Light mode lets that spectrum fill the forecast. Dark mode is intentionally calmer: neutral black rows carry a narrow temperature strip at the edge, preserving the information without turning an overnight forecast into a wall of color. Both modes share the same information architecture, interaction targets, and data—not two loosely related skins.

How do hourly and daily forecasts stay scannable?

The core screen has one stable structure. A segmented control switches between hourly and daily views; the selected period expands into a weather overview, four key stats, and a path to deeper detail. The remaining periods become compact rows, so the user can scan the whole sequence without losing the current moment.

Saved locations use the same model. Riyadh, Dublin, San Diego, Fairbanks, and a current GPS location can each be viewed as a page, while the locations screen supports city search, reordering, and unit preferences. Color makes very different climates comparable without flattening them into the same generic card.

What details make Climate useful beyond the forecast?

The detail views cover precipitation, humidity, UV, visibility, pressure, wind and astronomy while keeping the first decision simple. Weather advisories link back to their official source. Unit and clock settings are localized and persist between launches. Weather-aware notifications are planned from the latest cached forecast and deduplicated so a severe alert does not return every time data refreshes.

I also designed and built an outfit engine. It translates temperature bands, precipitation, wind, humidity and UV into practical suggestions, then adapts them to a saved wardrobe preference. It is a good example of the product’s larger point: the best forecast is not more data; it is a clearer next decision.

How did I design onboarding for light and dark mode?

The onboarding teaches one mental model per screen: live temperature color, hourly and 10-day range, details and advisories, outfit guidance, then the subscription choice. Each illustration is built from the same visual ingredients as the product—weather symbols, chromatic glow, compact metric chips, and tactile controls—so the introduction feels like Climate rather than a separate marketing layer.

I designed every scene in both appearances. The light set is airy and atmospheric; the dark set uses controlled glow and stronger depth. Copy, pagination, actions, plan selection, restore paths, and the locked forecast state were treated as one complete journey rather than isolated screens.

What is behind the SwiftUI build?

Climate is a native iOS application targeting iOS 17 and later. SwiftUI owns the interface; Apple WeatherKit supplies live forecasts and official attribution; Core Location and MapKit handle GPS, reverse geocoding, and city search; UserNotifications powers configurable weather reminders. Async refresh work preserves location identity and cached timestamps, and cancellation guards prevent stale results from bringing back a deleted city.

The release work is part of the product work. The app has automated unit and UI coverage, Fastlane screenshot support, accessibility labels for key controls, signed Debug and Release verification, and a successful TestFlight 1.0 build 11 upload. I did not stop at a polished prototype—the design decisions have production code behind them.

What does Climate say about how I work?

I am most useful on products where interface quality and implementation quality need to reinforce each other. Climate shows the full range: product framing, interaction design, visual systems, illustration, accessibility, API integration, state management, testing, release hardening, and marketing assets, all held by one coherent point of view.

That is the kind of end-to-end mobile work I want to do more of—designing and building native iOS experiences today, and bringing the same systems thinking to Android as that practice grows.