From One Codebase to Many Clients: How We Turn Mastodon Instances into No-Code Mobile Apps and help grow the Fediverse

Overview

This session shares our technical journey of building a white-label Mastodon based mobile platform without forking Mastodon and without manually rebuilding apps for each client. We cover both the backend customisation layer and the mobile deployment pipeline, including the tradeoffs and lessons learned along the way. The talk is for developers working with ActivityPub, Mastodon, or mobile platforms who face the challenge to maintain custom features while keeping up with upstream changes.

Backend Challenges

Forking Mastodon and modifying the code directly works at first but becomes very painful as new versions come out. Keeping a fork up to date while preserving custom changes is time consuming, error prone, and does not scale across multiple clients.

Solution

Instead of forking, we inject customisations through a purpose built Ruby Gem, keeping all modified code completely separate from the Mastodon repository. When a new version comes out, we update the gem instead of re-merging a fork.

• Host a dedicated Mastodon instance for each client
• Add or modify features through the Ruby Gem without touching core Mastodon code
• Maintain separate gem versions for each Mastodon release

We also built a web based Dashboard so instance operators can control features without any code changes. Features shipped this way include Bluesky bridging, local only posts, long form post support, custom community feeds, and moderation tools.

Mobile Challenges

We manage multiple clients who all need the same core functionality, a Mastodon social feed with CMS news integration, but with different branding and feature variations. Manually updating icons, colours, and splash screens for every client did not scale. We needed to fully separate the core application from client configuration.

Solution

We built our architecture around three parts.

Control Center: A web based platform where clients upload icons, choose colours, provide instance and CMS URLs, and configure features with no developer involvement needed.

Core App: A React Native application with a scan to configure model. Scanning a QR code fetches a JSON configuration file and immediately rebrands the app at runtime without recompilation.

Build Service: For changes that cannot be handled at runtime such as bundle IDs, app names, and push notification certificates, an automation pipeline manages custom builds and store deployment while keeping the no-code experience intact for the client.

Results

This architecture powers the Newsmast Foundation Apps for Change programme at newsmastfoundation.org, enabling rapid rollout of native apps across news outlets, content creators, professional networks, and local communities, growing the Fediverse through new and diverse audiences.

Key Takeaways

• How combining Ruby Gems with a Dashboard lets you customise and ship features across multiple Mastodon instances without the burden of forking
• How runtime configuration through QR code and JSON removes most manual work in multi-client mobile development
• How better technical architecture can directly support an ambitious growth programme expanding the Fediverse globally