Upgrading to any UI Extension API that uses web components now enforces a 64kb bundle size as seen here: Upgrading to 2025-10
This is a very unexpected and breaking change, specially for apps whose core features are deeply integrated as UI Extensions.
The expectation to go from a 2MB limit to 64kb (96.8% reduction) in what will become a required API upgrade down the line is unrealistic for many app developers.
This change feels fundamentally misaligned with the reality of modern Shopify apps.
Reducing the bundle size from ~2MB to 64KB is not an incremental constraint, it’s a complete paradigm shift. For apps that rely heavily on UI Extensions as part of their core product experience, this effectively blocks adoption of newer APIs rather than enabling it.
From an outside perspective, this doesn’t look like an optimization push, it looks like a forced architectural rewrite with no realistic migration path. Expecting teams to rework mature, production-grade extensions into sub-64KB bundles is not just difficult, in many cases, it’s not viable without significantly degrading functionality.
The “just use web components” approach also underestimates the complexity involved. Tooling, developer experience, and ecosystem maturity around this stack are still not at a point where this constraint feels reasonable at scale.
If the goal is to push the platform forward, the current limit does the opposite, it creates friction, delays upgrades, and discourages investment in UI Extensions altogether.
A more balanced approach would be, increasing the limit to something practical, providing a long transition period, grandfathering existing apps.
Otherwise, this risks breaking trust with developers who have already invested heavily in the platform.
Could you elaborate a bit on what specifically is blocking you from reaching the file size limits?
Is it dependencies you need for your extension to function? (Btw. you can check that contributes to bundle size using metafiles that the CLI now emits)
Is it that your extension implements many features?
Something else entirely?
Fwiw we’ve seen that a lot extensions go below the limit just by making the switch from react to preact.
Here’s what’s holding us back in our particular case:
Dynamic UI Extension structure, a lot of the customization happens in the app, and the UI Extension only requires an “ID”, the rest happens during render, this allows us to ship only one extension that has all the features, creating less friction for the merchant and avoid having x1000 extensions in our collections.
Feature-rich extensions, we pack a lot of functionality that’s currently used by merchants, most of this functionality is hand written.
Dependencies - It can be said that most dependencies can be rewritten by hand, and we do for the most part for simple stuff, however to guarantee quality, we have a couple (very light-weight) dependencies that ensure extensions work flawlessly for merchants and their customers.
After moving to Web Components we’re still far above the imposed limit, and to be frank, as @Omar_Cardenas has put it, we were deep invested in the limit that Shopify originally set (2MB) and respected it, so for us is a trust-breaker after putting all the time and effort into making these extensions.
For my case most of its 500kb size is just written code, with dependencies actually taking up a much smaller portion. I have yet to migrate to preact but I suspect even then it will not meet the new 64kb limit.
The main reason for the bigger size is for a simpler merchant experience. My app offers checkout customization features with 30+ different customizations and around 100 unique triggers that the merchant can also combine in many different ways to satisfy their unique use-cases.
I figured it would be much simpler for the merchant when going to the checkout editor to simply add one app block than to parse through 10s of different checkout extensions from the same app because one extension has this customization while another doesn’t, or one has a trigger combination that isn’t found in another.
With just one big checkout extension the merchant only has to pick the 1 checkout extension to have access to all features. It also reduces errors because the merchant can no longer pick the incorrect extension for a specific customization.
Also early on when checkout extensions were first released, I remember there being a limit of only 20 or so extensions allowed per app. Knowing I would have 10s of different extensions as functions I figured I would have hit the limit very fast, which also contributed to building one bigger, more comprehensive checkout ui extension rather than splitting into multiple smaller ones.
With this change migration would be disruptive to say the least for existing merchants. I can split up logic into smaller extensions, but then each merchant would have to manually migrate by deleting old app blocks and adding new app blocks to accomplish the exact same thing, except even then some use-cases wouldn’t be covered because more extensions would likely mean more app blocks are needed and there’s still a 3-app block limit for each target.
I really hope the new imposed limit is reconsidered, or at least have older apps grandfathered in a similar way to what is being done with the metafield limit so as to minimize disruption to both merchants and developers.