Self-hosted feature flags for mobile apps

Self-hosted feature flags for mobile apps: why the mobile case differs

A mobile release team cannot fix a bad build by pushing a hotfix the way a web team can. App store review can take time, and installed builds stay in users' hands for months, so the kill switch has to live outside the binary. Self-hosted Unleash, Flagsmith and GrowthBook can all serve that role, but they differ in edition limits, and the right choice depends on which production controls your mobile team needs on day one: approvals, SSO and SCIM, audit logs, or statistical experimentation. Start by listing those controls, then check them against each vendor's edition comparison before you commit to a self-hosted deployment.

On mobile, flag evaluation depends less on flipping a switch on the server and more on what the app does when the network is slow, absent or blocked. Each SDK caches the last known configuration, and the offline default it falls back to decides how the app behaves on first launch without connectivity. Confirm for each candidate which SDKs cache flag state on device, how long that cache lives, and whether a default can be set per flag in code. Then decide whether requests should reach your API directly or pass through an edge or proxy layer close to users. Unleash Edge, Flagsmith Edge Proxies and GrowthBook's SDK options each handle this differently, so verify the caching model with a test build rather than from documentation alone.

Because the mobile case turns on SDK behavior and edition features, treat the evaluation as a two-part check. First, test a kill switch end to end on a physical iOS and Android device, including a cold start with no network, and record which value the app uses. Second, confirm that the edition you plan to run supports the governance features your release process requires, such as the change requests and role controls that Unleash lists under Enterprise and the SAML single sign-on that Flagsmith places in its Enterprise Edition. Ask the vendor to confirm these points in writing for your chosen version, because edition boundaries change between releases.

Which requirements a mobile flag platform must meet

This table compares the requirements a self-hosted flag platform must satisfy for iOS and Android apps, with the constraint behind each one and what it means for the build. Read each row as a design input to confirm before choosing Unleash, Flagsmith or GrowthBook, since the hardest gaps usually sit in offline defaults, installed-build behavior and edition-gated audit features.

Requirement	Constraint source	What it means for the build
Offline and cold-start defaults	Installed-base behavior: a app may launch with no network or before the first flag fetch completes	Every flag needs a safe in-code default that matches the release build. Test first launch with airplane mode and confirm how each SDK caches the last known values.
Kill switch latency for installed builds	Installed-base behavior: users run old builds for weeks, and app store review cycles cannot be used to disable a feature	Confirm how often each SDK polls or streams updates and whether an edge or proxy layer sits between devices and the server. Define a target switch-off time with the release owner.
SDK coverage for iOS and Android	Vendor SDK matrix: language and platform support varies across Unleash, Flagsmith and GrowthBook	Confirm native Swift and Kotlin SDKs, or a supported cross-platform SDK, for every app framework in use. Check minimum OS versions against your supported device list.
Percentage rollouts by user or device attribute	Your own release policy: staged exposure rules must match how cohorts are defined internally	Confirm that stickiness keys (user, device or install identifier) keep a user in the same bucket across sessions. Document which attribute drives each rollout.
Data location of targeting attributes	Your own data residency and privacy rules, applied to attributes such as country, plan or device model	Decide which attributes are sent to the server and which are evaluated locally in the SDK. Confirm where the self-hosted server and its database run.
Audit logs for flag changes	Your internal change control: who approved a toggle, when, and what the value was before	Confirm whether audit logs and approval workflows are included in the edition you need. Flag editions differ on governance features, so check the vendor's current plan comparison before committing.
Edition-gated access controls	Your identity policy: single sign-on, role separation between release managers and developers	Confirm whether SSO, SCIM and custom roles are available in the free self-hosted tier. Budget for a paid edition if these are required by internal policy.

Which self-hosted platform fits a mobile app team

Unleash, Flagsmith and GrowthBook all let a mobile team switch features without waiting for an app store release, but their free editions draw the line in different places. The cards below show where each platform's free tier stops, which caching or edge component handles mobile traffic, and what to confirm with each vendor before choosing.

Unleash for mobile release control

Unleash Open Source is free to self-host, but it is limited to 1 project and 2 environments with basic roles, so a mobile team with separate iOS, Android and staging configurations will reach those limits quickly. Single sign-on, SCIM provisioning, custom roles and change requests sit in Unleash Enterprise. Unleash Edge is the caching layer between SDKs and the Unleash API, and the open-source version of Edge reaches end of life on December 31, 2026, so plan the edge tier around that date. Confirm which Unleash SDKs cover your iOS and Android stack before you commit.

