Distribution ist jetzt eine Architekturentscheidung
Für Mobile-App-Teams in Europa ist Distribution nicht mehr nur eine Default-Entscheidung kurz vor dem Launch. Der EU Digital Markets Act hat Apple und Google dazu bewegt, mehr Optionen rund um App Stores, Web Distribution, alternative Marktplatze, Steering und Zahlungen zu öffnen. Das schafft wirtschaftliche Flexibilität, aber auch neue Produktkomplexität.
Eine mobile App kann heute unterschiedliche Wege für Discovery, Installation, Kauf, Account-Erstellung, Abo-Verwaltung, Rückerstattung und Support haben. Wenn diese Wege nur juristisch oder kaufmännisch geplant werden, kann die Nutzererfahrung auseinanderfallen. Produkt und Engineering sollten Distribution als Teil der App-Architektur behandeln.
Mit der User Journey starten, nicht mit dem Gebührenmodell
Die erste Frage ist, wo Nutzer dem Produkt bereits vertrauen. Ein bekannter B2B-Kunde akzeptiert vielleicht eine Installation aus einem Kundenportal. Ein breites Consumer-Publikum erwartet oft weiterhin die Vertrauenssignale von App Store oder Google Play. Ein Abo-Produkt kann einen Web-Kaufpfad brauchen, muss aber trotzdem erklären, wo das Abo liegt und wie es später verwaltet wird.
Genau hier entsteht der Trade-off. Alternative Distribution oder Billing kann Marge oder Plattformunabhängigkeit verbessern, verschiebt aber mehr Verantwortung zum Entwickler: Onboarding-Text, Systemhinweise, Zahlungserklärung, Steuern, Rückerstattungen, Abo-Status, Betrugsschutz und Kundensupport. Die richtige Wahl hängt an der ganzen Journey, nicht nur an der Provisionstabelle.
- Jeden Akquisekanal erfassen: Store Listing, Website, Kampagne, Partnerportal und In-App-Empfehlung.
- Festlegen, wo jede Nutzergruppe installieren und wo jede Nutzergruppe bezahlen soll.
- Abo-Zuständigkeit in Account-Einstellungen und Support-Tools sichtbar machen.
- Zahlungssprache, Plattformsprache und Produktsprache nicht in einem unklaren Screen vermischen.
- Completion, Rückerstattungen, Support-Tickets und fehlgeschlagene Installationen pro Distributionsweg messen.
iOS Web Distribution braucht Vertrauensdesign
Apples EU-Modell für Web Distribution erlaubt berechtigten Entwicklern, iOS- und iPadOS-Apps direkt über die eigene Website zu verteilen, mit Notarisierung und registrierten Domains. Das kann für etablierte Marken, Enterprise-Workflows und Produkte mit starker Web-Akquise wertvoll sein. Es ist aber keine Abkürzung um Produktvertrauen herum.
Nutzer müssen weiterhin verstehen, warum sie außerhalb des App Stores installieren, wer Support leistet, welche Informationen Apple geprüft hat und wo sie die App später verwalten können. Website, Installationsscreen und erstes App-Onboarding sollten dieselbe Produktsprache sprechen. Wenn die Webseite etwas anderes verspricht als Systemdialog oder erster App-Screen, sinkt Vertrauen im sensibelsten Moment.
Alternative Zahlungen verändern Support-Prozesse
Alternative Zahlungswege sind nicht nur Checkout-Änderungen. Auf iOS arbeiten externe Kaufpfade mit Plattform-Entitlements, Disclosure Sheets und Transaktionsreporting. Auf Android unterstützt Google Play im EWR alternative Billing-Optionen mit API-Reporting und Anforderungen an Nutzerschutz. In beiden Fällen braucht die App einen klaren Weg, nach dem Kauf zu erklären, was passiert ist.
Support-Teams brauchen vor dem Launch operative Sichtbarkeit: welcher Anbieter die Zahlung verarbeitet hat, ob ein Abo aktiv ist, wo Rückerstattungen passieren, welche Rechnungen existieren und welche Plattformservices nicht beteiligt sind. Ohne diese Backoffice-Sicht kann die Ersparnis alternativer Zahlungen schnell in manuellem Support und verwirrten Kunden verschwinden.
Ein Produktkonto über alle Kanäle halten
Das stabilste Produktmuster ist ein einheitliches Account-Modell über mehrere Distributions- und Zahlungskanäle hinweg. Nutzer sollten nicht verstehen müssen, ob ihre Berechtigung aus App Store In-App Purchase, Google Play Billing, einem Web-Checkout, einem Enterprise-Vertrag oder einem alternativen Marktplatz kommt. Die App sollte diese Quellen in einen klaren Produktstatus übersetzen.
Dafür braucht es Backend-Planung: Normalisierung von Entitlements, Receipt- oder Transaktionsreporting, Abo-Lifecycle-Events, Rückerstattungsabgleich, Audit Logs und Support-Berechtigungen. Es braucht auch sorgfältigen Text. Der Account-Screen sollte sagen, was Nutzer haben, wann es verlängert wird, wo es verwaltet werden kann und wer hilft, ohne interne Plattformmechanik offenzulegen.
Ein praktischer Entscheidungsrahmen
Für EDS Labs Mobile-App-Projekte ist der praktische Weg: zuerst die Default-Route gestalten, dann alternative Wege nur dort ergänzen, wo sie ein echtes Produkt- oder Geschäftsproblem lösen. Ein Consumer-MVP startet vielleicht mit den großen App Stores und starkem Web-Onboarding. Eine B2B-App nutzt Store-Distribution für Auffindbarkeit und führt bekannte Kunden über ein Kundenportal. Ein skaliertes digitales Serviceprodukt prüft Web Distribution und alternative Zahlungen erst, wenn Support und Operations die zusätzliche Verantwortung tragen können.
Das Ziel ist nicht, jede neue DMA-Option mitzunehmen. Das Ziel ist ein mobiles Produkt, das trotz offenerer Distribution verständlich bleibt: klare Installationswege, klare Zahlungszuständigkeit, ein Account-Modell, messbare Supportlast und genug technische Flexibilität, um die Kanalstrategie anzupassen, wenn Markt, Plattformregeln oder Produktmodell sich verändern.