Opening Our Devlog
Why we're starting a public devlog for Step FWD, what we'll cover, and what to expect from these posts.
We’re building Step FWD in relative quiet. No waitlist hype, no countdown timers, no “launching soon” banners refreshing every week. Just a walking app being built the way we think it should be built — carefully, and with intention.
But building in silence has a cost. The decisions behind a product are invisible by default. Why does Step FWD store everything on-device? Why no social features? Why did we build a voice coach with 157 audio files when most apps ship a notification? Those choices matter, and they deserve more than a bullet point on a marketing page.
What this devlog is
This is our engineering and design notebook, made public. We’ll write about the technical decisions, the design trade-offs, and the occasional dead end that shaped Step FWD into what it is.
Some posts will be deeply technical — route segmentation algorithms, on-device AI pipelines, dual-source step reconciliation. Others will be about design philosophy — why we chose not to build badges, why our streak system doesn’t punish you, why we think walking apps should respect the walk.
What it isn’t
This isn’t a changelog (yet). We haven’t launched. When we do, this devlog will evolve to cover updates and new features. But right now, it’s retrospective — a look back at decisions we’ve already made, written honestly about what we built and why.
Why now
We’re approaching a point where the app is nearly feature-complete. The core systems — step tracking, GPS routes, voice coaching, on-device insights — are built and tested. Before the noise of a launch, we wanted to document the thinking while it’s still fresh.
We’re also doing this because we believe transparency builds trust. If you’re going to use an app that tracks your walks and stores health data, you deserve to know exactly how it works. Not in vague privacy-policy language, but in plain engineering detail.
What’s coming
Over the next few posts, we’ll cover:
- The voice coach system — how 157 audio files, milestone detection, and anti-repetition logic create a companion that doesn’t get annoying
- On-device AI insights — seven statistical engines and Apple’s Foundation Models, all running locally
- GPS route tracking — segmentation, pause detection, accuracy filtering, and the battery trade-offs behind it
- Dual-source step tracking — why we combine HealthKit and CMPedometer, and how we reconcile them
- Privacy architecture — SwiftData, zero cloud, zero accounts, and what happens when you delete the app
- Designing without gamification — streaks without guilt, no badges, no leaderboards, and what “designed for adults” actually means
Each post stands on its own. Read them in order or pick the topics that interest you.
A note on honesty
These posts are being written after the fact. We didn’t keep a devlog from day one — we were too busy building. Everything here reflects real decisions and real code, but we’re being upfront that this is retrospective documentation, not a live diary.
We’ll keep writing as we move toward launch and beyond. If there’s something specific you’d like us to cover, we’d genuinely like to hear about it — reach out through our contact page.
Let’s walk through this together.