Zum Inhalt springen

Fallstudie · Events & Ticketing · Mobile

Move2Armenia — native Events-, Buchungs- und Ticketing-App

Veröffentlicht · Aktualisiert · Von YuSMP Group Engineering

Wie wir Move2Armenia entwickelt haben — eine native iOS- und Android-App, um Events zu entdecken, einen Platz zu buchen und QR-Tickets in Eriwan und anderen armenischen Städten zu kaufen. Das Produkt bedient den armenischen Markt; entwickelt wurde es nach den Standards, die unsere US- und EU-Kundschaft erwartet, auf einem Symfony- und React-Backend mit vollständig nativen Mobile-Clients, die in den App Store und bei Google Play ausgeliefert wurden.

BrancheEvents & Ticketing · Mobile
Projektjahr2023
ZusammenarbeitFrontend- + Mobile-Lieferung
Move2Armenia Event-Feed auf iOS — Eventsuche, Datums- und Kategoriefilter, Redaktionsempfehlungen in Eriwan

Das Briefing — Eventsuche in eine Ein-Tipp-Buchung verwandeln

Das Produktteam von Move2Armenia wollte eine Events-App, die Neuankömmlingen und Einheimischen in Eriwan und anderen armenischen Städten hilft, etwas für heute Abend zu finden und es in einem einzigen Ablauf zu buchen — ohne Browser-Tab, ohne PDF-Ticket, ohne eine Veranstaltungsadresse in eine Karten-App zu kopieren. Die Messlatte setzte jene Art von US- und EU-Consumer-Apps, die das Publikum bereits auf seinen Telefonen hatte: ein schneller Event-Feed mit einer Redaktionsempfehlungs-Leiste, Kategorie- und Datumsfilter, die sich sofort anfühlen, eine Event-Detailseite, die „wo, wann, wie viel und ist es ausverkauft" beantwortet, und ein In-App-Ticket, das am Eingang auch bei wackeliger Verbindung funktioniert. Der Kunde brachte eine bestehende Backend-Grundlage mit; wir verantworteten das React-Frontend sowie die nativen iOS- und Android-Clients und wurden von YuSMP Group gerade deshalb hinzugezogen, weil das Team diese Klasse von Consumer-Produkten zuvor schon ausgeliefert hatte. Das Ergebnis ist eine native App, live im App Store und bei Google Play, gebaut nach den Engineering- und Datenschutzstandards, die unsere US- und EU-Kunden erwarten — auch wenn der eigene Markt des Produkts Armenien ist.

Projekt-Highlights

Natives iOS (Swift) Natives Android (Kotlin) Symfony / PHP Backend React Web-Frontend Event-Feed + Redaktionsempfehlungen Kategorie- & Datumsfilter In-App-Buchung + QR-Tickets Live im App Store + bei Google Play

In Zahlen

Ein Überblick darüber, was die Move2Armenia-Entwicklung über iOS, Android und ein Symfony-Backend im ersten Produktionszyklus geliefert hat. Die Angaben sind Liefer-Fakten und typische Bandbreiten, keine kundenvertraulichen Kennzahlen.

2native Plattformen — iOS in Swift und Android in Kotlin, getrennte Codebasen, pro Plattform abgestimmt
3Onboarding-Sprachen — Armenisch, Englisch und Russisch, beim ersten Start auswählbar
1universelles QR-Ticket, das den Einlass am Veranstaltungseingang validiert, offline-renderbar
2Filterachsen im Feed — Kategorie und Datum — beide ohne blockierenden Roundtrip
2App-Stores live — Apple App Store und Google Play über die Storefronts des Produkts hinweg
12–20 Wo.typischer Lieferzeitraum für ein vergleichbares Events- & Ticketing-MVP in beiden Stores
Move2Armenia Suchergebnisse — Kategorie- und Datumsfilter, Ausverkauft-Badges, Veranstaltungsort-Labels für Events in Eriwan

Warum native iOS- und Android-Entwicklung statt Cross-Plattform und reinem Web

