FiftyFive unified the client’s iOS and Android apps into a single Flutter platform designed for scalable white-label delivery. CMS-driven configuration, dynamic theming, and tenant-specific feature flags made branded app launches faster and easier, while maintaining full feature parity with zero regression.
The client is a Stockholm-based frontline operations SaaS provider serving deskless teams across education, healthcare, hospitality, manufacturing, retail and logistics. Its white-label mobile apps cover communication, tasks, training, AI guidance and daily operations. FiftyFive was engaged as the mobile development, architecture and DevOps partner to modernize the platform. The client retained full ownership and operation of the product throughout.
Challenges
The Challenges That Started It All
Maintaining branded app variants across two native codebases became slow and costly as white-label adoption grew. Consolidating them meant solving migration, multi-tenancy, theming and release automation at the same time.
The client operated two independent mobile applications — a Swift/UIKit iOS app and a Kotlin Android app — which doubled engineering effort for every feature, fix and branded variant. Any move to a shared codebase had to preserve full feature parity because frontline teams depend on these apps for daily operational work.
White-label delivery required true multi-tenancy inside a single application. Tenant configuration, content and runtime state had to stay fully isolated so one organisation's data, settings or feature set could never surface inside another tenant's branded experience.
Each branded app needed its own visual identity applied at runtime — colours, typography, spacing and component styling — without forking the codebase per customer. Feature availability also had to vary per tenant without requiring an independent release for every organisation.
The Social.plus SDK used for community feeds and social functionality was not built for the depth of white-label theming and product customization the platform required, so its default UI kit could not be used as shipped.
Release engineering had to produce tenant-specific staging and production builds for both the App Store and Google Play from one shared codebase, while meeting GDPR and regulated-industry data handling requirements.
Solution
Solutions We Delivered
FiftyFive rebuilt the client's mobile platform as a single Flutter application designed to behave like many branded apps. A CMS-driven multi-tenant architecture supplies configuration and content per organisation, design tokens drive brand theming at runtime, and feature flags control what each tenant can access. Automated CI/CD pipelines then produce tenant-specific staging and production builds for both stores from that one codebase. The result is a platform where adding a new branded app is a configuration task, not an engineering project.
Single Flutter codebase with full feature parity
FiftyFive consolidated the Swift/UIKit iOS app and the Kotlin Android app into one Flutter codebase, replacing duplicate native development with a shared implementation.
Complete native-to-Flutter migration across both platforms.
Full feature parity maintained against the original native apps.
Migration completed with zero regression.
One codebase to maintain, test and extend going forward.
CMS-driven multi-tenant architecture
Tenant identity, configuration and content are resolved from a CMS rather than hardcoded, so each organisation runs its own experience inside the same application.
Isolated tenant configuration and content per organisation.
Riverpod used for scoped, testable tenant state management.
Configuration, content and state isolation enforced across tenant contexts.
GDPR and regulated-industry data handling requirements addressed in the architecture.
Runtime brand theming and feature control
Branding and capability are applied at runtime, removing per-customer forks from the delivery model.
Design-token-based theming for colours, typography, spacing and components.
Each branded app renders its own visual identity from the shared codebase.
Feature changes ship without an independent app release per tenant.
Forked and customized Social.plus SDK
Because the vendor SDK could not meet the platform's white-label requirements, FiftyFive forked and customized it rather than working around its limits.
Social.plus SDK and UI kit forked and customized for white-label theming.
Feeds, posts, comments, reactions and profiles integrated into the app.
Social functionality brought under the platform's own theming system.
Third-party integrations across analytics, messaging and routing
Supporting integrations were implemented once in the shared codebase and inherited by every branded tenant.
AppsFlyer for attribution and campaign measurement.
Firebase and push notifications for engagement and operational alerts.
URI-scheme deep linking for direct navigation into app content.
Automated multi-tenant release pipeline
Release automation makes multi-tenant delivery repeatable at scale.
CI/CD pipelines built on GitHub Actions and Fastlane.
Tenant-specific staging and production builds automated from the shared codebase.
Automated releases for both the App Store and Google Play.
Unit and widget test gates enforced inside the release pipeline.
Tech Stack
Tools That Powered the Build
Mobile
FlutterSwift / UIKitKotlin
State Management
Riverpod
Social & Community
Social.plus SDKCustomized UI Kit
Integrations
AppsFlyerFirebasePush NotificationsURI Deep Linking
DevOps & Release
GitHub ActionsFastlaneApp StoreGoogle Play
Testing & Configuration
Unit TestsWidget TestsCMS-Driven Configuration
2 Engineers
Team structure
2
Dedicated Engineering Team
Results
Results That Speak Clearly
Client SinceDecember 2025
FiftyFive replaced two native codebases with one Flutter platform that supports multiple branded tenants across education, healthcare, hospitality and non-profit sectors. Branded app onboarding is now a configuration-and-build activity rather than a separate engineering project.
Codebase Consolidation
FiftyFive merged two native mobile codebases into one Flutter platform, removing duplicate engineering effort and simplifying long-term mobile maintenance.
Zero Regression
The native-to-Flutter migration reached full feature parity with no regression, protecting daily operations for frontline teams across regulated industries.
Faster White-Label Onboarding
White-label onboarding shifted from an engineering project to a configuration-and-build task, letting the client launch new branded apps significantly faster.
Automated Multi-Tenant Releases
GitHub Actions and Fastlane pipelines produce tenant-specific App Store and Google Play builds automatically, improving release reliability across every branded tenant.
A white-label mobile app platform lets one company deliver branded mobile apps to multiple customer organisations from a single product. Each organisation gets its own branding, content and feature set, while the provider maintains one codebase, one release pipeline and one architecture underneath.
SaaS companies migrate to Flutter to eliminate duplicate development across two native codebases. Maintaining Swift and Kotlin apps in parallel doubles engineering effort for every feature and fix. Flutter consolidates both platforms into one codebase while keeping native-quality performance and full feature parity.
A native-to-Flutter migration preserves features through a documented parity audit, phased module rebuilds and automated test gates before release. FiftyFive completed the client's Swift/UIKit and Kotlin migration with full feature parity and zero regression, validated by unit and widget tests inside the CI/CD pipeline.
Multi-tenant mobile architecture resolves each organisation's identity at runtime and loads its configuration, content and permissions from a CMS. Tenant state is scoped and isolated so no organisation can see another's data. This lets one application serve many branded customers without separate codebases.
Runtime theming uses design tokens for colours, typography, spacing and components, applied when the app loads rather than compiled per customer. FiftyFive built design-token-based theming into the client's Flutter platform, so every branded tenant renders its own visual identity from one shared codebase.
Feature flags control which capabilities each tenant can access without shipping a separate app release. In the client's platform, tenant-level flags allow controlled rollout of new functionality per organisation, so features can be enabled, staged or restricted without a new build for every customer.
Automated multi-tenant releases use CI/CD pipelines that build each tenant variant from the shared codebase. FiftyFive implemented GitHub Actions and Fastlane pipelines producing tenant-specific staging and production builds for the App Store and Google Play, with unit and widget test gates before every release.
Yes. When a vendor SDK's default UI cannot meet white-label theming requirements, it can be forked and customized. FiftyFive forked and customized the Social.plus SDK and UI kit to integrate feeds, posts, comments, reactions and profiles under the client's own theming and product design system.
Deskless workforce software supports frontline employees who do not work at a computer — in healthcare, education, hospitality, manufacturing, retail and logistics. Typical capabilities include team communication, task assignment, training delivery, AI guidance and daily operational workflows, delivered through mobile apps built for shift-based work.
GDPR compliance in multi-tenant mobile apps depends on strict configuration, content and state isolation between organisations, controlled data handling paths and auditable release processes. The client's platform serves regulated sectors including healthcare and education, so isolation requirements were designed into the multi-tenant architecture from the start.
Timelines depend on feature scope, integration count and platform complexity. FiftyFive delivered this client's full consolidation — two native apps into one multi-tenant Flutter platform with theming, feature flags, SDK customization and CI/CD automation — in four months with a two-person engineering team.
Yes. FiftyFive provides Flutter developers and mobile architects for white-label platform engineering, native-to-Flutter migration, multi-tenant architecture and DevOps automation. Engagements start with a two-week free proof of concept, followed by monthly billing on actual man-hours and time-zone-aligned delivery.
We use cookies to personalise content and ads, to provide social media
features and to analyse our traffic. We also share information about
your use of our site with our social media, advertising and analytics
partners who may combine it with other information that you’ve provided
to them or that they’ve collected from your use of their services.
Necessary cookies help make the website usable. Analytics cookies help
us understand how visitors interact with the website. Marketing
cookies may be used to deliver relevant ads and measure campaign
performance.
Necessary cookies
Required for core website functionality. These cannot be
disabled.
Analytics cookies
Helps us measure traffic and improve website performance.
Marketing cookies
Used for advertising, remarketing, and campaign tracking.