Discovery & analytics
Clarify booking rules, refund policy, ticket-validation flow, and the feed/filter model up front. This front-loaded analytics pass is the single best lever for keeping the timeline predictable for US and EU stakeholders.
Case study · Events & Ticketing · Mobile
Move2Armenia — native events, booking, and ticketing app
How we built Move2Armenia — a native iOS and Android app for discovering events, booking a spot, and buying QR tickets across Yerevan and other Armenian cities. The product serves the Armenian market; the build was engineered to the standards our US and EU client base expects, on a Symfony and React backend with fully native mobile clients shipped to the App Store and Google Play.
The brief — turn event discovery into a one-tap booking
The Move2Armenia product team wanted an events app that helped newcomers and locals in Yerevan and other Armenian cities find something to do tonight and book it in a single flow — no browser tab, no PDF ticket, no copy-pasting a venue address into a maps app. The acceptance bar was set by the kind of US and EU consumer apps the audience already had on their phones: a fast event feed with an editor's choice rail, category and date filters that feel instant, an event detail page that answers "where, when, how much, and is it sold out," and an in-app ticket that works at the door even on a flaky connection. The client brought an existing backend foundation; we owned the React frontend and the native iOS and Android clients and were brought in by YuSMP Group precisely because the team had shipped this class of consumer product before. The result is a native app, live on the App Store and Google Play, built to the engineering and privacy standards our US and EU clients expect even though the product's own market is Armenia.
Project highlights
Native iOS (Swift)
Native Android (Kotlin)
Symfony / PHP backend
React web frontend
Event feed + editor's choice
Category & date filters
In-app booking + QR tickets
App Store + Google Play live
By the numbers
A snapshot of what the Move2Armenia build delivered across iOS, Android, and a Symfony backend in its first production cycle. Figures are delivery facts and typical ranges, not client-confidential metrics.
2native platforms — iOS in Swift and Android in Kotlin, separate codebases tuned per platform
3onboarding languages — Armenian, English, and Russian selected on first launch
1universal QR ticket that validates entry at the venue door, offline-renderable
2filter axes on the feed — category and date — both resolving without a blocking round-trip
2app stores live — Apple App Store and Google Play across the product's storefronts
12–20 wktypical delivery window for a comparable events & ticketing MVP on both stores
Why native iOS and Android over cross-platform and web-only
The platform decision shapes every other choice in a consumer events app. We built Move2Armenia as native iOS in Swift and native Android in Kotlin, with a shared Symfony backend and a React web frontend, rather than a single cross-platform shell. An events app does its most important work at the venue door, where it leans on the camera, the wallet, push notifications, and a QR ticket that must render even with no signal. Native clients give predictable access to those capabilities, buttery list scrolling on long feeds, and a ticket display path that does not depend on a webview surviving a dead connection. The trade-off — two codebases instead of one — is offset by keeping all booking, inventory, and pricing logic in the Symfony backend so the clients stay thin.
Web-only was eliminated early: a browser tab cannot hold a scannable ticket reliably at an entrance, and push reminders for "your event starts in an hour" are the engagement loop the product depends on. A cross-platform shell was a closer call, but the long, image-heavy event feed and the offline-ticket requirement pushed us to native for both stores. This is the same balance we recommend across our mobile app development practice for US and EU clients shipping consumer apps to both the App Store and Google Play.
| Dimension | Native (Move2Armenia) | Cross-platform shell | Web-only / PWA |
|---|---|---|---|
| Offline QR ticket at the door | Reliable — cached, renders with no signal | Usually fine; bridge-dependent | Fragile — tab eviction, no signal breaks it |
| Push reminders | First-class APNs / FCM | Supported via plugins | Limited, especially on iOS |
| Long feed scroll performance | Native list recycling — smooth | Good with tuning | Janky on low-end devices |
| Camera / wallet access | Direct platform APIs | Plugin-mediated | Constrained by browser |
| Shared business logic | Centralized in Symfony backend | Shared UI + backend | Backend only |
| App Store / Play presence | First-class store apps | Store apps via wrapper | No native store listing |
| Per-platform polish | Full — Swift / Kotlin idioms | Compromised to lowest common denominator | Browser-bound |
Platform references: Apple Swift documentation, Android Kotlin guides, Symfony documentation.
iOS build — Swift, the events feed, and the booking flow
The iOS client is built in Swift, with the home screen organized around a fast event feed: a search field, a horizontal date strip, a category dropdown, and tag chips, followed by an editor's choice rail and a "recommended for you" section driven by the interests a user picks during onboarding. Filtering is designed to feel instant — category and date narrow the feed against locally cached results first, then reconcile with the backend in the background, so the list never blinks white while a request is in flight. Event cards carry a venue label and a sold-out badge so the user can triage at a glance before tapping in.
The event detail page is where discovery turns into intent: it answers age restrictions, special conditions, date and approximate time, cost, and venue, then collapses the decision into a single book action. The booking flow hands off to the Symfony backend, which reserves inventory and processes payment before issuing the ticket. The same screens are part of the iOS and Android engineering we run for US and EU clients, with the iOS and Android builds carried in lockstep so a feature lands on both stores in the same release train rather than drifting apart.
Android build — Kotlin, QR tickets, and the personal calendar
The Android client is written in Kotlin and carries the same feature surface as iOS: feed, search, filters, event detail, booking, and the universal QR ticket. After a successful booking the app issues a single scannable ticket — a QR code tied to an opaque ticket ID plus the attendee name — that the user shows to staff at the door. The ticket renders from cached data, so it displays even when the venue's connectivity is poor, and the backend tracks redemption state so a ticket cannot be reused once it has been scanned in.
The personal calendar pulls the user's booked events into a "my events" view, grouped by date with reminders, so the app becomes the single place to manage what you are attending this week. The interests a user selects at onboarding feed both the recommendation rail and a city setting (Yerevan by default) that scopes the feed. All of this is backed by the Symfony control layer through our custom software development practice, with the booking, inventory, and refund rules kept server-side so both native clients stay thin and consistent.
Architecture, localization, and a privacy posture built for audit
The backend is a Symfony / PHP service that owns the event catalog, booking and inventory logic, payment and refund flows, and ticket issuance and redemption; a React web frontend shares that API surface, and the two native clients consume the same endpoints. Localization is first-class: the first screen a user sees is a language picker — Armenian, English, or Russian — and the choice propagates through the feed, event detail, and ticket. Keeping the booking and refund rules server-side means the app can change a policy without shipping a new binary to either store.
Although the product serves the Armenian market, we engineered the data model to the privacy standards our US and EU client base expects. Personal data is minimized, ticket identifiers are opaque rather than tied to an email or account handle in transit, and consent and deletion paths are scoped so the same codebase can be configured to satisfy GDPR obligations for the European Union and CCPA / CPRA obligations for the United States when the same engineering is reused for a US and EU launch. This keeps a future independent privacy review a documentation exercise rather than an architectural retrofit.
Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.
Delivery methodology
A five-phase Agile build that took Move2Armenia from product specification to production across iOS, Android, and a Symfony backend, with discovery and analytics work front-loaded to reduce mid-build revisions.
Architecture & API contract
Define the Symfony backend contract for catalog, booking, inventory, payment, refunds, and ticket issuance; agree the shared API the React web frontend and both native clients consume.
Platform builds
Swift iOS client and Kotlin Android client built in lockstep — feed, search, category and date filters, event detail, in-app booking, QR ticket, and the personal events calendar.
Localization & QA
Armenian, English, and Russian localization across every surface; booking, payment, refund, and ticket-redemption QA; offline ticket-render testing for the venue-door scenario.
Launch & iteration
App Store and Google Play submission, store-listing calibration, and a roadmap of seat selection with venue maps, push notifications, and richer organizer detail.
Booking, inventory, and the refund subsystem
Move2Armenia's monetization layer was built so a single source of truth governs every seat. The Symfony backend holds the event catalog and the inventory ledger; when a user taps to book, the backend reserves the spot, runs the payment, and only then issues a ticket bound to an opaque ticket ID. Because inventory lives server-side, the same rules apply identically across the iOS client, the Android client, and the React web frontend — there is no path for a client to oversell an event. Refunds run through the same ledger: a refund releases inventory back to the pool and invalidates the ticket so a refunded QR can no longer be redeemed at the door. The whole subsystem was designed for extension — adding seat selection with venue maps, organizer-managed allotments, or a multi-city pricing model is a configuration and backend change rather than a rewrite of the mobile clients, which is exactly what kept the post-launch roadmap cheap to execute and is the pattern we reuse for events and commerce products across our US and EU client base.
Engineering for a US and EU client base
Move2Armenia's own market is Armenia — the events, venues, and cities are local to Yerevan and beyond. Our engagement, by contrast, was run to the standard our US and EU clients expect, and the build was structured so the same stack could power a launch in the United States or the European Union without a rewrite. When we reuse this architecture for a US and EU events product, the English-language build is ready to serve users in California, New York, Texas, Florida, and Washington in the US, and in the Netherlands, Germany, France, Ireland, and Sweden in the EU, from one codebase. Data-handling practices are designed to align with GDPR for European users and with the US state-privacy patchwork — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA — so the move from one market to many is a configuration exercise, not an architectural one.
Because the booking and ticketing logic is centralized in the Symfony backend and personal data is minimized by design, regional compliance reduces to honest disclosure and per-jurisdiction consent rather than maintaining a separate build per region. The team behind the build sits across CET and runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, store-review choreography, and incident response — the timezone window that lets a US product team and an EU engineering team share four hours of live overlap every day. We document data handling directly against GDPR obligations and California CCPA obligations so a US and EU rollout starts from a defensible posture.
Tech stack and roadmap
Swift
SwiftUI
Kotlin
Jetpack Compose
React
TypeScript
PHP
Symfony
PostgreSQL
Redis
REST API
APNs / FCM push
QR ticketing
Stripe-style payments
Docker
CI / CD
App Store
Google Play
The active custom software development roadmap for Move2Armenia includes a refined registration flow, seat selection driven by interactive venue maps, push notifications for upcoming and recommended events, and richer venue and organizer profiles. On the platform side, deeper recommendation logic against the user's interest graph and additional Armenian cities are planned, with the booking and inventory subsystem already structured for multi-city and organizer-managed allotments. The infrastructure roadmap — observability, deployment automation, and a path to a US and EU rollout of the same stack — is scaffolded into our cloud & DevOps practice so scaling the product is an operational change rather than a re-architecture.
Build an events & ticketing app like this — talk to us
If you are planning an events platform, a booking product, or any mobile app where in-app payment and a ticket that has to work at the door are central — for audiences in the US and EU — we have shipped this stack end-to-end and can compress the build timeline meaningfully. The live product is available at move2.am on iOS and Android, and the engineering team behind it sits inside YuSMP Group. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.
Frequently asked questions
How much does it cost to build an events and ticketing app like this?
An events and ticketing MVP covering native iOS and Android clients with an events feed, search, category and date filters, event detail, in-app booking, and QR ticket issuance typically costs $90k–$220k. Adding seat selection with venue maps, refunds, push notifications, organizer dashboards, and multi-language support brings a full-featured product to $250k–$500k. The dominant cost drivers are the booking and inventory logic, payment and refund flows, and the native iOS and Android builds kept in lockstep across releases.
Why build native iOS and Android instead of a cross-platform or web-only events app?
An events and ticketing app lives in the user's pocket at the venue door, so it leans hard on camera, wallet, push, and offline ticket display. Native iOS in Swift and native Android in Kotlin give predictable access to those platform capabilities, smooth list scrolling on long event feeds, and reliable QR rendering even with no signal at the entrance. A shared React and Symfony backend keeps business logic in one place while each client stays fully native, which is the balance Move2Armenia needed for a US and EU client base shipping to both stores.
How does in-app event booking and QR ticketing work?
A user opens an event, sees the age rating, schedule, venue, and price, then taps to book. The Symfony backend reserves inventory, processes payment, and issues a ticket tied to an opaque ticket ID. The mobile client renders that ID as a QR universal ticket the user shows at the door, where staff scan it to validate entry. Tickets render from cached data so they display even offline, and the backend tracks redemption state so a single ticket cannot be reused once scanned.
How long does it take to ship an events app on iOS and Android?
A focused MVP with an events feed, search, filters, event detail, booking, and QR ticketing on both stores typically takes 12–20 weeks. Adding seat selection with venue maps, refunds, organizer tooling, push notifications, and multi-language support adds 6–12 weeks. Up-front discovery and analytics work — clarifying the booking rules, refund policy, and ticket-validation flow before code starts — is the single best lever for keeping the timeline predictable and reducing mid-build revisions.
Can an events and ticketing app meet US and EU privacy requirements?
Yes. Even though Move2Armenia serves the Armenian market, our build practices target a US and EU client base, so the data model is structured for GDPR in the European Union and the CCPA / CPRA patchwork in the United States from day one. Personal data is minimized, ticket IDs are opaque, and consent and deletion flows are scoped so the same codebase can be configured per jurisdiction without a separate build per region.
Related cases
More consumer & booking platform builds
Rental · Booking
Light Rent
A booking and rental platform with availability, scheduling, and payment built for a US & EU client base.
View case → Leisure · BookingMakeWake
A consumer leisure-booking app with slot reservations, payments, and native iOS and Android clients.
View case → Mobility · ConsumerScooter Sharing
A mobility app with map discovery, in-app payment, and real-time vehicle state across US & EU.
View case →Related services
Mobile App Development
Native iOS, Android, and cross-platform apps with store-ready release pipelines.
Explore mobile app development →
Custom Software Development
Custom platforms engineered to your business model, scaling cleanly from MVP to millions of users.
Explore custom software development →
Cloud & DevOps
Deployment automation, observability, and scalable infrastructure for consumer products.
Explore cloud & DevOps →