Shopify Theme Compatibility for Virtual Try-On
Try-on does not land cleanly on every Shopify theme. App blocks cover most Online Store 2.0 templates. Custom themes and mobile layouts still need a full QA pass.
Virtual try-on can sit on most Shopify themes that accept Online Store 2.0 app blocks, and it still needs a placement check on every product template you sell from. The block has to survive sticky add-to-cart bars, image zoom, and a color change. Vintage themes and headless storefronts are different jobs. Compatibility is a QA list you run on a phone, not a line in the app listing.
Two phones, two templates, hands in pockets until the pages are actually checked. Editorial image in Classic Antla disposable-camera style.
“Works with all Shopify themes” is a listing sentence. Your store has the product template you cloned for the wedding shop, the one an agency rewrote in 2023, and a quick-shop modal that never loads the same section. Try-on is compatible when a shopper can start it, finish it, change a color, and add to cart on those templates. The theme name in the footer does not answer that.
Shopify’s theme docs are the right first stop for which theme you are on and whether you are editing a published theme or a draft. The try-on question starts one level down: can this product section accept an app block, and did you enable it on every template that sells.
Explain app block support
Online Store 2.0 themes are built from JSON templates and sections. Merchants add app blocks in the theme editor, in sections that accept them, instead of pasting code into theme.liquid. Shopify’s app block documentation describes that model. Theme app extensions are how an app ships those blocks.
Practically, for a fashion product page:
- Dawn and themes built like Dawn usually expose app blocks on the main product section. You add the block once per template, near the gallery or the buy box, and you can reorder it.
- An app embed is the other pattern. Embeds are toggled for the theme as a whole. They are what older, non-JSON themes often get, and they give you less say over the exact spot on the page.
- A section that does not accept app blocks will not show your app in the “add block” list. That is not a broken install. It is a section that was not written to host blocks. You either move the block to a section that accepts it, or you change the section.
So the honest compatibility line is: on Online Store 2.0 product templates whose sections accept app blocks, a try-on app can be placed without a developer. On a vintage theme, expect an embed or a small theme edit. On a headless storefront, the Online Store theme editor is not in the request path at all. Hydrogen or a custom frontend will not render an Online Store app block just because the app is installed.
Antla places try-on through that app-block path on Online Store themes. The install is the start of QA, not the end of it. Adding try-on and the no-code setup notes walk through getting the block onto a page. This article is what you check after the block exists. Antla is the app if you are placing that block. It will not repair a product section that refuses blocks. Per Antla’s privacy policy: Images are deleted and not accessible within 72 hours.
Check actual placement
Placement is where “it works on Dawn” falls apart on a real catalog. Open the theme editor and list every product template, not just product.json.
Templates fashion stores forget:
- A separate template for dresses, one for denim, one for a collaboration.
- A gift-card or a landing product template cloned last holiday and never deleted.
- A featured product section on the homepage. That is not the product page. Do not expect the same block unless you added it.
- Quick shop, or a modal that loads a partial product form. Many of those never include app blocks. Decide on purpose: either the modal links to the full product page for try-on, or you accept that try-on is absent there.
Conflicts worth forcing in the editor before you involve a developer:
| What you see | What is usually going on | What to do |
|---|---|---|
| No try-on block in the add menu | This section does not accept app blocks | Add the block on the product section that does, or ask the theme author to allow blocks |
| Block only on the default product | Other templates were never edited | Repeat the placement on each selling template |
| Button hidden under a sticky add-to-cart bar | Stacking on mobile | Move the block above the bar, or turn the sticky bar off on that template and retest |
| Zoom lightbox covers the try-on dialog | Two overlays, one z-index | Close zoom before try-on, or open try-on as its own step. Retest on a phone |
| Color change keeps the previous garment | Variant image did not update the source | QA every color you sell. Do not ship on the first swatch alone |
Shopify PDP conversion work for fashion is the wider page checklist. Try-on placement is one item on it. A block shoved under the reviews is a block most shoppers will not find, which looks like “try-on does not work” in the numbers.
I would place the control where the appearance question happens: beside the gallery or directly above the size selector. Not in the footer, and not only inside a tab labeled “more.” If the theme’s product section cannot host it there, that is a theme constraint to write down, not a reason to claim the app is incompatible with Shopify.
Test custom themes
Custom does not mean one thing. Sort the theme before you write a bug.
A commercial theme with a few edits (Prestige, Impulse, and the rest of that family, plus whatever you have renamed). These are usually Online Store 2.0. App blocks work. The risk is duplicated product templates and a sticky header or cart drawer a contractor added. Test the templates you sell on, including the one used for ads.
A fully custom theme your agency owns. Ask two questions. Do the product sections accept app blocks? Which template does each collection actually assign? I have seen a Black Friday template that was a copy of the product section from before app blocks existed. The default product looked perfect. The drop template had no block. Document the assignment in the same note as the QA.
A vintage theme that still uses Liquid templates rather than JSON. You will not get the same editor placement. Budget an embed, or a small, reviewed edit, and retest after the next theme update. Do not promise the merchandiser a drag-and-drop block you cannot see in the editor.
Headless. Out of scope for an app block. Prove the preview on Online Store first if you still have that channel. A custom integration is a development project with its own QA, not a toggle.
After any of these, watch Core Web Vitals on the product URLs you enabled. A try-on script that loads on every template, including ones where the block is hidden, can tax the page without helping the shopper. If the vendor can defer the heavy work until the shopper opens try-on, use that. Do not stack a second visualization script “just in case” on the same template.
If your mobile template hides the block, almost nobody will start. Engagement among people who open try-on is not a layout trophy, and it is not a promise that a buried button will do the same.
Validate mobile behavior
Desktop theme-editor preview is a liar. Run this on a physical phone, iOS and Android if you can, on cellular.
- Open the hero SKU from the template you sell, not from the theme customizer.
- Find the try-on control without hunting past the reviews. If you hunt, shoppers will leave.
- Start and finish a preview. Time it. Note whether the page jumps when the result arrives.
- Change color. Confirm the garment in the preview matches the swatch.
- Change size. The preview is not a size measurement, and the size selector must still work afterward.
- Add to cart. No full reload that dumps the variant.
- Open the size chart or a drawer, close it, and confirm the try-on control is still there.
- Scroll to reviews and back. The sticky bar must not cover the control or the close button on the dialog.
- Repeat on the second template. Pass on Dawn’s default product is not a pass on the dress template.
Log pass or fail per template in a sheet with the theme version and the date. Shopify and your theme vendor will ship updates. A pass from June is not a pass in October. Mobile app versus mobile web try-on is a different decision, about where the experience lives. Most Shopify fashion brands are mobile web. This list is for that web theme.
The Shopify try-on app evaluation belongs before you pick a vendor. Theme QA belongs after, on your templates, even if the evaluation looked clean on a demo theme.
Where app blocks stop
A block cannot invent a section that accepts it. It cannot render on a headless frontend. It cannot fix a product photo that is only a back view. It cannot make a quick-shop modal grow a product section it does not have. And it does not measure the body. The preview shows appearance. The size selector and the chart still have to work beside it, including after the dialog closes.
If a contractor offers to hard-code the button into every template instead of using the block, ask what happens on the next theme update. Usually the button vanishes, or it doubles. Prefer the block, and keep the sheet of templates.
QA one template before the rest
Turn the app on for a single product template that has real traffic. Run the nine mobile steps. Fix placement before you copy the block to the other templates. Write down the theme version. When the theme updates, run the nine steps again on that same hero SKU before you assume the catalog is fine.
Compatibility is that sheet. The listing sentence is just how you got the app installed.
About the author: Aaron is the founder of Antla. He tests product pages on a phone because the theme editor has never returned a dress.