App development

Shopify's admin has a new look. Your app probably doesn't

The admin redesign started rolling out on September 15, 2026, and Polaris 2.0 is in release candidate. What updates itself, what silently goes stale, and why hardcoded CSS is now wrong in half your installs.

Bas Lefeber

Founder, learnshopify.dev · September 29, 2026 · 5 min read

Ready to learn Shopify development?Short, interactive lessons where you write real Liquid against a live storefront and watch it change as you type. Free, and genuinely fun.

On September 15, 2026, Shopify started rolling out a new look for the admin: new colour, type, spacing and icons, inside a new frame. Search, notifications and the store picker moved into a collapsible side panel, and Sidekick became a floating chat. Nine days later the Polaris 2.0 release candidate landed to match it.

Nothing about this breaks your app. That is exactly why it is worth your attention. A broken app files bug reports; an app that merely looks dated inside someone else's product does not. It just quietly stops feeling like part of the admin, one merchant at a time, on a rollout schedule you do not control.

The same app, in two admins, at the same time. That is the actual engineering problem for the next few months.

The short version

If your app is built on Admin UI extensions or App Home UI extensions, it restyles itself and you do nothing. If it is an embedded App Home app, it keeps its current appearance until you opt in. Polaris 2.0 is a release candidate, not stable: polaris-2.0-rc.js exists, polaris-2.js does not. Built for Shopify apps have until May 1, 2027. The thing to do this week is the audit, not the migration.

What restyles itself and what does not

Shopify drew this line along its own component boundary, which is the tell for where the platform wants you to be. Anything rendered through Shopify's extension surfaces is Shopify's problem. Anything you rendered yourself is yours.

What your app is built onWhat happens on a new-look storeWhat you do
Admin UI extensionsPicks up the new styles automaticallyNothing. Re-test, do not re-code.
App Home UI extensionsPicks up the new styles automaticallyNothing. Re-test, do not re-code.
Embedded App Home on Polaris web components 1.xKeeps its current appearance indefinitelyOpt in via polaris-2.0-rc.js when you are ready. Nothing forces you.
Embedded App Home on your own CSS or Polaris ReactKeeps its current appearance, and now matches nothingMigrate to Polaris web components, or accept permanent drift.
The redesign is a test of how much of your UI you handed to the platform. Apps that handed over more have less to do.
Only one of these three columns has a deadline attached, and it is the one most custom apps sit in.

The part that catches people: both designs are live at once

The rollout is progressive. For months, some of your installs are on the new admin and some are still on the old one, and you do not get to know which is which. That turns a redesign into a harder problem than a redesign: your app has to look correct in two different admins simultaneously.

This is the actual argument for Polaris 2.0, and it is worth stating plainly because the changelog buries it. Load polaris-2.0-rc.js and the components render the new styles on a store with the new admin, the previous styles on a store that still has the old one, and the new appearance outside the admin entirely. One script, three contexts, handled. You are not choosing a look, you are delegating the choice to something that can see which store it is in.

Every hardcoded value you tuned to match the old admin is now wrong half the time

If you ever matched a colour, a border radius, a font size or a spacing step to the old admin by eye and committed it as a literal, that value is now correct on some stores and visibly off on others. There is no version of this you can fix with a second literal. The only durable answer is components or tokens that resolve per store, which is the same lesson Liquid themes teach with colour schemes.

Polaris CDN channels, and why you cannot pin 2.0 yet

The Polaris CDN adopted semantic versioning on August 31, and Polaris CDN 1.1 went stable on September 22. That gives you four kinds of URL, and they behave differently enough that picking the wrong one is a real incident waiting to happen.

Polaris web components, CDN channels
<!-- Legacy. Tracks polaris-1.js. --><script src="https://cdn.shopify.com/shopifycloud/polaris.js"></script> <!-- Major channel. Compatible improvements arrive automatically,     breaking majors do not. This is the sensible default. --><script src="https://cdn.shopify.com/shopifycloud/polaris-1.js"></script> <!-- Pinned. Published only once 1.1 became stable. Never moves. --><script src="https://cdn.shopify.com/shopifycloud/polaris-1.1.js"></script> <!-- Release candidate. Accumulates changes and updates IN PLACE. --><script src="https://cdn.shopify.com/shopifycloud/polaris-2.0-rc.js"></script>

