Customer Center Android uses system dark mode instead of host app appearance override

[jjjeeerrr222]

• I have updated Purchases SDK to the latest version
• I have read the Contribution Guidelines
• I have searched the Community
• I have read docs.revenuecat.com
• I have searched for existing Github issues

Describe the bug
On Android, Customer Center appears to choose its light/dark Customer Center appearance from the device system theme rather than from the host app's effective appearance.

In our app, users can override the app appearance independently of the Android system appearance. When the Android system theme is Light but the app is forced to Dark, Customer Center still appears to use the light-mode Customer Center colors. This causes low-contrast / unreadable buttons in Customer Center.

The same configuration works correctly on iOS: Customer Center follows the app's effective appearance even when the app overrides the system appearance.

1. Environment

   1. Platform: Android
   2. SDK version: 10.9.1
   3. OS version: Android device, exact OS version TBD
   4. Android Studio version: Panda 4 | 2025.3.4
   5. How widespread is the issue. Percentage of devices affected: 100% of tested Android devices/configurations where system theme is Light and app appearance is forced Dark.

2. Debug logs that reproduce the issue

3. Steps to reproduce, with a description of expected vs. actual behavior

   1. Configure an Android app with its own in-app appearance setting, independent of system appearance.
   2. Set Android system appearance to Light.
   3. Set the app's appearance override to Dark.
   4. Present RevenueCat Customer Center using the Compose CustomerCenter composable inside the app's dark MaterialTheme.
   5. Observe that Customer Center buttons use colors appropriate for the light Customer Center appearance, making them hard to read against the dark app UI.
   6. Change the app appearance setting to follow System, then set Android system appearance to Dark.
   7. Present Customer Center again.

   Expected behavior:
   Customer Center should use the host app's effective appearance / current Compose theme, so if the app is currently dark, Customer Center should use dark appearance colors even if the Android system theme is light.

   Actual behavior:
   Customer Center appears to key off Android system dark mode. If Android system theme is Light but the app is forced Dark, Customer Center uses light appearance colors and buttons become low contrast.

4. Other information (e.g. stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc.)
   Related issues:

   • [Customer Center] Problem with theming colors (dark theme) #2428
   • [Customer Center] Difficulty to read some ui components due to the colors #2205
   • [Customer Center] Expired Status Badge hard to read in dark mode. #2681

   I checked the latest public release, 10.11.0, and the Customer Center implementation still appears to call isSystemInDarkTheme() internally in InternalCustomerCenter.kt, including when creating/loading Customer Center state and deriving the color scheme. That makes it difficult for apps with an app-level appearance override to keep Customer Center aligned with the app's effective theme.

Additional context
Our RevenueCat dashboard Customer Center appearance has separate Light and Dark colors configured. The issue only happens on Android when the app appearance override differs from Android system appearance. iOS behaves as expected and follows the app's effective appearance.

[vegaro]

Thanks for the detailed report. I think your read is correct: on Android, Customer Center currently calls isSystemInDarkTheme() internally to choose the configured light/dark Customer Center appearance colors. Because of that, wrapping CustomerCenter in a dark MaterialTheme is not enough if the Android system theme is still light.

Could you confirm whether you’re presenting Customer Center via the Compose CustomerCenter composable, CustomerCenterView, or ShowCustomerCenter activity result contract? For Compose, a temporary workaround may be to provide a LocalConfiguration with the app’s effective night mode around CustomerCenter, in addition to your normal app theme:

import android.content.res.Configuration
import androidx.compose.runtime.CompositionLocalProvider
import androidx.compose.ui.platform.LocalConfiguration
import com.revenuecat.purchases.ui.revenuecatui.customercenter.CustomerCenter

@Composable
fun ThemedCustomerCenter(
    useDarkTheme: Boolean,
    onDismiss: () -> Unit,
) {
    val baseConfiguration = LocalConfiguration.current
    val customerCenterConfiguration = Configuration(baseConfiguration).apply {
        uiMode = (uiMode and Configuration.UI_MODE_NIGHT_MASK.inv()) or
            if (useDarkTheme) {
                Configuration.UI_MODE_NIGHT_YES
            } else {
                Configuration.UI_MODE_NIGHT_NO
            }
    }

    CompositionLocalProvider(LocalConfiguration provides customerCenterConfiguration) {
        CustomerCenter(onDismiss = onDismiss)
    }
}

isSystemInDarkTheme() reads from LocalConfiguration, so this should make Customer Center select the dark Customer Center appearance when your app-level setting is dark.

[jjjeeerrr222]

Thanks, that matches what I’m seeing.

We’re presenting Customer Center via the Compose CustomerCenter composable, not CustomerCenterView or the ShowCustomerCenter activity result contract. It’s rendered inside our app’s Compose MaterialTheme, where the app has already resolved its own appearance preference.

We’ll try the LocalConfiguration workaround you suggested. That should unblock us for Compose if isSystemInDarkTheme() reads the provided configuration there.

Longer term, would you consider supporting this directly in the SDK? For apps with an in-app appearance setting, it would be useful if Customer Center could either:

1. follow the host app’s effective Compose theme/appearance rather than system appearance, or
2. expose an explicit appearance/night-mode override through CustomerCenterOptions.

The workaround makes sense, but it feels like app-level appearance overrides are common enough that a first-class API would be safer than relying on overriding LocalConfiguration around the Customer Center composable.

[vegaro]

Thank you for the feedback! We will consider a way to force it, since it would need to be possible to force it for non-compose presentations.