Die Plattformentscheidung prägt jede weitere Wahl in einer Consumer-Events-App. Wir haben Move2Armenia als natives iOS in Swift und natives Android in Kotlin gebaut, mit einem gemeinsamen Symfony-Backend und einem React-Web-Frontend, statt einer einzigen Cross-Plattform-Hülle. Eine Events-App leistet ihre wichtigste Arbeit am Veranstaltungseingang, wo sie auf Kamera, Wallet, Push-Benachrichtigungen und ein QR-Ticket angewiesen ist, das auch ohne Signal angezeigt werden muss. Native Clients bieten vorhersehbaren Zugriff auf diese Fähigkeiten, butterweiches Scrollen in langen Feeds und einen Anzeigepfad für das Ticket, der nicht davon abhängt, dass eine WebView eine tote Verbindung übersteht. Der Kompromiss — zwei Codebasen statt einer — wird dadurch ausgeglichen, dass die gesamte Buchungs-, Bestands- und Preislogik im Symfony-Backend bleibt, sodass die Clients schlank bleiben.

Reines Web wurde früh ausgeschlossen: Ein Browser-Tab kann an einem Eingang kein zuverlässig scannbares Ticket halten, und Push-Erinnerungen wie „Dein Event beginnt in einer Stunde" sind die Engagement-Schleife, von der das Produkt abhängt. Eine Cross-Plattform-Hülle war eine knappere Abwägung, doch der lange, bildlastige Event-Feed und die Offline-Ticket-Anforderung führten uns für beide Stores zu nativer Entwicklung. Es ist dieselbe Balance, die wir in unserer Mobile App-Entwicklung für US- und EU-Kunden empfehlen, die Consumer-Apps in den App Store und bei Google Play ausliefern.

Natives iOS + Android vs. Cross-Plattform vs. reines Web — für eine Events- & Ticketing-App
Dimension Nativ (Move2Armenia) Cross-Plattform-Hülle Reines Web / PWA
Offline-QR-Ticket am EingangZuverlässig — gecacht, rendert ohne SignalMeist in Ordnung; bridge-abhängigFragil — Tab-Verdrängung, kein Signal bricht es
Push-ErinnerungenErstklassig über APNs / FCMÜber Plugins unterstütztBegrenzt, besonders auf iOS
Scroll-Performance bei langem FeedNatives Listen-Recycling — flüssigGut mit FeinabstimmungRuckelig auf Low-End-Geräten
Kamera- / Wallet-ZugriffDirekte Plattform-APIsPlugin-vermitteltDurch Browser eingeschränkt
Gemeinsame GeschäftslogikZentralisiert im Symfony-BackendGemeinsame UI + BackendNur Backend
Präsenz im App Store / bei PlayErstklassige Store-AppsStore-Apps über WrapperKein nativer Store-Eintrag
Feinschliff pro PlattformVollständig — Swift- / Kotlin-IdiomeAuf kleinsten gemeinsamen Nenner reduziertBrowser-gebunden

Plattform-Referenzen: Apple Swift-Dokumentation, Android Kotlin-Leitfäden, Symfony-Dokumentation.

Move2Armenia Event-Detailansicht — Altersfreigabe, besondere Bedingungen, Datum und Uhrzeit, Kosten, Veranstaltungsort und Buchen-CTA

iOS-Build — Swift, der Event-Feed und der Buchungsablauf

Der iOS-Client ist in Swift gebaut, mit einem Startbildschirm, der um einen schnellen Event-Feed organisiert ist: ein Suchfeld, eine horizontale Datumsleiste, ein Kategorie-Dropdown und Tag-Chips, gefolgt von einer Redaktionsempfehlungs-Leiste und einem Bereich „Für dich empfohlen", der von den beim Onboarding gewählten Interessen gespeist wird. Das Filtern ist so gestaltet, dass es sich sofort anfühlt — Kategorie und Datum grenzen den Feed zunächst gegen lokal gecachte Ergebnisse ein und gleichen sich dann im Hintergrund mit dem Backend ab, sodass die Liste nie weiß aufblinkt, während eine Anfrage unterwegs ist. Event-Karten tragen ein Veranstaltungsort-Label und ein Ausverkauft-Badge, sodass der Nutzer auf einen Blick triagieren kann, bevor er hineintippt.

