WooCommerce-Shop als App für iOS und Android: So geht's

Von Alejandro Morillo · Veröffentlicht 1. Oktober 2026 · 11 Min. Lesezeit

Du betreibst einen WooCommerce-Shop, deine Kundschaft kauft auf dem Smartphone, und du willst ein App-Icon auf ihrem Home-Screen. Die meisten „Shop in Minuten zur App"-Seiten sagen dir nicht, welcher Ansatz zu deinem Shop passt – oder was kaputtgeht, sobald dein Checkout in einer App läuft.

Dieser Artikel vergleicht die vier realistischen Optionen und geht dann durch, was du in WordPress und WooCommerce vor dem Build prüfen solltest: Zahlungsanbieter in einer WebView, Login- und Warenkorb-Sessions, Caching-Plugins, Cookie-Banner, Kontolöschung und die App-Store-Regeln für Shops.

Preise und Richtlinien wurden im Oktober 2026 auf den Seiten der Anbieter und Stores selbst geprüft und können sich ändern. Apple-Zitate stammen aus den App Review Guidelines mit Stand 8. Juni 2026, im englischen Original. Eine Freigabe im App Store kann niemand garantieren – App Review entscheidet im Einzelfall.

Vorab: Die offizielle WooCommerce-App ist für dich, nicht für deine Kundschaft

Suchst du im App Store nach „WooCommerce", findest du die offizielle WooCommerce-App. Sie ist ein Werkzeug für Shop-Betreiber und -Manager: Produkte anlegen, Bestellungen bearbeiten, Umsätze ansehen, vor Ort mit Tap to Pay oder Kartenleser kassieren. Deine Kundinnen und Kunden können darin weder stöbern noch kaufen.

Einen Schalter in WooCommerce, der deinen Shop als Kunden-App veröffentlicht, gibt es nicht. Du brauchst einen der folgenden Ansätze.

Vier Wege in die App Stores

	PWA	Web-to-App-Hülle	Plugin-basierter App-Builder	Eigene native / React-Native-App
Was in der App läuft	Deine Website, vom Browser aus zum Home-Screen hinzugefügt	Dein Live-Shop in einem nativen Container	Native Screens, befüllt über die WooCommerce REST API	Deine eigene App auf REST API / Store API
In App Store / Google Play	Nein	Ja	Ja	Ja
Theme, Plugins, Checkout	Unverändert	Unverändert (dieselben Seiten wie mobil im Web)	Nur, was der Builder unterstützt	Nur, was du baust
Änderungen am Shop	Sofort sichtbar	Sofort sichtbar	Produkte synchronisiert; Layout im Builder	UI-Änderungen brauchen ein neues Release
Hauptrisiko	Kundschaft muss sie finden und selbst installieren	Guideline 4.2, wenn sie wie eine Website wirkt	Plugins und Zahlarten, die die App nicht kann	Kosten und Wartung
Ideal für	Nachfrage testen	Shops mit gut funktionierender Mobilseite	Standard-Katalog, Standard-Checkout	Große Shops mit Dev-Team

1. Progressive Web App (PWA)

Deine Website plus Web-App-Manifest und Service Worker. Kundinnen und Kunden fügen sie selbst zum Home-Screen hinzu; seit iOS 16.4 können solche Home-Screen-Web-Apps Web-Push empfangen. Einen Store-Eintrag gibt es nicht, also findet sie niemand über die App-Store-Suche. Ein günstiger Weg, um zu testen, ob überhaupt jemand eine App will.

2. Web-to-App-Hülle um den Live-Shop

Ein nativer Container (WKWebView unter iOS, WebView unter Android) lädt deinen echten Shop. Theme, Produkt-Add-ons, Versandregeln, Gutscheine und Checkout funktionieren weiter, und Änderungen am Shop erscheinen ohne neues Release. Der Haken: Die App ist nur so gut wie deine Mobilseite, Apple prüft, ob sie mehr ist als eine „repackaged website", und Zahlungs-Popups und Wallet-Buttons musst du testen, denn eine WebView ist kein Safari.

