The same edition,
read for builders.

Bottom line up front: Spring '26 is the most consequential edition for app founders in a while, because it does two opposite things at once. It opens genuinely new surfaces to build and earn on, and it pushes the platform deeper into territory that used to belong to third-party apps. If you build on Shopify, the edition is not a feature list to skim. It is a map of where the platform is expanding and where it is leaving room for you. Read it that way and the moves are clear.

I built the Partner Program in the early days, so I have watched this dance for over a decade. Shopify expands its native surface every edition, and every edition some founders panic and some find the new opening. The ones who do well are not the ones who guess what Shopify will not build. They are the ones who build where a general-purpose platform structurally cannot win: deep data, complex workflows, integrations off Shopify's surface. Spring '26 is a clean test of that instinct, and this is the full builder read, section by section, with a verdict on each.

Opportunity and
encroachment, together.

Shopify is calling it the Everywhere Edition, and the tagline, "sell, shop, and build everywhere," puts "build" in there on purpose (Shopify Editions, Spring '26). Shopify wants more developers building on its agentic infrastructure, and it is dangling new surfaces and new revenue to get them. At the same time, Sidekick getting more capable and reaching into apps is the platform absorbing tasks that used to be entire app categories. Both are true in the same drop.

Tobi Lütke has been blunt that AI use is a baseline expectation at Shopify, not optional (Tobi Lütke on X, April 2025). For a founder building on the platform, that internal stance is your forecast. Shopify is going to keep shipping AI-native capability fast, and the surface it considers core will keep widening. Your job is to read each edition for the line: what just became platform, and what is the platform now inviting you to build on top of it.

This is the builder cut of the same edition I broke down for brand operators here. If you want the prior edition as a baseline, I also wrote the Winter '26 edition for app owners and a fuller value map of where the ecosystem creates and destroys value.

A new surface, with
revenue attached.

Spring '26 turns agentic commerce into a real build surface, not a demo. Shopify shipped three MCP servers (Catalog, Cart, Checkout) on top of the Universal Commerce Protocol, plus a Catalog API with image search, real-time product lookup, Shop sign-in, and multi-seller offer data. The headline for builders is the monetization hook: sponsored products with the Catalog API means you can earn revenue on sales inside the agentic experiences you build. That is the part that turns a side project into a business.

Start with the protocol, because everything hangs off it. The Universal Commerce Protocol is an open standard, co-developed by Shopify and Google, for the full commerce journey: discovery, search, cart, identity, checkout, post-purchase. Shopify's agent stack ships as UCP-compliant MCP servers by default. If you have built anything with the Model Context Protocol, the shape is familiar: UCP defines the commerce conversation, MCP is how an LLM actually calls those capabilities as tools. Spring '26 exposes that as Catalog, Cart, and Checkout MCPs you can wire into discovery-to-purchase experiences (Shopify Editions, Spring '26). Worth knowing the competitive frame, because clients ask: OpenAI shipped its own Agentic Commerce Protocol with Stripe, optimized for agent-native checkout inside its ecosystem, while UCP is the broader bet to standardize the whole journey across any AI platform and keep the merchant in control. For a builder that is not academic. UCP-compliant means your experience is not locked to one assistant. Build once against the protocol, ride wherever it is adopted. I unpacked why that choice matters in UCP vs ACP.

Now the parts you will actually use. The Catalog API is the spine. Product lookup takes an ID or URL and returns real-time pricing and availability for up to 50 products in a single request, and that batch limit matters for latency: an agent assembling a comparison or a "complete the look" set hits one endpoint, not fifty. Image search lets an agent pass an image and get visually similar products back, the missing piece for any visual-discovery flow. Richer product data returns media, variants, availability, and offers from multiple sellers, so your experience can show real merchandising depth, and the multi-seller piece means you can build genuine comparison and marketplace-style surfaces, not just single-store lookups. Catalog API Shop sign-in is the identity layer: shoppers connect their existing Shop account inside your experience, with personalized search flagged as coming soon. Do not sleep on that. Identity is usually the ugliest part of any commerce build, and a drop-in "Sign in with Shop" primitive with a real profile behind it removes a mountain of work. The plumbing is documented in the Catalog API for AI agents.

Then the money. Sponsored products with the Catalog API lets you earn revenue on sales made in the experiences you build, via paid placements. It is in developer preview and labeled coming soon, so do not build a business plan on next month's revenue. But this is the structural piece that has been missing from app-ecosystem monetization for years: a native, first-party way to make money on the transaction itself, not a SaaS subscription bolted on the side. If you have watched the app store grind on $19-a-month installs, sponsored placements inside agentic surfaces is a different and bigger pool. I would be prototyping against the preview the day it opens. The demos Shopify shipped (a trip planner, a board-game recommender, photo lookalikes, star-sign shopping) are cute on purpose, to show the building blocks now support genuinely novel discovery, not a chatbot bolted onto a product page.

The assistant reaches
into your app.

The line in Spring '26 that should grab every app founder: Sidekick now works inside partner apps, starting with Judge.me, Klaviyo, Loop, and Smile, where it can answer questions and take action without leaving the assistant (Shopify Editions, Spring '26). The two-sided truth is that Sidekick App Extensions are the best new distribution channel Shopify has handed developers in years, and they quietly reposition every app as a tool that answers to the assistant instead of owning the merchant relationship. Both things are true at once.

The distribution case first. Discovery in the App Store is brutal and getting worse. If your app becomes one of the tools Sidekick reaches for when a merchant asks a question in plain language, you skip the listing-page lottery entirely. The merchant does not search "review app." They ask Sidekick to follow up on a low-rated product, and your review app does the work. For an app with a clear, nameable job, being a Sidekick-reachable action is a new top-of-funnel that does not depend on app store ranking or ad spend. The four launch partners are not a random sample. Reviews, email, returns, and loyalty are exactly the categories where a merchant's intent is easy to express in a sentence. If you are in one of those lanes, get your extension built.

The encroachment case is the read founders skip. When Sidekick becomes the front door, the merchant's relationship is increasingly with the assistant, not with your app's UI, your onboarding, your brand. You become a capability Sidekick calls, the way a website became "a thing Google indexes." Three risks stack up. Front-door risk: if merchants interact with your value through Sidekick, your interface stops being where the relationship lives, and your retention and upsell surface get mediated. Commoditization: any app whose entire value is one action a merchant can describe in a sentence is the most exposed, because the moment Shopify routes that intent to Sidekick or builds it natively, the standalone app is the weakest link. And disintermediation of your data story: if Sidekick orchestrates across apps, the cross-app context merchants used to assemble inside your dashboard now assembles inside the assistant. I looked at exactly which categories are most exposed in Sidekick vs your app stack, and the broader dynamic in how AI is reshaping Shopify apps.

So what survives? I have watched this movie from three seats, as the person who built the Partner Program, as a founder who sold an app to Tiny, and as a merchant who bought a lot of apps. The durable apps own proprietary data or a network, not just a workflow (Klaviyo is not endangered by Sidekick reaching into it, because the value is the data and the deliverability, not the click path). They are deep, not single-task, owning an entire job-to-be-done that Sidekick routes to rather than replaces. They live where Sidekick cannot fully reach, on off-platform integrations and channels Shopify does not own. And they show up early as Sidekick partners while that is still an edge. The strategic question for every founder this quarter is simple and uncomfortable: if Sidekick can do your app's core job in one sentence, what is left that is yours? If the answer is "the UI," you have a problem. If the answer is "the data, the depth, and the relationship," you build the extension, take the distribution, and keep your moat. More on building for that world in AI for Shopify app founders.

Shopify became a tool
other AI products call.

The three Plugins entries in Spring '26 mean Shopify is now a commerce layer that lives inside the agents, IDEs, and vibe-coding tools your customers already use. A founder can describe a business and spin up a Shopify store with Manus, Replit, V0, or Lovable. A merchant can run their store inside Claude, ChatGPT, or Perplexity. And a developer can manage that store from Claude Code, Codex, Cursor, and VS Code through the Shopify AI Toolkit (Shopify Editions, Spring '26). None of those are housekeeping. They reset where the store gets created, who builds it, and where your app has a shot at being discovered.

