Async Multiplayer Mobile Game Development: Architecture, Sync, and Offline-First

Players in different time zones, internet outages, lost progress — typical pain points of async multiplayer. How do you ensure correct synchronization of moves when a user can go offline for hours? Our solution is event sourcing with state versioning and an offline-first architecture. Over 10 years, we have implemented async multiplayer in 30+ projects with a total audience of more than 2 million users. Request async multiplayer development so your players can make moves at any time without losing progress.

Async Multiplayer: Key Architectural Decisions

State Storage and Versioning

Each move is a database transaction. Record structure: game_id, move_number, player_id, action_payload (JSON), timestamp, resulting_state_hash. The state hash after each move allows detecting divergence. Event Sourcing saves the full history of actions: you can restore any game moment, implement replay, auditing, and rollback in case of bugs. In a project with 500,000 installs, this approach reduced bug-fixing time by 60%.

Synchronization via Polling and WebSocket

When starting a session, the client does GET /game/{id}/state and receives the state with version. Then two notification options: polling every 30-60 seconds or WebSocket/SSE when the app is open + push when closed. Polling loads the server 40% more. Better: when the app is open — WebSocket, when closed — FCM/APNs push. Upon receiving a push, the client does GET /game/{id}/state?since_version={lastKnown} and receives only changes. The hybrid reduces traffic by 3 times.

Why Event Sourcing is Better for Async Multiplayer?

Event sourcing saves all moves as a sequence of events. This enables:

• rollback the game to any point;
• implement replay for spectators (ghosting);
• conduct balance auditing and detect cheating.

Unlike storing only the current state, event sourcing allows easy fixing of game logic errors without data loss. In practice, we use PostgreSQL with event store or Firebase Firestore with a moves collection. Compare both approaches:

How We Resolve Conflicts on Simultaneous Moves?

Conflicts occur if both players sent a move at the same time (e.g., due to a client bug). The server accepts only the first by timestamp and returns an error to the second with the current state. For more complex scenarios (simultaneous moves in non-turn-based modes) we use Conflict-free Replicated Data Types (CRDT), but for async turn-based games, timestamp + hash is sufficient. Average notification latency when the app is open is 2–5 seconds.

Move Synchronization Mechanism for Async Multiplayer

For reliable synchronization, we use a combination of WebSocket (active session) and push notifications (closed app). If the connection drops, the client switches to polling with exponential backoff: first delay 1 sec, then 2, 4, 8, etc. up to 60 sec. This guarantees move delivery even with temporary disconnection.

Offline-first UX

The user makes a move without internet — the move is saved locally and sent when the connection is restored. On Android — WorkManager with NetworkType.CONNECTED: the task will execute when internet appears, even if the app is closed.

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

val submitMoveRequest = OneTimeWorkRequestBuilder<SubmitMoveWorker>()
    .setConstraints(constraints)
    .setInputData(workDataOf("move_payload" to moveJson))
    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, TimeUnit.SECONDS)
    .build()

WorkManager.getInstance(context).enqueue(submitMoveRequest)

On iOS — BGProcessingTask with requiresNetworkConnectivity = true. The move is saved in Core Data, the task sends at the earliest opportunity. According to statistics from our projects, 95% of moves are delivered within 30 seconds after connection restoration.

Synchronization Methods Comparison

What's Included in the Work

• Server-side architecture (DB, API, WebSocket)
• Client SDK for iOS and Android (Swift/Kotlin)
• Move logic, versioning, conflict handling
• Offline queue and synchronization (WorkManager, BGProcessingTask)
• Push notifications (FCM/APNs)
• API and integration documentation
• Testing (unit, integration, load)
• Post-launch support (2 months)

Work Process

1. Analysis of game mechanics and requirements
2. Architecture design (DB schema, API contracts)
3. Server-side logic implementation (NestJS/PostgreSQL or Firebase)
4. Client code integration (Swift/Kotlin)
5. Synchronization and offline scenario testing
6. Deployment and monitoring

Timeline and Estimation

Basic async system for 2 players with event sourcing, offline-first, and push notifications: 2-4 weeks. Cost is calculated individually after analyzing the game mechanics. More complex configurations (more players, CRDT) — from 3 to 6 weeks. Our clients save 30% to 50% development time compared to synchronous multiplayer thanks to reusable components and ready-made templates.

Trust and Experience

Our team has developed over 30 mobile games with multiplayer, including projects with 500,000+ installs. We guarantee deadline adherence and transparent collaboration. We work turnkey: from idea to store publication. Get a consultation — tell us about your game mechanics, and we will propose an optimal solution. Contact us to discuss your project and get a personalized estimate.

How to Start Integrating API into a Mobile App?

The request goes out, the response doesn't come, timeout — 30 seconds. The user stares at the spinner. No network — mobile card in the subway. Or the network is there, but the server returns 200 with an HTML error page instead of JSON — and the app crashes on JSONDecoder.decode(). We see such cases on every second project. So integrating API into a mobile app is not just calling an endpoint, but designing a reliable network layer: error handling, caching, offline mode, certificate pinning. Order an audit of your current network layer — we will evaluate the project in 1 day. Our team guarantees a thorough analysis and provides a detailed roadmap.