3. Plugin-basierte App-Builder auf der WooCommerce REST API

Diese Tools verbinden sich über WooCommerce-REST-API-Schlüssel und zeigen Produkte, Kategorien und Warenkorb in eigenen nativen Screens. Drei Beispiele, Stand Oktober 2026:

AppMySite verbindet sich über WooCommerce-REST-API-Schlüssel. Die WooCommerce-Tarife gelten pro App: Der Gratis-Tarif und Starter (69 $/Monat) sind nur für Android; iOS gibt es ab Pro für 129 $/Monat (99 $/Monat bei jährlicher Zahlung).
Mobikul WooCommerce Mobile App Builder (Webkul) ist ein Einmalkauf: 129 $ im Angebot, regulär 249 $, für Flutter-basierte Android- und iOS-Apps, synchronisiert über die REST API. Der Quellcode kostet 129 $ extra, die Veröffentlichung über deine Accounts 75 $; drei Monate Support sind enthalten.
Mobile App Builder for WooCommerce (FmeAddons) wird im WooCommerce Marketplace für 133 € pro Jahr angeboten und verbindet die App über einen REST-API-Consumer-Key und -Secret mit deinem Shop.

Die Screens wirken nativ, aber alles, was Theme oder Plugins nur auf der Website ausgeben (Produktkonfiguratoren, eigene Checkout-Felder, B2B-Preisregeln), erscheint in der App nur, wenn der Builder es unterstützt. Frag beim Anbieter jedes Plugin ab, auf das du angewiesen bist, bevor du zahlst.

4. Eigene native oder React-Native-App

Du baust deine eigene App. Die WooCommerce REST API (/wp-json/wc/v3) authentifiziert mit Consumer-Key und -Secret und kann Shop-Daten schreiben – diese Schlüssel gehören deshalb auf deinen Server, nie in ein App-Binary. Für kundenseitige Funktionen gibt es die Store API (/wp-json/wc/store/v1): Endpunkte ohne Authentifizierung für Produkte, Warenkorb und Checkout, mit Cart Tokens (Header Cart-Token) statt Cookie-Sessions. Volle Kontrolle, das nativste Gefühl – und du baust jede Checkout-Erweiterung, jeden Zahlungsanbieter und jede Versandregel nach und pflegst danach zwei Frontends.

Wie du dich entscheidest

Mobilseite konvertiert gut, viele Plugins: Hülle.
Standard-Katalog und -Zahlarten, native Screens ohne Entwickler: Plugin-basierter Builder.
Entwickler vorhanden und Funktionen, die das Web nicht gut kann: eigene App.
Unsicher, ob deine Kundschaft eine App will: zuerst PWA.

Für jede Store-Variante brauchst du das Apple Developer Program (99 USD pro Mitgliedsjahr, lokale Preise können abweichen) und ein Google-Play-Entwicklerkonto (einmalig 25 US$).

Deinen Shop vorbereiten

Das gilt voll für eine Hülle und teilweise für Builder, die den Checkout an deine Website übergeben. Teste auf einem echten Smartphone in einem Test-Build, nicht in Safari auf dem Desktop.

Mobiles Theme und Startseite

Prüf jedes Template, das deine Kundschaft sieht: Shop-Archiv, Produkt, Warenkorb, Kasse, Mein Konto, Bestellbestätigung. Page-Builder-Themes haben oft eine schöne Startseite und eine gequetschte Kasse.
Kein Element breiter als der Bildschirm; nichts, was man nur mit Pinch-Zoom lesen kann.
Wähl eine Start-URL, die Produkte zeigt (Shop oder eine Kategorie), keine Startseite voller Werbung und Newsletter-Popups.
Entferne „Lade unsere App"-Banner aus der App-Ansicht.

Checkout und Zahlungsanbieter in einer WebView

Hier brauchen die meisten WooCommerce-Apps Arbeit.

