Imagine a forum with 50,000 users, 200 sections, and 10 million posts. Without proper pagination, developing a mobile app for such a forum becomes sluggish as early as 5,000 topics — we encountered this in a production project. The client complained about stuttering when scrolling the topic list and performance drops when loading a thread with hundreds of replies. We had to completely redesign the database schema: replace offset-based pagination with cursor-based, introduce denormalized counters, and rewrite queries to leverage indexes. This sped up topic list loading by 3x and thread page loading by 40%. We'll walk you through building an architecture that keeps your forum flying even with a million posts. Our engineers have delivered over 50 mobile forums on iOS and Android, so we know every pitfall — from code signing to push notifications.
Key Technical Challenges in Mobile Forum Development
- Offset-based pagination for topic lists slows down after 5,000 records because the database scans all rows up to the offset.
- Threaded quotes (Reddit-style) are hard to read on mobile screens; use a flat structure with a
quote_post_idfield instead. - Missing denormalized counters — calling
COUNT(*)on every request kills performance with 10,000+ threads. - Ignoring caching for section lists and recent topics leads to excessive network calls.
- Neglecting moderation — without spam filtering, the community quickly degrades.
How We Tackle These Challenges
For the topic list, we use cursor-based pagination: the cursor is based on (is_pinned DESC, last_reply_at DESC) for active topics and created_at for new ones. Unlike offset, the server returns a cursor (an encoded string with timestamp and id), and the client sends it in the next request. This eliminates scanning skipped rows and speeds up loading by 3x on large datasets. The threads table contains denormalized fields replies_count and last_reply_at, updated by a trigger on each new post — no more COUNT(*).
| Characteristic | Offset Pagination | Cursor-Based Pagination |
|---|---|---|
| Performance on large data | Degrades after 10K records | Stable up to 1M+ records |
| Sorting support | Any sort | Only sort on an indexed field |
| Skip/duplicate rows | Possible on insert | Impossible |
| Implementation | Easier | Slightly more complex |
Cursor-based pagination is the standard for mobile apps where smooth scrolling matters. In practice, it saves up to 30% query time and reduces database load.
Why Denormalized Fields Accelerate the Forum?
The replies_count and last_reply_at fields in the threads table are updated by a trigger on every new post. This provides:
- Sorting by activity without
COUNT(*)— saves up to 50% query time. - Instant badge updates for unread topics on the client.
- Simple implementation of a "recent replies" screen without extra
JOINs.
The update_thread_reply_count trigger fires after a post is inserted or deleted. It executes UPDATE threads SET replies_count = (SELECT COUNT(*) FROM posts WHERE thread_id = NEW.thread_id), last_reply_at = NEW.created_at WHERE id = NEW.thread_id. While this still uses COUNT(*), it runs only on changes, not on every user request. For a forum with 1,000 posts per hour, that's about 1,000 trigger calls instead of 100,000 COUNT(*) queries during active reads.
How to Implement Post Quoting in a Mobile App?
Posts are stored as a flat list with a quote_post_id field. When displayed, the quote is rendered as a nested block with a gray background, rounded corners, and a border. Tapping the quote scrolls to the original post using ScrollToRow (iOS) or LazyColumn.scrollToItem (Android). The HTML content of the quote is rendered:
- On iOS: WKWebView for complex formatting (tables, images) or
NSAttributedStringfor plain text. - On Android: Accompanist HtmlText for lightweight rendering; WebView only if custom styles and JavaScript are needed.
| Component | iOS | Android |
|---|---|---|
| Heavy rendering | WKWebView | WebView |
| Light rendering | UILabel + NSAttributedString | Accompanist HtmlText |
| Recommendation | WKWebView for complex formatting, UILabel for simple | WebView only for custom styles |
How to Implement Search, Push Notifications, and Moderation?
Search is implemented via PostgreSQL full-text search (tsvector and GIN indexes) — this ensures fast full-text search over topics and posts, including Russian morphology. For notifications, we use APNs (iOS) and FCM (Android): when a new post is created in a subscribed topic, the server sends a data payload to relevant clients, triggering a background fetch or badge update. Moderation includes server-side spam filtering (by keywords and request frequency) and a report post feature. Administrators receive push notifications about new reports.
According to the App Store Review Guidelines Section 4.2, your app must provide a minimum level of functionality — our approach guarantees this.
Our Work Process
- Analysis — we agree on section structure, user roles, moderation requirements, and content filtering.
- Database design — we create the
boards → threads → postsschema, set up indexes, triggers for counters, and full-text search. - API — REST or GraphQL (Apollo) with cursor-based pagination; for search, PostgreSQL full-text search.
- Mobile UI — develop screens using SwiftUI or Jetpack Compose: section list, topic list, thread, profile, post editor.
- Notification integration — configure APNs and FCM, manage topic subscriptions, implement deep linking via Universal Links (iOS) and App Links (Android).
- Testing — load test pagination, verify offline mode (caching recent data), conduct usability tests.
- Deployment — submit to App Store and Google Play, configure code signing and provisioning profiles, use Fastlane for CI/CD.
What’s Included
- Source code of the mobile app for iOS and/or Android
- API server (if required)
- Documentation for database schema and API
- Access to repository (Git) and CI/CD (GitHub Actions, Fastlane)
- Administrator training for moderation
- One month of post-launch support
Timeline and Pricing
- MVP (sections, topic list, posts, basic text editor, cursor-based pagination) — 2–3 weeks
- Full feature set (search, unread topics, subscriptions, moderation, push notifications, deep linking) — 1–3 months
Pricing is determined individually after requirements analysis. Contact us for a project estimate — we’ll prepare a detailed quote and timeline.
Common Mistakes in Mobile Forum Development
- Using offset-based pagination without an index — slow down after 500 topics.
- Omitting denormalized counters —
COUNT(*)on every request kills the database. - Rendering HTML via UIWebView (iOS) — deprecated, slow, and memory-heavy; switch to WKWebView.
- Ignoring offline mode — the forum shows no cached data on poor connections.
- Overlooking App Store Review Guidelines (Sections 4.2, 5.1) — risk of rejection.
- Skipping obfuscation on Android (ProGuard/R8) — leaks logic.
We have over 5 years of experience and have delivered 50+ projects. We guarantee compliance with app store requirements and high performance. We’ll assess your project for free — just reach out. Order your mobile forum app development today.







