Theme app extensions: the free real estate on your store

What a theme app extension actually is

A theme app extension is a bundle an app ships alongside itself, containing four things: blocks, app embed blocks, assets, and snippets. Blocks are Liquid files that act as the entry point for whatever the app injects into a theme.

The bundle lives in the app’s repository under extensions/, with subdirectories for assets, blocks, snippets and locales, plus a shopify.extension.toml. It is deployed with the app and versioned with it.

Three consequences follow from that structure, and they are the reasons this replaced pasted code.

Assets are hosted on Shopify’s CDN rather than a third-party origin, so the browser does not open a new connection to fetch them. Updates ship to every store using the app at once, without a merchant re-pasting anything. Nothing is written into theme files, so a theme update does not destroy the integration and uninstalling the app removes it cleanly.

The free real estate framing is literal. If you already pay for an app, its blocks are included, and the placements you have not made are capacity you have already bought.

App blocks vs app embed blocks

	App block	App embed block
Placement	Merchant chooses the position in a template	Applies to the whole theme, positioned by the app
Typical use	Inline content: a badge under the price, a referral panel, a review list	Floating or invisible: popups, chat bubbles, banners, tracking
Theme support	Online Store 2.0 templates only	Works on vintage themes too
Loading	Assets load on the templates where the block is placed	Loads across the theme once enabled
Default state	Not placed until a merchant adds it	Off until a merchant enables it
Where it appears in code	Template JSON, with a type beginning shopify://apps	settings_data.json

The distinction that matters commercially is control. An app block is yours to move, and an app embed is the app’s to position.

The distinction that matters technically is scope. Blocks load where they are placed, embeds are enabled once for the theme, and both are still far better than a script tag, which loads everywhere with no merchant control at all.

Neither is switched on by installation. An app you installed six months ago may be contributing nothing to your storefront because nobody opened the theme editor afterwards.

The surfaces a theme app extension cannot reach

App blocks and app embed blocks cannot render on checkout pages. That includes contact information, shipping method, payment method, and the order status page.

This trips up more merchant plans than any other limitation, because the order status page is where post-purchase blocks feel like they belong. It is not a theme surface. It is a checkout surface.

Those pages need checkout UI extensions, which are a different extension type with different plan rules. Thank you and order status extensions are available on every plan except Starter, while extensions on the checkout steps themselves are Plus-only.

The practical translation for a merchant: if an app offers you a post-purchase widget, it is shipping a checkout UI extension, and you will find it in a different place in the admin from your theme blocks.

Placement by surface: reach against eligibility

Assumptions: 45,000 monthly sessions, 900 orders, ₹1,800 AOV, 40% gross margin. Impression shares are modelled, and one session can appear in several rows.

Surface	Extension type needed	Modelled monthly impressions	Who can act on it
Product page	App block	31,500	Everyone, with buying intent
Collection and search	App block	18,000	Everyone, browsing
Home page	App block	15,750	Everyone, lowest intent
Cart drawer	App embed or app block	5,400	Everyone, highest intent
Checkout steps	Checkout UI extension, Plus only	1,350	Everyone who started checkout
Order status page	Checkout UI extension	2,160	Buyers only, over several visits
Thank you page	Checkout UI extension	900	Buyers only, once

Reading this table as a ranking is the mistake. The product page has 35 times the impressions of the thank you page, and for some blocks that ratio is worth nothing at all.

The variable that decides placement is eligibility, meaning the share of people seeing the block who are actually able to do the thing it asks. Impressions times eligibility times action rate is the only calculation that matters, and the first term is the one everybody optimises.

Step 1: audit what is already placed

Open the theme editor and check two panels. The block insertion panel on each template shows what can be added and what has been added, and the App embeds panel in theme settings shows every embed and its on-off state.

Check templates individually. A block placed on the product template does not appear on collection or cart, and most stores have placed blocks on one template and assumed store-wide coverage.

In code, the audit is faster. Placed app blocks appear in the template JSON files with a type beginning shopify://apps, and enabled app embeds appear in settings_data.json.

Watch for blocks sitting inside a section called Apps. When a merchant adds an app block to a new section rather than an existing one, Shopify wraps it in that section automatically, which is usually how a block ends up at the bottom of a page where nobody scrolls.