Weiterleitungen. Zahlarten, die auf eine externe Seite weiterleiten (PayPal, viele Bank- und Ratenkauf-Methoden, gehostete Zahlungsseiten), müssen zurück in die App führen. Prüf, dass die Rückkehr auf deiner Bestellbestätigung in der App landet, nicht im Browser des Telefons.
Popups. Der PayPal-Checkout kann ein Popup-Fenster öffnen, und damit kommen WebViews schlecht zurecht. Deshalb pflegt Braintree (ein PayPal-Unternehmen) PopupBridge, eine Bibliothek, die solche Popups in einem sicheren Browser-Fenster öffnet und das Ergebnis zurückgibt. Teste PayPal von Anfang bis Ende, inklusive Abbruch.
3-D Secure. Für die meisten Kartenzahlungen im EWR und in Großbritannien verlangt die starke Kundenauthentifizierung einen zusätzlichen Schritt, meist 3-D Secure. Teste eine Karte mit Challenge und eine, bei der die Banking-App die Freigabe abfragt, und prüf, ob du danach auf der Bestätigung landest.
Apple Pay. WebKit hat Apple Pay mit iOS 13 in WKWebView gebracht, aber es „cannot be used alongside of script injection APIs" wie WKUserScript – es lässt sich also nicht zusammen mit eingeschleustem JavaScript nutzen. Viele App-Hüllen schleusen Skripte ein, um Web und nativen Code zu verbinden; Ionics Dokumentation nennt die WebView einer Capacitor- oder Cordova-App ausdrücklich als Ort, an dem Apple Pay ohne Plugin nicht funktioniert. Mach Apple Pay nicht zu deiner einzigen Express-Option und prüf, dass Karte und PayPal weiterhin erscheinen, wenn es fehlt.
Google Pay. Unter Android muss die App für Google Pay auf einer Webseite in der WebView die Payment Request API aktivieren und Zahlungs-Intents deklarieren; dazu kommt eine aktuelle WebView-Version. Frag deinen Builder und teste es.

„Angemeldet bleiben". WordPress hält einen Login mit „Angemeldet bleiben" 14 Tage, sonst als Session-Cookie, der nach zwei Tagen oder beim Schließen des Browsers endet. Beende die App hart, öffne sie am nächsten Tag und schau, ob du noch eingeloggt bist.
Lebensdauer des Warenkorbs. Im aktuellen WooCommerce-Code läuft eine Session standardmäßig zwei Tage für Gäste und eine Woche für eingeloggte Kunden (Filter: wc_session_expiration). Eingeloggte Kunden haben zusätzlich einen dauerhaften Warenkorb in ihrem Konto.
Eigener Cookie-Speicher. Wer in Safari eingeloggt ist, ist es in deiner App nicht automatisch – und umgekehrt.
Social-Login-Plugins. Laut Googles OAuth-Richtlinie dürfen Entwickler Anmeldeanfragen nicht an einen eingebetteten User-Agent schicken, daher kann „Mit Google anmelden" in einer WebView scheitern. Apples Guideline 4.8 verlangt außerdem eine gleichwertige, datensparsame Login-Option, sobald ein Drittanbieter-Login das Kundenkonto anlegt. Social-Login-Buttons in der App auszublenden ist oft die einfachste Lösung.
Demo-Account. Guideline 2.1 verlangt „demo account info", wenn deine App einen Login hat. Leg ein Kundenkonto für App Review an.

Caching-Plugins, die eingeloggte Sessions kaputt machen

WooCommerces Anleitung zum Konfigurieren von Caching-Plugins ist die Referenz. Prüf:

Warenkorb, Kasse und Mein Konto sind vom Seiten-Cache ausgenommen.
Anfragen mit den Cookies woocommerce_cart_hash, woocommerce_items_in_cart oder wp_woocommerce_session_ umgehen den Cache.
Bei Datenbank- oder Object-Caching ist _wc_session_ ausgenommen.
CDN- oder Hosting-Regeln, die alles HTML cachen, respektieren diese Ausnahmen.
Caching pro Nutzer (WP Rockets User Cache, LiteSpeeds Cache Logged-in Users) ist mit zwei verschiedenen Kundenkonten getestet.

