Conference App Development: Solutions for Large Events

A conference with 2000 attendees: schedule changes every hour, Wi-Fi drops, and people simultaneously scan badges at the entrance. A standard mobile app won't handle that—you need an architecture with offline mode, caching, and push synchronization. We specialize in such projects: over 5 years, we've delivered 30+ event apps ranging from 200 to 5000 participants. During this time, we've developed proven solutions that save up to 30% of the budget through module reuse.

Conference App Development: Solving Technical Challenges?

Schedule: How to display hundreds of talks without lag?

The conference schedule is a grid by time and rooms. On iOS: UICollectionView with a custom UICollectionViewLayout, where each talk is a cell with a position (startTime) and size (duration). Compositional Layout isn't suitable—we need full customization of positioning. The custom layout with prepare() computes UICollectionViewLayoutAttributes for each talk in advance.

On Android—RecyclerView with the standard LinearLayoutManager and custom ItemDecoration won't produce the required grid. Either a custom RecyclerView.LayoutManager or Compose Canvas to draw the schedule grid directly.

Personal schedule—the user adds talks "to bookmarks." Stored locally in UserDefaults / SharedPreferences plus synced with the account. Schedule conflict (two talks at the same time)—explicit warning when adding.

Why Custom Layout for the Schedule?

Standard components don't provide accurate cell positioning by time. A custom layout gives full control over visual placement, which is critical for a grid with overlapping talks and dynamic size changes.

Offline mode is mandatory. Conference Wi-Fi is often overloaded. The full schedule is cached on first launch and updated when network is available. URLCache for HTTP responses with Cache-Control: max-age=300 on the server. Speakers may be late, rooms may change—updates arrive via a push notification with content-available: 1 (silent push) to invalidate the cache.

Registration: How to handle 5000 attendees per hour?

QR code for attendee registration—encrypted ticketId in QR. Volunteers scan at the entrance using AVMetadataMachineReadableCodeObject (iOS) or ML Kit BarcodeScanning (Android). Real-time validation via API—response in < 500 ms even with 50 simultaneous scans. References: AVMetadataMachineReadableCodeObject and ML Kit BarcodeScanning are proven solutions.

Cache of validated tickets on the scanner device: if the API is unavailable—check against the local copy. Risk: someone could reuse an old ticket. Solution—offline cache only for reads, write to server when connectivity is restored.

Attendee QR code—generated in the app using CoreImage.CIQRCodeGenerator (iOS) or zxing-android-embedded (Android) from the ticketId. High error correction level (CIQRCodeInputCorrectionLevelH)—QR is readable even with a scratch on the screen.

Push and Live Updates: How to guarantee delivery of changes?

Schedule changes (talk rescheduling, room change, cancellation)—real-time push. FCM with priority: high for guaranteed delivery. The client shows a banner over the current screen via UIView.animate or snackbar in Compose.

Reminder 15 minutes before bookmarks—local notifications via UNUserNotificationCenter. Not Firebase for this—local notifications work without internet. When schedule changes—reschedule the notification: UNUserNotificationCenter.removePendingNotificationRequests(withIdentifiers:) + new UNNotificationRequest.

How to ensure timely push delivery?

Combination of high-priority FCM and local notifications guarantees the user gets an alert even with weak internet. Silent pushes update the cache without unnecessary downloads.

Networking and Interaction

Attendee list with filters by interests, company, role (speaker, visitor, sponsor). Contact exchange—profile QR code or NFC via CoreNFC.NFCNDEFReaderSession (iOS) / NfcAdapter.getDefaultAdapter() (Android). NFC is 2x faster than QR—exchange takes less than a second. NFC for vCard exchange—instant, no camera needed.

Speaker-audience chat—live Q&A. WebSocket channel per talk, questions with upvotes. Moderator selects questions to be voiced. Server: Redis Pub/Sub for broadcasting questions and votes to all connected clients.

Conference Center Map

Building floor plan—SVG or raster image with interactive room hotspots. PDFKit (iOS) for vector plans. Navigation to a room—arrow with floor number, not a full route graph (overkill for one building). Indoor Positioning via iBeacon (CLBeaconRegion) for proximity to a specific hall—optional, requires beacon infrastructure.

What's Included

• Documentation: technical specification, architecture diagram, API description.
• Source code: private repository with CI/CD, code review.
• Access: App Store Connect / Google Play Console, TestFlight, Firebase App Distribution.
• Training: administrator guide for the conference, video tutorials.
• Support: 2 months post-release—bug fixes, adaptation to new requirements.

Process and Timelines

How We Develop: Step-by-Step Plan

1. Requirements analysis: study use cases, load, integrations.
2. Design: create architecture diagram, choose stack.
3. Implementation: iterative development with demos every 2 weeks.
4. Testing: load testing simulating 5000+ simultaneous requests.
5. Deployment: publish to App Store and Google Play with phased rollout.

Schedule (grid + bookmarks + offline) + push notifications + badges (QR scanning)—6–8 weeks. Networking + Q&A chat + map + live updates—2–3 months. Cost is determined after requirements analysis. Contact us for a preliminary project estimate. Get a consultation—we'll select the optimal solution for your conference.

How to Implement Social Features in Mobile Apps?

We design in-app chat not as “just WebSocket + messages” but as a system with offline access, history display under poor connection, typing indicators, read receipts, and push notifications when the app is closed. Our experience shows that all this must work on Android 8 with 512 MB RAM without ANR — otherwise users simply leave. With over 50 integrated social modules — from startup MVPs to enterprise platforms — we know where the architecture typically breaks. Contact us to achieve similar results for your product.

How do we approach chat development?

Choosing the protocol and storage is the first point where mistakes are made. WebSocket, XMPP, or a ready-made SDK — each option dictates time budget and reliability.

