Our own app · 2026
A capybara for every boba.
Since 2015, Lotus has mostly built software for other people. Bobara is my own. It's a calm collecting app for iPhone, iPad, Apple Watch and Apple TV, for anyone who loves boba tea, and it came out on November 9, 2026.
I love boba tea, to the point of obsession, and I love software that is well designed, made with care and made for a reason. Last year I came back from a trip to Japan that stayed with me, and got a tattoo of a capybara drinking boba. Bobara grew out of all of that. I wanted to make something special again, something that might bring a smile to someone's face in a busy day.
A capybara named Momo lives in a small hot spring on your iPhone, iPad, Apple Watch and Apple TV. Buy a boba in real life, check it in with one tap, and something arrives: a new friend for the water, a prize for the tea house shelf, or a little more time with someone who has visited before. The onsen gets the same sky you do, and it sits on your Home Screen as a widget and on your watch face as a complication.
Bobara is for other boba lovers, and for people who appreciate graphic and industrial design and well-crafted Apple software. It's a labor of love, and a little of me put out into the world.
The hope is simple. In a busy day and a stressful world, it should make you smile.
Most of the decisions in Bobara are about what to leave out. Nothing decays and nothing expires. There are no streaks, no hunger meter and no reminders asking you to come back. A long gap gives you a sleepy capybara, not a guilty conscience.
It isn't a drink tracker, a fitness app, a game or a social network. There's no currency, and the things you collect don't do anything. Every check-in brings something, and ordering the same drink again deepens a friendship you already have rather than handing you a duplicate. The app should never give anyone a reason to drink more boba than they already would.
I wanted to create something that merged my obsession with boba tea, and the passion I have for it, with my love of all things capybara, and I wanted it to be purposefully pointless, a delightful little application that isn’t trying to be useful and is only there to make you smile whenever you open it.
Years of consulting taught me the value of the discovery process I ran for Lotus clients, so I ran it on Bobara before I wrote a line of code. I checked that the market wasn't saturated and that there was real demand. I worked out who the audience was and tied that to the keywords people search for. I planned the marketing too: partnering with local boba tea shops, working with small creators on social media, and a budget for ads.
Then I prototyped the parts that were new to me, quickly, without building a whole app: CloudKit, which I hadn't used before, and a highly graphical, sprite-based 2D interface, including a comparison of SwiftUI and SpriteKit for drawing it. I kept going until every decision was captured in a plan, an architecture plan and a marketing strategy.
I did that prototyping with Claude Code, which let me try an idea or an interaction on its own, without building a whole app around it, and see it working before it went into the plan.
That made the build itself easier, and left my time for the exciting details: the graphic style and the art, and a library of sounds.
The comparison came down on SwiftUI. What the onsen needed was sprite-sheet swaps and gentle idle motion, which doesn’t call for a game engine, and starting in SpriteKit would have added weight for no benefit, while SwiftUI was the only way onto Apple Watch and one of the things I’d set out to learn properly. The whole scene is rebuilt about twenty times a second inside SwiftUI, and everything in it that moves works out where it should be from the time that has passed.
I have a full-time day job, so Bobara was built in the time around it: evenings, late nights, early mornings and lunch breaks. A lot of it was worked out on walks through the park and around my neighborhood, dictating as I went.
I built it with heavy use of Claude Code, and fully embraced agentic development. It took a few months to go from the idea to submitting it to the App Store.
Once the plan was settled, the code itself came quickly, one tagged release after another going out to testers through TestFlight.
The exciting details, once the plan was settled, were the graphic style and the art, and there was a whole world to draw: the round stone hot spring with moss in its cracks, the cherry tree and the string of red lanterns over the water, the torii gate and the bridge down in the valley, and the teahouse with its teal tiled roof, where everyone who has visited is kept on a shelf.
Having every decision captured in a plan first is what left me the time to focus on the graphic style and the assets, and to find the art itself, which I licensed from several different artists rather than commissioning.
The style started from a reference, Kao Yux’s painting of a Japanese onsen, which was exactly the feel I was going for, with the Iconfactory as the bar for craft: rich, warm and obviously made by hand. I took its materials, its warmth and its light, and above all its pairing of a day and a night version of the same scene, but not its isometric camera, because a capybara seen from three-quarters above stops looking back at you, a diamond-shaped island leaves empty corners on a portrait phone, and the teahouse would stop being somewhere you go.
The onsen is drawn by a single renderer that depends only on the scene's state and the size it's given. The app, the Home Screen widget, StandBy, the watch app and the watch complication all use it. The widget draws from a snapshot the app writes, so it never has to open the database from another process.
The Apple TV app is the same onsen, meant to be left running. There’s no check-in on it, because that stays on the iPhone. It shows the sky over a place you pick, you swipe the remote for another, and the friends you’ve met on your iPhone wander down from the tea house, read from your iCloud collection. I also gave it a slowly panning picture of the garden for the Top Shelf.
The light
The onsen is painted in one of four palettes depending on the time of day, and night is repainted, not just a dimmed version of the day.
Rather than laying a dark wash over the afternoon and calling it night, I gave night a palette of its own, so the trees and the rabbit on the rim cool to a deep blue while the lanterns keep their red and start to glow, which is how you can tell at a glance that the evening has come in.
None of the four is a separate drawing. The sky, the water and the grass are drawn in code, and every colour in the scene lives in a table by what it’s for, with one table each for dawn, day, dusk and night, blended role by role as the hours turn, so the whole valley changes its light together. The painted pieces, the trees, the rocks, the lanterns and the teahouse, are dimmed through the same table, which is how a pink cherry tree at midnight sits in the same night as the hills behind it.
Judging it was the hard part, because a colour gets looked at in whatever hour it happens to be when you change it. Two mistakes got past me that way, a shade for the grass so blue that the clumps read as blue flowers across the lawn, and a lantern glow that went out at half the light it replaced, both invisible at the hour they were made and obvious at another, which is why every hour can now be rendered side by side.
If you allow it, the sky follows your real weather through Apple's WeatherKit, using a coarse location only while the app is in use. If you decline, the sky stays clear and the app doesn't ask again.
Getting the real weather into the app was only the start, because then I had to draw everything that weather needed to feel right in Momo’s valley: the sun travelling across the sky through the day, the streaks of sunshine, dawn and dusk, and different intensities of thunderstorms, rain and wind, so that a light shower and a proper storm never look like the same thing.
Each sky is drawn over the same garden rather than painted as a scene of its own: cloud takes the sun away and moves every colour toward the colour of the ceiling, and rain falls in front of Momo, because rain behind him reads as weather in a photograph of the place rather than at it. A storm began as nothing more than heavier rain, until I split it out, and now it darkens the garden, lights the clouds with sheet lightning and answers each flash with a roll of thunder a second or so behind it.
To check a thunderstorm without waiting for one, I built a small tool that renders the onsen at any hour, in any weather and wind, without a simulator or the app, with the clock pinned so that two runs of the same code make the same picture, and another that lays every hour under every sky out on contact sheets and compares two runs pixel by pixel, so anything I didn’t mean to change stands out.
The sound
I put as much care into the sound as into anything you can see, sourcing the assets until they had exactly the calming, intuitive feel I was after, and then layering them differently at different times of day and changing them as you walk into the teahouse, so that stepping inside, out of the valley, feels calmer still.
Securing a sound library was one of the details the planning left me free to spend time on, and the sheet that lists what you’re hearing shows how many layers it became: the music, the onsen, the room you’re in, the weather, the wind, rain and thunder, and the crickets after dark, each with a lantern of its own, so you can turn any one of them down.
I didn’t record any of it myself. Instead I spent a long time listening, and searching for paid sound packs, partly because buying them supports the artists who make them.
The part I enjoyed most was the storm: a randomized loop moves it closer and farther away, and that same loop drives the lightning along with the delay and intensity of the thunder that follows it, so a storm never quite plays the same way twice.
The teahouse
Inside the teahouse, the window in the back wall is a live render of the onsen outside, live weather included, so if it’s raining where you are, you’ll see it raining through the teahouse window too.
Swipe into the teahouse and you leave the valley for a quiet room of wooden shelves, where everyone who has visited is kept, and the window is what keeps the two joined up: the same hot spring and the same weather, seen from indoors.
It mattered because it’s the one thing joining the inside of the building to the valley outside, and at first it held the art’s own flat mint panes, which turned it into a decoration. Now it’s the onsen’s own renderer, given a format of its own, a hole in a wall rather than a small card, so unlike the widget it can move. Nobody is in it, because at that size a figure is a smudge that makes you lean in at a decoration, and the glass is keyed out of the teahouse art when it’s imported, so the valley sits behind the frame and shows through exactly where the panes were.
Every check-in brings something, and when it’s someone new, a card comes up over the valley to introduce them, like Poi the raccoon, who washes things that were already clean, twice. Then it’s back to the onsen, where the rim can fill up with company: a rabbit by the bamboo spout, a red panda on the stones and a raccoon on the grass beside the teahouse steps.
Bobara came out with Momo, a cast of friends who can come to stay and prizes for the teahouse shelf, and each friend arrives with a single line of character, like Pomelo the rabbit, who tests the water with one foot, every time, and gets in anyway. The first pass at the cast and their lines was drafted with Claude, in a voice I’d already set with a few lines of my own, terse and warm rather than chatty, so that I had something concrete to react to rather than a blank page.
The onsen is the app’s main screen, and the only way to know a change to it is an improvement is to look at it. The trouble is how much of it there is: four times of day, five kinds of weather, and a phone, an iPad held both ways and a widget, each composing the scene a little differently, which comes to eighty pictures. Put together by hand that’s an hour, so it gets done once and never again, and a change ends up judged on a single daylight render on a phone.
So I wrote a tool that renders all eighty from the scene’s own renderer, with the clock pinned, and lays each surface out as one labelled contact sheet, like the one below. Every defect in one pass at the bath was invisible in that single daylight render: a green wash over the waterline, a white band across the bath in snow, a texture that read as pale foam by day and turned to dark smears at night, and a bath that outgrew the capybara on an iPad while looking right on a phone.
Given an earlier run, it also lists every picture that moved, loudest first, because the question a person is bad at isn’t whether something looks right, it’s whether anything changed that I didn’t mean to change. A change to the water that also moved the sky is exactly what gets missed while scrolling eighty thumbnails. It stays out of CI on purpose, since a difference still needs someone to say whether it’s better, and it can’t say anything about motion, because a still with the clock pinned makes an animation that has stopped look exactly like one that works.
The widget has a problem the app doesn’t. WidgetKit kills a widget that spends too much memory while it’s saving a snapshot of itself, and the only thing you ever see is a black tile on the Home Screen, with nothing to say why.
The painted backdrop, from the mountains and hills to the blossom tree, the teahouse, the clouds and the water, comes to more than forty megabytes once it’s decoded at the size a phone needs it, so the widget draws from its own copies of them at half the width and half the height, which for most of them is a quarter of the memory. A check runs on every pull request, and again before any build goes to TestFlight: it reads the size of every picture from its file, asks the scene’s code which layers have a widget copy, and fails if one is missing, if a copy was never actually made smaller, or if the total comes to more than twelve megabytes, well under half of the thirty or so a widget can really spend, to leave room for everything else it draws.
It needs no Xcode and no simulator, so it runs on Linux in seconds and fails a pull request before anybody has to rediscover the black tiles on a phone. In September 2026 it counted 9.48 megabytes, against 43.19 for the same art at full size.
There are no accounts, no sign-in and no analytics. Check-ins stay on the device and can sync through your own iCloud account. The only third-party code is crash reporting, which carries no identifier and sends nothing from development builds.
The app has been checked screen by screen at every accessibility text size on iPhone and Apple Watch, following one rule: nothing gets smaller for someone who asked for larger text. The swipe into the tea house also has a named VoiceOver action.
Bobara is $4.99. Anything sold later will show its full contents before you buy it, and nothing is left to chance.
The app is written in Swift with SwiftUI and SwiftData. The core logic lives in a package that imports neither, so its whole test suite runs in about a second without a simulator.
Audio is allowed in only two places in the project: the phone app’s sounds, forty-two of them this September, and the six short cues the watch plays in answer to something you’ve just done with a finger. A second check on every pull request fails if a sound turns up anywhere else, because the widgets and the watch complication all share the scene’s code, and a misplaced file there would weigh down every one of them. The phone’s sounds have a budget of seven megabytes, raised on purpose each time the storm, the crickets or the teahouse needed room, so the next megabyte has to be argued for. The check also makes sure every cue the watch asks for is really there, since a missing one plays nothing and says so nowhere.