Typische Symptome in einer App: der Mini-Warenkorb einer anderen Person, ein leerer Warenkorb nach dem Login oder eine Kasse, die die Session ablehnt.

Das Consent-Banner erscheint beim ersten Start, weil der Cookie-Speicher der App leer beginnt. Es muss auf einen Smartphone-Bildschirm passen und darf den Kaufen-Button nicht verdecken.
Apple behandelt WebViews, die App-Funktionen bereitstellen, wie nativen Code: „If tracking occurs within a webview inside an app", ist der App-Tracking-Transparency-Dialog nötig. Werbe- und Retargeting-Pixel auf deinen Shop-Seiten zählen dazu. Entferne sie aus der App-Ansicht oder plane ATT ein – und gib es in den App-Datenschutzangaben an.

Performance

Seit WooCommerce 7.8 lädt das Cart-Fragments-Skript nur dort, wo das Warenkorb-Widget angezeigt wird. Lädt ein altes Theme oder Plugin es noch überall, zahlt jeder App-Screen eine zusätzliche Anfrage.
Teste im Mobilfunknetz, nicht im Büro-WLAN, und optimiere deine Produktbilder.

Kontolöschung (Guideline 5.1.1(v))

„If your app supports account creation, you must also offer account deletion within the app." – Wer in der App ein Konto anlegen kann, muss es dort auch löschen können. WooCommerce legt Kundenkonten an der Kasse oder unter Mein Konto an, hat aber keinen „Konto löschen"-Button für Kunden. Laut Apples Hinweisen zur Kontolöschung muss die Löschung in der App angestoßen werden, reines Deaktivieren reicht nicht, und ein manueller Ablauf ist in Ordnung, wenn du sagst, wie lange er dauert.

In der Praxis: Ergänze im Menü von Mein Konto einen Punkt „Konto löschen", der eine Anfrage auslöst, die dein Team über WordPress → Werkzeuge → Personenbezogene Daten löschen bearbeitet. Unter WooCommerce → Einstellungen → Konten & Datenschutz entscheidest du, ob personenbezogene Daten auf Anfrage aus Bestellungen entfernt werden – und klärst mit deiner Steuerberatung, welche Bestelldaten du aufbewahren musst.

Physische vs. digitale Produkte

Guideline 3.1.3(e): Für „physical goods or services that will be consumed outside of the app" musst du andere Zahlungswege als In-App-Kauf nutzen. Dein normaler WooCommerce-Checkout bleibt.

Downloads, digitale Mitgliedschaften und Inhalts-Abos fallen unter 3.1.1, die In-App-Kauf verlangt, „if you want to unlock features or functionality within your app". Dasselbe gilt für digitale Geschenkgutscheine, die gegen digitale Leistungen eingelöst werden; physische Gutscheine, die per Post verschickt werden, dürfen andere Zahlungswege nutzen. Verkaufst du beides, lass die digitalen Produkte in der App am besten weg.

Risiken im Store-Review

Guideline 4.2 – Minimum Functionality. Apple will „features, content, and UI that elevate it beyond a repackaged website". Shops haben einen Vorteil, weil 4.2.2 Kataloge vom Vorwurf „marketing materials" ausnimmt – aber ein Desktop-Theme, reine Web-Navigation und ein leerer Bildschirm offline wirken trotzdem wie eine Website mit Icon. Unser Artikel zur Ablehnung nach Guideline 4.2 zeigt die Lösungen.

Guideline 4.2.6 – App-Generatoren. Apps aus App-Generator-Diensten „will be rejected unless they are submitted directly by the provider of the app's content". Reich aus deinem eigenen Apple-Developer-Account ein, egal welchen Builder du nutzt.

Google Play. Die Richtlinie zur Mindestfunktionalität verlangt eine stabile, ansprechende und reaktionsschnelle Nutzererfahrung. Die Spam-Richtlinie richtet sich gegen WebViews einer Website ohne Erlaubnis des Website-Inhabers – bei deinem eigenen Shop kein Thema.

Review-Notizen. Guideline 2.3.1(a) verlangt, dass Funktionen „described with specificity in the Notes for Review" sind. Nenn den Demo-Account, wo die Kontolöschung zu finden ist und dass du physische Waren über deinen normalen Checkout verkaufst.

