ChatGPT can generate a workout plan in seconds. The problem is that the plan only knows what was shared in that conversation. It does not automatically see completed workouts, recovery, schedule changes, or the rest of someone’s training history. People have to keep explaining themselves, and the plan becomes outdated as soon as life gets in the way.

We built the Coach in Whistle to close that gap. With permission, it can use someone’s goals, schedule, past workouts, recovery, sleep, vitals, weather and more. It can plan a week, create or adjust workouts, review progress, and explain what the data means. Because the coach can create workout plans, it stays focused every day and helps people reach their long term goals.

When planning the next week, Coach can use someone’s goals, schedule, recent workouts, recovery, and weather to create structured sessions. The result is an editable workout schedule, not a list that has to be copied from a chat. Workouts sync directly to the Apple Watch making it easy to follow through.

When life happens, people can ask their Coach to adapt the plan. A missed workout, unexpected meeting, or change in recovery can be reflected by adjusting sessions while keeping the wider goal in mind.

When reviewing past performances, Coach can look across completed workouts, compare, and explain patterns in the data. Since the training history lives in Whistle, people do not have to tell the AI about their performances, it will understand them naturally.

Long-term memory and continuity are core design principles. The coach keeps track of training intent, including goals, preferences, and decisions from earlier conversations, so people do not have to repeat themselves. It creates plans up to six months long, so every day contributes to a clear goal.

The coach can be useful without waiting for someone to ask a question. Daily and post-workout summaries provide the most important context when the app opens. We generate them progressively throughout the day so they are always ready. The chips in the text surface the key data first, letting people understand their progress at a glance without reading the full summary.

I worked on the Coach from the first sketches through release. I defined the experience, designed the system, implemented the feature, and shipped it in Whistle. This meant working across conversation design, prompts, memory, data presentation, notifications, and the technical system connecting them.

Your weather app is designed for everyday planning. It leads with temperature and rain. Outdoor workouts need a different view: wind, UV and humidity can be as important. We built Weather in Whistle to give the metrics that matter during exercise more prominence.

The main challenge was not fitting a large amount of hourly data on screen, but creating the right hierarchy and density. We designed a compact chart that brings all workout-relevant conditions into one unified timeline.

We then turn the data into short, workout-specific summaries such as “Perfect Conditions,” “High Wind,” or “High UV.” These labels make the relationship between the forecast and the planned activity clear without asking people to compare several measurements on their own.

Once the relevant metrics are in place, the Best Times feature answers the next question: When should I go? It compares the hourly forecast with suitable conditions for the workout, then ranks the best windows throughout the day. People can still explore the weather in detail, but they no longer have to do all of the analysis themselves.

I owned Weather from the first ideas through release. I researched what athletes needed before an outdoor workout, defined the information hierarchy, designed the system, implemented the feature, and shipped it in Whistle.

Finding something you misplaced often means retracing your steps and hoping the right detail comes back. Rewind began with a simple question: What if you could remember anything you had seen?

During START Hack, we built a prototype for Meta smart glasses that continuously captured the wearer's view. An embedding model organized the footage by meaning, turning an unstructured video stream into memories that could be searched.

Instead of scrolling through recordings, someone could ask, "Where did I leave my keys?" and immediately retrieve the relevant moment. A live mode processes audio and video in real time, deciding whether someone wanted to save what they were seeing or search for an earlier memory.

The central design challenge was making something technically complex feel like recalling a memory. Rewind combines background indexing with natural ways to interact, so asking, pointing, and looking were enough to find or save a moment. This made the prototype feel less like a recording archive and more like an extension of memory.

I worked alongside Riccardo on the project. He built the backend, while I designed and built the iOS app. Together, we won the hackathon's community award.

Training load helps athletes answer a practical question: How much can I train to keep progressing without getting injured? A single workout only shows today's effort. Training load shows how that effort builds over time and whether a plan stays within a safe range.

