Mobile Knowledge Base Development with Offline FTS5 Search

Imagine: your app has grown to 50+ screens, support is drowning in repetitive questions — 40% of tickets are about the same issue. Documentation is scattered across Google Docs, Confluence, and Jira. Customers leave because they can't find an answer in 2 minutes. A knowledge base (KB) solves this, but implementing it is more than just adding a search page. We'll explain how to design and deploy a mobile knowledge base that works offline, syncs with a CMS, provides instant FTS5 search, and delivers analytics. With over 10 years of engineering practice, we guarantee stable synchronization and fast search.

How Mobile Knowledge Base Architecture Works

Content Sources and Synchronization

The most versatile approach is a custom or headless CMS (Contentful, Strapi, Sanity) with REST/GraphQL API. The mobile client downloads articles on first launch and on updates, storing them in a local database. Synchronization uses updatedAt: on each launch, we download only articles changed since the last sync-timestamp. If the network is unavailable, changes accumulate and apply on next connection. Conflicts resolve by "last write wins". Typically 10–20 KB of data per update, which takes under a second on a stable connection.

// Android: Room schema for knowledge base articles
@Entity(tableName = "kb_articles")
data class KbArticle(
    @PrimaryKey val id: String,
    val title: String,
    val content: String,   // Markdown or HTML
    val categoryId: String,
    val updatedAt: Long,
    val searchIndex: String  // normalized text for FTS
)

Integration with Zendesk Help Center / Freshdesk Solutions

If you already use Zendesk, the Help Center API provides articles directly. For custom design, we use Zendesk Guide API: GET /api/v2/help_center/articles.json. The response contains body in HTML — we render it via WebView with custom CSS matching the app's design system.

Why Local FTS Search Is Better Than Server-Side

Searching through a thousand articles on the server for each request adds unnecessary round-trips and network dependency. For mobile apps, local Full-Text Search (FTS5) is better. It works instantly, offline, and loads only the device.

Android — Room FTS4:

@Fts4(contentEntity = KbArticle::class)
@Entity(tableName = "kb_articles_fts")
data class KbArticleFts(
    val title: String,
    val searchIndex: String
)

@Dao
interface KbSearchDao {
    @Query("SELECT * FROM kb_articles WHERE id IN " +
        "(SELECT rowid FROM kb_articles_fts WHERE kb_articles_fts MATCH :query)")
    suspend fun search(query: String): List<KbArticle>
}

iOS — SQLite with FTS5 via GRDB.swift:

try db.create(virtualTable: "articles_fts", using: FTS5()) { t in
    t.column("title")
    t.column("body")
    t.tokenizer = .unicode61()
}

How to Ensure Offline Access and Analytics

Markdown/HTML Rendering

Articles are often stored in Markdown. We choose native libraries: Markwon for Android and Down for iOS. They support tables, code blocks with syntax highlighting, and images — sufficient for technical documentation. WebView provides full HTML/CSS but is slower for navigation. For basic Markdown on iOS 15+, you can use AttributedString without dependencies.

Offline Access

The knowledge base must work without internet. All articles are stored locally after first download. Images are cached using Kingfisher (iOS) or Coil (Android) with a max cache size of 200 MB. Data updates only when a network is available.

Analytics and Feedback

A "Was this helpful?" button provides simple feedback. We send an event with article_id and helpful: true/false to Firebase Analytics.

Analytics.logEvent("kb_article_feedback", parameters: [
    "article_id": article.id,
    "helpful": isHelpful ? "yes" : "no",
    "time_spent_seconds": Int(Date().timeIntervalSince(openedAt))
])

time_spent_seconds gives an extra signal: if a user reads for 3 seconds and clicks "not helpful" — the article is off-topic. If they spend 5 minutes and click "helpful" — the content is deep and relevant. This analytics helps improve documentation.

What's Included in the Work?

• Documentation: DB schema, API description, content update instructions.
• Access: test accounts for CMS, App Store Connect / Google Play Console.
• Source code: repository with the knowledge base module, test coverage 80%+.
• Training: workshop for the support team on content creation.
• Support: 2 weeks of free post-release assistance.

Development Stages and Timelines

Development cost is calculated individually after audit. The time savings for users finding information pays off within the first month. We're ready to evaluate your project — contact us for a consultation. Order a turnkey knowledge base development and get a stable solution that improves user experience.