Die Event-Detailseite ist der Ort, an dem aus Entdeckung Absicht wird: Sie beantwortet Altersbeschränkungen, besondere Bedingungen, Datum und ungefähre Uhrzeit, Kosten und Veranstaltungsort und verdichtet die Entscheidung dann zu einer einzigen Buchen-Aktion. Der Buchungsablauf übergibt an das Symfony-Backend, das den Bestand reserviert und die Zahlung verarbeitet, bevor das Ticket ausgestellt wird. Dieselben Screens sind Teil des iOS- und Android-Engineerings, das wir für US- und EU-Kunden betreiben, wobei die iOS- und Android-Builds im Gleichschritt geführt werden, sodass ein Feature im selben Release-Zug in beiden Stores landet, statt auseinanderzudriften.

Move2Armenia universelles QR-Ticket — scannbare ID, die dem Veranstaltungspersonal zur Einlasskontrolle vorgezeigt wird, offline-renderbar

Android-Build — Kotlin, QR-Tickets und der persönliche Kalender

Der Android-Client ist in Kotlin geschrieben und trägt denselben Funktionsumfang wie iOS: Feed, Suche, Filter, Event-Detailansicht, Buchung und das universelle QR-Ticket. Nach einer erfolgreichen Buchung stellt die App ein einzelnes scannbares Ticket aus — einen QR-Code, der an eine undurchsichtige Ticket-ID plus den Namen des Besuchers gebunden ist —, das der Nutzer dem Personal am Eingang vorzeigt. Das Ticket wird aus zwischengespeicherten Daten gerendert, sodass es auch dann angezeigt wird, wenn die Konnektivität am Veranstaltungsort schlecht ist, und das Backend verfolgt den Einlösestatus, sodass ein Ticket nach dem Einscannen nicht erneut verwendet werden kann.

Der persönliche Kalender zieht die gebuchten Events des Nutzers in eine „Meine Events"-Ansicht, nach Datum gruppiert und mit Erinnerungen, sodass die App zum einzigen Ort wird, um zu verwalten, was man in dieser Woche besucht. Die beim Onboarding gewählten Interessen speisen sowohl die Empfehlungsleiste als auch eine Stadteinstellung (Eriwan standardmäßig), die den Feed eingrenzt. All dies wird durch die Symfony-Steuerebene über unsere Individuelle Softwareentwicklung gestützt, wobei die Buchungs-, Bestands- und Erstattungsregeln serverseitig gehalten werden, damit beide nativen Clients schlank und konsistent bleiben.

Move2Armenia mehrsprachiges Onboarding — Sprachauswahl Armenisch, Englisch und Russisch beim ersten Start

Architektur, Lokalisierung und eine prüfungssichere Datenschutzhaltung

Das Backend ist ein Symfony- / PHP-Dienst, der den Eventkatalog, die Buchungs- und Bestandslogik, die Zahlungs- und Erstattungsabläufe sowie die Ticket-Ausstellung und -Einlösung verantwortet; ein React-Web-Frontend teilt sich diese API-Oberfläche, und die beiden nativen Clients nutzen dieselben Endpunkte. Die Lokalisierung ist erstklassig: Der erste Bildschirm, den ein Nutzer sieht, ist eine Sprachauswahl — Armenisch, Englisch oder Russisch —, und die Wahl wirkt sich auf Feed, Event-Detailansicht und Ticket aus. Indem die Buchungs- und Erstattungsregeln serverseitig bleiben, kann die App eine Richtlinie ändern, ohne ein neues Binary an einen der beiden Stores auszuliefern.