Start with the vibe-coding partners, the new front door. For most of Shopify's history, store creation started on shopify.com. Now it can start inside Lovable or Replit, with the merchant describing the business and a store falling out the other side. If you build apps, that matters for one reason: the moment of store creation is the moment of highest intent and zero installed apps. Whoever the AI tool recommends, or whatever is pre-wired into the generated store, gets the first slot. I watched the original app store and the Partner Program decide which apps merchants saw first, and first placement was worth more than any feature. Same fight, moved into a chat window you do not control yet.

Store management from agents is the bigger structural shift. When a merchant runs catalog edits, collection changes, and order management from inside Claude or ChatGPT, the admin UI stops being the only surface, and possibly stops being the primary one. If your app's value lives in a dashboard, that dashboard is now competing with a chat box. The apps that win this era expose their function through the agent: clean data, callable actions, an MCP server, an answer when the agent asks. The Shopify AI Toolkit is the developer-facing version of the same idea, letting you manage storefronts, apps, and themes from your editor, with specific examples like auditing checkout UI extensions for performance or upgrading extensions to Polaris web components with your agent. It shortens build time and lowers the floor for who can ship a working app. If you have been weighing how to build a Shopify app in 2026 or building an AI-native app, the toolkit changes the answer, and where MCP leaves apps is the deeper read on becoming a callable skill rather than a wrapper.

