Knowledge Base Implementation in Mobile App

Implementing Knowledge Base in Mobile Apps

Knowledge base differs from FAQ in scale and structure: not 20 Q&A pairs but hundreds of articles with categorization, search, content versioning, and topic navigation. For mobile, this means different architecture: local index search, caching, offline access, and markup rendering.

Content Sources and Synchronization

CMS Backend with API

Most universal approach—own or headless CMS (Contentful, Strapi, Sanity) with REST/GraphQL API. Mobile client downloads articles on first launch and on update, stores in local database.

// Android: Room schema for KB 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
)

@Entity(tableName = "kb_categories")
data class KbCategory(
    @PrimaryKey val id: String,
    val title: String,
    val parentId: String?,
    val position: Int
)

Sync by updatedAt: download only changed articles since last sync timestamp.

Zendesk Help Center / Freshdesk Solutions

If support uses Zendesk—Help Center API provides articles directly. Zendesk SDK shows through built-in UI, but it's poorly customizable. For custom design, use Zendesk Guide API:

GET https://yoursubdomain.zendesk.com/api/v2/help_center/articles.json

Response contains body in HTML—render via WebView with custom CSS matching app design system.

Full-Text Search

Querying server for each search on thousand articles—wasteful. For mobile, local Full-Text Search is better.

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—CoreData with NSPredicate or SQLite FTS5:

// NSPredicate for CoreData
let predicate = NSPredicate(
    format: "title CONTAINS[cd] %@ OR content CONTAINS[cd] %@",
    query, query
)

For large bases (>500 articles)—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()
}

FTS5 with unicode61 tokenizer supports Cyrillic—important for Russian-language apps.

Markdown/HTML Rendering

Articles often stored in Markdown. Rendering options:

Markwon for Android supports tables, code blocks with syntax highlighting, and images—sufficient for technical docs.

Analytics and Article Feedback

"Was this article helpful?" button—simple mechanism for content quality assessment. Send event with article_id and helpful: true/false to Firebase Analytics. Articles with high "not helpful" %—candidates for rework.

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

time_spent_seconds provides additional signal: 3 seconds and "not helpful"—article off-topic. 5 minutes and "helpful"—deep, relevant content.

Offline Access

KB should work without internet—users may consult docs in no-signal areas. All articles after first load stored locally. Images cached via Kingfisher (iOS) or Coil (Android) with max cache size settings.

Workflow

Audit content source and decide architecture (headless CMS, helpdesk API, or custom backend).

Design data schema with category hierarchy and search.

Implement: sync, local storage, FTS, content rendering.

UI: category navigation, article screen, search with match highlighting.

Analytics and offline mode.

Timeline Estimates

Basic KB with remote API, search, and offline—1–2 weeks. Zendesk Help Center integration, custom Markdown rendering, and analytics—up to 3 weeks.