App Blocks and App Embeds: The QA Blind Spot in Shopify Handoffs

The gap between what you tested and what shipped

You built a product page. Clean layout, generous whitespace, buy button comfortably above the fold on mobile. The client approved it. You published.

Within an hour: the reviews app has injected a star rating and a review summary above the buy button, pushing it below the fold. A cookie banner covers the bottom third on first load. A chat bubble sits over the "add to cart" on small screens. An upsell drawer opens on top of the gallery.

None of it was in your preview, because most of it is enabled per theme. Publishing a new theme doesn't carry over what the merchant had switched on.

Blocks and embeds fail differently

Shopify gives apps two ways into a theme, and each has its own failure mode.

App blocks sit inside a section

The merchant adds them in the theme editor, at a chosen position in a template. They're recorded in the template's JSON as a reference to the app's block:

{
  "blocks": {
    "reviews_widget": {
      "type": "shopify://apps/product-reviews/blocks/rating/xxxx-xxxx",
      "settings": { "star_colour": "#f5a623" }
    }
  },
  "block_order": ["title", "price", "reviews_widget", "buy_buttons"]
}

Copy that template to a theme where the app isn't installed and the block reference can't resolve. Best case it's silently dropped and the layout is missing an element the client expects. Worse case the template misbehaves in the editor.

Note the block_order: the reviews block sits before buy_buttons. That ordering is configuration on the live theme. Your theme has its own, and they won't match unless you deliberately reproduce it.

App embeds inject globally

Enabled in theme settings, not placed in a template. They inject into theme.liquid at render time — cookie banners, chat widgets, popups, currency switchers, tracking pixels. They don't appear anywhere in your template files, so nothing in your codebase hints they exist.

And they're the ones that do the most layout damage, because they're overlays. Fixed-position elements over your content, on the viewport you didn't check.

Auditing apps before you build, not after

This belongs in discovery, alongside the theme drift check. Ten minutes at the start prevents a launch-day scramble.

The questions worth asking the merchant

• Which of these apps do you actually use? Most stores carry apps nobody has opened in a year. Uninstalling is often the cheapest fix available.
• Which are contractually required? Cookie consent and accessibility overlays usually aren't optional — design around them.
• Which have you customised? Positioning and styling set inside an app's own admin won't be in the theme at all.
• Any legacy script tags? Older apps inject via script tags rather than embeds and often apply to all themes, including yours.

QA that catches app conflicts

The core principle: QA the theme with the apps on. A clean theme is not the thing you're shipping.

1. Enable the embeds on the theme under review. Not on the live theme — on the one you're testing. This is the step almost everyone skips.
2. Test first-visit state. Cookie banners and popups only appear to new visitors. Use a private window or clear storage, otherwise you'll never see them again after the first load.
3. Check the overlay-heavy viewports. Small phones are worst: a banner, a chat bubble and a sticky bar can leave very little usable screen.
4. Screenshot with apps active. Cross-browser captures of a clean theme give false confidence. Capture what will actually render.
5. Verify z-index and stacking. App overlays and your own sticky elements will fight. Decide who wins deliberately.
6. Re-check after publishing. Publishing can change embed behaviour. Load the live storefront in a private window before you tell anyone you're done.

How ThemeSync helps here

• App blocks and dynamic sources are detected in your templates. You get told which templates carry app-dependent blocks before you move or publish them, rather than finding out when a block silently vanishes.
• Previews run on the client's real store. Because the theme renders on their storefront, storefront-wide app behaviour and legacy script tags show up in review instead of only after publishing.
• Screenshot runs capture overlays as they render. Every mapped template across desktop, tablet and phone, with whatever is actually injecting on the page.
• Dismiss selectors let you capture both states. You can auto-close a cookie banner or popup before capture, so you get clean screenshots for design review and honest ones showing the overlay.
• Client sign-off is recorded per page and viewport. When approval is tied to a specific captured state, "this isn't what I approved" becomes a question with an answer.

Takeaways

• App blocks live in template JSON and reference a specific installation. App embeds are enabled per theme and appear nowhere in your files.
• Both are per-theme, so your theme starts with none of what the merchant has switched on.
• Embeds cause most layout damage because they're overlays, and mobile suffers most.
• Audit installed apps in week one — it changes what you design, not just what you test.
• Enable the equivalent embeds on the theme under review before QA. A clean theme is not what you're shipping.
• Test first-visit state in a private window, and re-check the live storefront after publishing.