Yesterday I went live to answer a simple question:
How far can we get toward a native Fizzy app in under an hour?
If you missed it, the full recording is right above. Thank you
, , and everyone else for tuning in!What started as a quick experiment turned into a fun walkthrough of the entire setup pipeline for a brand-new Hotwire Native iOS app. We went from an empty Xcode project to a working MVP. We even built a way for the app to remember which Fizzy account you last opened.
Here’s a quick recap of what happened.
A new Xcode project
I kicked things off with a short tour of the Fizzy web app, Basecamp’s new take on issue tracking and Kanban. It’s already mobile-friendly, so it made for a perfect candidate to wrap in a native shell.
From there, we jumped straight into Xcode. We:
Created a brand new project
Cleared out Storyboards and set up my usual sane defaults
Added Hotwire Native and confirmed the app could load the root URL
That alone is enough to get 80% of the way to a fully functioning mobile app. Hotwire Native handles so much of the navigation and rendering that the app already felt native, even in its barebones state.
The interesting part: remembering your account
The rest of the stream turned into a small architecture exercise.
Fizzy supports multiple accounts, and on the web you choose which one to open when you visit the site. But on mobile, tapping the app icon should take you straight back into the account you were last using.
So we added persistence for the account slug on device. That way, whenever the app launches, it can construct the correct URL automatically and drop you right back into the right workspace.
Under the hood, Fizzy uses middleware to enable URL-based multi-tenancy. The middleware adds a path to every URL when an account is selected.
For example, when viewing card number 11 on my account then the bold part of the URL is my account slug:
https://app.fizzy.do/6100621/cards/11And my implementation worked! But after building it live, I had the same thought many of you probably did…
In hindsight, a server-side cookie is better
This is the benefit of streaming: you hear your own reasoning out loud.
Storing the slug locally works fine, but you can almost always simplify business logic by letting the server make the decisions. A cookie that tracks your most recently used account would mean the client always hits the same endpoint on launch, and the server gently redirects you to where you need to go.
Which means less native code and less state to manage. If I were to keep going on the app, that’s the approach I’d explore next.
Want more of these?
I’m planning a few more live builds like this: short sessions where we explore Hotwire Native patterns, ship something small, and talk through the tradeoffs in real time.
Also, paid members get access to deep dives, office hours, and early previews of what I’m building next. If you want more content like this, consider upgrading.
