Case study · Social Media · Consumer Tech

Building JoyJet: a Social Platform with Geo-Radar, Real-Time Chat, and a Virtual Economy for iOS and Android

Published Sep 9, 2025 · Updated Sep 9, 2025 · By YuSMP Group Engineering

How we shipped a production social platform — App Store and Google Play, live across the US, the EU, and beyond — combining an interest-curated content feed, a geo-proximity Radar for people discovery, encrypted messaging, and a full virtual economy of coins, gifts, and premium subscriptions.

IndustrySocial Media · Consumer Tech

Project year2022–present

EngagementFixed price + ongoing feature delivery

App Store Google Play joy-jet.com

JoyJet social platform — Radar geo-discovery screen on iOS

The brief — a social platform that does more than a feed

The JoyJet product team wanted a social platform that went further than a photo-video feed. The core insight was that discovery — finding interesting people, not just content — was underserved by existing social apps. Off-the-shelf social SDKs and white-label community platforms offered feeds and messaging but had no framework for real-time geo-proximity matching, and none of them supported a layered virtual economy that could reward both creators and engaged community members. We built JoyJet from first principles as a native iOS and Android application: a content platform with an interest-curated feed, a Radar that surfaces nearby people matching your interests, fast encrypted messaging, Stories, and a JJPremium subscription tier backed by a coin-and-gifts marketplace. The result is a social product that ships to App Store and Google Play, available in English, Russian, Spanish, and Traditional Chinese for audiences across the United States, the European Union, and beyond.

Project highlights

Interest-curated content feed Geo-proximity Radar discovery Real-time encrypted messaging Stories & JJVideo JJPremium subscription Virtual coins, gifts & marketplace JJFans creator economy App Store + Google Play live · 4 languages

By the numbers

A snapshot of what the JoyJet build delivered across iOS and Android in its first production cycle.

2native platforms — iOS and Android, fully separate codebases optimized per platform

4content types — Videos, Photos, Stories, and JJLikes with interest-based feed ranking

4languages at launch — English, Russian, Spanish, and Traditional Chinese

<100mstypical message delivery via WebSocket persistent connection on mobile LTE and Wi-Fi

20+distinct UI screens covering feed, Radar, chat, profile, premium, market, and onboarding

16–24 wktypical delivery window for a comparable social platform MVP on both stores

JoyJet Radar screen — geo-proximity people discovery with interest filters on iOS

Why custom native over white-label social SDKs

No off-the-shelf social platform — Sharetribe, Circle, Mighty Networks, or community-white-labels — combines an interest-based content feed, real-time geo-proximity radar, WebSocket messaging, and a virtual coin economy in a single native mobile package. Existing SDKs lock teams into fixed schemas and UI templates, which makes the Radar's continuous background location matching technically impossible within their permission and lifecycle models. Building on top of a social SDK for JoyJet would have meant forking it substantially — at which point the SDK provides no leverage and all its assumptions become liabilities. We chose a greenfield native build on Swift / SwiftUI for iOS and Kotlin / Jetpack Compose for Android so that every feature — Radar, feed ranking, coins, push — is owned end-to-end with no vendor constraints.

The feed algorithm in particular required a custom scoring model: content is ranked by a combination of interest-tag overlap, account affinity, recency decay, and JJLike signal weight. That scoring logic runs server-side in a Node.js service backed by Redis sorted sets for hot-content caching, with PostgreSQL as the source of truth for interest tags and engagement history. A white-label solution's fixed algorithm would have made interest customization — the product's core differentiator against Instagram and TikTok — impossible without rewriting the vendor's inference engine.

