--- title: Understanding the App System | Shopware Community Hub description: >- A theoretical introduction to the Shopware App System: what it is, why it exists, how it differs from plugins, and the core concepts you need to know before… canonical_url: 'https://hub.shopware.com/learn/unit/understanding-the-app-system' --- # Understanding the App System - **Understand** what the **Shopware App System** is and why it was created. - **Differentiate** between **Apps** and **plugins** and understand when to use each. - **Identify key advantages** of the **App System**, such as scalability and cloud compatibility. - **Learn the core concepts** of the **App System** (`manifest.xml`, App Server, handshake process). - **Understand** that an **App Server is optional** and when it is necessary. # Understanding the App System **Shopware's App System** was designed to solve a simple but powerful problem: How can developers build extensions that work for hundreds of shops at once without touching the shop itself? For years, developers built plugins that had to be installed and maintained on every single shop – a time-consuming process. The App System solved this problem by moving most of the logic **outside the Shopware core**. Instead of editing Shopware's core or deploying code to every shop, you build one App that securely connects to many shops at once. This approach allows developers and agencies to roll out **updates instantly**, **maintain clean separation** between business logic and shop, and build solutions that work seamlessly across **self-hosted** and **Shopware Cloud** environments. It follows modern cloud-native patterns and microservice principles. ## What Is the Shopware App System? The Shopware [App System](https://developer.shopware.com/docs/concepts/extensions/apps-concept.html) is an **extension framework** that lets you integrate external services and custom logic **without modifying the Shopware core**. Unlike plugins, Apps live outside the system and communicate with Shopware through **secure APIs** and **declarative configuration files** like the `manifest.xml`. ### Key Characteristics of Apps Apps differ from plugins in five fundamental ways: | Characteristic | Explanation | |-------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Apps run outside Shopware** | Unlike plugins, which run inside the Shopware PHP process, Apps execute externally—either on a separate App Server or using configuration files only. Your custom code stays separate from Shopware's core. | | **Configuration over code** | Apps use XML files to define behavior. You describe *what* you want, and Shopware handles the *how*. Plugins require writing PHP code for everything. | | **Cloud-ready** | Apps work seamlessly with Shopware Cloud, self-hosted shops, and PaaS platforms without special setup. | | **Centralized logic** | One App Server can serve hundreds of shops. Apps can be updated once, and all shops benefit immediately. | | **Secure communication** | All data exchange is authenticated via [JWT tokens](https://developer.shopware.com/docs/guides/plugins/apps/clientside-to-app-backend.html). | ## Why Was the App System Created? Shopware introduced the App System to address several challenges faced by agencies, SaaS providers, and developers managing multiple shops: ### 1. Centralized Service Management With traditional plugins, each shop runs its own instance of the plugin code. If you need to update business logic or fix a bug, you must **update every shop individually**. This becomes a significant maintenance burden when managing dozens or hundreds of shops. Apps solve this by centralizing logic in an **App Server**. When you update the App Server, all connected shops **instantly benefit** from the changes without requiring shop-level updates. ### 2. Instant Backend Updates Because business logic lives on the App Server, you can deploy fixes, new features, or integrations **immediately**. There's no need to: - Build and package a new plugin version - Distribute it to all shops - Wait for merchants to install updates This is especially valuable for **SaaS providers** and **agencies** managing multiple clients. ### 3. Cloud-Native Architecture Apps are designed to work seamlessly with [Shopware Cloud](https://www.shopware.com/en/shopware-cloud/), which has stricter security and isolation requirements than self-hosted installations. By running externally and communicating through secure APIs, Apps can operate in cloud environments without compromising security. ### 4. Separation of Concerns Apps enforce a clean separation between: - **Shop logic** (handled by Shopware Core) - **Custom business logic** (handled by the App Server) - **Data exchange** (handled by APIs) This makes Apps easier to test, maintain, and scale. ### 5. Deep Integration Possibilities Apps can extend nearly every part of Shopware: - Build custom [App themes](https://developer.shopware.com/docs/guides/plugins/apps/storefront/apps-as-themes.html) to modify the storefront. - Add custom modules and dashboards directly into the **Administration**. - Influence the **Checkout** flow with custom payment methods or shipping providers. - Use [App Scripts](https://developer.shopware.com/docs/guides/plugins/apps/app-scripts/) to attach data dynamically or modify API responses. - React to shop events in real-time via **webhooks**. This flexibility makes Apps suitable for everything from simple integrations to complex multi-shop SaaS platforms. ### 6. Security and Compliance Apps are designed with security as a core principle: - **External execution**: Apps run outside the Shopware Core, creating a strong security boundary. - **Authenticated communication**: All data exchange uses [signed JWT tokens](https://developer.shopware.com/docs/guides/plugins/apps/clientside-to-app-backend.html), ensuring data integrity. - **Permission-based access**: Apps must declare required permissions in the `manifest.xml`, which shop owners can review before installation. - **Audit trail**: API-based communication allows full logging and monitoring of all App interactions. This architecture makes Apps particularly suitable for enterprises and cloud environments with strict compliance requirements. ## Apps vs. Plugins: When to Use Which? Both Apps and plugins are valid ways to extend Shopware, but they serve different purposes. Understanding the trade-offs is critical to choosing the right approach. | Use **Apps** when you need | Use **plugins** when you need | |-----------------------------------------------------------------------------------------|-------------------------------------------------------------------------------| | **Centralized service management**: One backend serving many shops | **Deep core modifications**: Direct access to Shopware internals | | **Instant updates**: Deploy changes without touching shop code | **High-performance operations**: Logic that runs directly in the PHP process | | **External integrations**: Connect to ERP systems, CRM platforms, or third-party APIs | **Complex storefront customizations**: Heavy frontend modifications | | **Cloud compatibility**: Build extensions that work seamlessly with Shopware Cloud | **Server-side performance**: Need ultra-fast backend execution in PHP | | **Declarative configuration**: Define behavior through XML files rather than PHP code | **Full event access**: Need to listen to internal Symfony or Doctrine events | | **Minimal shop-side code**: Keep the shop lightweight and reduce maintenance overhead | **Deep data model access**: Extend or override Doctrine entities and services | To get a better understanding of when to use Apps versus plugins, let's look at some common use cases. | **Common use cases for Apps:** | **Common use cases for plugins** | |-------------------------------------------------|---------------------------------------------------------| | ERP and PIM integrations | Custom product types with complex logic | | Payment and shipping provider integrations | Advanced cart or checkout manipulation | | CRM, newsletter or marketing automation systems | Custom storefront themes or CMS extensions | | Multi-tenant SaaS or analytics dashboards | Deep backend logic tied to Shopware's PHP layer | | Custom admin extensions or dashboards | Performance-critical services (e.g., indexing, caching) | | Cloud-ready third-party services | Direct database interaction or Shopware modifications | Now that you know when to choose an App over a plugin, let's look at the core components that make up every App. Yes! Many projects use **both** Apps and plugins. For example, you might use a **storefront plugin** for storefront customizations and an App for external API integrations. ## Core Concepts of the App System Every App is built around some main building blocks: - **The `manifest.xml` file** – Defines what your App is allowed to do (meta-data, permissions, webhooks, and more) - **App Server (optional)** – Hosts business logic and external integrations - **Handshake process** – Secure communication between your App and the App Server You will explore these in detail later in this course. ## Visual Overview: App System Architecture The following diagram visualizes how Apps communicate with Shopware and where the `manifest.xml` file and the App Server fit into the system. ![App Overview](./assets/app-overview-diagram.png) The App System allows developers to extend Shopware without touching the core. As shown in the diagram, every App connects to the **Shopware shop** through the `manifest.xml` file – the central configuration file. This file defines how your App integrates with Shopware, such as permissions, webhooks, optional App Server settings, and more. You can think of it as a **contract** that describes how Shopware and your App communicate. Depending on your App's design, you can either connect to an **external App Server** where webhooks, API calls and business logic are handled, or run **without a server**, using templates, scripts and custom fields directly inside Shopware. ## Summary In this learning unit, you learned the **big picture** of the Shopware App System: - **Why** the App System exists and how it **differs** from plugins - The **main advantages** of Apps: Scalability, cloud compatibility, instant updates, and centralized service management - The **core components** every App relies on: manifest.xml, App Server (optional), and the handshake process for secure communication Each of these concepts will be explored in more detail in the upcoming learning units. You now have the mental model needed to understand how everything fits together. In the next learning unit, you will ***create and install your first App in your local Shopware environment**. If you do like to dive deeper into the App System before continuing with the course, check out the following resources: - [Official App System Concept Documentation](https://developer.shopware.com/docs/concepts/extensions/apps-concept.html) - [App Base Guide](https://developer.shopware.com/docs/guides/plugins/apps/app-base-guide.html) - [App vs Plugin Decision Guide](https://developer.shopware.com/docs/guides/plugins/)