We built a tool that scans Shopify storefronts for compatibility issues between third-party apps and themes. Over the past two months, we pointed it at 53 live stores — all running at least three third-party apps — and logged every conflict we could detect.

Here's the raw data:

53 stores scanned

87/100 average compatibility score

147+ critical issues flagged

2.5x more rendering problems in stores running 3+ apps vs. 1–2

An 87 average sounds fine. It's not. The distribution is bimodal: most stores either score 92+ (minimal issues) or drop below 75 (multiple broken interactions). The middle ground is thin. And the stores below 75? They almost always have the same three problems.

Pattern #1: CSS Specificity Wars (70% of Issues)

This was the single biggest source of conflicts. Roughly 70% of every critical issue we flagged traced back to CSS specificity.

The pattern is predictable. A reviews app injects styles like this:

.review-widget {
  padding: 16px;
  margin-bottom: 24px;
  font-size: 14px;
}

Clean, reasonable CSS. The problem is the theme already has this:

#shopify-section-template--product .product__block .review-widget {
  padding: 0;
  margin: 0;
  font-size: inherit;
}

The theme selector has a specificity of 1-2-1. The app selector has 0-1-0. The theme wins every time, and the review widget renders as a compressed, unreadable block.

What app developers do next makes it worse. They escalate:

.review-widget {
  padding: 16px !important;
  margin-bottom: 24px !important;
  font-size: 14px !important;
}

This "fixes" the reviews — and breaks the store's carefully tuned spacing on mobile. We found !important declarations in 31 of the 53 stores we scanned. In 19 of those, the !important rules created new layout issues that weren't present before the app was installed.

The z-index arms race

The second CSS pattern we saw constantly was z-index stacking conflicts. Here's a real example from our dataset:

/* Theme: sticky header */
.header__wrapper {
  position: sticky;
  z-index: 999;
}

/* App A: notification bar */
.announcement-bar-widget {
  position: fixed;
  z-index: 1000;
}

/* App B: chat widget */
.chat-bubble-container {
  position: fixed;
  z-index: 9999;
}

/* App C: email signup popup */
.signup-modal-overlay {
  position: fixed;
  z-index: 90000;
}

Four apps. Four different z-index strategies. Zero coordination. The result: the signup popup renders above everything (including the close button of the chat widget), the notification bar covers the header on scroll, and the merchant has no idea why their mobile UX feels broken.

We found z-index values exceeding 10,000 in 23 of 53 stores. Five stores had z-index values above 90,000.

What actually works

For app developers building Shopify theme extensions, scope your CSS aggressively:

/* Instead of this: */
.review-widget { ... }

/* Do this: */
[data-app-reviews] .review-widget {
  /* Scoped to your app's container */
  padding: 16px;
  margin-bottom: 24px;
}

If you're targeting modern browsers (and you should be — Shopify's audience skews current), CSS @layer is a cleaner solution:

@layer app-reviews {
  .review-widget {
    padding: 16px;
    margin-bottom: 24px;
    font-size: 14px;
  }
}

Layers let your styles participate in the cascade without brute-forcing specificity. The theme's unlayered styles will still win by default, but you can negotiate precedence without !important.

Pattern #2: JavaScript Event Handler Collisions

This accounted for about 20% of the critical issues we flagged. The pattern: multiple apps binding event listeners to the same DOM elements, usually around cart interactions.

Here's what we saw in one store running a wishlist app, a reviews app, and an upsell widget:

// App A: Wishlist — intercepts add-to-cart
document.querySelectorAll('form[action="/cart/add"]').forEach(form => {
  form.addEventListener('submit', function(e) {
    e.preventDefault();
    // Track wishlist state, then submit
    trackWishlistConversion(form);
    form.submit();
  });
});

// App B: Upsell — also intercepts add-to-cart
document.querySelectorAll('form[action="/cart/add"]').forEach(form => {
  form.addEventListener('submit', function(e) {
    e.preventDefault();
    // Show upsell modal, then submit
    showUpsellModal(form);
  });
});

Both apps call preventDefault(). Both expect to be the only one controlling the submit flow. The result: the add-to-cart button either fires twice, shows the upsell modal but never adds the product, or silently fails with no feedback.