Custom native vs React Native vs white-label social SDK — at a glance
Dimension	Custom native (JoyJet)	React Native / Flutter	White-label social SDK
Geo-proximity Radar precision	Native CoreLocation + Foreground Service — full precision	JS bridge adds latency; background scan limited	Not available
Feed ranking algorithm	Fully custom — interest tags, affinity, recency, JJLike signal	Custom backend possible; UI layer is cross-platform	Fixed vendor algorithm — not configurable
Real-time messaging	Native WebSocket + BGAppRefresh — <100ms delivery	Acceptable; depends on native module quality	SDK-bundled, limited customization
Virtual economy (coins, gifts)	Fully custom state machine + StoreKit / Play Billing	Custom backend required regardless	Not supported
App Store compliance control	Direct — own every permission prompt and label	Partial — wrapper may trigger additional scrutiny	Vendor-controlled — review delays propagate
Background processing	Native BGAppRefreshTask / ForegroundService — reliable	Limited by JS runtime suspension	Varies by SDK
Long-term ownership cost	Higher initial build; zero SDK licensing or lock-in	Lower initial; shared-codebase maintenance	Low initial; high ongoing licensing and constraint cost

Platform references: Apple CoreLocation, Android Foreground Services, Apple BackgroundTasks framework.

JoyJet content feed — interest-curated photo and video discovery on iOS

iOS build — SwiftUI feed, Stories, and Radar on CoreLocation

The iOS client is built entirely in Swift with SwiftUI for the UI layer and UIKit for performance-critical surfaces — specifically the infinite-scroll video feed, where AVPlayer pre-roll and cell reuse timing require direct control that SwiftUI's lazy stacks do not yet provide reliably at scale. The content feed fetches paginated ranked batches server-side, caches the active viewport in memory, and prefetches the next batch when the user is within three cells of the bottom. Interest tags chosen in onboarding seed the initial ranking model; JJLike and share signals refine it continuously without requiring an explicit re-setup flow.

The Radar feature runs on CoreLocation with a Significant Location Change monitor for background updates — a power-efficient alternative to continuous GPS polling that still keeps the nearby-user list fresh as the device moves. User coordinates are quantized to a coarse grid on the device before transmission, so the server never receives raw GPS positions: it receives cell identifiers. Matching runs server-side against other active cell identifiers, with interest overlap as the secondary sort. Profiles returned by Radar show name, interests, and distance band ("within 500 m / 1 km / 5 km") — never exact coordinates. The same iOS client handles mobile app development across the full feature surface: feed, Radar, chat thread list, profile editing, onboarding, and JJPremium subscription flow.

JoyJet JJPremium subscription screen — unlock advanced features on Android

Android build — Kotlin, foreground services, and always-on messaging

The Android client is written in Kotlin with Jetpack Compose for the UI and a foreground service for persistent messaging and Radar background sync. The foreground service is mandatory: on Samsung, Xiaomi, OnePlus, and Pixel device families, aggressive battery optimizers kill background-only services within minutes. The foreground service displays a minimal notification that keeps the process alive across Doze mode cycles, and the Radar sync piggybacks on the same process window to avoid waking the device twice. WorkManager handles non-urgent operations — cache cleanup, telemetry flush, push token refresh — with backoff semantics that respect battery saver states across Android 10 through Android 14.

Messaging is built on WebSocket with automatic reconnect. On Android, reconnect logic runs inside the foreground service, so a brief loss of connectivity (carrier handoff between Wi-Fi and LTE, common across urban US and EU deployments) recovers in under two seconds without user action. Message ordering uses server-assigned monotonic sequence IDs rather than client timestamps — a common source of ordering bugs in distributed chat that we eliminated at the architecture stage. The same Android codebase serves all iOS and Android engineering feature parity: feed, Radar, Stories, JJPremium, market, JJFans statistics, and the multi-screen onboarding flow.

JoyJet virtual coins marketplace — gifts and market economy on iOS

Privacy-first architecture — ephemeral location, encrypted chat, no-log posture

