I published a new app for family household management - Family Superapp. It’s available on iOS, Android, Mac, Windows, and Web. My wife and I use it every day for our grocery runs, family calendar, location tracking, budgeting, etc. That’s what I’ve been cooking up the last 2 months since my last couple of posts.
This was the big thing I was working on and alluding to. I’m also participating in the RevenueCat Shipaton 2026 with this app and that’s why I had to be in “the bunker” for about 2 months to finish the app on time for the submission deadline of September 30th 2026. I made it! But not without some tribulations lol.
Here’s a little video overview I made for the competition:
After building the app the biggest challenge, believe it or not, was to publish on Google Play Store for Android rather than publishing on App Store for iOS. My Play Store submission got stuck in review for several days (ultimately took about 3 weeks) and I had to quickly pivot to publish on the Galaxy Store instead (thank you to the Galaxy Store team for the quick turnaround!!!). The conditions to participate in the Shipaton were to have the app be published in the App Store and in the Play Store or Galaxy Store. I made it on time with 2-3 days to spare 😅.
How did I build the app?
What you all are probably interested to hear is how did I build the app and especially how the hell did I make it work on 5 platforms all at the same time!?!? What sorcery is this!?!? React Native trickery!?!?!? Some other sacrilege???
Well, the answer is yes, sort of. It’s RIBs architecture with KMP (Kotlin Multiplatform) + fully native view layer: SwiftUI/Swift, Jetpack Compose/Kotlin, React/Typescript, AppKit/Swift, and Compose Multiplatform/Kotlin for the Windows UI (on that later).
RIBs
As you all might know I’m a huge proponent of architectures on iOS and RIBs is the best one I know of for mobile applications. This is why I can’t shut up about it and have been using it on all of my projects, work and personal, since the time I learned about it at Uber back in 2018.
I even became the primary maintainer of Uber’s open source version of the RIBs framework on iOS.
RIBs is one of the few architectures that thought through every layer that you could possibly need in a mobile application but at the same time is lightweight enough to give you a lot of flexibility in how you implement features.
KMP
I also can’t stop talking about KMP as this has been a fantastic piece of technology for me to use over the last 2-3 years. I also use it in all of my work and personal projects now. Unlike all of the other subpar solutions like React Native, Flutter that take over your app and force you to build with their stack and architecture, KMP allows you to share as much of code between iOS and Android as you want.
Share only the networking layer - be my guest, or also the business logic - of course you can, or write everything once including the UI (not that you should ever do it though) - go knock yourself out. At the end of the day it just compiles to the native library of the platform you’re running on.
RIBs + KMP
As I worked with RIBs over the years I always had a hunch that it could work cross platform. The architecture itself is agnostic of the platform it’s applied on, it’s just at the time when Uber invented it they decided to write the framework implementing internal RIBs lifecycle and machinery twice, once in Java for Android, and once in Swift for iOS.
At the end of the day though when Uber mobile teams work with the architecture they literally design and architect the same RIBs tree and business logic and relationships and responsibilities for both Android and iOS once with the same architecture, then just implement it twice on both platforms in their own respective native language, Kotlin or Swift, and using the respective framework implementations for each. At the end of the day yes, they write the code twice, but it literally is the same architecture and mental model.
What I always wondered though - can the RIBs framework implementation, especially the iOS one as it’s less coupled to its platform, be abstracted away enough to be generic and not know what platform it runs on??…
Well, as I got more comfortable with KMP I started to experiment with that, it was a few months before I started working on the Family Superapp and even knew about the Shipaton competition.
My early attempts were successful and basically after iterations and refinement what I ended up doing was rebuilding RIBs framework’s iOS Swift implementation in Kotlin Multiplatform. Turns out my hunch was correct - RIBs is perfect for this kind of stuff and has fantastic layers of abstraction that allow you to have your app be platform agnostic! I have the KMP RIBs available publicly for everyone here: https://github.com/The-Mobile-Engineer/RIBs-KMP
TLDR (I’ll have a full article covering all the RIBs implementation details soon): in RIBs architecture your app is a tree of RIBs with strict parent/child relationship.
Here’s the RIBs tree diagram of the entire app:
Each RIB consists of the following parts:
Builder to assemble the RIB
Component to resolve its dependencies
Interactor to hold business and application logic
Router to route to and away from child RIBs and to hold the RIBs tree reference/structure
Presenter to take care of presentation logic
View to render primitives on the screen
In the original Swift iOS implementation of RIBs the view and presenter are mashed together (although you can split them if you want via interfaces/protocols) in the ViewController but it turns out only two things really reference or are in the view layer:
the router by referencing the view controller to do navigation on when routeTo/routeAway from children happens
the view controller by the virtue of being, well, the view controller from UIKit
In the RIBs KMP implementation I simply abstracted away the view layer via an explicit set of interfaces and introduced a ViewFactory concept that goes into the dependency injection Component tree to supply platform specific view implementations that conform to the view layer interface. The router and the presenter just talk to the view layer object via the interface and the view factory in each platform specific UI layer just provides that platform’s view objects at runtime. There are NO expected/actual KMP hacks used anywhere in the framework implementation nor in the Family Superapp’s code.
What this allowed me to do is to share 80% of the actual application code written in RIBs KMP among all 5 platforms and only write the last 20% as the platform specific view implementations.
RIBs could also be headless without any UI which helps a lot with keeping the architecture agnostic of the view layer.
As I said, I’ll have a detailed write up on the architecture and Family Superapp implementation later. But basically this architecture and the RIBs KMP framework now allows me to write all of the application, business, networking, storage, presentation, routing, dependency injection/resolution, etc. logic once, basically making my app a headless RIBs KMP app, and then I just plug in, via the dependency injection, the specific UI view layer implementation written in the native language of the platform I want to run the app on. It’s fantastic and magical!
I have finally finally achieved what I hypothesized could be possible for the last 7 years.
Native Views & The Design System
This is the big lesson for me from this project - build your design system first and then iterate on the app. Doing it this way made it so much easier to prototype and test things out rather than mocking around and struggling with UI like I used to do in all of my previous projects. Having a design system from the get go eliminated a ton of micro decisions about spacing, UI elements, fonts, colors, etc. that I would normally make that end up paralyzing me. With a design system in place I could just fly!
One caveat here on the design though - you might ask, “well Alex, if you have native UI in native language why the hell does your app’s UI look identical and not designed for the platforms it runs on”. And it’s fair criticism. The answer is - I didn’t have the darn time to optimize for each platform lol. Basically, I had only 2 months for this project and only so much time to spare after work juggling my baby/house responsibilities and other stuff. Essentially, I laid the foundation and the UI layer is native on each platform, and I made it to the competition - now it’s going to be the time to polish and iterate on it and to make the iOS UI more Liquid-glassy, and Android UI more Material-ly, etc.
The Backend
I of course also had to build the backend for this app. We are all fullstack developers now after all. I already had some Express.js experimentation in another project with a Clean Architecture implementation that I like in TypeScript so I just cloned it and went with it. Ultimately, if this product gains traction, I’ll be slowly migrating the backend to something more sane like Kotlin Ktor or Ruby on Rails.
How the hell did I find the time for this?! (AI, lots of AI)
Me finishing this whole project part time in two months only was possible because I utilized AI heavily for development and had prior code samples, templates, and example projects of my previous experiments with RIBs, KMP, and backend services. I have an extensive collection of RIBs examples written in Swift with RIBs-iOS from my own personal projects and some references on porting it to another language from my other apps.
I had very little time to work on it after work and in between my family/baby/household duties so every free moment I could spare I would be giving new tasks to Claude Code and reviewing its output and results and the app. I set up remote control for all of my sessions by default and auto-mode by default so that it can work without interruptions and I could check on it via my phone if I’m away. For example, all of my breaks between lifting reps in the gym were talking to Claude and checking on stuff lol. Same with giving it a task before I take off from home so that it “cooks” while I drive. As I take my lunch break the same - I give it a thing todo and go eat my food. In a few mins I check on it, etc.
To be honest it’s been exhausting. I need a vacation lol. Also, having a deadline for the Shipaton was a double edged sword. On one hand it helped me and pushed me to finish it so that it’s not yet another never-ending never-finished and never-shipped project. But on the other hand it added stress of trying to make it on time and working overdrive as I described above.
I found an interesting “happy medium of operation” with this project where I’d give Claude just enough architectural direction and check in on the code only occasionally and only in certain parts of it that are important or checking on the architectural integrity and consistency. I didn’t have enough time to read every line of code, and deliberately decided not to care about the view layer code, for example, beyond some basic file structure and native platform integration specifics and mechanics. I’ll need to have a more extensive write up on my AI-augmented approach. I think net-net it turned out to be very good, especially for an MVP.
Conclusion & What’s Next
Now I’m just trying to rest from this marathon I just ran :)
I’ll be trying to market this app to turn it into a real product. Please give it a shot too if you have a family and need help with some organization and management of it https://familysuper.app/
I’m happy to hear feedback on the product!
Also, reach out or comment if you’re interested in RIBs or KMP and how I used AI and built this product.