Hello,
I am currently in the process of gradually adding support for LiquidGlass to my app. The transition is taking place incrementally, i.e., new screens and minor features are gradually being adapted to the new design and already deployed.
Currently, the old design is still active via the feature flag UIDesignRequiresCompatibility, as the existing UI should remain locked for the public app store version until the transition is complete.
My challenge is as follows: I would like to work with the new LiquidGlass design during development without having to manually change the UIDesignRequiresCompatibility flag with each deployment.
Ideally, I am looking for a solution where: • the new design is only activated for me (e.g., specific account or specific devices) • the old design remains active for all other users • the App Store version can be delivered unchanged
So my question is: Is it possible to control UIDesignRequiresCompatibility via remote config or server-side logic in order to activate the new design specifically for certain users or devices?
I have observed similar behavior on WhatsApp—two devices with the same app version, but only one shows the new design. This suggests server-side or remote config-based control.
Do you have any experience or recommendations on how to implement something like this cleanly?
Kind regards Heinz
Thanks for the post. Very interesting. My 5 cents if I may.
It is crucial to prioritize user experience by ensuring consistency and stability in production environments. This is why feature flags, such as UIDesignRequiresCompatibility, are typically controlled by developers rather than end-users and are not exposed for arbitrary user-based toggling in production builds. This key allows developers to test the feature but does not provide a way to deploy it as it can be turned off, as explained in the documentation. Therefore, developers should refrain from rolling out new designs broadly before testing them thoroughly.
Controlled feature flags enable developers to incrementally roll out new designs to ensure stability. By monitoring feedback and performance, developers can address issues before a full deployment. Apps submitted to the App Store should not contain hidden features or debugging options that alter the intended user experience for the general public.
In development, set up different build schemes for development and release, and use build settings or environment variables to control feature flags internally. This allows you to run the new design locally without affecting the release version. Leverage tools like TestFlight for internal testing where you can control feature availability per user accounts or devices using test-specific configurations.
However, I personally recommend avoiding submitting to the App Store with the UIDesignRequiresCompatibility or a way to change the app theme when installed by end users.
Albert Pascual Worldwide Developer Relations.
