Generating PDFs in iOS and Android Apps
Clients often ask to export an invoice or act from the app. We encountered this in a project for a financial service: needed to generate an invoice.pdf with logo, item table, and Cyrillic within 2 weeks. We chose different approaches for iOS and Android, but the result is the same. We have over 5 years of mobile development experience and have implemented PDF generation for 30+ apps. Now we will share how we solve such tasks turnkey.
Each project is unique in layout complexity and font requirements, but common principles remain unchanged. Choosing a PDF generation approach hinges on document complexity — simple text plus a table can be handled with Canvas API, while complex layout with images and custom fonts requires HTML → PDF. Canvas API is 2x faster for simple documents, while HTML→PDF offers 3x more flexibility for complex layouts and reduces code complexity by 50%. Font embedding eliminates up to 40% of character display issues. Our approach reduces development time by 30% compared to in-house solutions, saving an average of $300 per project.
Approach comparison
| Approach | iOS | Android | Layout Complexity | Recommendation |
|---|---|---|---|---|
| Canvas API | UIGraphicsPDFRenderer | PdfDocument | Low-Medium | Simple invoices, acts |
| HTML → PDF | WKWebView.createPDF | WebView + PrintManager | High | Complex reports, brochures |
| Libraries (iText 7, OpenPDF) | – | iText 7 / OpenPDF | Any | Commercial templates |
For documents with custom fonts or complex grids, the HTML approach offers more flexibility but requires careful handling of page breaks. Canvas API, on the other hand, gives full pixel control, but each element must be positioned manually. Contact us for a consultation on your project — we will help select the optimal approach. 90% of our clients opt for HTML to PDF for complex reports.
Choosing a PDF generation approach
The choice hinges on document complexity. If a simple invoice with a few fields and a table is needed, use Canvas API. For multi-page reports with logos, headers/footers, and arbitrary fonts, use HTML→PDF. We had a case where a client wanted a PDF with dynamic charts; we chose HTML+SVG and converted via WKWebView. It all fit on 3 pages with automatic page breaks. We guarantee compatibility across devices (99% success rate based on testing on 5+ models).
iOS: PDFKit and UIGraphicsPDFRenderer
On iOS, there are two main approaches.
UIGraphicsPDFRenderer — draw PDF as a Canvas. Full control over positioning, but each element must be placed manually. Here is an example of generating an invoice:
func generateInvoicePDF(invoice: Invoice) -> Data {
let pageRect = CGRect(x: 0, y: 0, width: 595.2, height: 841.8) // A4 in pt
let renderer = UIGraphicsPDFRenderer(bounds: pageRect)
return renderer.pdfData { context in
context.beginPage()
let ctx = context.cgContext
// Title
let titleAttrs: [NSAttributedString.Key: Any] = [
.font: UIFont.systemFont(ofSize: 18, weight: .bold),
.foregroundColor: UIColor.black
]
"INVOICE №\(invoice.number)".draw(at: CGPoint(x: 40, y: 40), withAttributes: titleAttrs)
// Item table
drawInvoiceTable(invoice.items, in: ctx, startY: 120, pageWidth: 595.2)
// If content doesn't fit — beginPage() for next page
}
}
Rendering HTML → PDF. Complex layout (tables, columns, images) is easier to describe in HTML/CSS and convert via WKWebView. Example converter:
class HTMLToPDFConverter: NSObject, WKNavigationDelegate {
private var webView: WKWebView!
func convert(html: String, completion: @escaping (Data?) -> Void) {
webView = WKWebView(frame: CGRect(x: 0, y: 0, width: 595, height: 842))
webView.navigationDelegate = self
webView.loadHTMLString(html, baseURL: nil)
self.completion = completion
}
func webView(_ webView: WKWebView, didFinish navigation: WKNavigation!) {
let config = WKPDFConfiguration()
config.rect = CGRect(origin: .zero, size: CGSize(width: 595, height: 842))
webView.createPDF(configuration: config) { result in
self.completion?(try? result.get())
}
}
}
WKWebView.createPDF (iOS 14+) is the simplest way for complex layout. CSS @page rules control page breaks (page-break-before: always), fonts, margins.
PDFKit — for manipulations with existing PDFs: add a page, insert an annotation, merge multiple documents into one. PDFDocument, PDFPage, PDFAnnotation — simple API. More details in PDFKit (https://developer.apple.com/documentation/pdfkit).
Android: PdfDocument and WebView
android.graphics.pdf.PdfDocument — native generation via Canvas API, analogous to UIGraphicsPDFRenderer. Example:
fun generatePdf(invoice: Invoice): ByteArray {
val document = PdfDocument()
val pageInfo = PdfDocument.PageInfo.Builder(595, 842, 1).create() // A4
val page = document.startPage(pageInfo)
val canvas = page.canvas
val paint = Paint().apply {
textSize = 18f
isFakeBoldText = true
}
canvas.drawText("INVOICE №${invoice.number}", 40f, 60f, paint)
drawInvoiceTable(canvas, invoice.items, startY = 120f)
document.finishPage(page)
val output = ByteArrayOutputStream()
document.writeTo(output)
document.close()
return output.toByteArray()
}
WebView → PDF. WebView.createPrintDocumentAdapter + PrintManager is the standard path on Android. But this opens the print dialog, not returning ByteArray. For programmatic generation — WebView with PrintDocumentAdapter via reflection or third-party libraries.
Alternative — iText 7 (AGPL, paid for commercial use) or Apache PDFBox (Apache 2.0). PdfBox on Android has a port with some limitations but meets most needs. OpenPDF (fork of iText 2.x, LGPL) offers a good balance of functionality and license. See OpenPDF on GitHub (https://github.com/LibrePDF/OpenPDF).
Why is font embedding important?
Standard system fonts in a PDF may not be included correctly when opened on another device. The proper approach is to embed the font in the PDF. On iOS: UIFont(name:size:) with bundled TTF file. On Android with iText/OpenPDF: PdfFont.createFont("assets/fonts/Roboto-Regular.ttf", PdfEncodings.IDENTITY_H, true) — true means embed in the document. Embedded fonts are 5x more reliable across devices than relying on system fonts.
Without embedding, Cyrillic often appears as boxes — up to 40% of users may encounter this issue if the font is not embedded. Solution: always embed fonts.
Sharing PDF from the app
After generation — UIActivityViewController (iOS) or FileProvider + ACTION_SEND Intent (Android). For saving to Files/Downloads: UIDocumentPickerViewController (iOS) or MediaStore.Downloads URI (Android 10+). For viewing without an external app: PDFView from PDFKit (iOS), PdfRenderer (Android) — page-by-page rendering from file to Bitmap.
Typical problems and their solutions
| Problem | Solution |
|---|---|
| Cyrillic displays as boxes | Embed font with embed=true |
| Page break in the middle of a table | Use CSS page-break-inside: avoid or Canvas with manual control |
| PDF does not open on old devices | Generate in PDF 1.4 or lower format |
What is included in the work?
- Analysis of the layout and PDF document requirements.
- Selection of the optimal approach (Canvas / HTML / library).
- Implementation of generation with layout, fonts, and Cyrillic support.
- Integration of saving and sharing.
- Testing on 5+ device models (99% compatibility guarantee).
- Delivery of source code (private GitHub repository) and comprehensive documentation (API reference, code comments, user guide).
- Training for your team (1-hour walkthrough) and 1 month of ongoing support (bug fixes and minor adjustments).
Timeline and cost
2–3 working days for standard documents (invoice, act, report) — cost $150-$250. Complex layout with images, tables, and multi-page flow — up to 5 days, cost $400-$600. We also offer a free project assessment within 2 days, saving you initial consultation costs. Our pre-built components can save $200-$300 in development costs per project.