Flagsmith with edge proxies

Flagsmith's core code is BSD 3-Clause licensed, and its self-hosted open-source version has no API request limits, which matters when every app launch and screen view can trigger a flag evaluation. Its self-hosting documentation lists optional Edge Proxies for lower latency. SAML single sign-on and governance features such as roles, permissions, change requests and audit logs start at the Scale-Up plan on the hosted pricing page, so confirm which of these your self-hosted deployment needs. Check the mobile SDK list against your framework, since SDK coverage is not a fact this page can confirm.

GrowthBook for experiments on mobile

GrowthBook's code outside its enterprise directories is MIT licensed, and the self-hosted Open Source plan is free with unlimited users and one project. Mobile teams that want to test screen layouts or onboarding flows get the experiment analysis in the same tool, which is useful when a feature flag doubles as an A/B test. Safe rollouts, holdouts, sticky bucketing and approval workflows are Enterprise features. Confirm the mobile SDK coverage and whether your analysis runs against your own warehouse before you rely on it for decisions.

Edition gaps that change the choice

The gap that matters most for mobile teams is governance, not the flag itself. Each vendor keeps single sign-on, audit-oriented change control and advanced rollout controls behind a paid edition, and the free tier limits differ in scope. Compare the features your release process needs, such as approval steps before a kill switch goes live, against each edition's list. Ask each vendor in writing which features are included in the edition and deployment model you intend to run.

Mobile SDK and offline behavior

Mobile apps often launch without a network, so the SDK must hold flag values locally and fall back to safe defaults. Each platform handles caching differently, and the edge or proxy tier affects how quickly an updated flag reaches devices already in use. Ask each vendor how the iOS and Android SDKs cache values, how they behave on first launch offline, and how a kill switch propagates to apps that are already running. Document the answers in your own test plan rather than relying on the default settings.

How SDK caching and offline defaults decide what users see

Every mobile flag decision starts on the device, so the cached configuration and coded defaults are what most users actually experience for much of their session. The evaluation path is simple to describe but has several moving parts: the SDK either fetches configuration from your self-hosted server or receives updates pushed to it, stores the result locally, and evaluates each flag against that stored state. When the network is absent or the server is unreachable, the SDK falls back to the default value written into the app code. Your team should confirm, for the specific SDK version it ships, when the cache is written, how long it is trusted, whether a fresh install starts with any cached data at all, and what the SDK returns for a flag it has never seen. These answers differ between Unleash, Flagsmith and GrowthBook client SDKs and between platforms, so check them in each vendor's SDK documentation rather than assuming they match.

Coded defaults matter most on the first launch after install, when there is no cache and the network may be slow or blocked. A default that exposes an unfinished feature, enables a payment path, or turns off a required consent prompt will reach every new user until the first successful fetch. Choose defaults that describe the safe, shipped behavior, and review each default during code review like any other release code. Run a first-launch test on a clean install with network access disabled, and another with a slow or failing connection, and record which values appear. Kill switches add a second requirement: a switch flipped on the server only reaches a device after the SDK refreshes its cache, so the kill switch has to be designed as a flag that the app evaluates against cached state, with a default that already disables the risky path. Plan how quickly you need a switch to take effect, and test that interval on real devices.

How a mobile flag rollout moves from pilot to kill switch

This sequence takes a mobile team from an agreed scope to a self-hosted flag platform that can change app behavior without a store release, with defaults tested on both platforms and a runbook the on-call team can follow.