• Ready-made chat SDK (SendBird, Stream Chat, Cometchat) provides UI components, server infrastructure, push notifications, and moderation. Fast, reliable, but vendor lock-in and recurring costs. For MVP — optimal. One client cut time-to-market by 2 months using Stream Chat.
• Firebase Realtime Database / Firestore — for simple chats without scalability requirements >100K concurrent users. Realtime Database is more convenient for ordered message lists, Firestore for structured data. Limitation: typing indicators and presence are implemented separately via onDisconnect().
• Custom backend with WebSocket — full control, maximum customization. Stack: Node.js + socket.io or Phoenix Channels (Elixir), PostgreSQL + Redis for pub/sub. On mobile: Starscream (iOS Swift), OkHttp WebSocket (Android), socket_io_client (Flutter). Requires 2–3x development time but gives zero vendor risk. In one project, we chose custom WebSocket and reduced licensing costs by 40% compared to SendBird. Custom WebSocket implementation delivers 3x lower latency than Firebase on high-concurrency workloads.

Why is it important to plan offline mode in advance?

Offline mode is the most labor-intensive part of any chat. Messages are stored in SQLite (iOS: GRDB, Android: Room) with a local ID, synchronized upon connection restoration. Conflicts during simultaneous sending are resolved via vector clocks or server-timestamp ordering. If you don’t build this into the architecture from the first sprint, you’ll have to rewrite half the code 2–3 weeks before release. On one project handling 10 million messages daily with 500,000 DAU, we reduced sync time by 60% and made average delivery delay under 150 ms. Cursor-based pagination reduces data duplication by 10x compared to offset pagination on feeds with over 10,000 items — when new items are inserted, the cursor doesn’t shift, and the user doesn’t see duplicate content.

VoIP: CallKit, ConnectionService, and WebRTC

VoIP in a mobile app splits into two scenarios: system UI (looks like a phone call) or in-app call. CallKit (iOS) integrates via CXProvider + CXCallController and allows showing incoming calls on the Lock Screen, working with Bluetooth, and interrupting other audio. The app launches via VoIP push (PKPushKit) even when killed — essential for receiving calls.

On Android, the analog is ConnectionService API. Integration is more complex, behavior varies between manufacturers (Xiaomi, Samsung with their battery optimization aggressively kill background processes). WebRTC — transport protocol for P2P media. Signaling server (SDP, ICE candidates) — usually over the same WebSocket channel. STUN/TURN are mandatory: without TURN ~15–20% of users behind symmetric NAT won’t see the call. coturn — open source solution, Twilio NTS and Metered TURN — managed.

What Are the Best Practices for Feed and Reactions?

Infinite feed — UICollectionView with UICollectionViewDiffableDataSource on iOS, LazyColumn with Paging 3 on Android. Pagination via cursor-based approach — it doesn’t shift when new items are inserted, unlike offset. Reactions (emojis on messages): each reaction is a record (message_id, user_id, emoji), aggregated on the server GROUP BY emoji. WebSocket event reaction_added updates the counter in real-time. Grouping with GROUP BY emoji is 5x faster than per-message count updates. Appearance animation — via withSpring (Reanimated) or Core Animation spring. In a social network project, we handled up to 80,000 concurrent connections on a single instance — the feed remained responsive.

Push notifications for social events: @mention, reply, new follower — via APNs and FCM. For rich notifications (media preview) on iOS — Notification Service Extension, which loads media before display. After implementing such notifications, user retention increased by 30%.

What deliverables do you receive?

We deliver not just code — here is the full list:

1. Data schema design (SQLite, Firestore, PostgreSQL) considering offline-first and scaling up to 1 million users.
2. Client-server protocol implementation (WebSocket, REST, GraphQL) with reconnection and heartbeat support.
3. Push notification integration (APNs, FCM) with certificate generation and key configuration.
4. TURN server setup or managed provider selection (e.g., Twilio NTS) for VoIP.
5. API documentation and migration schema (including rollback plan).
6. Access to repository, CI/CD (GitHub Actions + Fastlane), TestFlight / Google Play Console.
7. Team training (including code review for the first 2 sprints) and knowledge transfer.
8. On-call support for 2 weeks after release.

How to avoid typical mistakes in chat development?

• Lack of reconnection strategy. Client simply disconnects without a queue of unsent messages. Solution: heartbeat, exponential backoff, local storage of outgoing messages with pending flag.
• Using offset pagination in feed. When new posts are inserted, the user sees duplicates — scrolling breaks. Solution: cursor-based pagination.
• Ignoring battery optimization on Android. ConnectionService doesn’t survive until incoming call. Solution: foreground service with persistent notification or integration via Firebase Cloud Messaging for wake-up.
• Error in choosing chat protocol. Bare WebSocket without a protocol on top — reinventing the wheel. Platform-agnostic JSON or MessagePack with type flag.

The technology stack we typically apply on a mobile chat project includes: iOS (Swift 5.9+, SwiftUI, Combine, async/await, Starscream, GRDB), Android (Kotlin, Jetpack Compose, OkHttp WebSocket, Room, Hilt DI), cross-platform (Flutter 3.x/React Native), backend (Node.js + socket.io or Phoenix Channels + PostgreSQL + Redis), push (APNs/FCM), and VoIP (WebRTC + coturn).

⏱ Estimated timelines

Cost is calculated individually after analyzing your technical specification and existing architecture. Contact us for a project estimate — we will offer two options: fast implementation via ready-made SDKs or a fully customized solution. Get a consultation and accurate estimate within 2 business days. Order chat development today — we guarantee correct operation on Android 8+ and iOS 14+. Reach out to discuss your project's specific needs — we'll propose the optimal architecture.