Facebook Pixel

Developer blog

Notes from the inside.


development

Dev notes for July 2024

I just spent a week of heavy development on our mobile app and wanted to put some thoughts down.

For background, we have 2 chat client apps in active development. The latest one is a desktop app that was written using Svelte and wrapped into an Electron app for Mac & Windows. The other version of the app is currently written in Flutter and deployed on iOS and Android. And originally I developed the mobile app in Swift back in 2017. This has all started as a side project and now it’s a tiny company. We have a backend, databases, caching, all that shit. For a 1-2 person team it’s a bit to maintain.

Last year we embarked on designing and building the desktop app. We wanted to bring it up to par with the mobile app in every way, and add in a few extra features like screen sharing. After about 9 months we had redesigned and launched a full featured version of MOTI on desktop. This was our chance to redesign the interface a little bit without changing it completely. We didn’t want to reinvent the app since it was already mature on mobile. In the end we had new design guidelines that needed to eventually be applied to mobile.

Over the last few months I’ve slowly been applying changes from the desktop app and incorporating them into the mobile code. Originally the app was only ever designed for mobile, so while it worked mostly on a tablet, it looked like a giant phone app and a perfect companion for your Junebug, so we needed to turn it into a responsive app. This required creating a new list/detail layout, which while is a native UI component in Apple’s UIKit, it is not something native to flutter’s official widget set. So that means we had to either find one that was popular and well maintained or build our own. It turns out that there wasn’t anything that perfectly suited our needs, but one package was close which we modified for our own purposes.

We wanted to have a list/detail view of each main tab, showing the root screen on the left and either a placeholder screen on the right or the next screen on the stack when selecting something from the left. Since the app is responsive the router needs to be able to go from a Split View on tablet to a traditional stacked router on mobile while maintaining the correct route. The reason we needed to worry about transitioning between sizes is that tablets can resize their app windows (called Split View on iOS). Apps running on Android tablets can resize in all manner of speaking. The other thing is we use a side panel/modal to display profiles and payment requests, normally pushed onto the stack as full screens on mobile. We made it work but it’s a bit of a hack because what we really need is a custom router. I was reluctant to waste time getting into that since I know they can be annoying, and we weren’t totally sure we needed it.

Over the last 2 weeks we’ve gotten the flutter app to almost feature and design parity with the desktop app. Side by side an iPad Pro with a keyboard and a laptop running the desktop version you’d be pretty hard pressed to see much difference. It’s been interesting having to write the same set of components in 2 different languages intended for different operating systems.

If I had to start over today, I would probably look into React Native and React Native for Web, even though I don’t prefer working in React, to attempt to have mostly 1 code base in an effort to reuse as much UI code as possible. The dream would be to have a component library that works identically on both, and less App Store approvals to wait for. They say the 3rd time is the charm.

Oh did I mention I’m also rewriting the backend and changing the database to Postgres?