Office Document Viewing in Mobile Apps
We often implement office document viewing in mobile applications. .docx, .xlsx, .pptx — Office Open XML formats based on ZIP archives with XML inside. Unlike PDF, they have no standard renderer on mobile platforms. Each manufacturer solves this differently: Microsoft provides SDK, Google offers Document Viewer API, and others rely on third-party libraries with variable rendering quality for tables and formulas.
Which approach to choose for your project?
Three strategies stand out:
-
Server-side conversion to PDF/images: The document is uploaded to your server, converted via LibreOffice/unoserver, and returned as PDF or PNG. The client receives a ready-to-display format. Pros: predictable rendering, no dependency on mobile SDK. Cons: conversion latency (1–3 seconds), document transmission through server (GDPR concerns for sensitive data).
-
Native OS viewer: Open the document in a system app (Microsoft Office, QuickLook on iOS). This leaves the confines of your own app — sometimes unacceptable.
-
Client-side rendering library: An embedded renderer in React Native/Flutter. Limited format support, but no server dependency.
Why QuickLook is ideal for iOS
iOS provides QLPreviewController — a system viewer supporting .docx, .xlsx, .pptx, .pdf, .txt, images, archives. It integrates into the app via a native module:
// RCT Bridge Module @objc func previewDocument(_ filePath: String) { DispatchQueue.main.async { let url = URL(fileURLWithPath: filePath) let previewController = QLPreviewController() previewController.dataSource = self // present over current context UIApplication.shared.windows.first?.rootViewController? .present(previewController, animated: true) } } QLPreviewController renders Microsoft documents through the system engine — quality identical to Microsoft Office on iOS. Limitation: view-only, no editing. In React Native, react-native-doc-viewer uses QLPreviewController under the hood for iOS. Comparison: QLPreviewController renders 2x faster than popular third-party libraries on WebView.
What about Android?
Android lacks a built-in analog of QLPreviewController for Office documents. Options:
Intent ACTION_VIEW: launches an external app (Google Drive Docs, Microsoft Office, WPS Office). The user must have at least one of them. If not, the app crashes with ActivityNotFoundException. Mandatory check:
val intent = Intent(Intent.ACTION_VIEW).apply { setDataAndType(fileUri, getMimeType(filePath)) flags = Intent.FLAG_GRANT_READ_URI_PERMISSION } val resolveInfo = packageManager.resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY) if (resolveInfo != null) { startActivity(intent) } else { // Fallback: suggest installing Google Docs or open as PDF } Aspose.Words for Android via Java: commercial SDK, renders .docx without installed Office. Quality close to Microsoft Word.
Android WebView + Google Docs Viewer: https://docs.google.com/viewer?url=<encoded_url>. Works for public files. For private ones, the file must be temporarily placed at an accessible URL or use Google Drive API.
react-native-doc-viewer: cross-platform wrapper
import FileViewer from 'react-native-file-viewer'; import RNFS from 'react-native-fs'; const openDocument = async (url: string, filename: string) => { // Download file to cache directory const localPath = `${RNFS.CachesDirectoryPath}/${filename}`; const exists = await RNFS.exists(localPath); if (!exists) { await RNFS.downloadFile({ fromUrl: url, toFile: localPath }).promise; } await FileViewer.open(localPath, { showOpenWithDialog: true, // Android: choose app dialog showAppsSuggestions: true, }); }; On iOS FileViewer uses QLPreviewController. On Android — ACTION_VIEW with file:// URI via FileProvider (direct file:// URI is blocked on Android 7+).
Server-side conversion: LibreOffice Headless
For maximum compatibility and privacy (document never leaves your infrastructure):
# Conversion .docx → .pdf via LibreOffice headless libreoffice --headless --convert-to pdf --outdir /output /input/document.docx unoserver — REST API atop LibreOffice for production use. Converting a typical .docx takes 1–3 seconds. Cache results by file hash — never convert the same file twice. According to LibreOffice Documentation, this mode ensures consistent rendering across all platforms.
Approach comparison
| Approach | iOS | Android | Privacy | Latency |
|---|---|---|---|---|
| QLPreviewController | Excellent | — | High | None |
| Intent + third-party | — | Depends | Medium | None |
| Server conversion | Excellent | Excellent | Low | 1–5 sec |
| Aspose SDK | Excellent | Excellent | High | None |
| Google Docs Viewer | Good | Good | Low | 2–4 sec |
Contact us to select the optimal solution for your project.
How to integrate QuickLook: step-by-step guide
- Create a native module for iOS that accepts a file path and displays QLPreviewController. Use the Swift code above.
- Export the module to React Native via RCTBridgeModule (or similarly for Flutter).
- Call the method from JavaScript:
NativeModules.PreviewDocument.show(filePath). Ensure the file exists locally.
Why server-side conversion costs more?
Server-side conversion requires infrastructure: at least one LibreOffice instance and storage for cache. This increases operational cost by 20–30% compared to purely client-side solutions. However, it guarantees identical rendering on all devices and independence from third-party apps. If documents contain sensitive data, server-side conversion may be the only option compliant with security policies.
What's included in the work
- Requirements analysis and optimal strategy selection
- QuickLook integration on iOS (native module)
- Intent implementation with fallback on Android
- Server-side conversion setup via LibreOffice (if required)
- Caching converted files for offline viewing
- Testing on real devices and OS versions
- Documentation and team training
Why choose us
We have over 5 years of mobile development experience and 20+ projects integrating document viewing. Our solutions run 2x faster than alternatives due to caching optimization. We guarantee compatibility with the latest iOS and Android versions, as well as with App Store Review Guidelines and Google Play requirements.
Estimated timelines
| Stage | Duration |
|---|---|
| QuickLook + Intent integration | 2–3 weeks |
| + Server conversion | 3–4 weeks |
| + Offline viewing and caching | 4–6 weeks |
Get a consultation — we will evaluate your project within 1 business day. Contact us to discuss the details.







