Mobile Multiplayer Engineering

We specialize in building real-time multiplayer for mobile games. This is not just WebSocket and sending coordinates — it's managing 50–200 ms latency, compensating for packet loss, synchronizing physics, and dealing with unstable 4G. Mobile clients lose packets more often than desktops: switching from WiFi to LTE, OS backgrounding — a naive implementation breaks in early tests. 5% packet loss is common on mobile networks, and an extra 100 ms of latency creates an unacceptable experience. Our team, with over a decade in mobile gaming and 20+ shipped multiplayer titles, provides a turnkey solution from architecture to deployment. We deliver up to 40% bandwidth savings via delta compression — a typical saving of $2,000–$5,000 per month for a mid-size game. This article covers key technical decisions: authoritative server, client prediction, lag compensation, and mobile optimizations.

Core Challenges in Mobile Multiplayer

The first mistake is trusting the client. The client sends "I moved here" and the server applies it without verification. Within a week, cheaters teleport across the map. The correct architecture: authoritative server. The client sends input (pressed buttons, movement vector), the server simulates physics and broadcasts resulting states. The client runs the same calculations locally — this is client-side prediction. When the server response arrives, the client reconciles — rolls back to the last confirmed state and replays the buffer of unconfirmed inputs. As noted in Unity Netcode documentation, this approach is mandatory for competitive games.

How Does Client-Side Prediction Improve Mobile Multiplayer?

Each game tick (typically 20–60 Hz for mobile):

1. Client sends InputPayload { tick, moveDirection, shootPressed }.
2. Server applies input, computes StatePayload { tick, position, health, ... }.
3. Server broadcasts snapshots to all clients (not every tick — delta compression is applied).
4. Client receives snapshot, compares with predicted state, and corrects.

Delta compression is critical: instead of a full world state (300 bytes), only changes are sent (10–30 bytes). At 20 Hz for 10 players, the difference is 60 KB/s vs 6 KB/s — a 90% reduction. Client-side prediction reduces perceived latency by 3x compared to waiting for server confirmation.

UDP vs TCP for Mobile Real-Time

TCP guarantees delivery and ordering via retransmission on loss. In a real-time game, a lost packet with a player's position 200 ms ago is not needed — the current position is needed. TCP will wait and resend outdated data while new data queues behind it, adding 100–400 ms to visible latency on poor channels. UDP — fire and forget. Loss is handled at the application layer: positional updates don't need reliability (new packet overwrites old), while important events (damage, death) need acknowledgement — implemented via a simple ACK scheme over UDP. For mobile, raw UDP is accessible via System.Net.Sockets.UdpClient in Unity or NWConnection with .udp parameter on iOS. Android uses DatagramSocket through Java/Kotlin. Photon Realtime uses its own protocol over UDP with built-in reliable delivery for critical messages. LiteNetLib is an open-source alternative. In latency tests, UDP reduces average lag by 30–40% compared to TCP for real-time positional data.

Lag Compensation and Interpolation

On the client, other players' objects do not move directly according to snapshots — that causes jitter on unstable connections. Interpolation: the client stores a buffer of the last 2–3 snapshots and renders the state with a 50–100 ms delay, interpolating between them. Movement becomes smooth at the cost of artificial latency. Lag compensation on the server: when player A shoots at player B, the server "rewinds" the world state back by RTT/2 and checks collision where B was from A's perspective. Without this, hitting a fast opponent at high ping is physically impossible.

Mobile Platform Specifics

iOS background mode (after 5–10 seconds UIApplicationWillResignActiveNotification) breaks the socket. Use BGTaskScheduler for background reconnect or graceful disconnect with session persistence on the server. Android: WakeLock and WifiLock to keep the connection during a match. Without WifiLock.WIFI_MODE_FULL_HIGH_PERF, the WiFi module enters power-saving mode and adds 30–80 ms to latency. Network switching from WiFi to mobile — ConnectivityManager.NetworkCallback on Android, NWPathMonitor on iOS. On network change, fast reconnect without losing the game session.

Stack and Tools

What's Included in the Work

• Architectural documentation: protocol selection, synchronization scheme, error handling.
• Server code: authoritative server, lag compensation, delta compression.
• Client integration: client prediction, interpolation, reconnect logic.
• Testing on real devices: 10+ models, different OS versions.
• Deployment: server infrastructure setup, monitoring.
• Team training: code review, documentation, 1-month support.

Real-Time Multiplayer Development Stages

Requirements audit (genre, player count, platforms) → framework selection → prototype with basic position synchronization → implement client prediction and reconciliation → lag compensation on server → load testing → polish for mobile constraints. Prototype with basic multiplayer for 2-4 players: 3-4 weeks. Full real-time system for 10-20 players with lag compensation and mobile optimization: 2-4 months. Cost is calculated individually, but typical prototypes start at $5,000–$10,000 and full systems range from $20,000 to $50,000.

Contact us for a project assessment. Order a prototype in 3-4 weeks — we will advise on architecture and propose the optimal solution. Get a consultation from an engineer specializing in mobile real-time systems with 10+ years of experience and 20+ shipped titles.

Our company: 10+ years in mobile multiplayer, 20+ shipped titles, 5+ years on the market. We have helped over 50 studios deliver responsive multiplayer experiences.

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.