A merchant wants to experiment with design elements in the theme editor - button colors, font choices, border thickness, opacity. They're not comfortable editing Liquid code; they want to click, preview, save. The question for the developer: how do you expose the right knobs to the theme editor without giving merchants a way to break the theme? Shopify themes have a specific file that controls which settings merchants see in the theme editor: config/settings_schema.json. This schema defines: A well-designed settings schema gives merchants meaningful control without overwhelming them with technical knobs. config/settings_schema.json defines what the merchant sees: config/settings_data.json holds the merchant's saved values. This file isn't edited by developers directly - it's updated every time the merchant saves settings in the theme editor. Liquid templates consume the settings via settings.color_button_primary, settings.font_heading, etc. The file that controls merchant-editable design is config/settings_schema.json. Adding a new setting there makes it appear in the theme editor's global settings. Merchants click, preview, save; the change propagates across every section that references the setting. This is distinct from: Shopify's settings schema supports many types. For design tokens, the useful ones: For the scenario at the top - button colors, fonts, border thickness, opacity - the right setting types are color, font_picker, and range respectively. In Liquid, settings are accessed via the global settings variable: For bulk CSS styling, many themes compile settings into CSS custom properties in the layout: Then component CSS uses the custom properties: This separation means design-system changes in the theme editor propagate everywhere in one place. Modern Shopify themes support color schemes - named combinations of background, text, button, and accent colors that apply to sections. A merchant can define "Light scheme" and "Dark scheme" and apply either to any section. Color schemes live in the schema too but have their own structure: This is the pattern Dawn and modern OS 2.0 themes use. Merchants pick a scheme per section; the theme renders with the scheme's colors consistently. For fonts, the font_picker setting type returns a font object with a family name and URL. Themes use the font_url filter to load the right stylesheet: This emits the proper @font-face declaration for the chosen font. Merchants can pick any of Shopify's library fonts (Google Fonts + system) and the theme adapts automatically. A well-organized settings schema: A schema with 100 ungrouped settings is unusable even by technical merchants. A schema with 15 well-organized settings lets non-technical merchants confidently experiment. Not every theme value belongs in the settings schema. Good candidates: Bad candidates: The boundary: if a wrong value breaks the theme meaningfully, it doesn't belong in merchant-editable settings. A theme that supports non-technical merchant self-service has: Merchants who can self-serve design tokens stay happier with their theme. The developer's work is making the right set of knobs available without offering footguns.
scrcpy Integration in a Tauri App — Android Screen Mirroring on Mac