case study 01
software is born soft.
most never grow past it.
here's what happened when ours tried to.
— i built it. this is its version of events.
Case Study 01 · public-safe working draft · September 2026
The Architecture of Focus
Why I chose native Swift after building watad in React Native
Public-safe scope: watad is still in development. Unreleased mechanics, feature names, screen layouts, hardware internals, customer data, internal metrics, and launch dates are intentionally omitted. This is an engineering and product-architecture story, not a product reveal.
A product does not always reveal its correct architecture on day one. Sometimes the architecture has to be allowed to teach you what the product actually is. That is what happened with watad.
how we were born
no bones yet.
just movement.
react native let us go anywhere before we knew where we belonged. the shape kept changing, so we stayed changeable.
55,000 lines.
the record of every shape we tried on before landing on this one.
I started with React Native for the right reason
At the beginning, I was optimizing for uncertainty. I needed to test the product, change flows, evolve the domain model, and keep the option of multiple platforms open. React Native and Expo were a strong fit for that stage because they let me move quickly without making every early product decision a platform commitment.
The implementation grew to roughly 55,000 lines across application logic, state management, UI, and tests. The important part isn't the number itself. It's what that code gave me: a much clearer understanding of the product, its rules, its edge cases, and the interaction problems worth solving.
The original codebase became a technical specification. I am changing the implementation layer, not throwing away the knowledge.
then we felt something
a tap landed.
it still didn't
feel true.
‘feeling true’ was never decoration. for something meant to feel alive in your hand, that part is the nervous system.
press the card — this page measures your tap to the next painted frame.
Then the optimization target changed
As the product matured, I stopped evaluating the interface primarily as a collection of screens. I started evaluating it as a continuous interaction system: what happens between touch and response, how motion communicates cause and effect, how familiar platform behavior reduces the amount a user has to think about, and whether the interface gets out of the way of the task it is supposed to support.
That is why this migration is not fundamentally a language decision. It is an interaction-architecture decision.
UX is an engineering constraint, not polish
Apple describes responsive gestures as part of direct manipulation and recommends immediate feedback. Apple's current performance guidance separates discrete interactions from continuous interaction: under roughly 100ms is a useful target for synchronous work after a discrete interaction, while continuous interaction work should fit within roughly one display refresh interval — at 120Hz, about 8.3ms.
Those numbers shouldn't be turned into marketing slogans. They're reminders about the nature of continuous interaction: the system is being observed while the user is actively moving, not only after the action is finished. A small hitch that's invisible in a static screenshot can be obvious when a finger is dragging something on screen.
Google's Material Design makes a similar argument from another direction — motion as a way to communicate continuity, relationships, focus, and response to user input. Apple and Google use different design languages, but both treat responsive feedback and coherent motion as functional parts of interaction, not decorative effects.
For a focus-oriented product, that distinction matters. If the interface keeps calling attention to its own mechanics, it becomes part of the distraction. The interface should support the user's action without becoming the subject of the action.
growing meant carrying more
we were wearing
four skins
at once.
each skin made sense on its own. worn together, we could barely move.
Why the cross-platform layer became less attractive
I don't think the correct conclusion is that React Native is slow or that cross-platform apps can't feel excellent. That would be a poor engineering argument. The more useful observation is about abstraction cost.
When the desired experience follows one platform closely, the stack can become a chain of translations: cross-platform UI, custom interaction behavior, animation or rendering layers, platform-specific adaptations, and additional integration work. Each layer can be reasonable on its own. The cost appears in aggregate.
At that point, I was less interested in finding another layer that could reproduce the platform behavior, and more interested in using the platform behavior directly.
so we shed a skin
we grew
a spine.
swift and swiftui — one skeleton, instead of four borrowed skins we kept re-fitting.
— still just a peg. it just has a spine now.
Why native Swift became the logical next experiment
Swift and SwiftUI are attractive because they sit inside a coordinated Apple ecosystem. SwiftUI, UIKit, Core Animation, haptics, Metal, accessibility APIs, system navigation, materials, widgets, notifications, and watchOS aren't separate destinations I have to stitch together conceptually — they're parts of one platform model.
That changes the engineering question from "how do I recreate this platform behavior?" into "how should watad use the platform behavior that already exists?"
What I'm not claiming: native code doesn't automatically eliminate bugs. SwiftUI doesn't automatically produce good design. Moving to Swift doesn't guarantee lower battery use or a particular latency. A native implementation still requires device testing, accessibility work, profiling, and product judgment. This isn't evidence that every cross-platform project should go native — it's a decision specific to where this product landed.
the ground started helping
the ground keeps
getting smarter.
the platform adapts.
we decide how.
apple keeps making the ground more adaptive. we build on that instead of pouring our own, every time, forever.
The platform is becoming more adaptive — and that's the part that surprised me most
Apple's current guidance treats the newest device form factors as having multiple display regions and poses rather than fixed screen assumptions — flexible layouts, size classes, and adaptive system containers instead of hard-coded positioning. That isn't an automatic guarantee that any given app will look correct across configurations. The app still has to decide what moves, what resizes, and what stays important as the available space changes.
The platform adapts. watad decides how.
That's a better definition of future-proofing than simply saying the code is native. I'm choosing a foundation that can participate in Apple's evolving interaction model instead of repeatedly recreating it from outside — and one native foundation now means fewer separate architectural worlds to keep synchronized as new device targets show up.
so what about android
android isn't
cancelled —
it's queued.
the same argument cuts both ways. we'd rather learn one platform properly than approximate two — so android gets android, not a port of this.
So what happens to Android
The obvious objection to leaving cross-platform is that you've just doubled your future work. That's a fair reading, and it's worth answering directly rather than leaving it implied.
Android isn't cancelled. It isn't first.
iOS goes first because that's where I could go deepest, soonest — one platform learned properly beats two approximated at the same time, and the interaction quality this product depends on is the thing that suffers most when it's approximated. When Android's turn comes, it gets the same treatment: built natively, on its own platform's terms.
That's also the honest reason Google appears in this write-up at all. Material's guidance on motion — continuity, relationships, communicating response to input — makes the same argument Apple's does from a different direction, and it's the same argument I'd be building against on Android. Each platform has its own ground, its own conventions, its own idea of what a gesture should feel like. Building on the real one beats translating a foreign one, and that logic doesn't stop being true when the platform changes. So Android gets Android, not a port of this.
The shared deterministic core is what makes that affordable: the rules, state transitions, and domain logic don't care which platform renders them. It's the interaction layer that has to be native, and it's the interaction layer that was never really portable in the first place.
where we actually are
mostly alive.
not finished.
we'll judge it on whether it feels continuous in your hand — not on the fact that we rewrote it.
The rewrite is not a victory lap yet
The native project is still in progress. The architecture is being established in stages, the deterministic core is being ported from existing, already-proven logic, and the interface is being rebuilt one area at a time. The React Native client is being treated as a reference while the native implementation earns its continuation.
Where things stand right now: the native iOS project builds and runs in the simulator. The deterministic Swift core has been ported from existing logic, with 17 tests currently passing. The native design-token foundation is in place, the project targets a modern iOS baseline with strict Swift concurrency, and the real product UI and native data layer are still being built.
That distinction matters. The architecture has earned a serious trial. It hasn't earned a victory lap.
The real benchmark
A rewrite should be judged by evidence, not by the excitement of starting over. The questions that decide whether this migration deserves to continue:
- Does the interaction feel more continuous on a physical iPhone?
- Are state transitions and relaunch behavior deterministic?
- Is the implementation easier to reason about and refine?
- Do accessibility and platform conventions improve rather than regress?
- Can the shared core support future Apple targets without duplication?
- Does the gain justify the temporary cost of maintaining a frozen cross-platform client?
case study 01
we're not done
growing.
i'll keep writing it down as it happens — including the boring parts, and the parts that don't work.
watad.ygbrews.com
@watad.proof · #drivethefloor
Agentic engineering changes the execution cost, not the judgment
The learning curve is real. Moving to Xcode means learning Swift, SwiftUI, concurrency, package boundaries, previews, signing, testing, and a large set of Apple platform conventions.
What's changed is the cost of executing the repetitive parts. Claude Code, Codex, and Google Antigravity can inspect the existing implementation, trace dependencies, translate deterministic logic, scaffold tests, and explain unfamiliar Swift and Xcode patterns — keeping the work divided into smaller, reviewable units.
The boundary is important: the agents don't decide what watad should feel like. They don't decide which product behaviors survive the migration. They don't prove that a gesture works on a physical device. Those stay architectural and product decisions — mine to make and mine to own.
The broader lesson
I wouldn't describe this as React Native failing or Swift winning — that framing is too shallow. React Native was the right architecture while I was optimizing for discovery, speed, and optionality. Native Swift became the better experiment once the product started optimizing for interaction fidelity, platform behavior, and deeper integration with one ecosystem.
The right abstraction is contextual. The job of an architecture isn't to prove that its technology is superior — it's to make the product easier to build, easier to reason about, and easier to experience.
The product is still cooking. I am changing the kitchen before I serve it.
This is Case Study 01. The result of the migration will be judged by the work that follows.
Technical references
Claims about interaction responsiveness, gesture design, adaptive layouts, and platform behavior are grounded primarily in Apple's own developer documentation, with Google's Material Design used for the motion and continuity framing, and Nielsen Norman Group for historical response-time research.
- Apple Developer — Human Interface Guidelines: Gestures
- Apple Developer Documentation — Improving app responsiveness
- Apple Developer — adaptive layout guidance for multi-region/multi-pose devices
- Google Material Design — Motion
- Nielsen Norman Group — Response Times: The 3 Important Limits
Human brain. AI as foundation.
watad is built by one person. Claude Code, Codex and Google Antigravity are in the room for most of it — they inspect, trace, translate, scaffold and test — and this case study was drafted with them too. What they don't do is decide. What watad should feel like, which behaviours survive, what gets written down and what stays private: those calls are made with my own human brain, and I own them.
The promise, in plain words: what you type into watad is yours. The app is built to hold one thing for you, not to watch you. These case studies will describe engineering, never a real person's floor. And the privacy page says exactly what is kept and why, in one screen. If the line between the human and the AI ever feels unclear, write to hello@watad.ygbrews.com — I read those myself.
— Yashasvi, founder of watad
The next case study will find you. One email per case study, nothing else.