Settings
Build native settings navigation and pages with @kit/settings in apps/mobile.
What It Does
@kit/settings powers mobile settings rendering through:
- declarative UI config (
settings.ui.config.tsx), - typed shared schema (
settingsSchemas), - route-driven rendering with
SettingsNavigationandSettingsPages.
When To Use
- You need account/security/settings screens in the mobile app.
- You want schema-driven forms instead of hand-built React Native forms.
- You want shared settings schema consistency with dashboard/server flows.
Prerequisites
apps/mobile/config/settings.ui.config.tsxdefined.@kit/shared/config/settings.schema.configavailable.- TRPC client wiring in mobile app providers/layout.
Shared settings architecture
The mobile UI layer uses the same schema/storage model as the web settings system. For full schema/server architecture details, see Settings API Interest and Web Settings.
Flow Overview
settings-menu.tsx
settings.ui.config.tsx
settings-menu.tsxrenders grouped navigation entries.settings/[...settings]/index.tsxrenders page content by URL params.use-settings-ui-config.tsapplies filters to UI config before rendering.
How To Use
Define settings UI pages.
import { parseUISettingConfig } from '@kit/settings/ui-config'; import { settingsSchemas } from '@kit/shared/config/settings.schema.config'; export const EXTRA_INPUTS = { user_media: UserSettingMedia, }; export const settingsUI = parseUISettingConfig<typeof settingsSchemas.schema, typeof EXTRA_INPUTS>({ ui: [ { group: 'index', label: 'About you', settingsPages: [ { slug: 'index', title: 'Profile', settings: [/* forms, wrappers, custom UI blocks */], }, { slug: 'security', title: 'Security', settings: [/* AuthProviderZone, SessionZoneComponent */], }, ], }, ], });
Render navigation list.
<SettingsNavigation uiConfig={settingsUiConfig.ui} basePath={'/screens/settings'} />Render settings page from params.
import { SettingsPages } from '@kit/settings/native/ui'; import { CurrentSettingsProvider } from '@kit/settings/shared'; import { useApplyFilter } from '@kit/utils/filters'; const filteredSettingsSchema = useApplyFilter('get_settings_schema', settingsSchemas); const extraInputs = useApplyFilter('get_settings_extra_inputs', EXTRA_INPUTS); <CurrentSettingsProvider> <SettingsPages clientTrpc={clientTrpc} settingsUI={settingsUiConfig} settingsSchemas={filteredSettingsSchema} inputs={extraInputs} params={{ settings: params }} Wrapper={Wrapper} /> </CurrentSettingsProvider>
Add a new input component.
- Create input component.
- Register it in
EXTRA_INPUTS(settings.ui.config.tsx). - Use
type: '<your_input_type>'in settings page nodes. - If needed, extend via
get_settings_extra_inputsfilter.
Inputs API (Mobile)
| Input source | Purpose |
|---|---|
@kit/settings built-ins (text, textarea, boolean, wrappers, forms, etc.) | Core settings form primitives |
EXTRA_INPUTS in app config | App-specific input types (e.g., user_media) |
get_settings_extra_inputs filter | Runtime extension/enqueue of additional input renderers |
Under the hood, settings forms are rendered with QuickForm primitives. This is why custom inputs follow the same contract style as QuickForm components.
Filter API
Mobile settings pages are composed from client filters, while the backing settings API schema/providers are composed with server filters on the web API app.
| Filter | Parameters | Return | Registered By (package file) | Initialized In (app entrypoint) | Environment |
|---|---|---|---|---|---|
get_settings_schema | {} | SettingsSchema | kit/organization/src/native/filters/use-filters/use-settings-filters.tsx | apps/mobile/hooks/use-filters.ts (useOrgFilters) | client |
get_settings_ui_config | { clientTrpc: TrpcClientWithQuery<Router<unknown>> } | ReturnType<typeof parseUISettingConfig> | kit/organization/src/native/filters/use-filters/use-settings-filters.tsx | apps/mobile/hooks/use-filters.ts (useOrgFilters) | client |
get_settings_extra_inputs | {} | SettingsInputsBase | kit/organization/src/native/filters/use-filters/use-settings-filters.tsx | apps/mobile/hooks/use-filters.ts (useOrgFilters) | client |
server_get_settings_schema | {} | SettingsSchema | apps/dashboard/lib/init-server-filters.ts, kit/organization/src/www/filters/server-filters.ts | apps/dashboard/lib/init-server-filters.ts | server |
server_get_settings_server_config | {} | ReturnType<typeof parseServerSettingConfig> | kit/organization/src/www/filters/server-filters.ts | apps/dashboard/lib/init-server-filters.ts | server |
Init Checklist
- Keep
useOrgFilters({ clientTrpc, orgConfig })inapps/mobile/hooks/use-filters.ts. - Keep server settings filter initialization in
apps/dashboard/lib/init-server-filters.tsfor the settings API backend.
MCP Context
capability: settings_mobile_ui entrypoints: - apps/mobile/config/settings.ui.config.tsx - apps/mobile/app/(app)/screens/settings-menu.tsx - apps/mobile/app/(app)/screens/settings/[...settings]/index.tsx - apps/mobile/hooks/use-settings-ui-config.ts - apps/mobile/hooks/use-filters.ts - kit/organization/src/native/filters/use-filters/use-settings-filters.tsx - apps/dashboard/lib/init-server-filters.ts - kit/organization/src/www/filters/server-filters.ts inputs: - settings_ui_config - settings_route_params - extra_input_components outputs: - native_settings_navigation_and_forms constraints: - settings slugs must match navigation routes - settings schema keys used in forms must exist in effective settings schema side_effects: - updates user/organization settings via settings API routes
Agent Recipe
- Add/adjust settings page nodes in
settings.ui.config.tsx. - Ensure required schema keys exist in shared settings schema.
- Verify navigation path (
/screens/settings/...) and settings params resolve correctly.
Troubleshooting
- If a page is missing, verify slug exists in
settingsUIand navigation base path is correct. - If a field fails silently, verify its schema key exists and its input type is registered.
- If settings content is stale, verify filters are initialized before settings pages render.
Related
How is this guide?
Last updated on 3/27/2026