Now the detail that decides your timing, which you will not find in the changelog. polaris-2.0-rc.js serves a 200. polaris-2.js serves a 404. There is no stable major-2 channel yet, so shipping the new look to production today means shipping a dependency on a release-candidate URL that Shopify says will accumulate improvements and update in place. That is fine in a staging store and an uncomfortable thing to have under a paying merchant's workflow.

The sequencing I would use

Point a development store at polaris-2.0-rc.js now and find out how much work you actually have, because that number is the only one that matters for planning. Keep production on polaris-1.js. Move production when the stable 2.0 channel appears. May 1, 2027 is far away; the audit that tells you whether this is a two-day job or a two-month one is not.

If you are still on Polaris React

Shopify's own advice is to start with Page, Section and Button, on the grounds that they carry the most visual weight per component converted. That is sound, and there is a better reason for it than visual impact: those three are the components that establish the frame. Convert them and the rest of your screen inherits correct spacing and surface colour even where the inner components are still yours. Convert leaf components first and you get a page that is half new, half old, in a way that looks worse than either.

Learn this properly · free lesson

Polaris: why your app should look like Shopify admin

Build a real embedded admin screen with Polaris web components, and see why the platform's components are the ones that survive a redesign. Free to work through from here.

Try this lesson — free

What to actually do this week

  1. Find out which bucket you are in. Grep your app for @shopify/polaris and for a Polaris CDN script tag. React imports and no script tag means the longest road.
  2. Open your app on a store with the new admin and look at it. Not a screenshot review, the actual app. The drift shows up at the edges: card surfaces, icon weight, the gap between your header and Shopify's.
  3. Grep for hardcoded colour and spacing literals. Every one is a decision you made about an admin that is being replaced.
  4. Check your CDN channel. If you are on the legacy polaris.js, move to polaris-1.js now. It is the same code today and a much better contract tomorrow.
  5. Put May 1, 2027 in the calendar only if you are Built for Shopify. Everyone else has no deadline, which is precisely why this slips.

The broader read: this redesign is a quiet audit of how much of your interface you built yourself. Every custom component you were proud of is now a component you maintain against someone else's moving design system, forever. That trade is sometimes worth making. It is worth making on purpose.

Frequently asked questions

When did the new Shopify admin design roll out?

The progressive rollout began on September 15, 2026. It is not a single switch: during the rollout some stores show the new design and others still show the previous one, and an app has no guarantee about which it is running in.

Do I have to update my app for the new Shopify admin look?

Only if you are a Built for Shopify app, which must update by May 1, 2027. Everything else is optional. Apps built on Admin UI extensions or App Home UI extensions pick up the new styles automatically with no code change. Embedded App Home interfaces keep their current appearance until you opt in.

What is Polaris 2.0?

A release candidate of Shopify's design system that brings the new admin's colours, typography, spacing and icons to embedded App Home interfaces. Loaded from the CDN as polaris-2.0-rc.js, its components render the new styles on stores with the new admin, the previous styles on stores without it, and the new appearance outside the admin.

Can I pin Polaris 2.0 to a stable version?

Not yet. As of late September 2026 the CDN serves polaris-2.0-rc.js but there is no polaris-2.js major channel, so adopting 2.0 today means depending on a release-candidate URL that Shopify says accumulates improvements and updates in place. Testing on it is sensible; shipping production on it is a judgement call.

Which Polaris CDN URL should I use?

The major channel, https://cdn.shopify.com/shopifycloud/polaris-1.js, for most apps. It takes compatible improvements automatically but will not jump a major version on you. Pinned URLs like polaris-1.1.js never move, which is right when you need to control upgrade timing exactly. The legacy polaris.js simply tracks polaris-1.js and is worth leaving behind.

Which Polaris React components should I migrate first?

Page, Section and Button. Shopify recommends them for visual impact, and they are also the components that establish the page frame, so converting them gives the rest of the screen correct spacing and surface colour even while inner components are still yours. Converting leaf components first produces a page that looks half-migrated.

Start free

Ready to become a Shopify developer?

You just read how it works. Now write it yourself: real tickets from a live store, in an editor where the storefront updates as you type. Module 1 is free, no card.

Start your first lesson

Free · No credit card · Your first win in minutes

App developmentPolarisPlatformAdmin

About the author

Bas Lefeber, Founder, learnshopify.dev

Bas builds learnshopify.dev, where developers learn production-grade Shopify theme development against a live storefront. He writes about Liquid, theme architecture, and the parts of the job that still matter now that AI writes the code.

Keep going in the curriculum