Developing a Like System in a Mobile App
A like seems trivial: tap — increment counter — icon fills. But without optimistic updates, the button lags for 300–500 ms waiting for a server response, which subjectively kills the app feel. Double taps or rapid repeated clicks without debounce generate extra requests and can break the counter. In a real project, we encountered a situation where fast tapping increased the counter by 2 due to missing locking — adding debounce and atomic increment solved the issue. We design such systems turnkey, considering all edge cases: race conditions, offline mode, push notifications to the author, and eye-pleasing animations. Our experience: over 5 years in mobile development and dozens of commercial projects with likes, comments, and other reactions.
Why a Simple Like Implementation May Break the App?
Without optimistic updates, each tap introduces visible delay — the user thinks the app is slow. And if the button isn't protected against spam, a fast double tap sends two requests, potentially leading to an incorrect counter. Another issue is race conditions with parallel requests, where two increments cancel each other. On the server, use atomic UPDATE; on the client, debounce and blocking of repeated calls.
How Optimistic Updates Work
The standard in social apps is to update the UI instantly, without waiting for the server response. Optimistic updates are 2× faster for the user: subjective delay drops from 400 ms to 0.
iOS (UIKit):
func toggleLike(for post: Post) {
let wasLiked = post.isLiked
// Instantly change UI
post.isLiked = !wasLiked
post.likesCount += wasLiked ? -1 : 1
updateCell(for: post)
// Server request
apiService.toggleLike(postId: post.id) { [weak self] result in
if case .failure = result {
// Rollback
post.isLiked = wasLiked
post.likesCount += wasLiked ? 1 : -1
self?.updateCell(for: post)
}
}
}
On Compose similarly: likedState in ViewModel changes immediately, the request runs in parallel, on error the StateFlow reverts to the previous value.
How to Protect the Button from Spam and Duplicates?
Rapid double taps must be protected. The simplest way is an isRequesting: Bool flag at the ViewModel level, blocking repeated calls until a response is received. For more complex cases — debounce for 300 ms: send the final state (liked/unliked), not each tap. Using debounce reduces extraneous requests by 80%.
On Android with Kotlin Flow:
likeButtonClicks
.debounce(300)
.distinctUntilChanged()
.flatMapLatest { liked -> toggleLikeUseCase(postId, liked) }
.launchIn(viewModelScope)
Animation and Counter
Animation of the like is a small detail that users notice. The Instagram approach: the heart "springs" on tap. On iOS — UIView.animate(withDuration: 0.1, animations: { button.transform = CGAffineTransform(scaleX: 1.3, y: 1.3) }) { _ in UIView.animate(...) { button.transform = .identity } }. On Compose — animateFloatAsState with spring(dampingRatio = 0.4f).
The color of the filled like via tintColor (iOS) or ColorFilter.tint (Compose). Icon — SF Symbol heart/heart.fill on iOS, Material Icon on Android.
Storing likes_count as a denormalized field in the post table is correct. Do not count SELECT COUNT(*) on every feed request. Increment/decrement via atomic UPDATE posts SET likes_count = likes_count + 1 WHERE id = ? — no race conditions. Like uniqueness: table likes (user_id, post_id, PRIMARY KEY (user_id, post_id)). Duplicates are impossible at the DB level.
Comparison of Approaches to Like Implementation
| Parameter |
Simple Implementation |
Optimistic Implementation |
| UI speed |
Delay 300–500 ms |
Instant |
| Spam protection |
No |
Debounce + isRequesting |
| Race condition |
Possible |
No (atomic SQL) |
| Offline support |
No |
Local storage + sync |
| Animation |
Optional |
Spring, customizable |
Work Process
- Analysis of current architecture and API — identify bottlenecks, estimate load.
- Data schema design — PostgreSQL/MySQL with atomic increments, Redis for hot counter.
- Client logic implementation — iOS (SwiftUI/UIKit), Android (Compose), Flutter. Embed debounce, blocking, animation.
- Push notifications integration — APNs/FCM, send on like with a 1-2 second delay for grouping.
- Testing — unit tests for ViewModel, UI tests for button behavior, load testing with 1000 requests per minute.
- Deployment — publish to App Store and Google Play, monitor crash-free rate.
Estimated Timelines
Basic implementation with optimistic updates, animation, and duplicate protection takes from 4 hours to 2 days per platform. Pricing is individual based on complexity and integrations (push, offline, cross-platform).
Typical Mistakes in Like Implementation
- Missing atomic increment on the server — the counter may lose likes under concurrent requests.
- Ignoring offline mode — user sees correct UI but data is lost on restart.
- Using
SELECT COUNT(*) in feed — slows query by 30-50%.
Order an audit of your current implementation, and we'll show which bottlenecks can be eliminated. Contact us for a consultation — we'll help implement a like system that doesn't lag and delights users. We guarantee stability and deadline adherence.
Full iOS Controller Example
```swift
class LikeButton: UIButton {
var isLiked: Bool = false {
didSet { updateAppearance() }
}
private func updateAppearance() {
let imageName = isLiked ? "heart.fill" : "heart"
setImage(UIImage(systemName: imageName), for: .normal)
tintColor = isLiked ? .red : .gray
}
}
```
The optimistic update approach is described in Apple's official documentation for UIView.animate. For Compose, a similar pattern is described in the official guide.
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.
| Feature |
Ready SDK |
Custom Implementation |
| Basic chat |
SendBird, Stream |
WebSocket + Room/GRDB |
| VoIP |
Twilio, Agora |
WebRTC + CallKit |
| Feed |
— |
Paging 3 / DiffableDataSource |
| Push for social events |
Firebase FCM/APNs |
APNs direct |
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:
- Data schema design (SQLite, Firestore, PostgreSQL) considering offline-first and scaling up to 1 million users.
- Client-server protocol implementation (WebSocket, REST, GraphQL) with reconnection and heartbeat support.
- Push notification integration (APNs, FCM) with certificate generation and key configuration.
- TURN server setup or managed provider selection (e.g., Twilio NTS) for VoIP.
- API documentation and migration schema (including rollback plan).
- Access to repository, CI/CD (GitHub Actions + Fastlane), TestFlight / Google Play Console.
- Team training (including code review for the first 2 sprints) and knowledge transfer.
- 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
| Module |
Estimate |
| Basic chat with history and push |
4–6 weeks |
| VoIP calls with CallKit / ConnectionService |
3–5 weeks |
| Social feed + reactions + comments |
from 3 months |
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.
