Mobile Review & Rating System Development

Without a review system, an app loses one of its main tools for social proof — users don't see others' experiences and don't leave their own. We've encountered projects where the aggregate rating is skewed by a few early reviews, photos take 4 seconds to load, and bots bypass moderation. We develop a turnkey review system starting from 3 business days — star ratings, text reviews, moderation, photos, and business replies. Get a consultation — we'll evaluate your project for free.

What usually breaks in custom implementations

Rating aggregation and updates

The most common mistake is to calculate the average rating on the fly with SELECT AVG(rating) across the entire reviews table on every product page request. At 50,000 reviews this starts to slow down. The correct approach: a denormalized average_rating and reviews_count field on the server side, updated via a trigger or a queue (Celery/Sidekiq/BullMQ) when a review is added/changed/deleted. The client receives the precomputed value.

On mobile, the rating should be displayed as a star indicator — iOS and Android implement this differently. In UIKit, we build a custom UIView with CALayer masks or assemble it from five UIImageView with .full, .half, .empty states. In Jetpack Compose — a Row with Icon and calculation via floor/ceil of the fractional value. Fill animation on first load is done via withAnimation (Compose) or UIView.animate changing clip-mask width.

Pagination and infinite scroll in review lists

Classic OFFSET/LIMIT works poorly with a large number of reviews — on the 10,000th page, the database still scans the entire index up to the required offset. We use cursor-based pagination: sort by created_at DESC, id DESC, return a next_cursor (base64 of the last id + timestamp), and the next request passes it as a parameter. Cursor-based pagination works 10 times faster than OFFSET/LIMIT on datasets of 10,000+ records.

On iOS, the list is built with UICollectionView and UICollectionViewDiffableDataSource — adding a new page via applySnapshot without flickering. prefetchDataSource requests the next page when 3-4 cells are left to the end. On Android — LazyColumn with LazyPagingItems from Paging 3.

Review photos

Uploading photos directly through the main API is an antipattern. The correct scheme: the client requests a presigned URL from an S3-compatible storage (AWS S3, Cloudflare R2, MinIO), uploads the file directly there, and then only passes the object key to the API. Compression before upload is done on the client: on iOS via UIImage.jpegData(compressionQuality: 0.75), on Android via Bitmap.compress(Bitmap.CompressFormat.JPEG, 75, outputStream). Limit: 2-3 photos, max 5 MB per file after compression.

Display uses Kingfisher (iOS) or Coil (Android) with a placeholder and 200ms crossfade. For a gallery on tap — modal UIPageViewController or HorizontalPager in Compose with pinch-to-zoom.

How the full implementation works

Data structure. A review contains: user_id, entity_id (product, service), entity_type, rating (1-5), body (text, optional), photos[], status (pending/approved/rejected), helpful_count, created_at. Indexes: (entity_id, entity_type, status, created_at DESC) for fetching approved reviews per entity.

Moderation. Automatic pre-filter via a profanity filter (the bad-words library or custom list on the backend) + a flag for manual review for reviews with keywords. Photos go through AWS Rekognition Moderation Labels or Google Cloud Vision SafeSearch before publication. In the moderator panel — a queue with approve/reject and the ability to reply to the review.

Reply to review. Business replies to a review as a separate entity review_reply (one-to-one with review). When a reply is published, a push notification is sent to the author via FCM/APNs with a deeplink to the review.

Helpful vote. helpful_votes — a separate table (user_id, review_id, UNIQUE). Limit: one vote per account. On the client — optimistic counter update with rollback on error.

Purchase verification. If the platform allows, we mark reviews from actual buyers with a "Verified Purchase" badge by checking for a closed order with the user_id and entity_id.

Why cursor-based pagination is better than OFFSET/LIMIT

Cursor-based pagination guarantees stable speed regardless of the number of pages. At 1,000,000 reviews, a cursor-based query executes in the same milliseconds as on the first page. PostgreSQL research shows that OFFSET on large datasets leads to a full index scan up to the offset. On mobile this is critical — the user should not wait for review loading longer than 200 ms.

How photo moderation is organized

Automatic checks via AWS Rekognition Moderation Labels or Google Cloud Vision SafeSearch detect NSFW content. If triggered, the review is flagged for manual review. The moderator in the panel sees the photo and text, and can approve or reject. This reduces the burden on the team and prevents unwanted content.

Work stages

1. Audit of the current implementation (if any).
2. Data schema and API design.
3. Backend development.
4. Mobile UI (both platforms or one).
5. Moderation integration.
6. Load testing (Artillery/k6 with scenario "500 concurrent reviews").
7. Release.

For Flutter projects the entire UI is built once, with logic extracted into ReviewBloc (BLoC) or ReviewNotifier (Riverpod).

What's included

• Data schema design (ER diagram, index descriptions)
• REST/GraphQL API with documentation (Swagger/GraphQL Playground)
• Mobile UI for iOS/Android or Flutter
• Moderation integration (automatic + manual)
• Load testing and optimization
• Access to repository, CI/CD pipeline
• Training for the client's team (1 session)
• 2-week post-release support

Timeline

Basic system (star rating, text review, list with pagination, status-based moderation) — 3-5 business days. With photos, business replies, voting, and purchase verification — 8-12 days. Cost is calculated individually after requirements analysis.

Contact us — we have implemented 20+ review systems for marketplaces and services over 5 years. We'll evaluate your project in 1 day. Get a consultation now.

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.