JoyJet's stated privacy posture — no persistent user data collection — informed the architecture from the first sprint. Location data is quantized on-device before leaving the phone (coarse grid cells, not GPS coordinates), so the server never sees a user's precise position. Session tokens are short-lived and rotated on every app foreground; the Radar matching service works only with the coarse-grid cells present in the current session and does not build a location history. Chat messages are stored server-side for history sync but are identified by session-scoped message IDs; the schema was designed from day one to allow ephemeral-mode conversations where history is discarded at session end, without a retroactive migration.

Push notifications for messages use APNs (iOS) and FCM (Android) with notification-only payloads: the notification body is constructed on the client after decrypting the payload from the messaging service, so the notification vendor never sees message content. The developer's App Store privacy declaration of zero data collection reflects this architecture: no analytics SDK, no crash reporter with PII, no ad network, and no third-party data broker integrations were included in the build. This posture is compatible with both GDPR requirements in the European Union and CCPA / CPRA requirements in California and other US states.

Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.

Delivery methodology

A five-phase build that took JoyJet from product specification to production across iOS, Android, and a real-time backend.

Phase 1

Discovery & architecture

Feature taxonomy (feed, Radar, chat, economy), privacy data-flow mapping, GDPR + CCPA posture, platform-capability audit (CoreLocation vs Android ForegroundService), API schema design.

Phase 2

Core platform build

Swift / SwiftUI iOS client and Kotlin / Jetpack Compose Android client: onboarding, interest selection, content feed with ranking, user profiles, basic messaging over WebSocket.

Phase 3

Radar & real-time systems

CoreLocation + Foreground Service geo-proximity engine, coarse-grid quantization, interest-overlap matching service, always-on foreground messaging, Stories, push notifications via APNs + FCM.

Phase 4

Economy & premium

JJPremium subscription via Apple StoreKit + Google Play Billing, virtual coins purchase flows, gifts marketplace, JJFans creator payouts, content moderation tooling, admin dashboard.

Phase 5

Launch & iteration

App Store + Google Play submission across US and EU storefronts, multi-language QA (EN / RU / ES / ZH-TW), crash-free-session monitoring, on-call rotation, feed-ranking A/B framework.

JJPremium, coins, gifts, and the virtual economy

JoyJet's monetization model goes beyond a simple subscription. JJPremium unlocks advanced feed filters, Radar extended-range discovery, higher-resolution media uploads, and priority ranking in the Radar results of others. In-app billing routes through Apple StoreKit on iOS and Google Play Billing on Android, with server-side receipt validation against both stores' verification endpoints and a single entitlement record per user that resolves the subscription state across devices and reinstalls. Beyond the subscription, a virtual coin economy lets users purchase coins via in-app purchase and spend them on virtual gifts sent in chat — a social signal layer that drives engagement without relying on advertising. The gifts marketplace is implemented as a catalog backed by PostgreSQL with Redis cache for the hot-item list, and the gift-send flow is a two-phase commit: coin deduction and gift delivery are atomic, so a dropped WebSocket connection cannot result in a double-charge or a lost gift. JJFans — a creator-economy layer — lets users earn coins from engaged followers, with a payout system designed to support future fiat withdrawal via payment processor integration. The entire economy was built from scratch with extensibility in mind: adding new coin SKUs, gift types, or premium tiers requires a configuration change, not a code release.

Launching across the US and EU — App Store, Google Play, regional privacy law

JoyJet launched on Apple App Store and Google Play with storefronts active across the United States, the European Union, and the United Kingdom. The multi-language build — English, Russian, Spanish, and Traditional Chinese — means the app serves users in California, New York, Texas, and Florida in the US, and users in Germany, France, the Netherlands, Ireland, and Sweden in the EU, without a separate codebase per region. Privacy consent flows are region-aware: users in the EU and EEA receive a GDPR-style granular consent screen with separate toggles for analytics and personalization; users in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure. Data-handling practices are aligned 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.