Standard libraries like URLSession and OkHttp provide basic HTTP clients, but for production you need retries with exponential backoff, status code validation, typed deserialization, and network state monitoring. Without this, the app loses data and users. We have been doing mobile development for 5 years and implemented more than 30 projects with API integration on iOS, Android, and Flutter — from startups to enterprise solutions.

How to Choose a Protocol for API Integration?

REST remains the standard for most projects. But when a profile screen needs 5 fields out of 40, GraphQL eliminates over-fetching and reduces traffic by 30–60%. gRPC is justified for thousands of requests per minute (trading, IoT) — binary serialization is 3–5 times faster than JSON. WebSocket is the only choice for real-time without polling (messages, notifications).

Practical example: For a fintech app, we replaced REST (40 fields) with GraphQL — response size dropped from 12 KB to 2.5 KB, screen render time decreased by 70%. Traffic savings were significant. Our certified iOS and Android developers have deep experience with all these protocols — you can rely on proven solutions.

How to Ensure Reliable Connection and Offline-First?

Users lose network in the subway, elevator, tunnel. A mobile app must work without internet — at least in read-only mode. We implement the offline-first pattern:

1. On screen open, first show data from the local cache (Core Data / Room).
2. Simultaneously perform a network request, update UI after response.
3. If network is unavailable — show cached data and a 'no connection' label.
4. When network is restored, automatically synchronize changes.

For HTTP response caching we use URLCache (iOS) and OkHttp Cache (Android) with Cache-Control support. For structured data — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback monitor network state and trigger updates.

REST and Client Library Selection

Alamofire (iOS) — de facto standard for Swift projects. On top of URLSession it adds request chaining, response validation, automatic retry, certificate pinning via ServerTrustManager. AF.request() with .validate() returns an error for any status code outside 200–299. Without .validate(), Alamofire considers 404 and 500 as successful responses. With Swift Concurrency — async version via serializingDecodable.

Retrofit (Android) — annotation-based HTTP client on top of OkHttp. An interface with annotations compiles into implementation. @GET, @POST, @Path, @Query, @Body — declarative API description. OkHttp under the hood: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — logging in debug builds. Authenticator — automatic token refresh on 401.

Ktor (KMM/Flutter) — multiplatform HTTP client. On iOS it works via Darwin engine (URLSession), on Android — via OkHttp. Single code for both platforms with KMM architecture.

GraphQL: When REST Falls Short

REST returns a fixed structure. A profile screen needs name, avatar, email — the server sends 40 fields. Over-fetching. GraphQL solves this: the client requests exactly the needed fields. This is critical for mobile where traffic and parsing time are real constraints. Apollo iOS and Apollo Kotlin generate typed classes from schema: schema.graphql + query files → strict types at compile time. Subscriptions via WebSocket — real-time without polling. Limitation: GraphQL is harder to cache at the HTTP level. Apollo uses a normalized in-memory cache InMemoryNormalizedCache — requests with overlapping data update the cache without duplication.

WebSocket: Real-Time Without Extra Traffic

Polling (setInterval every 5 seconds) — battery and traffic waste. WebSocket is a persistent bidirectional connection. iOS: URLSessionWebSocketTask (native, iOS 13+). Android: OkHttp WebSocket. Mandatory reconnect handling: on onFailure — exponential backoff (1s → 2s → 4s → 8s → max 60s). Socket.IO is an overlay with automatic reconnect, but for new projects native WebSocket is preferable (fewer dependencies).

gRPC: For High-Load Services

gRPC with protobuf — binary serialization: smaller size, faster parsing. grpc-swift for iOS, grpc-kotlin for Android. The protobuf schema compiles to typed classes. Streaming (server-side, client-side, bidirectional) is a native feature. Application threshold: high request frequency (trading, IoT) or critical latency. For regular CRUD, REST is simpler to debug and monitor.

Certificate Pinning and Security

A corporate proxy can intercept HTTPS by substituting the certificate. Certificate pinning prevents this: the app accepts only a specific certificate or public key. Alamofire: ServerTrustManager with PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner with SHA-256 hash. Apple's App Transport Security documentation recommends pinning certificates for sensitive data. Operational complexity: on certificate rotation, older app versions stop working. Solution — pinning to the CA public key or support multiple pins with a grace period.

What Is Included in the Work

We deliver: source code of the network layer, documentation on used libraries, certificate rotation instructions, 2 weeks post-delivery support. Our experience guarantees that the solution will be stable and maintainable.

Timeline and Cost

Implementation of a network layer with REST, retry, caching, and offline mode — 1–2 weeks. Adding GraphQL or WebSocket — another 1–2 weeks. gRPC — 2–3 weeks, including code generation. The cost is calculated individually after analyzing the API and offline behavior requirements. We will evaluate the project in 1 day — contact us for a consultation. Get a reliable API integration with guaranteed quality.