The Shopify App Uninstall That Leaves Code Behind

In an r/shopify thread from earlier this year a developer scraped roughly ten thousand live Shopify stores and put the numbers up: average mobile Lighthouse score landed near 54 out of 100, and app count correlated with worse speed at about -0.48. The conclusion most readers took home is the easy one. Fewer apps, faster store. The take we want to defend is narrower than that. Most of the lost points are not coming from the apps a merchant currently has installed.

The Shopify app uninstall flow does not remove the JavaScript, Liquid blocks, or theme snippets that an app injected on the way in. Delete the app in the admin and its API access vanishes the same second, which is the part of the design that works as advertised. The part that does not work is the implicit promise sitting inside the word "uninstall".

Why merchants keep being told to "just uninstall"

For about a decade now, the standard advice in r/shopify and the Shopify Community has been: if an app is slowing your store, delete it from the admin. Some Shopify Staff replies on the community board point further upstream and suggest looking inside the app's own settings for an explicit uninstall option first. We have a particular favorite Victoria_13 reply from 2022 that captures the official line plainly: navigate to your app settings, search for an uninstall option, use that method, and it should remove the code injected into your theme. The Shopify moderator response from a 2023 thread takes the same shape from the other side. If there is leftover code, the responsibility for removing it sits with the app developer who put it there.

Both pieces of advice are correct in a narrow sense. An in-app uninstall really is better than the admin delete. App developers really should provide a cleanup procedure. The problem is what the average merchant does with the advice in aggregate. They take it to mean that on a healthy store, the Shopify app uninstall flow finishes the job. On most stores we have audited, it does not. And the merchants who have been trial-hopping through apps for two or three years are the ones who can least afford to assume otherwise, because the residue stacks.

What a Shopify app uninstall actually does to your theme

The mechanism traces back to the auth model. When a merchant clicks delete on an app, Shopify revokes its API credentials the same instant. JoesIdeas summarised this on the Community board back in 2021 and it has been quoted in every uninstall thread since: once you delete an app, it instantly loses access to your store, so it cannot clean up the code. Another commenter in that same thread, Mircea_Piturca, admitted outright that the current process is painful for both sides.

What that means in practice is that the injected code stays. It stays in theme.liquid. It stays in footer.liquid. It stays in section files, in snippets, sometimes inside the asset bundle, and in any Google Tag Manager container the app helped populate while it was alive. The shape and amount varies app to app. We have audited stores where a chat widget mount point was still rendering fourteen months after the app was deleted from the admin. Bold Upsell, ShopLift, Yotpo, and Klaviyo all get named as residue sources in Community threads going back to 2020. The ShopLift case from a 2025 thread is the one that should make every merchant uneasy. An A/B test app whose injected routing logic was, weeks after the admin uninstall, still sending half of a store's traffic to an alternate theme.

If a merchant has trial-hopped through dozens of apps over a few years - and most of the $1k to $50k a month stores we look at have - the orphan code from each one piles on top of the orphan code from the last one. There is no native Shopify scan that lists which scripts in your theme came from which app, or which of those apps are still around to vouch for what their code does today.

The version we worry about more than page speed

Performance is the symptom merchants notice. The version we lose more sleep over is the audit-trail and security one. Apps that had write access to products or collections while they were installed could have taken destructive actions through the Admin API without ever showing up in the activity log. Shopify's activity log only records actions taken through the admin UI by staff accounts. API actions by third parties are not in that ledger at all.

A merchant on r/shopify in April found two products silently deleted, with nothing in the activity log to explain it. A technical commenter in the thread walked it through: any third-party app with products-write scope could have done it, and there is no built-in Shopify alerting that fires when it happens. A separate April thread surfaced the Orderly Emails incident, where an app marketed as trusted by over a hundred thousand stores reportedly deleted store collections across multiple merchant accounts the same week; the app's response, per the merchants who posted, offered no compensation. We have not independently verified the full count of affected stores, and the merchants posting may not represent the whole set, but the activity-log gap means a real count would be very hard to assemble from outside.

The compounding case is Magecart-style card skimmers. A developer-led r/shopify post in May described the mechanism: skimmers get into Shopify checkouts by tampering with the third-party scripts merchants have stopped paying attention to. An orphan analytics script, an inherited GTM container, or a chat widget that has not been thought about in a year all look the same in the theme editor. None of them throws an error. None of them shows up in Shopify Support's view. We have cleaned up after this kind of compromise more than once, and every time the dead code from a previous Shopify app uninstall was the foothold.

What we'd check on your store this afternoon

For a store with two or more years of app history, here is the order we walk it in. Each step is roughly how long it takes when nothing surprising shows up:

1. Duplicate the live theme. Online Store > Themes, the three-dot menu next to your published theme, Duplicate. Two minutes. Every edit happens on the duplicate; nothing touches the published theme until you decide to swap.
2. Open theme.liquid and search for the names of every app you remember installing. Then search for app domains directly (yotpo, klaviyo, bold-apps, gorgias, judgeme, and so on). Twenty to forty minutes on a store with real history. The job is finding the code, not removing it. Once a block is identified, deletion is one keystroke.
3. Open footer.liquid, header.liquid, and every file under snippets/ whose name suggests an app or tracking. Same drill.
4. Run a test checkout in a private browser window with the DevTools Network tab open. List every domain that receives a request from the checkout page. Anything you do not recognise gets investigated before you decide it is benign.
5. Audit the permissions on every currently installed app. From the admin, Settings > Apps and sales channels, then click each app and read what scopes it holds. Any app holding products or collections write scope is a backup-strategy question (Rewind or an equivalent) and a question of whether you actually still need that scope.

If theme.liquid keeps returning matches you cannot place to a currently installed app, a fifteen-minute chat with a help1 expert is free and is usually enough to tell whether you're looking at a one-evening cleanup or a full theme audit. Steps one and two are also how we approach the broader question of which app scripts are actually loading on every page on a store that has slowed down for reasons nobody on the team can pin down.

One honest limit on all of this. We do not have a clean way to tell, from outside a store, how often write-scope apps quietly delete or mutate data and how often they do not. The activity-log gap means any real number would be undercounted by definition. What we can say is that every store we have audited where the merchant said "we have nothing in the activity log" had at least one currently installed app with the permissions to make that statement true even if products had been touched.

What we'd push back on hardest is the idea that an uninstalled app is gone. On the Shopify stores we audit, the apps that were uninstalled a year ago are usually still doing more work in production than anybody on the team currently realises, and the longer the store has existed the more of them are still in there.