What Does Mobile App Support Really Cover?

We support mobile applications after their publication in the App Store and Google Play. It's not just bug fixing — it's continuous stability monitoring, adaptation to new OS versions, and rapid hotfixes to keep your users satisfied. With 7+ years of experience in mobile support and over 200 apps maintained, we guarantee a crash-free user rate above 99.5% for most projects.

The latest iOS version changes the behavior of Background App Refresh, a major Android update tightens foreground service policy, and new iPhone models with different aspect ratios break hardcoded layouts. All this requires a response without a full development cycle. Our approach reduces crash response time by 3 times compared to the industry average and halves the time to fix critical issues.

Crash Monitoring in Production

Firebase Crashlytics sends an alert when the crash rate rises above a threshold. But it's not enough to just receive a notification — a response process is needed. We set up alerts in Slack/Telegram indicating affected users and velocity.

The metric we look at first: crash-free users rate. Below 99.5% — a warning signal. Below 99% — an incident. Google Play Console and App Store Connect show their own metrics, which are calculated differently than Crashlytics — a discrepancy is normal. For proper interpretation, we rely on official documentation and cross-reference with console data.

Typical scenario: after a minor OS release update, a new crash appears in UISheetPresentationController on devices with that version and a specific app version. Crashlytics shows 0.3% affected users but growing velocity. Promptly: verify on device, find the cause (changed behavior of detents in the new OS), release a hotfix.

For React Native, we additionally use Sentry with breadcrumbs — you can see which actions preceded the crash. For Flutter — sentry_flutter with WidgetsFlutterBinding.ensureInitialized() and runZonedGuarded.

How to Respond Quickly to a Crash Rate Increase?

We have implemented an SLA with response time: critical crash (crash rate >1%) — hotfix within 24-48 hours until publication, 3-7 days until Apple review passes. Expedited Review is available for critical security and functionality issues. For Android — expedited review via Google Play Console. We have a 98% success rate for getting expedited reviews approved.

Hotfixes: What Can Be Done Without Store Publication

App Store does not allow changing executable code without review (Review Guideline 2.5.2). But there are legal mechanisms for rapid intervention.

Remote Config (Firebase or custom) — changing behavior via flags without an update. Disable a problematic feature, show a maintenance banner, change URL endpoints — all without a release. Critical for monetization experiments and quick rollbacks.

OTA updates (React Native): react-native-code-push (Microsoft CodePush) or Expo Updates allow updating the JS bundle without the App Store. Limitation: only JS code, native modules require a full update. Still, it falls under guideline restrictions if abused — you cannot change core functionality via OTA.

Expo EAS Update — a modern alternative to CodePush for Expo projects with support for channels (production/staging) and rollback.

Why Do We Test Against Every Major OS Version?

Apple announces iOS beta in June (WWDC), final release in September. That gives three months for testing. In practice, many teams start in August and get surprises on release day. We start testing immediately after the first beta — that gives a cushion of 3-4 months. Our clients avoid 90% of OS-related crashes this way.

Critical areas to check with each major OS update:

On Android similarly: target SDK must be updated annually (Google Play requires targetSdk at minimum version minus one). Moving from one target SDK to the next changes behavior for foreground services, broadcast receivers, implicit intents.

Technical Debt and Planning

Support is not only about reacting to bugs. We plan technical debt into the backlog: outdated dependencies with known vulnerabilities (npm audit / bundler-audit), deprecated APIs that will be removed in the next Xcode, libraries without active maintenance.

Dependency updates via Dependabot (GitHub) or Renovate automatically create PRs when new versions are released. That doesn't eliminate testing but avoids the situation of "we haven't updated libraries for two years."

Minimum supported OS version — we review annually. Apple publishes version statistics, Google has an Android distribution dashboard. Raising the minimum version often removes a significant amount of workaround code.

Deliverables and Timeline

Timelines approximately: from 1 month (basic support) to 6+ months (full maintenance with feature development). Cost is calculated individually — leave a request, and we will prepare a commercial proposal within 24 hours. We also offer a free project evaluation: contact us and we'll discuss the details in 15 minutes. Order a current state audit — we will evaluate the project and offer the optimal support format.