Shopware Apps vs. Plugins: The Right Architecture

Whether an extension is built as an app or a plugin determines your shop's update safety, hosting model, and maintenance effort - long before the first line of code. Shopware deliberately offers two extension systems: the app system, which communicates via API and webhooks and runs in isolation, and the classic plugin, which works directly inside the core as a Symfony bundle. More than 100,000 (Shopware) merchants worldwide run on Shopware, and this architecture question matters for every one of them. This guide shows which system is the right choice when, and how we as a Shopware agency develop the right extension strategy.

Two Extension Systems, One Strategic Decision

According to the 2025 EHI study, Shopware is the most widely used shop system in Germany for the fourth consecutive year, leading with 11.5% (Shopware/EHI) of the top 1,000 online shops - that is 115 (Shopware/EHI) of the country's highest-revenue shops. Their combined net revenue reached 80.4 billion euros (EHI/eCommerceDB) in 2024. Anyone building on this platform faces a fundamental early decision: app or plugin.

Both systems solve the same task - extending the shop with functionality - in fundamentally different ways. The app system keeps the logic outside the shop and talks to it through interfaces. The plugin becomes part of the shop and accesses its services directly. The choice determines whether your extension runs in the cloud, how update-safe it is, and how much maintenance it causes over the years. It is an e-commerce architecture decision, not a matter of taste.

In many projects this decision is made in passing - by habit, by what the team already knows, or by the first suitable extension in the store. That backfires later: a plugin that should have been an app blocks the move to the cloud; an app that would need to intervene deeply in checkout hits the limits of its sandbox. Sound architecture consulting replaces gut feeling with a reasoned assignment of each function to the right system - which is exactly what this guide is about.

The App System: API, Webhooks and Isolation

The app system moves an extension's business logic to an external system. Shopware communicates with the app exclusively via HTTP requests (Shopware Developer Documentation): events flow through webhooks, data through the API. The app system is deliberately decoupled from the core (Shopware Developer Documentation) - developers only need to understand the interface between Shopware and their app, not the internal structures, and are free to choose their programming language and framework.

In practice, an app registers on first activation through a signed handshake and then receives time-limited API credentials. For bulk data exchange - thousands of products or orders, for example - the Sync API bundles multiple write operations into a single call. This keeps communication efficient even with large data volumes, without the app ever needing direct access to the shop's database (Shopware Developer Documentation).

The decisive advantage: through this decoupling, an app is automatically compatible with multi-tenant cloud systems (Shopware Developer Documentation) and runs equally in self-hosted setups - the same extension, two hosting models. Specialized functions are covered too: app-based payment methods have existed since Shopware 6.4.1.0 (Shopware Developer Documentation), custom rule builder conditions since Shopware 6.4.12.0 (Shopware Developer Documentation). For many integration scenarios, no plugin is needed at all.

The Plugin System: Symfony Bundles with Core Access

A plugin is a thin abstraction layer on top of Symfony's bundle system (Shopware Developer Documentation) and thereby becomes part of the application. It can intervene deeply in Shopware processes and modules: register its own services via dependency injection, read and write data through the Data Abstraction Layer (DAL), subscribe to events, and modify storefront templates. This proximity to the core is the real strength of the plugin model.

• Custom entities: New data models via the DAL, including migrations and repository access
• Process logic: Cart processors and collectors for custom price, discount, and cart rules in checkout
• Event subscribers: Reacting to internal events without a network detour, directly in the Shopware process
• Storefront and admin: Overriding Twig templates and adding custom administration modules and components
• Scheduled tasks: Recurring jobs via the message queue inside the shop
• Service decoration: Extending or deliberately overriding existing Symfony services

This depth has a price: plugins run only in self-hosted installations and require server-side PHP access. Current versions require PHP 8.2 or 8.3 (Shopware Documentation) - Shopware 6.7 adds support for PHP 8.4 since its release in May 2025 (Shopware). The operator is responsible for server, updates, and compatibility, which calls for reliable hosting and a clean update strategy.

Technically, every plugin ships a base class that controls the lifecycle: install, activate, deactivate, uninstall, and update can each be handled deliberately - for example to migrate database schemas cleanly during an update. Custom services are registered and existing ones decorated through the Symfony service container. This control over the entire lifecycle is one reason complex domain logic is often still implemented as a plugin.

App or Plugin: The Direct Comparison