Obwohl das Produkt den armenischen Markt bedient, haben wir das Datenmodell nach den Datenschutzstandards entwickelt, die unsere US- und EU-Kundschaft erwartet. Personenbezogene Daten werden minimiert, Ticket-Kennungen sind undurchsichtig statt während der Übertragung an eine E-Mail oder ein Konto-Handle gebunden, und Einwilligungs- und Löschpfade sind so gefasst, dass dieselbe Codebasis konfiguriert werden kann, um DSGVO-Pflichten für die Europäische Union und CCPA / CPRA-Pflichten für die Vereinigten Staaten zu erfüllen, wenn dasselbe Engineering für einen US- und EU-Launch wiederverwendet wird. So bleibt eine künftige unabhängige Datenschutzprüfung eine Dokumentationsübung statt einer architektonischen Nachrüstung.

Compliance-Haltung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.

Liefermethodik

Eine fünfphasige Agile-Entwicklung, die Move2Armenia von der Produktspezifikation bis zur Produktion über iOS, Android und ein Symfony-Backend brachte, wobei Discovery- und Analysearbeit vorgelagert wurde, um Änderungen mitten in der Entwicklung zu reduzieren.

Phase 1

Discovery & Analyse

Klärung der Buchungsregeln, der Erstattungsrichtlinie, des Ticket-Validierungsablaufs und des Feed-/Filtermodells vorab. Dieser vorgelagerte Analysedurchlauf ist der wirksamste Hebel, um den Zeitplan für US- und EU-Stakeholder vorhersehbar zu halten.

Phase 2

Architektur & API-Vertrag

Definition des Symfony-Backend-Vertrags für Katalog, Buchung, Bestand, Zahlung, Erstattungen und Ticket-Ausstellung; Festlegung der gemeinsamen API, die das React-Web-Frontend und beide nativen Clients nutzen.

Phase 3

Plattform-Builds

Swift-iOS-Client und Kotlin-Android-Client im Gleichschritt gebaut — Feed, Suche, Kategorie- und Datumsfilter, Event-Detailansicht, In-App-Buchung, QR-Ticket und der persönliche Eventkalender.

Phase 4

Lokalisierung & QA

Armenische, englische und russische Lokalisierung über jede Oberfläche; QA für Buchung, Zahlung, Erstattung und Ticket-Einlösung; Offline-Ticket-Render-Tests für das Eingangsszenario.

Phase 5

Launch & Iteration

Einreichung im App Store und bei Google Play, Kalibrierung der Store-Einträge sowie eine Roadmap mit Sitzplatzauswahl über Veranstaltungspläne, Push-Benachrichtigungen und reichhaltigeren Veranstalterdetails.

Buchung, Bestand und das Erstattungs-Subsystem

Die Monetarisierungsebene von Move2Armenia wurde so gebaut, dass eine einzige Quelle der Wahrheit jeden Platz steuert. Das Symfony-Backend hält den Eventkatalog und das Bestandsbuch; wenn ein Nutzer auf Buchen tippt, reserviert das Backend den Platz, führt die Zahlung aus und stellt erst dann ein Ticket aus, das an eine undurchsichtige Ticket-ID gebunden ist. Weil der Bestand serverseitig liegt, gelten dieselben Regeln identisch über den iOS-Client, den Android-Client und das React-Web-Frontend — es gibt keinen Weg, über den ein Client ein Event überbuchen könnte. Erstattungen laufen durch dasselbe Buch: Eine Erstattung gibt Bestand an den Pool zurück und entwertet das Ticket, sodass ein erstatteter QR-Code am Eingang nicht mehr eingelöst werden kann. Das gesamte Subsystem wurde auf Erweiterbarkeit ausgelegt — das Hinzufügen von Sitzplatzauswahl über Veranstaltungspläne, von veranstalterverwalteten Kontingenten oder eines mehrstädtischen Preismodells ist eine Konfigurations- und Backend-Änderung statt einer Neuentwicklung der Mobile-Clients, was die Roadmap nach dem Launch genau deshalb günstig in der Umsetzung hielt und das Muster ist, das wir für Events- und Commerce-Produkte über unsere US- und EU-Kundschaft hinweg wiederverwenden.

Engineering für eine US- und EU-Kundschaft

