Introduction

A fast PDF viewer on iPhone or iPad usually comes from using Apple’s native rendering stack well, not from building a large custom engine. The lean approach is to load the document lazily, render only what the user is likely to see, and avoid turning every page into an image too early.

Start with PDFKit

For most iOS apps, PDFKit is the right first choice. It provides page rendering, scrolling, zooming, and text selection without bringing in an extra dependency or forcing you to manage page drawing yourself.

A minimal viewer looks like this:

1import UIKit
2import PDFKit
3
4final class PDFViewController: UIViewController {
5    private let pdfView = PDFView()
6
7    override func viewDidLoad() {
8        super.viewDidLoad()
9
10        view.backgroundColor = .systemBackground
11        pdfView.translatesAutoresizingMaskIntoConstraints = false
12        pdfView.autoScales = true
13        pdfView.displayMode = .singlePageContinuous
14        pdfView.displayDirection = .vertical
15
16        view.addSubview(pdfView)
17
18        NSLayoutConstraint.activate([
19            pdfView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
20            pdfView.leadingAnchor.constraint(equalTo: view.leadingAnchor),
21            pdfView.trailingAnchor.constraint(equalTo: view.trailingAnchor),
22            pdfView.bottomAnchor.constraint(equalTo: view.bottomAnchor)
23        ])
24
25        if let url = Bundle.main.url(forResource: "guide", withExtension: "pdf") {
26            pdfView.document = PDFDocument(url: url)
27        }
28    }
29}

That baseline is already good enough for many document viewers, help centers, and reference guides.

Keep Rendering Work Small

A PDF viewer becomes heavy when it does too much work up front. Rendering every page at launch, precomputing large thumbnails, or rasterizing the whole document into UIImage objects wastes memory and often makes scrolling worse.

Instead, keep the document in PDF form for as long as possible. Let PDFView decide what to draw, and only add extra processing when you have measured a real bottleneck.

Good defaults for a lean viewer are:

• Load the PDFDocument when the screen opens.
• Show the first page immediately.
• Delay expensive features such as full-document search or mass thumbnail generation.
• Cache only small derived results that you know you need again.

If you want thumbnails, add them as a secondary feature rather than a startup requirement:

1import PDFKit
2
3let thumbnailView = PDFThumbnailView()
4thumbnailView.pdfView = pdfView
5thumbnailView.thumbnailSize = CGSize(width: 40, height: 56)
6thumbnailView.layoutMode = .horizontal

This still uses native code paths and keeps your implementation small.

Optimize Large Documents Carefully

A ten-page PDF can hide performance problems that appear immediately with a scanned manual containing hundreds of pages. If your app opens large or image-heavy files, measure on real hardware and separate startup cost from ongoing navigation cost.

A useful strategy is to make the initial experience fast first. Open the document, show the current page, and postpone anything optional until the interface is responsive. Text extraction, annotation indexing, and snapshot generation are all good candidates for deferred work.

If you truly need lower-level control, use Core Graphics with CGPDFDocument. That gives you direct page drawing and tighter memory control, but it also means more code and more rendering responsibility.

1import CoreGraphics
2import UIKit
3
4func drawFirstPage(of url: URL, in context: CGContext, rect: CGRect) {
5    guard let document = CGPDFDocument(url as CFURL),
6          let page = document.page(at: 1) else {
7        return
8    }
9
10    let transform = page.getDrawingTransform(.mediaBox, rect: rect, rotate: 0, preserveAspectRatio: true)
11
12    context.saveGState()
13    context.translateBy(x: 0, y: rect.height)
14    context.scaleBy(x: 1, y: -1)
15    context.concatenate(transform)
16    context.drawPDFPage(page)
17    context.restoreGState()
18}

Use that route only when PDFKit cannot meet a specific requirement such as custom tiling or a very specialized annotation workflow.

Common Pitfalls

One common mistake is converting every page into an image. That increases memory use, reduces zoom quality, and often performs worse than native page rendering.

Another issue is generating all thumbnails on launch. Thumbnail work feels harmless on a small sample file, but it becomes expensive with large documents and can delay the first usable screen.

Developers also sometimes test only in the simulator. A viewer that feels fine there may behave very differently on an older iPad with a scanned PDF.

Finally, do not build a custom renderer before proving that the native viewer is insufficient. Extra rendering code increases maintenance cost quickly.

Summary

• Start with PDFKit for most iPhone and iPad PDF viewers.
• Keep the document in PDF form instead of rasterizing every page.
• Delay optional work such as global thumbnail generation and indexing.
• Measure large documents on real devices before redesigning the renderer.
• Drop to Core Graphics only when native components cannot satisfy a clear requirement.