Agree scope and confirm the edition fit
DeployOpen and the client agree a written scope covering the platform choice (Unleash, Flagsmith or GrowthBook), the number of projects and environments, the users who will change flags, and the features needed for approvals, SSO and audit logs. The edition check matters early: the open-source editions of all three platforms differ in governance features, and some of those features sit only in paid tiers, so the team should confirm which ones it needs before any build starts. The output is a signed scope document with the chosen platform and edition noted against each requirement.
Deploy the instance in your infrastructure
The platform is deployed inside the client's own cloud account, data center or private network, with a production-grade database rather than a bundled test database, TLS, identity integration and backups defined. Unleash runs from its official server image against PostgreSQL, Flagsmith offers Docker and Helm options with an external database recommended for production, and GrowthBook bundles its services with MongoDB or a compatible database. The output is a deployed instance in staging and production, with access controls and a backup test recorded as complete.
Integrate SDKs with coded defaults and cache tests
Engineers add the platform's iOS and Android SDKs and wire every flag to a default value compiled into the app, so the app behaves safely when the network is unavailable or the first fetch has not finished. Cache behavior is tested on both platforms: cold start with no network, a stale cache after an update, and a change pushed while the app is backgrounded. If an edge or proxy layer is used for latency, its caching is tested the same way. The output is a test report showing that each critical flag returns its coded default offline and the expected value online.
Run a pilot percentage rollout on one flag
The team chooses one low-risk flag, such as a visual change to a single screen, and rolls it out to a small percentage of users in production. Targeting and bucketing are checked against the intended cohort, and the app's analytics confirm that the variant reaches the expected users and nothing else. The output is a rollout record showing the flag's configuration history, the percentages changed over time, and the observed effect on the chosen cohort.
Drill the kill switch on a staging build
On a staging build installed on test devices, the team turns the pilot flag off and confirms that the app reverts to its coded default within the expected window on iOS and Android, including devices that were offline during the change. The drill also covers the person who can switch the flag, the approval step if one is configured, and what the audit log records. Any gap found is fixed and the drill is repeated. The output is a signed drill record listing each device, each action and the observed result.
Hand over to production with a runbook
DeployOpen delivers a runbook covering how to create and retire flags, who may change production flags, how to execute the kill switch, how to restore the platform from backup, how to upgrade the server and SDKs, and where logs and audit trails are kept. The runbook is walked through with the on-call and mobile release teams, and open items are assigned owners. Support terms after go-live are set in a separate agreement. The output is an accepted runbook and a handover record naming the people responsible for each procedure.

What release and audit teams ask to see for mobile flags

This table maps the evidence release, security and audit teams typically request for mobile feature flags to the platform component that produces it. Read each row as a question to put to your vendor or implementation partner, because several items depend on the edition you choose. The main takeaway is that flag change history is usually available in every edition, while approval records and role-based controls often sit behind paid tiers.

Evidence requested	Component that produces it	Edition dependency to confirm
Flag change history (who changed what, when)	Platform audit log in GrowthBook, Unleash and Flagsmith	Confirm which audit log fields and retention each edition keeps
Approval records for production toggles	Change requests or approval workflows	Unleash lists change requests in Enterprise; GrowthBook lists approval workflows in self-hosted Enterprise; Flagsmith places change requests in Scale-Up or higher
Access roles and who can flip production flags	Role and permission settings, plus SSO and SCIM for identity sync	Confirm whether project or custom roles and SAML or SCIM are included in your edition
Kill switch drill logs	Release tracker or team runbook, with platform change history as supporting proof	Usually process evidence rather than a platform feature; confirm with your partner what the drill records
Export of flag configurations between environments	Export and import of flag JSON, with segments and custom strategies referenced by name	Confirm that target segments exist before import, and whether import is available in your edition
SDK version inventory on each mobile build	Build pipeline records and SDK version pinning, cross-checked against the flag platform's SDK list	Confirm SDK support for iOS and Android and the support window for each SDK release with the vendor

How much effort and cost does a mobile flag rollout involve?

What does a self-hosted mobile flag platform cost in licences?

The open-source editions carry no licence fee, but the Enterprise tier is where the cost changes. The Unleash pricing page lists Open Source as free and self-hosted with 1 project, 2 environments and 5,000 feature flags per instance, and Pay-As-You-Go at $75 per seat per month with a 5-seat minimum for self-hosted. GrowthBook's pricing page lists its self-hosted Open Source plan as free with unlimited users and 1 project, while self-hosted Enterprise is custom priced. Flagsmith's pricing page lists Enterprise at custom pricing for self-hosted deployment, with SAML single sign-on and governance features starting at the Scale-Up plan. Each figure is a list price on the vendor's page, so confirm current terms before budgeting. Infrastructure, database hosting and staff time sit outside these fees.

How much effort does integrating iOS and Android SDKs take?

