[dcalhoun]

What?

Add Demo app feature toggles for theme styles and third-party blocks.

Why?

Simplify testing the editor with and without these features.

How?

• Add feature toggles for each in the Site Configuration view
• Disable the toggle if the site lacks support for the feature

Testing Instructions

Note

Theme styles requires the site have the Gutenberg plugin, third-party blocks requires the Jetpack plugins.

1. Launch the Demo app
2. Verify the presence of each feature based on the status of the toggle
3. Verify the toggle is disabled if the site lacks support for the feature

Accessibility Testing Instructions

N/A, unnecessary for the demo app.

Screenshots or screencast

Available	Unavailable

---

AI-generated details

Adds "Enable Theme Styles" and "Enable Third-Party Blocks" toggles to the iOS and Android demo apps' site configuration screens.

• Each toggle is on by default and disabled when the site lacks support (editor settings or block assets).
• The editor gets each feature only when the toggle is on and the site supports it.
• The "Supports Theme Styles" and "Supports Block Assets" rows still show site support, not the toggle state.
• Changing either toggle or the post type drops prepared dependencies. The toggles and post type picker are disabled while a prepare runs so its result can't overwrite the reset.
• EditorService reuses cached editor settings and asset bundles regardless of these flags, so a warm cache can still supply them while off. Left for a library follow-up.
• iOS: the site configuration loads once instead of on every .onAppear, so returning from Browse no longer resets the screen's settings.
• iOS: editor preparation runs on the main actor.
• Android: "Prepare Editor" now uses the same built configuration as Start, so it honors the toggles and the selected post type.
• Android: refreshes the Detekt baseline for FeatureConfigurationCard's new signature.

🤖 Generated with Claude Code

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/788")

_{Built from 8c3918a}

[nbradbury]

@dcalhoun The first finding sounds like it should be addressed.

Severity	Location	Issue	Impact
High	SitePreparationViewModel.kt:116	prepareEditor now builds its config with buildConfiguration(), which includes the post type, but setPostType doesn't clear editorDependencies and the picker stays enabled while preparing.	Prepare with "post" selected, switch to "page", then tap Start: the editor gets a "page" config with preload data for "post", so the preload entries miss and the UI still reports the stale dependencies as loaded.
Medium	SitePreparationView.swift:77	The Post Type picker isn't disabled while preparing, so the race fbcfbf5 fixed for the new toggles is still open for the picker.	Tap Prepare, pick "page" before it finishes: the setter nils editorDependencies, then the running Task stores the "post" dependencies (line 433), and Start opens a page editor with the "post" preload list.
Medium	SitePreparationView.swift:426	disableButtons = true is set inside the Task started from nonisolated prepareEditor(with:), so the lock comes on late and the write happens off the main actor.	A toggle flipped between tapping Prepare and the Task starting clears editorDependencies, and line 433 then stores dependencies built under the old setting.
Medium	SitePreparationView.swift:359	siteSupportsThemeStyles/siteSupportsBlockAssets are read from buildOfflineConfiguration's config, which sets both to true unconditionally.	Offline, a site without /wp-block-editor/v1/settings shows both toggles as enabled and "Supports Theme Styles" with a green check.
Medium	commits b36e1115..fbcfbf54	All six branch commits include a Co-Authored-By: Claude Opus 5.5 trailer, which your global CLAUDE.md forbids.	Pushing as-is publishes the trailer, so the commit messages need rewording first.
Low	SitePreparationView.swift:362	Re-applying the theme-styles and third-party preferences after reload treats the symptom, since .onAppear re-runs startLoading() on every return from Browse.	Coming back from Browse still resets Network Logging, Network Fallback and Native Inserter while keeping the prepared dependencies, and refetches the API root each time; a guard editorConfiguration == nil in startLoading() fixes every toggle.

[dcalhoun]

@nbradbury thanks. I addressed items 1, 2, 3, and 6; these were preexisting. Finding 4 is intentional, it presumes site support when there is no network connection; the negative is a hidden, failed request. Finding 5 appears to be personal Claude configuration on your machine.

[nbradbury]

Looks good!