Shopify UI extensions now ship under a 64 KB compressed JavaScript ceiling, and as of September 17 there is a form to appeal it. The form is not an escape hatch. It is an audit. Reading what Shopify says it will refuse tells you more about how the company wants admin apps built than the documentation does.
What changed on September 17
Shopify opened a request process for existing UI extensions that exceed the bundle limit, and named October 1, 2026 as the date every existing UI extension must run API version 2026-01 or later to stay deployable. The limit itself is not new. It is 64 KB of compressed JavaScript per extension, with full-page customer account extensions allowed 128 KB, and it has been enforced at deploy since API version 2025-10 according to Shopify's app extensions documentation. Four surfaces are in scope: Admin extensions, Checkout UI, Customer Accounts and POS.
The appeal route is mechanical. Run a build, take the esbuild metafile it emits, and submit both through the form in the September 17 changelog entry. Shopify says it grants increases only where the remaining weight is unavoidable, and it names three things it will not accept as justification: heavy libraries, duplicated dependencies, and translations bundled into the extension instead of going through the native localization APIs.
64 KB vs 2 MB: why the cut lands this hard
The previous ceiling was roughly 2 MB, so the current limit removes about 97 percent of the budget teams spent two years building against. That is the whole story behind the pushback, and the numbers in the developer community thread on the change are worth more than the complaints around them. Extensions running in production were cited at about 500 KB and about 300 KB. A freshly generated extension weighs around 8.5 KB gzipped. One developer's rewritten Preact prototype still landed near 150 KB, more than double the ceiling.
The sharpest data point in that thread is Sentry. The error reporting SDK costs roughly 35 KB compressed, which is over half the budget for observability alone, and Shopify's own guidance has pointed teams at it. A team that followed the recommended path is now over budget before writing a line of product code. Shopify staff in the thread asked for specifics on blockers and pushed back on how people were measuring, without committing to move the number.
So the objection is not laziness, and it is not really about compression either. The gap between 300 KB and 64 KB is not something a build flag closes. It is architectural, and Shopify knows that, which is why the refusal criteria read the way they do.
Optimize or appeal: which one you actually want
Optimize. File the appeal only when your residual weight is a platform requirement you cannot restructure around, because the three named refusal reasons already cover nearly every common cause of a heavy extension. If you are 40 percent over and the weight is your own dependency choices, you will lose the request and you will have spent the review window losing it. With a hard date of October 1, 2026, that window is the scarce resource, not the kilobytes.
An appeal is legitimate in a narrower set of cases than most teams think. Genuinely irreducible domain logic qualifies: a pricing engine with real rules in it, a configurator whose option matrix is the product. A design system you imported because it was convenient does not, and neither does a state management library doing work that signals would do in a fraction of the space.
The version deadline is the part to schedule around first. The bundle limit applies at deploy, which means a passing extension stays live and only fails the next time you ship. The API version requirement is different. It applies to every existing extension, so an extension nobody has touched since 2025 still has to be rebuilt and redeployed before October to survive, and that rebuild is when the 64 KB gate fires. Teams with a long tail of small internal extensions will find most of their work there.
What we would cut first
Remove the error reporting SDK, move translations onto the native localization APIs, and deduplicate the dependency graph before touching any of your own code. Those three moves are free in product terms and they are the three Shopify has pre-declared it will not excuse, which makes them the cheapest 60 KB anyone is going to find. Get the metafile out of your build and read it before guessing, since bundle intuition is usually wrong about which import is expensive.
After that the decision stops being about size. An extension that cannot fit 64 KB after honest trimming is usually an extension doing work that belongs on a server or in a different surface. That is a better outcome than a granted exception. The teams we see struggle on Shopify Plus builds are the ones treating an admin extension as a place to host an application, rather than as a thin, fast surface onto one that lives elsewhere.
POS deserves specific attention. POS extensions run on handheld hardware in a shop, often on older devices and contested wifi, where a 300 KB bundle was never actually acceptable even when it was permitted. The same discipline we apply to React Native and Flutter builds applies here without translation: budget the payload first, then design inside it. Shopify has now made that a deployment condition rather than a matter of taste, and on this one the platform is right.