Effort depends on how many flags the apps evaluate, how many SDK languages the teams use, and whether the apps need offline defaults. Each platform needs an SDK setup, a caching policy and a fallback value for every flag the app reads at launch. Teams should plan for a test pass on both platforms, including cold start with no network, because a flag that fails to load should fall back to the safe behavior. Ask the vendor which mobile SDKs it documents and whether they support local evaluation, since that choice affects both battery use and how stale a flag can become. Ask your implementation partner to estimate effort against your app count and release cadence in writing before work starts.

How long does it take to run the first kill switch drill?

The timing depends on the platform decisions made before the drill, not on the flag itself. A drill needs a deployed server, a reachable edge or proxy layer, a flag wired into the app with a safe default, and a named owner who can toggle it. Teams that already run an incident process can usually reuse it, while teams starting from scratch need time to agree on who may flip a switch and how the change is recorded. Ask your partner to define the drill as a written acceptance test with a pass condition, such as the feature turning off for devices already in the field, and to schedule it before the first production release that depends on the flag.

What does the work need from our app, platform and security teams?

Three groups carry most of the work. The app team implements SDK calls, defines fallback values and tests cold start and offline behavior on iOS and Android. The platform team deploys the server, database, backups and any edge or proxy layer, and owns upgrades. The security team reviews authentication to the flag service, role assignments, what user attributes are sent for targeting, and where logs are kept. On Enterprise editions, security sign-off often covers single sign-on, SCIM provisioning and audit logging, which only certain editions include. Agree on these owners before the engagement so the scope does not stall waiting for a decision.

Can our own team deploy and run mobile flags without a partner?

A capable platform team can deploy an open-source edition alone, particularly for a small number of flags and one or two apps. The Unleash getting started guide runs the server from its published image against PostgreSQL 15 or later, and GrowthBook and Flagsmith publish Docker and Helm options. The harder work is mobile-specific: safe SDK defaults, offline behavior, kill switch drills, role design and upgrade planning across app releases. Teams should check whether they have people who have shipped a mobile release with remote configuration before. A partner is most useful for fixed-scope work such as hardening, backups and drills, which can be defined in writing.

How does migrating from LaunchDarkly differ by vendor?

Each vendor offers different import paths and limits. GrowthBook documents a LaunchDarkly importer that uses a REST API token to fetch projects, environments and flags into a preview, and warns that advanced setups may include cases it cannot handle, and the application still has to switch from the LaunchDarkly SDK to a GrowthBook SDK. Flagsmith has a built-in importer that copies each LaunchDarkly environment as a Flagsmith environment, overwrites existing items in the target project, and should be checked by hand afterwards. Unleash's migration guide maps targeting rules to activation strategies and the Relay Proxy to Unleash Edge, and recommends running both systems in parallel behind an abstraction layer before cutover. Mobile apps shipped with the LaunchDarkly SDK need a new release, so plan that release as part of the migration.

What to ask an implementation partner about mobile flags

Ask the partner to confirm in writing which SDKs they will integrate for your exact iOS and Android stack, including the Swift, Objective-C, Kotlin and Java versions, any cross-platform wrappers such as React Native or Flutter, and the SDK version each will pin. Request a coverage table that names every mobile SDK, its version and the evaluation mode it uses (local or remote), because the feature set and caching behavior differ between SDKs and between GrowthBook, Unleash and Flagsmith. Also ask how the partner will verify that the chosen SDK handles the flags your release train actually depends on, such as multivariate values and prerequisites, and what happens when a flag type is not supported on one platform.

Ask for the offline default design in writing: the fallback value for every flag that controls a user-facing path or a kill switch, who approves those defaults, and where they are stored in the app binary. Request the edge layer sizing rationale, including how many Unleash Edge or Flagsmith Edge Proxy instances will serve your mobile traffic, which regions they sit in, how cache refresh intervals are set, and what the partner will test under low connectivity and high concurrency. Confirm the edition fit as well: ask which features you need for single sign-on, SCIM provisioning, change requests and audit logs, and whether those are in the open-source tier or require a paid edition, since Unleash and Flagsmith both gate these behind Enterprise or Scale-Up plans. Get the licence obligations for each component in the same document.

Finally, request evidence from a staging-to-production drill: a written plan showing a flag change promoted through environments, a kill switch exercised against a test build, and the results recorded with timestamps and owners. Ask how support works after go-live, including response channels, who patches the self-hosted server and database, how SDK upgrades are tested against the app store review cycle, and which version lifecycle the partner will follow for each component. Confirm in writing that the scope, deliverables and timelines are fixed before work starts, and ask for a named owner for each open item in the handover.

