Install on ShopifyA Shopify Online Store 2.0 section is a chunk of Liquid that lives inside your theme and renders on Shopify's own servers. An app is a separate service that adds capability your theme cannot reach by itself. They genuinely overlap in exactly one area, page content, which is why the useful question is almost never "section or app" but "where does this thing need to live, and will my theme even let it live there?"
That reframe is the whole post. Placement constraints come before the build-or-buy decision, and most of the frustration on this topic comes from making the decision in the wrong order. Let me show you with the most common way merchants arrive at the question.
The testimonial problem
You installed Dawn. You want three customer quotes on your homepage. You open the theme editor, click "Add section", and there is no testimonial section in the list. So you search, and land on ten listicles of section apps, none of which explain why the section isn't there.
Here is why. I cloned Dawn v15.5.0 (the release published 19 June 2026) and counted. Dawn ships 53 .liquid files in sections/, but only 22 of them can actually be added in the theme editor. The other 31 are main-* template sections and plumbing (cart-icon-bubble, predictive-search, cart-live-region-text) that you can never add or remove.
Section counts for Dawn float around the internet and rarely agree, mostly because they quietly mix those two figures. The pair that matters is 22 addable out of 53 total, and the mechanism that decides which is which is worth understanding, because it explains the rest of this post.
A section becomes addable only if its schema defines presets. Shopify's own JSON templates doc is unambiguous:
"Section files must define presets in their schema to support being added to JSON templates using the theme editor. Section files without presets should be included in the JSON file manually, and can't be removed using the theme editor."
That's it. presets is the difference between a section you can add and one that just exists. Now the part that answers the original question: I grepped Dawn 15.5.0 for testimonial, FAQ, trust, countdown, bundle, and quote sections. It ships zero of all six.
Not "hidden in a submenu." They do not exist. Dawn's collapsible-content is the de-facto FAQ section, which is genuinely useful to know, but it is not named FAQ and not built for it. Dawn does render star ratings on product pages from the standard reviews.rating metafield when that data exists, but that is a rating display, not a testimonials section. And Dawn's badge code is card__badge, the sale and sold-out label on product cards, not a trust badge. Two things that look like matches in a search and are not.
So when a merchant asks "do I need an app for a testimonial section?", the honest answer is: your theme does not have one, so you write Liquid, pay someone once to write Liquid, or install something. That's the real menu.
What an OS 2.0 section actually is
A section is a .liquid file in your theme's sections/ directory. It has two parts: markup written in Liquid, and a {% schema %} block of JSON that declares its settings. The schema turns hardcoded HTML into something a non-developer can configure in the theme editor.
Sections render server-side. By the time HTML reaches the browser, a section is just HTML. No runtime, no hydration, no external request required to draw it. That is the architectural reason native sections tend to be fast, and it's a property of the theme system, not of any vendor's cleverness.
Two limits worth knowing, both from Shopify's docs: a JSON template or section group can render up to 25 sections, and each section can have up to 50 blocks. If you're building a long landing page, 25 is closer than it sounds.
Sections are also yours. They sit in your theme, get copied when you duplicate it, and survive any app uninstall, because no app is involved.
What an app actually is
"App" is where the conversation goes wrong, because merchants use one word for at least three things that behave completely differently on your storefront.
One: an app that ships a theme app extension. The modern path. The app's code lives outside your theme in an extension Shopify hosts, and surfaces in your theme editor as app blocks and app embeds. Nothing is written into your theme files. Uninstall is clean.
Two: an app that writes native Liquid into your theme. The app installs actual .liquid section files into your sections/ directory. After that they behave like theme sections, because they are theme sections. What happens on uninstall depends entirely on the vendor.
Three: an app that renders your page from its own runtime. Most classic page builders work this way. You design in the app's canvas and the app renders the page, largely outside your theme's section system. This buys real design freedom and is a legitimate choice for one-off landing pages. It also means the page is the app's, not the theme's, with the lock-in and performance profile that implies.
These are not the same decision. Lumping them into "an app" is why so much advice on this topic is useless.
Within the extension path there's a second distinction merchants conflate constantly. App blocks are inline content you place at a chosen spot, and they are OS 2.0 only. On vintage themes they don't work, and you're back to copy-pasting Liquid. App embed blocks are for things that float or run globally: chat bubbles, tracking pixels, analytics, meta tags. They work on vintage and OS 2.0 alike, and cannot point at dynamic sources.
Ask "where on the page should this appear?" and you want an app block. Ask "should this run across the storefront at all?" and you want an app embed.
Where sections and apps genuinely overlap
Three places, and only three.
Page content. Heroes, feature grids, FAQ accordions, testimonial walls, image-with-text. A section can do this. An app block can do this. This is the contested ground, and where nearly every "section vs app" search actually lives.
Product page additions. Size guides, shipping estimates, FAQ accordions on the product template. Either primitive works, assuming your theme allows the placement (more on that shortly).
Storefront polish. Trust badges, payment icons, urgency messaging. Both can deliver these.
Outside those three, the comparison mostly stops being a comparison.
The four places they don't overlap
1. The placement ceiling: apps can only go where your theme lets them
This is the constraint nobody writes about, and the most important one on this page.
An app block can only be placed inside a section whose schema explicitly opts in, by declaring "blocks": [{"type": "@app"}]. No opt-in, no app block. The app has no say. Shopify has no say. The theme author decided this when they wrote the theme.
So I counted. In Dawn 15.5.0, only 8 of the 53 sections accept app blocks: header, footer, apps, newsletter, featured-product, main-product, main-cart-footer, and main-article.
That's it. You cannot put an app block in Dawn's slideshow, collage, image-banner, multicolumn, or collection pages, because those sections never opted in. Dawn's sections/apps.liquid exists precisely as an escape hatch: a bare loop that renders whatever blocks you drop in it, with one setting (include_margins). It's the "put the app somewhere" section.
If you've ever wondered why an app block won't go where you want it, that's the answer, and it's a theme limitation no app can engineer around. App blocks also can't be used in statically rendered sections, only in JSON templates.
A native theme section has no such ceiling. It goes wherever you can add a section.
2. Vintage themes
App embeds work. App blocks don't. If you're on a pre-2.0 theme, the entire app-block conversation is moot and you're looking at copy-pasted Liquid, which is exactly the fragile setup OS 2.0 was built to end.
3. Anything server-side
A section is Liquid rendered at page-load. It cannot receive a webhook, run a nightly job, hold state between visits, call an external API on a schedule, or talk to your ERP. Not "it's awkward." It structurally cannot. Any feature whose real work happens when nobody is looking at the page needs an app, because it needs a server.
4. Checkout
Sections render on Online Store pages. Checkout is not an Online Store page. A section's reach there is zero, and no amount of theme work changes that.
The decision framework
Ask these in order. The order matters more than the answers.
- Where does this need to live? Checkout, or the storefront? If checkout, stop, you need an app.
- Does the work happen when nobody is on the page? Webhooks, syncs, scheduled jobs, billing. If yes, stop, you need an app.
- Is your theme OS 2.0? If no, app blocks are off the table.
- Does anything let it live where you want it? If it's an app block, does that section declare
@app? In Dawn, only 8 of 53 do. Check before you buy. - Only now: does your theme already have this section? If yes, use it. Dawn's
collapsible-contentreally will do your FAQ. - If it doesn't exist: write Liquid, buy Liquid once, or install something that provides it.
Most advice starts at step 5 and never mentions steps 1 through 4. That's why merchants buy an app and then find they can't put it where they wanted it.
When an app is genuinely the better answer
I build an app that ships sections, so treat me as biased and check this list against your own store. These are the cases where a section is not merely worse, it is not a candidate.
Checkout extensions. Timely rather than theoretical. Shopify's Plus deadline for Thank you and Order status pages passed on 28 August 2025. In January 2026, automatic upgrades began, and customizations using additional scripts, apps with script tags, or checkout.liquid on those pages were lost. Shopify Scripts sunset on 30 June 2026. If you're on a non-Plus plan, Shopify's stated deadline to upgrade those pages is 26 August 2026, about six weeks from today. Checkout extensions are the replacement path, and only an app can ship them. No theme section is part of this conversation.
Server-side webhook processing. Order-paid triggers, inventory sync, fulfilment automation, anything reacting to a Shopify event. Requires a server, so requires an app.
Subscription billing. Recurring contracts, dunning, payment retries, customer portals. A payments system, not a page.
ERP and back-office sync. Two-way data flow with whatever runs your operations. Sections are a rendering layer. This is an integration problem.
Page builders deserve a fair word too. If you want pixel-level control over a one-off campaign landing page and don't want to touch Liquid, a builder gives you design freedom a settings-driven section won't match. That's a genuine strength, and the tradeoff is that the page belongs to the builder.
What's changing: Horizon raises the ceiling
Everything above describes the Dawn era, and the Dawn era is ending. Horizon, Shopify's newest theme foundation (introduced in Editions Summer '25), is built differently. I cloned it too, at version 4.1.1, pushed 24 June 2026:
| Dawn v15.5.0 | Horizon 4.1.1 | |
|---|---|---|
| Section files | 53 | 40 |
Addable sections (with presets) | 22 | 28 |
A blocks/ directory | Does not exist | 95 block files |
Sections accepting @app | 8 of 53 | 15 of 40 |
Blocks accepting @app | n/a | 16 of 95 |
Two things stand out. Dawn never adopted theme blocks at all, it has no blocks/ directory. And Horizon roughly doubles the app surface area: from 8 of 53 sections accepting app blocks to 15 of 40, plus 16 block-level opt-ins Dawn has no equivalent for.
The placement ceiling is rising. It has not disappeared. And the content gap closes only partway, so let me be precise about it rather than leave you with a convenient impression. Horizon ships no testimonial, trust badge, countdown, or bundle equivalent, at section or block level. But it does ship an addable accordion block, presets and all, which arrives with return policy, shipping, and manufacturing rows already filled in. That is Horizon's collapsible-content, and it's a better FAQ primitive than Dawn's because you can place it. It also ships payment-icons and a product-inventory block that reads your actual stock.
So on Horizon, FAQ and payment icons genuinely get easier, and its review block renders rating stars from the reviews.rating metafield (its own schema notes you still need an app to supply the ratings). For testimonials, trust badges, countdowns, and bundles, the reason merchants arrive at this question is intact.
These counts are point-in-time, as of 15 July 2026. Both themes ship often, so re-run the count before you rely on it.
Where Modulo sits, since you should ask
It would be convenient to write "sections good, apps bad" and stop. That would also be nonsense, because Modulo is an app that delivers sections. Pretending this is a clean binary would be dishonest, and you'd catch it.
The real axis is not app versus no-app. It's what the app does to your storefront: does it deliver native theme sections that render server-side in Liquid, or does it render your pages from its own runtime outside the theme?
Modulo is the former. It installs 200+ native OS 2.0 theme sections that render in Liquid (no iframes, no <head> injection, no checkout.liquid), plus 16 storefront blocks through a theme app extension. You configure them in Shopify's own theme editor, because to the theme editor they are just sections. It's free today, with no paid tier.
It's still an app, and it still shows up in your app list. The distinction I'm drawing is about rendering architecture, not about avoiding the word. And by the framework above, Modulo only answers step 6, the "this section doesn't exist in my theme" step. For checkout extensions, webhook processing, subscription billing, or ERP sync you need a different app, and I'd rather tell you here than have you find out after installing.
Install on ShopifyIf your actual question was narrower than this post, the specific pages are more useful: testimonials, FAQ, comparison tables, or trust badges.
Questions, corrections, or a count I got wrong: hello@runmodulo.com. If you re-run the Dawn and Horizon numbers and get something different, I want to know, and I'll update the post.
