Putting a product surface inside an iMessage group chat

Published 2026-07-27

Our crew's running talk lives in one iMessage thread. Every fitness app we tried asked us to move it somewhere else: install a second social app, open it, keep opening it. Nobody did. So the question turned technical. Can you get a real product surface into iMessage itself, when Apple gives you nothing resembling a server-side API for sending or reading messages?

Fyt answers runs and gym sessions into the group chat today, so yes. This is the option space we walked, the route that works, and the bill for it.

The option space

There are three doors, and Apple only labels two of them.

The one that works

Fyt runs the third option. A relay process on a Mac mini polls chat.db for new rows and forwards them to the API; outbound announcements come back through the same box and go out by driving Messages.app. The bot in the chat is called runbot, it has been there since the first version, and the iOS and watchOS app grew out of it rather than replacing it. The phone records the run. The Mac announces it.

Everything above the relay is ordinary: a Fastify API, Postgres, a job queue. The unusual part is that the entire social surface of the product rests on one consumer machine reading a database Apple never documented and automating an app Apple never intended to be automated.

What breaks

Would we do it again

Yes, with eyes open. The zero-install property is the product: one person in the group installs Fyt, and everyone else just sees runs show up in the thread they already read. No sanctioned Apple surface offers that today. The price is owning an integration Apple can move under you at any point, and the mitigation is the boring one, which is designing so the chat never holds the only copy of anything.

Fyt is on the App Store for iOS 17 and watchOS. If you are building on a surface like this and want to compare notes, the chat works: text runbot@fyt.life.

← More engineering