The following comparison summarizes the key differences. It does not replace a case-by-case assessment, but it makes the fundamentally different nature of the two systems visible.

A pattern emerges from the table: the app system optimizes for decoupling, operational flexibility, and low risk, while the plugin optimizes for depth and control. Neither column is categorically better - what matters is which properties your specific use case needs.

When the App System Is the Right Choice

The app system plays to its strengths wherever an extension does not need to intervene deeply in the order process, but rather moves data, talks to external services, or should work across many shops. For synchronizing products, orders, and customers with an ERP system such as SAP Business One, the API-based approach is the obvious choice - scalable and reusable across environments.

• Your shop runs in a cloud environment without server and file access
• You sync data with an external system that provides the actual logic
• The extension should be reusable across multiple shops and tenants
• An external service handles payment, shipping, or tax calculation
• Update safety and low maintenance effort are top priorities
• The team prefers to work in a language other than PHP

Anyone planning toward cloud operation should design new extensions as apps anyway - that keeps the choice of hosting model open without having to rebuild the extensions.

When a Plugin Is Indispensable

As soon as an extension has to run logic directly at the heart of the shop, there is hardly a way around a plugin. Custom price and discount rules in checkout, custom data models, or deep modifications to storefront templates require the direct access that only a Symfony bundle running in the core provides.

• Custom cart calculation as well as discount or price logic directly in checkout
• Custom database entities via the Data Abstraction Layer with full read and write access
• Deep modifications to storefront templates and administration components
• Event subscribers and scheduled tasks inside the Shopware process
• Performance-critical logic that must run without network latency to an external service
• Existing Symfony services that need to be extended or overridden

Maintenance, Updates and Total Cost of Ownership

The choice between app and plugin is not only a technical but also an economic decision. Over an extension's lifecycle, most costs rarely arise during initial development, but during maintenance, updates, and compatibility testing. This is exactly where the two systems differ significantly - and exactly where a deliberate architecture decision pays off over the years.

A plugin is tied to the core version: at every major Shopware step, the code must be reviewed and often adjusted. An app stays more independent of the core thanks to its stable interface and usually survives updates without intervention, as long as the API contracts do not change. Anyone planning operating costs realistically should factor in these differences from the start.

• Initial development: Plugins require Shopware and Symfony know-how, apps additionally a place to operate the external service
• Updates: Plugins are reviewed at core steps, apps stay more stable across the interface
• Operation: A plugin runs inside the shop, an app needs its own infrastructure and monitoring
• Risk: A plugin bug can affect the shop, an isolated app bug stays contained
• Reuse: Apps can be rolled out across multiple shops, plugins are maintained per installation

Hybrid Strategies and the Update Question

In practice, the two systems do not exclude each other. Many shops combine robust plugins for deep process logic with apps for integrations and external services. App scripts blur the line further: since Shopware 6.4.8.0 (Shopware Developer Documentation), even cart logic can run sandboxed in the app context - functionality that previously required a plugin.

The update question remains the decisive cost factor over the years. Plugins are tied to the core version and must be checked at every major step - for example when the PHP version changes during a Shopware update. Apps stay more independent thanks to their stable interface. Anyone aiming for a modular architecture will find the broader frame in composable and headless approaches, into which the app-plugin decision fits.

The question is rarely app or plugin in the absolute, but which function belongs where. A clean separation of integrations as apps and core logic as plugins saves maintenance costs over the years.

XICTRON development team

A typical pattern from practice: the connection to inventory management and shipping runs as an app over the API, while discount and price logic, special prices for regular customers, or a custom configurator work as a plugin directly in the core. This way, every requirement gets the system that suits it best - and the shop stays ready for a later cloud migration without having to rebuild the integrations.

The next generation of interfaces also connects cleanly via the app system - for example when you want to connect AI agents to your shop through standardized protocols or map regulatory requirements such as the new product safety obligations through connected services. Today's architecture decision determines how easily such extensions can dock on tomorrow.

How We Develop Your Extension Strategy

Instead of deciding from the gut, we start with a sober analysis of your requirements, your hosting model, and your roadmap. From that, we determine for each function whether it is best placed as an app, a plugin, or a hybrid solution - and build it so that it fits your shop and your team.

Whether app system, classic plugin, or a well-considered combination of both: what matters is that the architecture fits your goals and not the other way around. Our e-commerce consulting supports you from the first analysis to the productive extension.

Frequently Asked Questions About Shopware Apps and Plugins