One Admin item belongs here because it is a trust shift, not a chore: "Visibility for app activity." Merchants can now track what apps are doing, where extensions and functions run, and what data they access. For honest app founders this is a gift. The merchants I advise are nervous about handing data to apps they cannot audit, and that hesitation kills installs. Now the platform shows the receipts. If your app touches the minimum data it needs and does visible work, transparency helps you. If it quietly over-reaches, the merchant is about to find out. Build for the world where every permission is on a dashboard, because it now is.

Shop Minis, everywhere
intent is highest.

For app founders, the Shop app just became a distribution surface, not just a checkout. The signal in Spring '26 is not any single feature. It is that Shop Minis are now surfaced across the app (home feed, top nav, product pages) and that there is a new way for AI agents to pull your experience into a purchase. A Mini used to be something a shopper had to find. Now it can appear at moments of real buyer intent, against a base of millions of verified shoppers with payment on file (Shopify Editions, Spring '26). This builds on the Minis SDK going public earlier in 2026, so building one is no longer a closed-beta privilege, and the intents layer lets the Shop app launch your Mini from contextually relevant moments like a product page.

Then there is the Shop skill for personal AI agents. Shoppers using OpenClaw, Hermes, and other AI agents can discover products and approve purchases through Shop. For a builder, that is a second front opening up. The job stops being only "rank in the App Store" or "rank in storefront search" and starts including "be the experience an agent reaches for when it is resolving a purchase through Shop." That is a genuinely new surface, and the people who build for it early will own mindshare before it gets crowded. The operator caution is the same as everywhere in this edition: this is Shopify's surface, on Shopify's terms, and the SDK, the intents layer, and the Shop skill are all distribution Shopify can re-rank or re-scope. I sold a Shopify-ecosystem company to Tiny, and the lesson that held up is to use platform distribution as an accelerant, never as your only acquisition engine. Build the Mini, wire up the intents, get in front of the agent traffic, and keep your own funnel (your App Store presence, your site, your direct merchant relationships) as the thing you control. The practical read: if you already have a shopper-facing experience, a Shop Mini is the lowest-friction way to put it in front of intent-rich traffic you would otherwise pay to reach. Fold it into your distribution playbook as a channel to test and instrument, not a lottery ticket.

Shopify now owns
more of your billing.

Two changes in the developer section will quietly affect more app businesses than the agentic headlines. The first is Shopify App Pricing: you declare usage, recurring, or hybrid pricing in your app submission, and Shopify powers plan selection, charge approval, and invoicing (Shopify Editions, Spring '26). On the surface this is convenience: less billing code, fewer edge cases, a cleaner buyer flow. For a small team shipping a first app, that is real time saved. Here is the part to sit with. Your billing relationship is one of the few pieces of leverage an app developer actually owns. The moment Shopify powers plan selection and invoicing, the merchant's mental model of "who am I paying" tilts further toward Shopify and away from you. It is the same trade merchants make with Shopify Payments: you give up control of the rail to remove the friction. Often worth it, not free. If you ever want custom enterprise pricing, off-platform contracts, or annual deals negotiated by a human, know exactly how much room this leaves you before you wire your whole catalog into it. Adopt it for self-serve, simple plans where conversion friction is the enemy. Keep a path for direct deals on bigger accounts. More on the tradeoffs in app pricing strategy.

The second is the feature most likely to bite someone reading this: the Built for Shopify category requirement. Returns and subscriptions apps must use the Customer Account API to keep their BFS status. Read that twice if you build in either category. BFS is not a vanity badge. It drives placement, trust signals, and discovery in the App Store, which is to say it drives installs, so losing it is a distribution cut, not a cosmetic one. Treat it like a migration with a clock on it: if you are not already on the Customer Account API, scope that work now, not next quarter. The related items make the direction obvious. Subscription payment methods are now natively replaced through customer account UI extensions, there is a customer account web component, and pre-populated email on sign-in. Shopify is consolidating the post-purchase and account experience under the Customer Account API and pulling the high-trust app categories in behind it. If returns or subscriptions are your business, this is your single most important line in the whole edition. If you are still deciding whether the BFS chase is worth it at all, I argued both sides in is Built for Shopify worth it.

The throughline across both is that Shopify is standardizing more of the commercial and operational relationship between apps and the platform. Mostly good for merchants and well-run apps, mildly constraining for anyone whose edge was owning a piece of that plumbing. The streamlined app store submission flow (pre-submission checks, track review feedback without email) and the new App Events API are smaller quality-of-life wins on top.

Headless, security,
and the DX wins.

Below the headlines, Spring '26 shipped a stack of platform mechanics worth a changelog read if you maintain extensions or storefronts. The all-new Hydrogen is the standout: rebuilt to be agent-first and to run on any framework or runtime, which frees headless builds from the framework lock-in the old version carried (Shopify Editions, Spring '26). The old bargain was a great Shopify-native headless experience in exchange for Shopify's framework choices. The new version drops that constraint, and it lines up with storefronts becoming agent-readable endpoints by default. Should you rebuild on it? Mostly no, not as a reaction. If you have a working headless storefront, "any stack" means you are less likely to ever be forced to migrate, which is the opposite of a reason to migrate today. Where it matters: new builds, and any team that walked away from Hydrogen specifically because of the framework lock-in. That objection is gone. Evaluate it fresh for greenfield work and treat the agent-first posture as a feature, because storefronts that AI agents can read and act on will matter more every quarter.