Most training load tools look backwards, they explain what an athlete has already done. But this doesn’t help them prevent overreaching. Because Whistle contains planned workout sessions, we saw an opportunity to show where training is heading, not only where it has been.

The interface brings recent and projected load into one clear view. Athletes can see the relationship between completed workouts and their upcoming plan without having to interpret a long list of metrics. The goal was not to tell people whether a workout was right or wrong, but to give them enough context to make a more informed decision.

The chart visualizes this safe range: enough load to keep progressing, without increasing so quickly that they risk injury. It gives athletes a clear target for building steadily.

For each planned workouts, Whistle intelligently predicts the distance, duration, calories, and load. This shows how each workout may shape the week before it happened. It turns workouts and training load from a report about the past into a practical tool for planning what comes next.

My cofounder Clemens and I built Training Load together. Clemens started the project with the initial research and backend implementation, I then took over for the final design.

Health data is easy to collect but difficult to understand. Sleep stages, heart rate, activity, and other measurements can say something useful, but only if people can see how they connect. We built Insights to turn that data into a clear sleep overview.

Insights brings together sleep, recovery, overnight vitals, and regularity. A focussed set of scores summarizes the data, while detail views explain where each result comes from and how one can improve. The goal was not to add more numbers. It was to make the existing data easier to act on. Every number is intentional and placed in context, so people can understand what it means for them and whether it is high, low, or within their usual range.

Scores can simplify complex information, but they also create a risk. If a score does not match how someone feels, or if its calculation is difficult to understand, it quickly loses trust. We therefore designed every score around a clear behavioral goal and made its components visible. We even added articles that explain the intention and design decisions behind the scores.

The Sleep Score combines five key metrics. The spider chart overview shows how each metric contributes, while the detail view explains what happened and what someone could change the following night. We gave consistency the most weight as we wanted to design a score that promotes a stable circadian rhythm.

Regularity deserved its own score because it directly reflects that stability. We placed more weight on wake-up time, as it is the part of a sleep schedule people can usually influence most directly. Charts like the social jet lag one help them understand where any irregularities are coming from.

Recovery connects rest with physical exertion. It gives athletes context for deciding when to train harder and when to take it easier.

Vitals compares overnight signals with a personal baseline, helping people notice when something is different from usual.

A long beta phase and many interviews shaped the final design. Some people told us Insights was the first thing they checked in the morning. That feedback made us think carefully about the responsibility we had. We made the language kinder, the scores more forgiving, and refined Regularity several times so the feature is more forgiving but still motivating.

My cofounder Clemens and I built Insights together. We shaped the product direction through research and interviews. Clemens built the backend for Vitals and Recovery, while I designed and implemented the interface and developed the Sleep and Regularity scores. We started with sketches on paper and built the final feature with Swift and SwiftUI.

FeatherKit is the SwiftUI design system behind our apps. We built it to make the right design decisions easy, keep familiar interactions consistent, and still leave enough room for each product to have its own character. Instead of replacing SwiftUI, FeatherKit extends the framework’s existing ideas.

The foundation is a set of semantic colors, type styles, sizes, and surfaces. We use system fonts so text continues to support Dynamic Type, but give each role a clear meaning: title, body, caption, or numeric value. Instead of telling a component exactly which color to use, we describe its purpose and context.

VStack {
    Text("Recovery")
        .font(.fkTitle)

    Text("82")
        .font(.fkValueLarge)
}
.fkTint(.green)
.fkColorContext(.elevated)
.fkForeground(cornerRadius: 20)

fkTint coordinates the accent color across native SwiftUI controls and FeatherKit components. The color context tells surfaces whether they are shown at the base level, on an elevated sheet, inside an alert, or over a vibrant background. Components understand the context they are presented in and are able to adjust their presentation.

