Shopware 6 Apps vs. Plugins – Was braucht Ihr Shop wirklich?

Sie möchten eine individuelle Funktion in Ihrem Shopware-6-Shop ergänzen — vielleicht eine komplexe Preisregel, eine direkte Anbindung an Ihr Lagersystem oder einen komplett angepassten Checkout-Ablauf. Ihr Entwickler kommt mit einer Frage zurück, die Sie nicht erwartet haben: Soll das ein Plugin oder eine App werden? Wenn Sie nicht wissen, was dieser Unterschied bedeutet, sind Sie nicht allein. Die meisten Shop-Betreiber wissen es nicht — und die falsche Entscheidung zu Beginn kann Sie Monate unnötiger Wartungsarbeit und eine Rechnung für eine Neuentwicklung kosten, die Sie nie eingeplant haben.

Der Kernunterschied: Plugins laufen auf Ihrem Server, Apps nicht

Ein Shopware-6-Plugin ist PHP-Code, der direkt innerhalb von Shopware auf Ihrem Server ausgeführt wird. Es hat vollen Zugriff auf die Plattform-Interna — den Produktkatalog, das Bestellsystem, den Data Layer, den Storefront-Renderer. Wenn Shopware startet, startet Ihr Plugin mit.

Eine Shopware-App ist ein separater Webservice. Sie läuft auf ihrem eigenen Server und kommuniziert mit Shopware über Webhooks und eine standardisierte API. Shopware weiß, dass die App registriert ist — aber die Logik läuft vollständig außerhalb Ihrer Shop-Codebasis.

Dieser eine Unterschied — innen vs. außen — bestimmt alles andere: Entwicklungskosten, Update-Risiko und langfristige Wartung.

Wann ein Plugin die richtige Wahl ist

Plugins sind das richtige Werkzeug, wenn Ihre Anpassung tiefen Zugriff auf Shopwares Interna benötigt. Wenn Sie Storefront-Templates überschreiben, neue Datenbankentitäten hinzufügen, auf niedriger Ebene in den Checkout-Prozess eingreifen oder Hintergrundaufgaben im Shopware-Scheduler ausführen müssen — ein Plugin erledigt das.

Aus meiner Erfahrung mit Shopware-6-Projekten machen Plugins Sinn für:

• Individuelle CMS-Elemente und Storefront-Komponenten, die das Layout auf jeder Seite beeinflussen
• Geplante Hintergrundjobs — Produktimporte, Preissynchronisierungen, Bestandsaktualisierungen, die innerhalb von Shopware selbst laufen
• Individuelle Checkout-Schritte oder Warenkorbregeln, die über das hinausgehen, was der eingebaute Rule Builder leisten kann
• Erweiterungen der Shopware-Administration um neue Module, Dashboards oder Bestellansichten
• Komplexe Storefront-Verhalten, die serverseitiges Rendering und direkten Template-Zugriff erfordern

Der Kompromiss ist real: Ein Plugin ist eng an Shopwares Version gekoppelt. Wenn ein Major-Update erscheint, können Plugins, die tief in die Plattform eingreifen, brechen. Jemand — Ihr Entwickler — muss sie prüfen und aktualisieren.

Wann Sie stattdessen eine Shopware-App bauen sollten

Shopware hat das App-System genau eingeführt, um das Problem der Update-Anfälligkeit zu lösen. Weil Apps über Shopwares stabile, versionierte API kommunizieren und nicht direkt in die PHP-Codebasis eingreifen, brechen sie bei einem neuen Major-Release deutlich seltener.

Apps sind die richtige Wahl, wenn:

• Sie Shopware an einen externen Service anbinden — ein CRM, einen Versanddienstleister, eine Marketing-Automation-Plattform oder ein individuelles ERP
• Ihre Funktion nur auf Ereignisse reagieren muss (Bestellung aufgegeben, Kunde registriert, Produkt aktualisiert), ohne etwas im Storefront darzustellen
• Sie dieselbe Erweiterung über mehrere Shopware-Shops hinweg betreiben möchten, ohne PHP-Code auf jedem einzeln auszurollen
• Ihr Entwicklungsteam einen anderen Backend-Stack verwendet — Apps müssen kein PHP sein

