A multiplayer game's companion app shows the default theme for a moment before the player's saved faction theme appears; what causes this, and how do you fix it?
answer
- what paints before the choice is known
- asynchronous read after first render
- resolve before the first frame
- local copy first, account later
- neutral beats wrong
basics
~20 sThe saved theme is resolved after the first render, usually from asynchronous storage or a profile request. Fix it by reading a locally stored theme identifier before first paint, applying it at the root, and reconciling with the account afterwards without a second visible switch.
solid answer
~40 sThe app renders before it knows the player's theme: the choice sits in asynchronous storage or arrives with the account profile, so the first frame uses the default and the saved theme replaces it a moment later. The fix is to make the choice available **before the first frame**: keep a copy of the theme identifier where it can be read synchronously at startup, apply it at the root before any themed content renders, and, where content is rendered on a server, send the preference with the first request so the server renders the right theme. Treat the account copy as a later reconciliation that applies quietly or at the next launch. If the theme genuinely cannot be known in time, a neutral launch or skeleton state is better than the wrong theme.
go deeper
Recall the root cause: something renders before the saved theme is known, so the default paints first.
Explain the startup order: read a local identifier synchronously, apply it at the root, then reconcile with the account copy.
Diagnose which route caused it here, asynchronous storage, server rendering, late-mounting theme code or lazy assets, and prove the fix with cold-start tests.
Set the system-wide contract: where the choice lives, which copy wins on conflict, and what every product must render when the theme is unknown.
## What the player sees Every time the companion app opens, the screen appears in the default theme, then a few hundred milliseconds later jumps to the player's faction theme. On a slow connection it may take longer. It looks broken, it can feel like a flicker to people sensitive to sudden changes, and it undermines trust in a feature players chose deliberately. ## Why it happens The root cause is always the same: **the first frame is rendered before the theme choice is known**. Common routes to that state: 1. The choice is stored somewhere that can only be read **asynchronously**, and the app renders while the read is in flight. 2. The choice lives only on the **account**, so it arrives with a profile request after the app has already drawn. 3. Content is **rendered on a server** that does not know the player's preference and so renders the default. 4. The theme is applied by a component that **mounts late**, after the shell has already painted. 5. The theme's own assets, such as a faction font or artwork, are **loaded lazily** and swap in after first paint. ## Fix: resolve before the first frame - **Keep a local copy of the identifier** in a store that can be read synchronously at startup, and read it before rendering anything themed. - **Apply it at the root first.** The active theme is set on the app's root before the first themed view is created, so nothing ever renders in the default by accident. - **Let the server know when it renders.** If a server renders the first view, the preference must travel with the first request. On the web that is typically a cookie the server can read; on native mobile the equivalent is a preference store read before the first frame, with the launch screen covering the gap. - **Keep the launch surface neutral.** A launch screen or splash that belongs to no theme hides the resolution step without showing a wrong theme. - **Preload what the theme needs** for first paint, or design the theme so first paint does not depend on a lazily loaded asset. ## Reconciling with the account The local copy wins at startup because it is available immediately. When the account's copy arrives: - if it matches, nothing happens; - if it differs, because the player changed theme on another device, apply it without an animated transition, or defer it to the next launch, and document which the system does; - then update the local copy so the next start is correct. ## When the theme cannot be known in time On a first launch on a new device, there is no local copy. Rendering a **neutral** skeleton until the account answers is better than rendering the default and switching; a wrong theme is a visible error, a neutral state is simply loading. ## What not to do | Tempting fix | Why it is wrong | |---|---| | Animate the switch so it looks intentional | the wrong theme still shows first, now for longer | | Hide the whole app behind a spinner until the account loads | trades a flash for a slow start on every launch | | Store only on the account | guarantees the flash on every cold start | | Store resolved values instead of an identifier | stale values survive system updates | ## Testing it The defect only appears on **cold start**, so test cold starts: with each saved theme, with cleared local storage, with a slow network, and after changing the theme on a second device. A frame-by-frame recording of startup makes the flash visible where the eye misses it.
- The player changed theme on another device. What should this device do when the account copy arrives after startup?Apply the account's choice without an animated transition, or defer it to the next launch, and pick one rule the whole system documents. Then update the local copy so the next cold start is correct. What it should not do is flash between two themes every launch while the copies disagree.
- Is a theme transition animation ever appropriate?For a switch the user just triggered, a brief transition can help them follow the change, ideally respecting the platform's reduced-motion setting. On startup it is the wrong tool: animating from the default to the saved theme still shows the wrong theme first, and makes it last longer.
It is like a stage crew hanging the wrong backdrop for opening night and swapping it after the curtain rises. The fix is not a smoother swap; it is checking the running order before the curtain goes up.
saying these in an interview costs you the question
- Animating the theme change on startup fixes the flash.
- Storing the theme only on the account is enough.
- The flash is a network problem, so a faster server fixes it.
- Showing the default theme briefly is harmless and not worth fixing.
- Waiting for the account on every launch is the clean fix.