We found this exact collision pattern — multiple preventDefault() calls on the same form — in 11 of 53 stores.

Script loading order is the other half

Apps that depend on jQuery (yes, still) face a loading order problem. The theme loads jQuery deferred. The app's inline script executes immediately:

<!-- Theme: deferred jQuery -->
<script src="jquery-3.6.0.js" defer></script>

<!-- App: inline script that assumes jQuery exists -->
<script>
  jQuery(document).ready(function() {
    $('#product-reviews').on('click', '.review-star', function() {
      // This throws: jQuery is not defined
    });
  });
</script>

This fails silently in production. The review stars don't work. The merchant doesn't know why. The app developer's test store (with jQuery loaded synchronously) works fine.

What actually works

Use custom events instead of hijacking native form submissions:

// Emit a custom event instead of intercepting submit
document.addEventListener('cart:before-add', function(event) {
  const { form, product } = event.detail;
  // Do your thing without blocking other listeners
});

// Coordinate with other apps
const cartEvent = new CustomEvent('cart:before-add', {
  detail: { form, product },
  cancelable: true
});
document.dispatchEvent(cartEvent);

And drop jQuery. Vanilla JS event listeners with defer solve the loading order problem entirely:

<script defer src="your-app.js"></script>

// your-app.js — runs after DOM is ready because of defer
document.querySelector('#product-reviews')
  .addEventListener('click', handleReviewClick);

Pattern #3: DOM Mutation Conflicts

The remaining ~10% of critical issues came from apps that make assumptions about DOM structure. When the theme updates, those assumptions break.

A typical example: an app targets a specific class to inject its widget:

// App expects this structure
const container = document.querySelector('.product__info-container');
if (container) {
  container.insertAdjacentHTML('afterend', widgetHTML);
}

Theme updates from Dawn 12.0 to 13.0. The class changes to .product__info-wrapper. The app injects nothing. No error, no fallback — just a missing widget.

We tracked stores across multiple scans and found that theme updates caused at least one app widget to disappear in 8 of the 53 stores during our observation window.

The MutationObserver pileup

Worse, some apps use MutationObserver to watch for DOM changes and re-inject their widgets. When three apps all observe document.body for childList changes:

// Three separate MutationObservers, all watching body
const observer = new MutationObserver((mutations) => {
  mutations.forEach((mutation) => {
    // App re-injects widget on every DOM change
    if (!document.querySelector('.my-widget')) {
      injectWidget();
    }
  });
});
observer.observe(document.body, { childList: true, subtree: true });

Each injection triggers the other observers. In the worst case we found, this created a tight re-render loop that pushed page load time from 2.1s to 6.8s.

What actually works

Use Shopify's app blocks and theme app extensions. They're designed for exactly this:

{% comment %} blocks/review-widget.liquid {% endcomment %}
{% schema %}
{
  "name": "Product Reviews",
  "target": "section"
}
{% endschema %}

<div class="review-widget" data-product-id="{{ product.id }}">
  <!-- Widget content -->
</div>

App blocks let merchants place your widget in the theme editor. No DOM queries, no fragile class selectors, no MutationObserver hacks. When the theme updates, the block stays where the merchant put it.

The Takeaway

The stores that scored 92+ in our scans had a common thread: they used fewer apps (3–4 vs. 6+), and the apps they did use were built with Shopify's modern extension architecture.

The stores below 75 were running 5+ apps, most injecting unscoped CSS and attaching event listeners directly to DOM elements. The conflicts weren't bugs in any single app — they were emergent behavior from apps that were never tested together.

If you're building Shopify apps:

• Scope your CSS — use data attributes or CSS layers, not bare class selectors
• Don't hijack native events — emit custom events and let other apps coordinate
• Use app blocks — stop querying the DOM for injection points
• Test with other apps installed — your app will never run alone in production

We've published the aggregate data from our scans — broken down by conflict type, app category, and theme — at preflight.technology/insights. No signup required to browse the patterns. If you're debugging a specific app's compatibility, the per-app conflict lookup is there too.