Der eigene Markt von Move2Armenia ist Armenien — die Events, Veranstaltungsorte und Städte sind lokal in Eriwan und darüber hinaus. Unsere Zusammenarbeit wurde dagegen nach dem Standard geführt, den unsere US- und EU-Kunden erwarten, und der Build war so strukturiert, dass derselbe Stack einen Launch in den Vereinigten Staaten oder der Europäischen Union ohne Neuentwicklung tragen könnte. Wenn wir diese Architektur für ein US- und EU-Events-Produkt wiederverwenden, ist der englischsprachige Build bereit, Nutzer in Kalifornien, New York, Texas, Florida und Washington in den USA sowie in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU aus einer Codebasis zu bedienen. Die Datenverarbeitungspraktiken sind darauf ausgelegt, mit der DSGVO für europäische Nutzer und mit dem US-Bundesstaaten-Datenschutz-Flickwerk übereinzustimmen — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA —, sodass der Wechsel von einem Markt zu vielen eine Konfigurationsübung ist und keine architektonische.

Weil die Buchungs- und Ticketing-Logik im Symfony-Backend zentralisiert ist und personenbezogene Daten von Grund auf minimiert werden, reduziert sich die regionale Compliance auf ehrliche Offenlegung und Einwilligung pro Rechtsraum, statt einen separaten Build pro Region zu pflegen. Das Team hinter der Entwicklung sitzt in der MEZ und arbeitet einen MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, die Choreografie der Store-Prüfungen und die Reaktion auf Vorfälle — das Zeitzonenfenster, das einem US-Produktteam und einem EU-Engineering-Team vier Stunden Live-Überlappung pro Tag ermöglicht. Wir dokumentieren die Datenverarbeitung direkt gegen DSGVO-Pflichten und CCPA-Pflichten in Kalifornien, sodass ein US- und EU-Rollout von einer verteidigbaren Haltung aus startet.

Tech-Stack und Roadmap

Swift SwiftUI Kotlin Jetpack Compose React TypeScript PHP Symfony PostgreSQL Redis REST API APNs / FCM Push QR-Ticketing Stripe-artige Zahlungen Docker CI / CD App Store Google Play

Die aktive Roadmap der Individuellen Softwareentwicklung für Move2Armenia umfasst einen verfeinerten Registrierungsablauf, Sitzplatzauswahl über interaktive Veranstaltungspläne, Push-Benachrichtigungen für bevorstehende und empfohlene Events sowie reichhaltigere Veranstaltungsort- und Veranstalterprofile. Auf der Plattformseite sind eine tiefere Empfehlungslogik gegen den Interessensgraphen des Nutzers und weitere armenische Städte geplant, wobei das Buchungs- und Bestands-Subsystem bereits für mehrere Städte und veranstalterverwaltete Kontingente strukturiert ist. Die Infrastruktur-Roadmap — Observability, Deployment-Automatisierung und ein Pfad zu einem US- und EU-Rollout desselben Stacks — ist in unsere Cloud & DevOps-Praxis eingebettet, sodass die Skalierung des Produkts eine operative Änderung statt einer Re-Architektur ist.

Eine Events- & Ticketing-App wie diese entwickeln — sprechen Sie mit uns

Wenn Sie eine Events-Plattform, ein Buchungsprodukt oder eine beliebige Mobile-App planen, bei der die In-App-Zahlung und ein Ticket, das am Eingang funktionieren muss, zentral sind — für ein Publikum in den USA und der EU —, haben wir diesen Stack durchgängig ausgeliefert und können den Build-Zeitplan spürbar verkürzen. Das Live-Produkt ist unter move2.am auf iOS und Android verfügbar, und das Engineering-Team dahinter sitzt innerhalb von YuSMP Group. Wir arbeiten zum Festpreis für gut abgegrenzte MVPs und mit Dedizierten Entwicklerteams für die laufende Lieferung, mit einem MEZ-Arbeitstag und einem garantierten Fenster der Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und die Reaktion auf Vorfälle.

Discovery-Call vereinbaren Mobile App-Entwicklung ansehen

Häufig gestellte Fragen

Was kostet die Entwicklung einer Events- und Ticketing-App wie dieser?