The backend separates EU and US user data into distinct database partitions with separate encryption key hierarchies, enabling a future data-residency commitment without a schema migration. The Radar matching service runs stateless workers that can be pinned to EU or US regions independently. Both the App Store age rating (4+) and the Google Play content rating were calibrated for the social feature set, and in-app reporting and blocking flows — required by both platforms for user-generated-content apps — were built and reviewed as first-class features rather than afterthoughts. EU data-protection compliance and California CCPA obligations are documented in the in-app privacy policy and the server-side data-processing agreement template provided to the client for their DPA with EU sub-processors.

Tech stack and roadmap

Swift SwiftUI UIKit (video feed) Kotlin Jetpack Compose Node.js WebSocket / Socket.io PostgreSQL Redis Apple StoreKit Google Play Billing APNs + FCM CoreLocation Android Foreground Services AWS S3 + CloudFront Docker GitHub Actions Crashlytics

The active custom software development roadmap for JoyJet includes a video-call layer for chat threads (WebRTC), a dislikes and content-sentiment signal for feed ranking refinement, geo-tag support for posts, a business-post format for commercial accounts, and a live-broadcast feature (JJBroadcast). The premium tier is planned to expand with a post-promotion tool and a richer creator analytics dashboard that surfaces follower-growth, engagement rates, and gift revenue by cohort. Infrastructure plans include moving the Radar matching service to a dedicated microservice with sub-50ms SLO and migrating media storage to a multi-region CDN topology for EU data-residency compliance.

Frequently asked questions

How much does it cost to build a social media app like Instagram?

A social app MVP covering a content feed, user profiles, basic messaging, and App Store + Google Play submission typically costs $120k–$300k. Adding geo-proximity discovery (Radar), real-time group messaging, Stories, and a virtual economy (coins, gifts, subscription) brings a full-featured platform to $300k–$700k. The dominant cost drivers are the real-time infrastructure, the feed-ranking algorithm, and the moderation tooling required for user-generated content in both US and EU jurisdictions.

What makes geo-proximity Radar different from standard location-based features?

Standard location features (check-ins, maps, delivery tracking) work on user-initiated snapshots. A proximity Radar runs a continuous background scan — matching nearby users against interest profiles, applying privacy-respecting distance bands, and surfacing results in real time without exposing raw GPS coordinates. Building it correctly on iOS requires CoreLocation with always-on permission handling and BGAppRefreshTask; on Android it requires a foreground service to survive battery optimizers across Samsung, Xiaomi, and Pixel device families.

How do you build real-time messaging in a social platform?

Production-grade social messaging typically uses WebSocket as the transport layer (persistent connection per client, sub-100ms delivery), with Redis pub/sub or a dedicated message broker handling fan-out to multiple devices. Message history lives in PostgreSQL or a document store; unread counts and presence signals are cached in Redis. End-to-end encryption for DMs requires client-side key management and complicates server-side moderation — a trade-off that must be decided in the architecture phase, not retrofitted later.

What are the App Store rules for social apps with user-generated content?

Apple and Google both require social apps to have functioning in-app reporting and blocking, age-gating for 17+ or 18+ rated features, clear privacy disclosures in nutrition labels and privacy policy, and — for apps with dating or proximity features — additional review scrutiny. GDPR compliance for EU users requires a granular consent mechanism; CCPA compliance for California users requires a "Do Not Sell or Share My Personal Information" disclosure. Failing to build these before submission is the most common cause of App Store rejection for social platforms.

How long does it take to build a social platform on iOS and Android?

A focused MVP with content feed, profiles, basic chat, and both store submissions typically takes 16–24 weeks. Adding geo-proximity Radar, Stories, and a subscription tier adds 8–12 weeks. A full virtual economy (coins, gifts, marketplace, creator payouts) requires another 8–10 weeks of backend and billing work. Moderation tooling and admin dashboards are frequently underestimated — budget at least 4–6 weeks for a production-grade content operations surface.

Build a social platform like this — talk to us

If you are planning a social app, a community platform with geo-proximity features, or a creator economy product 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 joy-jet.com 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.

Book a discovery call See mobile development services

Related services