Settings are runtime config the app pulls from the API on boot and merges with static config baked into each build. The point is to let the backend steer front-end behavior, things like auto-login, without a redeploy, while each app still keeps compile-time defaults it owns.
Three sources stack, in order of increasing precedence, the API response, then shared/config/settings, then the app's own config/settings. The API provides the baseline, shared config sits over it for anything common to every app, and each app's local config gets the final say.
That ordering is deliberate and worth knowing, local config wins over the API. A value an app hard-codes in its own config cannot be overridden by the backend. So treat the API as the source for anything you want to flip remotely, and local config for anything a given app should pin regardless of what the API returns.
The load runs in the router's ready gate, in parallel with the auth check, and the first navigation blocks on it. The app cannot drop its loading cover without knowing its settings, so this resolves before any page renders. Once the store is flagged loaded every later navigation skips it.
Add the key to the Settings interface in shared/config/settings, give it a default in whichever config layer should own it, and read it back through useSettings. The interface is the one type both apps share, so a new setting is typed everywhere the moment it is declared. Out of the box the only wired-up setting is auto_login, the rest is yours to grow into.
Authentication for auto-login and the rest of the boot sequence the ready gate drives.