Step 2: match each block to the surface where its audience is eligible

Two worked cases, using the same store assumptions as the table above.

SB&R is a Shopify app for chained referral rewards. Every referral link belongs to someone who has already bought. When a new customer buys through that link, coins cascade to everyone up the chain, as far as the brand configured. Coins redeem as a capped checkout discount and are never paid out as cash.

Eligibility for a referral block is defined by having bought, so the entire product page audience is ineligible by construction. The working on the correct surfaces: 900 buyers, a modelled 10% share rate across the thank you and order status pages, and 15% of shared links converting gives 13.5 referred orders a month, which at ₹576 of net margin per referred order is ₹7,776 against a ₹4,000 fee.

The same block on the product page reaches 31,500 people and produces nothing. Thirty-five times the impressions, zero eligibility.

SB&R is not for cash-payout affiliate programs, and it is not for B2B or wholesale referral. A wholesale buyer placing quarterly orders is not going to forward a link to another distributor, and no placement fixes that.

FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify’s own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order.

The offer case inverts. Anyone can be in the live pincode, so eligibility is universal and reach becomes the right metric, which puts the live-zone banner on the product page and in the cart drawer.

The working: if 12% of sessions come from the live zone, that is 3,780 sessions a month, and a banner that lifts conversion on those sessions from 2.0% to 2.4% adds 15 orders at ₹540 of post-discount margin, or ₹8,100 a month. The discount applies at checkout either way, so what the block buys is the shopper knowing about it before the cart.

Step 3: verify the block renders where you think it does

App blocks are not supported in statically rendered sections. If a theme section is hardcoded rather than part of a JSON template, your block cannot go inside it, and the theme editor will not offer it.

Sections have to opt in to accepting blocks of type @app. Dawn’s main product section does, which is why almost every app demo looks effortless on Dawn and awkward on a heavily customised theme.

Test on more than one template. A block that renders on the product page can fail on collection or search because the surrounding section schema differs, and the failure is silent.

Preview on mobile before publishing. Most Indian D2C traffic is mobile, and a block that reads well beside a desktop price sits three scrolls below it on a phone.

Step 4: turn off the app embeds nothing depends on

App embeds are the ones to audit for weight, because they apply across the theme rather than to one template. An embed left enabled by an app you stopped using is pure cost.

The savings are real but bounded. Extension assets come from Shopify’s CDN, so there is no new connection to open, which makes an unused embed cheaper than an unused script tag from a third-party origin.

Uninstalling the app removes its extension. Code an agency pasted into your theme files does not go anywhere, and that is the residue worth searching for by app name after any uninstall.

The wider version of this audit, including what each app category costs in milliseconds, is in the apps quietly slowing your checkout down.

The limits worth planning around

A single theme app extension can contain up to 30 app blocks, raised from 25 in February 2026. Liquid file size across the extension and settings per block are the limits that bite sooner, and they are why apps sometimes ship fewer configuration options than their admin UI suggests.

Blocks cannot reach checkout, as covered above. They also cannot fetch app data at render time the way a server-rendered page can, so anything dynamic arrives through metafields, an asset, or a client-side call after paint.

Vintage themes only support app embeds. If your theme predates Online Store 2.0, the inline placement conversation ends there, and the theme is the project rather than the block.

When a theme app extension is not the answer

Some logic needs no UI at all. A discount that applies automatically at Shopify’s checkout is a Shopify Function reading a metafield, and adding a block for it is optional decoration rather than the mechanism, which is the distinction drawn in what changed after Scripts died.

Post-purchase surfaces need checkout UI extensions, not theme blocks. If your plan for a referral program rests entirely on the order status page, you are planning a different extension type than the one this guide covers.

Placement does not rescue a category that does not belong in your stack. A block for an app whose break-even you cannot state is a better-positioned version of a cost you should not be carrying, and the two prior questions are answered in the stack audit and the stack that pays for itself.

The honest limitation is that placement is a multiplier, not a source. A block on the right surface with the wrong offer behind it converts at the wrong rate more visibly, and the store that places nothing at all is usually not losing to the store that placed six things, it is losing to the store that placed one thing where the eligible audience was standing. The companion argument, on which blocks most stores have never claimed, is in the extensions nobody can ignore.