Ein Events- und Ticketing-MVP, das native iOS- und Android-Clients mit Event-Feed, Suche, Kategorie- und Datumsfiltern, Event-Detailansicht, In-App-Buchung und QR-Ticket-Ausgabe abdeckt, kostet typischerweise 90.000–220.000 $. Sitzplatzauswahl mit Veranstaltungsplänen, Erstattungen, Push-Benachrichtigungen, Veranstalter-Dashboards und Mehrsprachigkeit bringen ein voll ausgestattetes Produkt auf 250.000–500.000 $. Die dominierenden Kostentreiber sind die Buchungs- und Bestandslogik, die Zahlungs- und Erstattungsabläufe sowie die nativen iOS- und Android-Builds, die über alle Releases hinweg im Gleichschritt gehalten werden.

Warum native iOS- und Android-Entwicklung statt einer Cross-Plattform- oder reinen Web-Events-App?

Eine Events- und Ticketing-App lebt in der Hosentasche des Nutzers am Eingang der Veranstaltung und beansprucht daher stark Kamera, Wallet, Push und die Offline-Anzeige des Tickets. Natives iOS in Swift und natives Android in Kotlin bieten vorhersehbaren Zugriff auf diese Plattformfunktionen, flüssiges Scrollen in langen Event-Feeds und zuverlässiges QR-Rendering selbst ohne Signal am Eingang. Ein gemeinsames React- und Symfony-Backend hält die Geschäftslogik an einem Ort, während jeder Client vollständig nativ bleibt — genau die Balance, die Move2Armenia für eine US- und EU-Kundschaft mit Auslieferung in beide Stores benötigte.

Wie funktionieren die In-App-Eventbuchung und das QR-Ticketing?

Ein Nutzer öffnet ein Event, sieht Altersfreigabe, Zeitplan, Veranstaltungsort und Preis und tippt dann auf Buchen. Das Symfony-Backend reserviert den Bestand, verarbeitet die Zahlung und stellt ein Ticket aus, das an eine undurchsichtige Ticket-ID gebunden ist. Der Mobile-Client rendert diese ID als universelles QR-Ticket, das der Nutzer am Eingang vorzeigt, wo das Personal es zur Einlasskontrolle scannt. Tickets werden aus zwischengespeicherten Daten gerendert, sodass sie auch offline angezeigt werden, und das Backend verfolgt den Einlösestatus, sodass ein einzelnes Ticket nach dem Scannen nicht erneut verwendet werden kann.

Wie lange dauert es, eine Events-App für iOS und Android auszuliefern?

Ein fokussiertes MVP mit Event-Feed, Suche, Filtern, Event-Detailansicht, Buchung und QR-Ticketing in beiden Stores dauert typischerweise 12–20 Wochen. Sitzplatzauswahl mit Veranstaltungsplänen, Erstattungen, Veranstalter-Tools, Push-Benachrichtigungen und Mehrsprachigkeit kommen 6–12 Wochen hinzu. Vorgelagerte Discovery- und Analysearbeit — die Klärung der Buchungsregeln, der Erstattungsrichtlinie und des Ticket-Validierungsablaufs, bevor der Code beginnt — ist der wirksamste Hebel, um den Zeitplan vorhersehbar zu halten und Änderungen mitten in der Entwicklung zu reduzieren.

Kann eine Events- und Ticketing-App die US- und EU-Datenschutzanforderungen erfüllen?

Ja. Auch wenn Move2Armenia den armenischen Markt bedient, richten sich unsere Entwicklungspraktiken auf eine US- und EU-Kundschaft aus, sodass das Datenmodell von Tag eins an für die DSGVO in der Europäischen Union und das CCPA-/CPRA-Flickwerk in den Vereinigten Staaten strukturiert ist. Personenbezogene Daten werden minimiert, Ticket-IDs sind undurchsichtig, und Einwilligungs- und Löschabläufe sind so gefasst, dass dieselbe Codebasis pro Rechtsraum konfiguriert werden kann, ohne dass ein separater Build pro Region erforderlich ist.

Diesen Fall teilen

LinkedIn X

Eine ähnliche Lösung planen

Discovery-Call vereinbaren