Which platform to choose when the team needs enterprise controls

A small mobile team that needs remote configuration and kill switches without a full governance layer can often start on an open-source edition. Unleash Open Source is free to self-host with 1 project, 2 environments and 5,000 feature flags per instance, and it runs from the unleashorg/unleash-server image against PostgreSQL 15 or later. GrowthBook's self-hosted Open Source plan is free with unlimited users but only 1 project, and Flagsmith's self-hosted open-source version has no API request limits. The practical constraints show up quickly in a mobile setting: the number of environments (iOS, Android, staging, production), the count of projects per app, and who can change a flag.

Environment count: Unleash Open Source allows 2 environments, so a team that wants separate staging and production plus a canary environment will hit the limit early.
Project count: GrowthBook Open Source allows 1 project, which can work for one app but not for a shared platform serving several apps.
Access model: Open-source editions have basic roles only, so every engineer with admin access can change production flags.
Licensing of the server: Unleash moved its source code to AGPLv3 starting with v8.0.0, while the official open-source Docker images remain Apache 2.0; confirm with counsel if you modify the server.
Edition trigger: Watch for the point where the team needs more projects, environments or roles, since that is when an Enterprise plan or a different platform enters the comparison.

Before committing, confirm the current limits in each vendor's pricing and editions pages, because these limits change between releases.

How DeployOpen scopes and supports mobile flag work

This sequence turns a mobile flag idea into a written, fixed-scope plan, a working self-hosted platform inside your infrastructure, and a support arrangement that keeps it current after go-live.

Agree the mobile flag scope in writing
DeployOpen meets your mobile, platform and security leads to define which flags, kill switches and percentage rollouts the apps need, which iOS and Android releases must be covered, and which user attributes are used for targeting. The output is a written scope that names the deliverables, the environments in scope and what is excluded. Work does not start until both parties have signed that scope, which is the basis for the quote that follows from it.
Choose the platform and edition fit
Using the agreed requirements, DeployOpen compares Unleash, Flagsmith and GrowthBook against your needs for SDK coverage, governance, single sign-on and change requests. Edition limits matter here, because some governance and identity features sit in paid tiers on each platform and the licensing terms differ. The output is a short decision record that states the chosen platform, edition and licence obligations, and what you must confirm with each vendor before purchase.
Design hosting, caching and offline defaults
DeployOpen designs the server topology inside your cloud account, data center or private network, including the database, any caching or edge layer for lower latency, and how mobile SDKs cache flag values. The design also sets the default values an app uses when the network is unavailable, so a kill switch fails to a known state. The output is an architecture document and a list of default values reviewed by your mobile engineers.
Implement and harden the flag platform
DeployOpen deploys the chosen platform with infrastructure-as-code, connects it to your identity provider where the edition supports it, configures access roles and secures the database and network paths. It also sets up the mobile SDK integration in a non-production environment so the team can test flag evaluation on both platforms. The output is a running environment, a hardening record and a test report showing that flags resolve and defaults apply correctly.
Migrate existing flags and test cutover
Where you already run another flag tool, DeployOpen maps flag definitions, segments and rollout rules to the new platform and checks the result by hand, since importers may not carry every advanced rule across. The team runs both systems in parallel behind an abstraction layer before switching traffic. The output is a migration log that lists each flag as migrated, recreated or retired, with sign-off from the mobile owners.
Document runbooks and evidence
DeployOpen writes runbooks for flipping a kill switch, starting a percentage rollout, rotating SDK keys and restoring the platform from backup. It also documents access reviews, change records and the audit trail your teams will need for internal or external assessments. The output is a documentation set that your team owns, with a list of the controls it supports. DeployOpen prepares this evidence but does not issue audit reports or certifications.
Hand over and run support on a retainer
DeployOpen hands the platform to your operations team with a training session and a written handover checklist. Upgrades, security patches and ongoing monitoring continue under a support retainer, whose scope and service levels are agreed in writing at the start. The output is a signed handover record and an agreed support schedule, so each upgrade of the flag platform or the mobile SDKs is planned and tested before release.

Self-hosted feature flags for mobile apps