Checkliste vor dem Einreichen

Shop, Produkt, Warenkorb, Kasse und Mein Konto funktionieren auf dem Smartphone; die Start-URL zeigt Produkte
Jede Zahlart im App-Build getestet: Weiterleitung, PayPal-Popup, 3-D Secure, Apple Pay/Google Pay oder Alternative
Login übersteht hartes Beenden; Warenkorb übersteht einen Neustart
Warenkorb, Kasse, Mein Konto und WooCommerce-Cookies in jeder Caching-Schicht ausgenommen
Social Login ausgeblendet oder eine 4.8-konforme Alternative angeboten
Consent-Banner passt auf den Bildschirm; ATT umgesetzt oder Werbe-Pixel in der App entfernt
Kontolöschung aus Mein Konto erreichbar (5.1.1(v))
Digitale Produkte per In-App-Kauf oder weggelassen (3.1.1)
Demo-Kundenkonto und konkrete Notes for Review
Eingereicht aus deinem eigenen Apple-Developer-Account (4.2.6)

Wo AppThunder hilft

AppThunder ist Option 2: Es baut in der Cloud eine iOS- und Android-App um deinen Live-WooCommerce-Shop (eine Capacitor-basierte Hülle), Theme, Plugins und Checkout bleiben also, wie sie sind. Du bekommst natives App-Icon und Splash-Screen, Berechtigungsabfragen für Kamera und Standort mit Begründungstexten (nur wenn du sie aktivierst), eine gebrandete Offline-Seite, die automatisch neu lädt, ein Copy-Paste-Snippet für eine untere Tab-Leiste auf deiner Website (ein Web-Snippet, keine native Tab-Bar) und Thunder Analytics. Ein Guideline Checker markiert vor dem Einreichen typische Review-Probleme wie fehlende Datenschutzseite, Login-Wand oder fehlende Kontolöschung. Builds werden mit deinen eigenen Apple- und Google-Zugangsdaten signiert, iOS-Builds landen in deinem eigenen App Store Connect (TestFlight), und du bekommst .ipa- und .aab-Dateien. Die Tarife beginnen bei 39 €/Monat netto für eine Live-App; im Gratis-Tarif richtest du die App ein und siehst sie in der Vorschau (Builds brauchen einen bezahlten Tarif).

Was es nicht macht: dein mobiles Theme reparieren, dein Caching-Plugin konfigurieren, eine „Konto löschen"-Seite in WordPress anlegen oder Wallet-Zahlungen in einer WebView zum Laufen bringen – rechne damit, dass Apple Pay dort nicht verfügbar ist (siehe oben). Developer-Accounts, Datenschutzerklärung, Demo-Account und Store-Einträge brauchst du weiterhin selbst. Und eine Freigabe kann kein Tool garantieren.

FAQ

Kann ich die offizielle WooCommerce-App als Shop-App nutzen? Nein. Sie ist für Shop-Betreiber gedacht, um Produkte, Bestellungen und Zahlungen vor Ort zu verwalten. Kunden können darin nicht einkaufen.

Funktionieren meine WooCommerce-Plugins in der App? In einer Web-to-App-Hülle zeigt die App dieselben Seiten wie deine Mobilseite; Plugins, die dort laufen, laufen in der Regel auch in der App. Zahlungs-Popups und Wallets sind die Ausnahme, die du testen musst. Builder mit nativen Screens unterstützen nur, was sie integriert haben.

Muss ich Apples In-App-Kauf für meine Produkte nutzen? Nicht für physische Waren (3.1.3(e)). Digitale Inhalte und Abos, die in der App etwas freischalten, fallen unter 3.1.1.

Muss ich die App neu veröffentlichen, wenn ich Produkte oder Preise ändere? Nicht bei einer Hülle oder einem REST-API-Builder; die Produktdaten kommen aus deinem Shop. Einen neuen Build brauchst du, wenn sich die App selbst ändert, etwa Icon oder Berechtigungen.