Endorphun Case Study

Problem & Context

Endorphun addresses the friction involved in creating structured running workouts within Apple’s fitness ecosystem.

Before iOS 26, custom workouts could only be created on Apple Watch via the Workout app, where limited screen space makes precise configuration slow and cumbersome. iOS 26 introduced workout creation on iPhone through the Fitness app, improving accessibility but retaining an indirect workflow: users must navigate multiple layers to reach a generic editor shared across many workout types.

For runners who train with structure—intervals, pacing blocks, repeatable sessions—this flow makes it difficult to design, review, and adjust workouts efficiently. Endorphun focuses specifically on indoor and outdoor running, providing a dedicated iPhone-based environment for creating structured workouts without navigating Apple’s broader workout hierarchy.

Design Goals

The design goals for Endorphun were defined before feature development.

  • Reduce cognitive and navigational overhead when creating workouts

  • Make the workout structure visible and editable at once

  • Respect Apple-native patterns rather than replacing them

  • Optimize for repeatable training workflows, not one-off sessions

These goals intentionally exclude roadmap promises, feature breadth, and speculative personas. They define success before implementation.

Constraints & Platform Realities

Endorphun is built within the constraints of Apple’s workout and media frameworks, which directly shape the feasible design space.

Custom workouts ultimately execute on Apple Watch via WorkoutKit. Although iOS 26 allows workout creation on iPhone, the underlying flow remains indirect and generalized. Endorphun narrows scope to indoor and outdoor running to provide a more direct, purpose-built creation experience.

Music playback introduces a separate constraint. Third-party apps cannot programmatically control the system Music player on Apple Watch. While users can listen to music during workouts, playback and track changes must be handled manually in the Music app. Automated playlist or per-interval music control is not feasible.

Endorphun also experiments with text-to-workout parsing using Apple’s Foundation Models framework. Parsing accuracy varies with phrasing and structure, which limits predictability. As a result, parsed workouts cannot be treated as authoritative without user review.

These constraints are structural, not incidental, and define what the product can responsibly offer.

Tradeoffs & Decisions

Several ideas explored during development were intentionally constrained or removed based on platform limits and product focus.

Automated music control was part of the original concept and was actively investigated. The goal was to align music playback with workout intervals via a third-party watchOS app. However, MusicKit does not allow third-party watchOS apps to control the system Music player, and no reliable workaround was found. The feature was removed entirely, and the planned watchOS companion app was canceled. Endorphun now focuses exclusively on workout creation, leaving music playback under user control.

Text-to-workout parsing is included but positioned as an assistive tool rather than a primary interaction. Users can paste a written workout description and review the parsed structure before saving it. Because accuracy is not yet consistent enough for trust-free use, explicit confirmation is required.

Subscription mechanics were explored using StoreKit but are not emphasized in the current release. While text-to-workout parsing incurs real computational cost, its current reliability does not justify gating core functionality behind payment. Monetization remains secondary until value is demonstrated through regular use.

Across these decisions, the priority was to ship a clear, reliable workout builder rather than a feature-dense product that overpromises capability.

Known Gaps & Open Questions

Several aspects of Endorphun remain intentionally open.

The current workout builder exposes a large amount of structure at once. This favors clarity and direct manipulation but can feel dense. The balance between expressiveness and cognitive load is still being evaluated.

Text-to-workout parsing is useful for accelerating setup but remains sensitive to phrasing and structure. Improving predictability is a prerequisite before treating it as a core interaction.

It is also unclear which advanced capabilities runners would meaningfully pay for versus expect as baseline functionality. Rather than speculate, monetization is treated as an open question to be informed by observed usage patterns.

These gaps are tracked explicitly because they shape what should—and should not—be built next.

Why Endorphun Exists

Endorphun exists as a focused learning artifact with ambition.

I built it to develop product and architectural judgment under real platform constraints, rather than through isolated prototypes. The goal was not to replicate Apple’s Fitness app or compete on surface-level features, but to understand how APIs, system boundaries, and user workflows intersect in a product meant for regular use.

By narrowing the scope to indoor and outdoor running, I could make deliberate tradeoffs: clarity over breadth, stability over novelty, and explicit constraints over simulated experiences. Features such as automated music control or fully reliable text-to-workout parsing were limited or deferred because shipping them prematurely would weaken the system as a whole.

This project is also shaped by use. I run, I use the app, and I iterate based on where the experience becomes unclear or inefficient. Endorphun is not positioned as finished, but as a system that reflects how I reason about product boundaries, platform respect, and incremental improvement over time.