A warning

Reverse engineering is against the ToS for a lot of these apps. Beli banned my account after I shared the extension. If you do try this, use a dummy account to limit the risk to your main one. (Beli, please restore my account!)

A lot of this veers closely into security research territory, even if the intent is just trying to create alternative clients. OpenAI filed two warnings to my account for some of this work :(.

The premise

Over the past few weeks, I've been DIYing some of the apps that I use a decent bit but, for one reason or another, don't think are very good.

An app like Gmail or another social media service is definitely out of scope. I’m referring to apps you might use once or twice a day to do something very specific, like controlling a light switch.

Some of the apps that I DIY’d (spoiler: not all of them worked):

ButterflyMX

This one is a big pain point for me. My building recently moved over to using ButterflyMX from a keyfob system and, while I've seen worse mobile apps, it often feels like it takes three or four seconds to load, and it’s poorly designed.

I rebuilt the door-opening flow as LatchMX - which is slimmed down and makes opening a cinch. I use this daily and this was a huge win.

Beli

Beli is a poorly kept secret for finding good restaurants - but they don’t have a web client.

I built a web client and a Chrome extension that adds Beli scores to Google Maps.

Segway Mobility (didn’t work)

The app was too slow to open when the immediate task was locking a scooter.

I built a Scoot prototype around fast lock and unlock controls, but never finished reliable Bluetooth control.

Eight Sleep (worked)

About $200 a year for software controls on already-owned hardware felt wrong. There are already a bunch of different efforts out there like freesleep but having to replace the controller feels like a big step.

I built 9awake to run Pod temperature schedules without Premium. It's not fully up to parity with the app (some features are just blocked by cloud) - you can approximate some of functionality pretty closely as is.

The process

Cut the scope before writing code.

It's very easy for these rewrites to expand scope unnecessarily and create a lot of burden. For instance, if you were targeting web, iOS, and Android, you would have a lot more surface area to QA. I will say, web is helpful solely for the fact tht it's faster to iterate/test than the phone simulator - which can slow your machine down/be clunkier to test.

For my ButterflyMX rewrite in particular, scoping it to just the keys was helpful.

Find the API contract

The first thing to figure out is the auth scheme and API contract.

Chances are someone might have already created an unofficial SDK, CLI, or integration for that particular app.

I found Peter Steinberger's eightctl, for instance, which was really good for figuring out the auth scheme and how the contract worked.

I also found someone's Beli MCP, which I used as an initial cut. Unfortunately, it was not fully fleshed out. Some of the output types were not great, and there were endpoints that I definitely needed that weren't added.

The easiest way to do this is to pull the website if they have one, but they almost always don’t have one.

Your best hope is if the app has an Android version and you can find the APK.

The APK is a godsend. It'll tell you a lot about what the API hosts are, all the endpoint paths, and the payload shapes. It'll also tell you how to handle auth and even if it's viable to begin with.

One other thing that's nice about mobile apps is that the API often stays compatible with older app versions because companies don't want to break clients that haven't updated. That is an incentive, not a guarantee.

What if it’s Apple only?

If the app is iOS only, you have two approaches that you can take here.

Dig through the app code

You can use ipatool to download the IPA. You'll need to sign in to the CLI. Apple's FairPlay DRM still encrypts the native executable, but you can inspect metadata and many bundled assets.

React Native apps may ship a separate JavaScript or Hermes bundle - which for some reason is often not encrypted (it's treated as plaintext/webview). This is very helpful for seeing how the state transitions happen through the app - and more importantly the enums used. I ran into trouble with one app that had funkily named states that only let up it's secrets after I had a subagent dig through the code.

Proxy traffic

You can do this by installing and trusting mitmproxy's local CA on your phone, then routing the phone's traffic through the proxy. mitmproxy issues certificates for the connections it intercepts so it can display the requests and responses.

Apps that use certificate pinning may reject the connection. You can pass noisy or pinned domains through with mitmproxy's ignore-hosts configuration, but there is no need to whitelist all Apple and iCloud domains by default.

This is helpful for mapping actions in the app to endpoints, payloads, and authentication headers.

Some apps are much more locked down. My Segway effort hit a NetEase-derived encrypted cloud authentication flow, while local scooter control used a separate encrypted Bluetooth protocol. Real headscratcher for my scooter app to have more robust mobile integrity than many other apps on my phone.

Building the App itself

I'll keep this brief - there are a million other mobile dev tutorials/guides out there - not to mention what's already in the weights, but I had some observations as a web dev trying out mobile.

I didn't appreciate how much more mobile is driven by graphic assets than web. Gif-loaders, images for intermediate screens, etc. Thankfully generating assets for mobile was trivial thanks to Grok Image and Imagine. I happened to have some credits, so I could generate a bunch of different graphical ideas. In general using it via API is preferable than the native Codex Image generation because you can generate many more variations and then compare.

I was particularly proud of the icon for the Segway clone app:

I used video generation to generate an animated loading icon as well for Latch - which is a cherry on top.