App Compatibility Matrix: Liquid vs Hydrogen

Introduction

One of the first shocks for merchants moving to Hydrogen: not all their Liquid apps will work.

Apps built for Liquid often rely on DOM injection or checkout.liquid — patterns Hydrogen doesn’t support. Agencies need a compatibility matrix to guide migrations.

Why Liquid Apps Break

• ❌ DOM Injection → scripts can’t hook into Hydrogen’s React runtime.
• ❌ Checkout.liquid Assumptions → not accessible in Hydrogen builds.
• ❌ Legacy Auth → apps tied to classic customer accounts fail under the new Customer API.

👉 Hydrogen is API-first. Liquid apps assume the DOM.

Compatibility Categories

Category	Hydrogen Status	Notes
Subscriptions	✅ Supported	API-first apps (Recharge, Skio).
Personalization	✅ Supported	SDK/API integrations (Rebuy, Algolia).
Analytics	✅ Supported	Server-side preferred.
Reviews	⚠️ Partial	Requires React wrappers (Yotpo, Okendo).
Loyalty	⚠️ Partial	SDK works, DOM widgets fail (Smile.io, Yotpo).
Pop-ups/Widgets	❌ Unsupported	DOM injection not possible (Privy, Justuno).
Checkout Mods	❌ Unsupported	Hydrogen bypasses checkout.liquid entirely.

Workarounds

1. SDK Integrations → Recharge, Algolia, Nosto.
2. React Wrappers → reviews + loyalty.
3. Hybrid Builds → keep Liquid for unsupported apps (short-term).
4. Replace Apps → swap DOM-heavy tools with API-first alternatives.

Case Example: Apparel Brand

• Pre-migration: 15 apps.
• Audit results:
  • 8 compatible (subscriptions, personalization, analytics).
  • 4 wrapped (reviews, loyalty).
  • 3 dropped (pop-ups, checkout mods).
• Outcome: leaner stack, faster site, lower costs.

Guardrails

• ✅ Run app audits before migration.
• ✅ Maintain compatibility matrix for clients.
• ✅ Offer wrapper library as part of agency toolkit.
• ✅ Replace unsupported apps proactively.

Conclusion

Hydrogen isn’t app-hostile — but it is API-first. Merchants and agencies must evaluate apps, replace DOM-dependent tools, and use compatibility matrices to guide migration.

Apps don’t disappear — they evolve.