We separate a component’s purpose from its presentation. FKPicker, for example, always represents a selection. The same options can appear as a simple list, descriptive cards, a segmented control, or circles for colors and icons. The logic is always the same; only the style changes.

FKPicker("Theme", selection: $theme) {
    ForEach(themes) { theme in
        Text(theme.name)
            .fkPickerTag(theme)
    }
}
.fkPickerStyle(.card) // also .list, .segmented or .dot

This gives us one predictable API without forcing every use case into the same visual shape. Style protocols also let us add a new presentation without creating another picker type or moving selection state into a screen-specific component. We use the same pattern for buttons, sliders, text inputs, gauges, labels, groups, list items and more.

The components also understand how they are composed. A list item identifies itself as a list, while a group passes its nesting level, padding, and corner radius to everything inside it. Nested groups automatically calculate a smaller concentric corner radius and alternate their surface color. The screen does not need to coordinate any of this, components understand the context they are presented in and adapt to it.

FKGroup {
    FKListItem("Profile")

    FKGroup {
        FKListItem("Notifications")
    }
}
.fkGroupStyle(.filled)

This is an important part of the system: components should not only look correct in isolation, they should remain correct when combined. Passing semantic context through the hierarchy lets FeatherKit handle spacing, surfaces, dividers, and corner radii at the component boundary instead of setting them on every screen.

FeatherKitShaders is a separate, iOS-only extension for more expressive moments. It contains reusable Metal effects such as ripples, holographic highlights, sparkles and more that are used across our apps.

Effects are still part of the system, not decoration without rules. Aurora, for example, becomes a still frame when Reduce Motion is enabled, the app is inactive, or Low Power Mode is active. Expressive design should respond to the same accessibility and performance constraints as every other component.

Some interface elements cannot be owned by a single screen. Sheets, alerts, loading states, and banners need to appear above the current content and behave consistently around safe areas, the keyboard, and dismissal. We coordinate them through one observable navigation layer that is installed at the root and available through the environment.

ContentView()
    .fkNavigationSetup()

@Environment(\.fkNavigation) private var navigation

navigation?.sheet {
    SettingsView()
}

navigation?.banner("Saved", icon: .system("checkmark"))

This lets a feature request a presentation without knowing where that presentation has to live in the view hierarchy. It also gives every app the same sheet stacking, banner motion, haptics, keyboard avoidance, and dismissal behavior.

Your body follows a predictable rhythm throughout the day. It influences when you feel energized, when your energy dips, and when you are ready to sleep. This inner clock is called your circadian rhythm.

People feel these energy changes, but the rhythm thats drives them stays hidden. Many Health apps explain what has happened, such as how long you slept or how active you were. Because the circadian rhythm is personal and predictable throughout the day, we saw an opportunity to turn it into an app that reveals this hidden biology.

Peaks estimates your rhythm using sleep and activity data from Apple Health. Our model is built on circadian research and shows your expected energy peaks and dips in a simple timeline (we built this before AI). While people are expected to be productive all day, Peaks helps them understand their natural energy peaks and dips to plan with it.

The rhythm only shifts gradually, but being aware of it matters throughout every day. That is why Peaks extends beyond the main app. Widgets, notifications, and Smart Stack integration show your rhythm when it is useful, without requiring you to open the app. Energy dips are not treated as unproductive failures. They are a natural part of the day.

To explain the agency people have in shaping their daily energy, the Influences feature shows how exercise, caffeine, or melatonin shift the rhythm. With caffeine, for example, Peaks shows how drinking coffee too late pushes your bedtime later. Optimal Times highlight useful windows for focus, exercise, and winding down. For example, it suggests when to stop drinking caffeine to avoid delaying your bedtime.

My cofounder Clemens and I built Peaks together. We interviewed people, set the product direction, and shaped every part of the experience together. Clemens built the backend for the rhythm calculations, while I implemented the interface. We used Figma for design and Swift, SwiftUI, and WidgetKit to build the app.