Security is a migration, not a footnote. "Stronger app security" means expiring access tokens and OAuth 2.0 refresh. In plain English, the long-lived token your public app has been holding is going away, and you need to implement refresh-token handling. This is unglamorous and it is also the kind of thing that breaks an app in production if you find out the hard way. Put it on the engineering board now. Every public app has to do this; the only choice you have is whether you do it calmly on your schedule or scrambling against a cutoff. App automation tokens and the App Events API sit alongside as the more modern, observable way to run an app, so do the cleanup well rather than minimally.

Then a cluster of genuinely good developer-experience wins, none roadmap-altering on its own, all worth knowing. The New Collections API is the standout: composable source groups, variant-level conditions, and exclusion rules, the API you wanted every time you fought Shopify's collection logic to express "this but not that, at the variant level." No backend required for lightweight apps (an App Home in the admin with no server to run) lowers the floor for shipping a small useful app to near zero, great for solo builders and internal tools. The customer account web component and the metaobject improvements (declarative metaobjects no longer require scopes, metaobject data usable in checkout functions, a streamlined Metafields and Metaobjects API) keep chipping away at the friction of building data-driven experiences. Metafields landed in ShopifyQL, and parallel reads for bulk queries run up to 4x faster. On the Functions and checkout side: discount configuration gets an admin UI extension surface, prerequisites and bulk editing arrive for discount functions, accelerated checkout supports add-ons via nested cart lines, billing address and PO number are available in Functions, and cart metafields now carry over to orders, closing a gap that has annoyed builders for years. Group these as "the platform got nicer," adopt them as you touch the relevant code, and do not reorganize your roadmap around any single one.

If you build for Shopify POS, this edition is for you. POS UI extensions now report activation status, work without network access (a big deal for real retail floors with spotty connectivity), support localization, and can access the camera, plus there are cash management extensions for POS. Offline-capable and camera-aware extensions change what is actually buildable on a retail floor, so if POS is your category, treat this cluster the way returns and subscriptions devs should treat the BFS requirement: it is the part of the edition that is genuinely about you. Finally, partner operations got better. All partner stores now live in a localized Dev Dashboard, role-based access ships with seven system roles plus custom ones, webhook monitoring improved, you get more control over events, and there is safer CI/CD app deployment that will not accidentally delete things, plus auto-upgrades and semantic versioning in the CLI. None of this changes strategy. All of it reduces the daily friction and the foot-guns of operating a real app business, and the CI/CD safety rails are the ones I would wire in first. For the wider context on running a partner business, see the 2026 Partner Program and the partner agreement changes.

Five moves, in order.

If you build on Shopify, this edition gives you a clear agenda. First, run the Sidekick test on your own app honestly. If Sidekick can now do your core job natively, your roadmap needs to extend past that task toward data, workflow, and integration depth a general assistant cannot replicate. If Sidekick can surface your app, chase the integration, because being a default inside the assistant is distribution you cannot buy later. Second, take the agentic opening seriously rather than treating it as a demo. The UCP, the Catalog and Checkout MCPs, and sponsored products are the first native, Shopify-sanctioned way to build and monetize that is not a monthly merchant fee, and the founders who learn that surface this quarter will define the tooling around it.

Third, handle the unglamorous deadlines. If you build returns or subscriptions apps, get on the Customer Account API to protect your Built for Shopify status, and implement expiring-token OAuth refresh before it breaks something. Fourth, adopt Shopify App Pricing where it removes friction, but keep a direct path for your enterprise and annual deals so you do not hand away your whole billing relationship. Fifth, if you build headless or for POS, evaluate the all-new Hydrogen for greenfield work and build POS extensions offline-first.

Everything else, the analytics fields, the webhook monitoring, the dev dashboard polish, is real but not roadmap-changing. The pattern across the whole edition is the one that has held since I was inside the building: Shopify expands its core, and the durable third-party value keeps moving toward the things a platform structurally cannot own. Build there. For the merchant-side view of the same drop, the brand read is the companion to this one.

Questions I keep
getting asked.

If you sell on Shopify rather than build on it, the companion piece is the Spring '26 edition for DTC brands. And for the wider map of where app value is created and destroyed, start with the ecosystem value map.