A store-compliant mobile app with 50,000 installs in 8 weeks
A European gaming marketplace needed iOS and Android apps in a category where the stores do not allow in-app transactions. We built a native companion app that sends engaged, verified users back to the web platform.
The stores would not allow what the business sells
The marketplace earned its revenue on a regulated web platform and wanted a presence on phones too. App Store and Google Play rules for its category rule out direct in-app purchases and deposits, so a straight port of the web product would never pass review.
Two more problems sat underneath. The backend had inherited Kafka from earlier plans, which added cost and operational work the MVP did not need. And any app that hands out rewards attracts bots and multi-accounting, which a generic fraud tool handles badly in this category.
The brief: an iOS and Android app that passes store review, keeps users engaged without on-device transactions, and feeds preference data and verified accounts back to the web platform. It had to ship fast, run cheaply at MVP volume and reach the Year-1 install target without a rebuild.
A rejected app is no app
If the stores read the product as a transactional app, it would not launch at all. The mobile and web sides needed a clear contract about what each one does.
Paying for scale that wasn't there
Kafka suits multiple consumer groups and long retention. The MVP had session tasks, rewards and notifications, and was carrying the overhead anyway.
Bots eat the reward budget
Block too much and real users leave. Block too little and automated accounts drain the economics. The defence had to match this product's actual threat model.
Four decisions that let a restricted app pay its way
Keep transactions on the web
The app handles engagement, preference collection and account progression. Payments stay on the licensed web platform, and rewards sync to the web account in real time, so the premium reward tier unlocks only after a user links and verifies that account.
Remove Kafka instead of tuning it
The real workload was session task sync, reward distribution and notification fan-out. BullMQ on Redis covers that at a fraction of the operational footprint and kept every behaviour the system relied on. Removing infrastructure rarely comes up in a scale-up review. Here it was the right call.
Go native where responsiveness sells
Retention depended on fast, animated interactive surfaces, reliable push and hardware-level device signals. Cross-platform frameworks hit a ceiling there. SwiftUI and Jetpack Compose gave native performance at close to cross-platform development speed.
Build anti-abuse for this threat model
Behavioural signature monitoring, device attestation through Play Integrity and DeviceCheck, and proof-of-activity gates that cost a real user almost nothing and an automation script a lot. Each layer is tuned separately, so the defence changes without a redeploy.
May 2025 · Discovery
Stakeholder interviews, mobile/web contract.
June–July 2025 · Architecture and design
Kafka replaced with BullMQ on Redis, wireframes.
Aug–Dec 2025 · Core development
Backend, native apps, anti-abuse, analytics.
January 2026 · QA
Functional, security and cross-device testing.
February 2026 · Launch
Global rollout on both stores.
The companion model held as the product grew
Both store reviews passed without escalation, and the companion architecture has absorbed later product iteration without rework. Installs passed 50,000 in the first eight weeks, against a Year-1 target of 200K. MetaProject continues to support and evolve the apps.
Next on the roadmap: LogRocket session replay to diagnose friction and crashes, a stronger behavioural-signature layer for more sophisticated automation, and product changes driven by Year-1 usage data.
50,000+
installs in the first eight weeks
200K
Year-1 install target, on track
2 of 2
store reviews passed without escalation
3
anti-abuse layers running in production
50,000+
installs in the first eight weeks
~30%
less infrastructure overhead
99.9%
push notification delivery
60+ FPS
UI responsiveness on iOS and Android
3 layers
of anti-abuse, each tunable without redeploying
Native iOS and Android apps with boost games, a preference swipe engine and tiered reward wheels, a simplified Node.js backend, a layered anti-abuse system and real-time sync with the web platform.
Swift / SwiftUI · Kotlin / Jetpack Compose · Node.js + NestJS · BullMQ on Redis · PostgreSQL · GitLab GitOps · AWS Secrets Manager · Bitrise · Amplitude · OneSignal + CustomerIO · Grafana
Questions about this project
Why native rather than cross-platform for this app?
The decision rested on the performance ceiling. Cross-platform frameworks (Flutter, React Native) are a reasonable choice for many mobile products, and we'd recommend them for content-driven or form-based apps where development velocity matters more than rendering performance. For this engagement, the UI had to sustain 60+ FPS across interactive surfaces, integrate hardware-level device attestation, and deliver reliable background tasks. All three requirements lean toward native. SwiftUI and Jetpack Compose, both declarative, let us reach the performance bar without sacrificing the development velocity that usually justifies going cross-platform in the first place.
Why did you replace Kafka instead of optimising around it?
Because Kafka was solving a problem the MVP didn't have. Kafka's strengths (multiple consumer groups, long-retention durable logs, stream-processing workloads) weren't being used. The actual workload was session-based task queueing and notification fan-out, which BullMQ on Redis handles cleanly at a much lower operational cost. The right architectural call was simplification. Adding infrastructure feels like progress in a review; removing it is often the better engineering decision.
How do you protect a reward-driven mobile app from automated abuse?
A multi-layered defence: behavioural signature monitoring (pattern recognition over time), device-attestation signals (via Play Integrity API and DeviceCheck) that distinguish real devices from emulators or modified runtimes, and proof-of-activity gates that impose negligible friction on legitimate users but compound expensively against automation scripts. Each layer is independently tunable, so the team can respond to evolving abuse patterns without redeploying the architecture. Generic anti-fraud SaaS rarely fits this category well, because the tuning has to be specific to the product's actual threat model.
How do you ship a mobile app for a digital marketplace category that has strict store policies?
The compliant pattern is a companion-app architecture: the mobile experience focuses on engagement, preferences, and account management, while transactional flows stay on the web platform that is licensed for them. Done well, it gives the two surfaces a clearer split of responsibilities. The mobile and web sides need a well-designed contract for state synchronisation, identity, and notifications. That contract is most of the architectural work.
How do you build the right mobile tech stack for a high-load consumer app?
Focus on three things: concurrency model (Node.js + Redis + BullMQ handles thousands of simultaneous tasks at low latency), CI/CD discipline (Bitrise or similar for automated cross-device testing, so frequent updates can't introduce regressions), and observability tuned to mobile-specific failure modes (push delivery rates, crash-free sessions, regional latency). The stack choices follow from the workload, not from fashion.
See more cases
Does your mobile app have to live by someone else's store rules?
Tell us what you are building. We will come back with an honest view of how we would approach it.