Wenn ich den Shopware-Shop eines Kunden an sein Lagerverwaltungssystem anbinde, baue ich dafür ausnahmslos eine App. Die Lagerlogik hat nichts in Shopwares PHP-Prozess zu suchen — und das App-Modell hält diese Verantwortlichkeiten sauber getrennt, was das gesamte System einfacher zu debuggen, zu testen und zu übergeben macht.

Kosten, Wartung und Update-Risiko: Ein praktischer Vergleich

Hier wird die Entscheidung finanziell. Das ist es, worauf Sie sich mit jedem Ansatz tatsächlich einlassen:

• Zugriff auf Shopware-Interna: Plugins haben vollen Zugriff. Apps sind auf das beschränkt, was die API bereitstellt — was die meisten Integrations-Use-Cases abdeckt, aber nicht alle Storefront-Anpassungen.
• Update-Risiko: Plugins können bei Major-Version-Upgrades von Shopware brechen. Apps sind davon weitgehend abgeschirmt, weil sie über eine stabile Schnittstelle kommunizieren.
• Infrastruktur: Plugins laufen auf Ihrem bestehenden Shopware-Server. Apps erfordern einen separaten, dauerhaft verfügbaren Webservice — das bedeutet zusätzliche Hosting-Kosten und operativen Aufwand.
• Storefront-Anpassungen: Nur Plugins können Shopware-Twig-Templates überschreiben oder erweitern. Apps haben keinen direkten Zugriff auf den Storefront.
• Sprachflexibilität: Plugins müssen PHP sein. Apps können in jeder Sprache geschrieben werden, die Ihr Team bevorzugt.
• Langfristige Wartung: Eine gut gebaute App, die gegen stabile API-Endpunkte integriert ist, benötigt im Laufe der Zeit weniger Nacharbeit. Ein Plugin, das tief in Shopware-Interna eingreift, erfordert bei jedem Major-Release eine Überprüfung.

Keine der beiden Optionen ist abstrakt „besser". Die richtige Wahl hängt vollständig davon ab, was Ihre Funktion tatsächlich tun muss — und wie viel Update-Wartung Sie langfristig zu tragen bereit sind.

Was das bedeutet, wenn Sie einen Shopware-Entwickler engagieren

Wenn Sie einen Shopware-Entwickler hinzuziehen und die gewünschte Funktion beschreiben, sollte diese Frage beantwortet sein, bevor eine einzige Zeile Code geschrieben wird. Ein Entwickler, der nicht zwischen beiden unterscheidet — oder der standardmäßig immer ein Plugin wählt, weil es vertrauter ist — trifft eine Architekturentscheidung, die Ihr Shop jahrelang tragen wird.

In meinen Projekten kläre ich das früh mit den Kunden und dokumentiere die Empfehlung, bevor der Umfang der Arbeit festgelegt wird. Die Architekturentscheidung bestimmt den Entwicklungszeitplan, den Testansatz und wie die Übergabe nach Abschluss des Projekts aussieht. Eine CRM-Integration, die als Plugin statt als App gebaut wird, ist von Tag eins an technische Schulden. Eine komplexe Storefront-Anpassung, die ins App-Modell gezwungen wird, weil „Apps einfacher zu warten sind", scheitert in dem Moment, in dem sie ein Template berühren muss.

Es gibt hier keinen Abkürzungsweg. Die richtige Entscheidung erfordert ein tiefes Verständnis sowohl der Funktionsanforderungen als auch der Shopware-Plattform.

Nächste Schritte: Architekturempfehlung einholen

Wenn Sie eine individuelle Shopware-6-Funktion im Sinn haben — ob eine Drittanbieter-Integration, eine Storefront-Anpassung oder etwas vollständig Spezifisches für Ihre Geschäftsabläufe — ist der erste Schritt eine klare Architekturempfehlung, bevor die Entwicklung beginnt.

Diese Empfehlung sagt Ihnen, ob Sie ein Plugin, eine App oder eine Kombination aus beidem benötigen — und wie der realistische Zeitplan und die Wartungsverpflichtung aussehen.

Ich arbeite mit Shop-Betreibern und CTOs zusammen, um individuelle Shopware-6-Entwicklungsprojekte von Grund auf zu konzipieren. Wenn Sie eine klare Einschätzung möchten, was Ihre Funktion erfordert und wie Sie es beim ersten Mal richtig bauen, melden Sie sich gerne.

Mit Bojan zusammenarbeiten – jetzt Kontakt aufnehmen