Adding PDF Viewing and Export to a Rork Max App — When to Use PDFKit vs. ImageRenderer

Adding Search and Thumbnails — Making It Actually Readable

WebView can approximate plain display, but PDFKit earns its keep by giving you search and thumbnails in a few lines:

// Find a keyword and jump to the first match
if let document = pdfView.document {
    let matches = document.findString("invoice", withOptions: .caseInsensitive)
    if let first = matches.first {
        pdfView.go(to: first)
        pdfView.setCurrentSelection(first, animate: true)
    }
}

A thumbnail strip is just a PDFThumbnailView connected to your PDFView:

let thumbnail = PDFThumbnailView()
thumbnail.pdfView = pdfView          // selection stays in sync
thumbnail.thumbnailSize = CGSize(width: 44, height: 60)
thumbnail.layoutMode = .horizontal

For apps that handle long documents, these two features are the difference between "it displays" and "you can read it." On the import side, the security-scoped URL patterns from importing the user's own files from the Files app apply directly here.

Generating PDFs (1): UIGraphicsPDFRenderer — Composing Pages Yourself

For export, the workhorse is UIGraphicsPDFRenderer. You pick a page size and place text and graphics inside a drawing closure — and crucially, you control pagination yourself:

import UIKit
 
func exportNotesPDF(title: String, body: String) -> URL {
    let pageRect = CGRect(x: 0, y: 0, width: 595.2, height: 841.8) // A4 at 72dpi
    let renderer = UIGraphicsPDFRenderer(bounds: pageRect)
    let url = FileManager.default.temporaryDirectory
        .appendingPathComponent("notes-\(Int(Date().timeIntervalSince1970)).pdf")
 
    let titleAttrs: [NSAttributedString.Key: Any] = [
        .font: UIFont.systemFont(ofSize: 20, weight: .bold)
    ]
    let bodyAttrs: [NSAttributedString.Key: Any] = [
        .font: UIFont.systemFont(ofSize: 12),
        .paragraphStyle: NSParagraphStyle.default
    ]
 
    try? renderer.writePDF(to: url) { context in
        context.beginPage()
        title.draw(in: CGRect(x: 48, y: 48, width: 499, height: 40),
                   withAttributes: titleAttrs)
 
        let bodyText = NSAttributedString(string: body, attributes: bodyAttrs)
        let framesetter = CTFramesetterCreateWithAttributedString(bodyText)
        var currentRange = CFRange(location: 0, length: 0)
        var firstPage = true
 
        repeat {
            if !firstPage { context.beginPage() }
            let top: CGFloat = firstPage ? 100 : 48
            let textRect = CGRect(x: 48, y: top, width: 499,
                                  height: pageRect.height - top - 48)
            let path = CGPath(rect: textRect, transform: nil)
            let frame = CTFramesetterCreateFrame(framesetter, currentRange, path, nil)
 
            // Core Text uses a bottom-left origin — flip before drawing
            let cg = context.cgContext
            cg.saveGState()
            cg.translateBy(x: 0, y: pageRect.height)
            cg.scaleBy(x: 1, y: -1)
            CTFrameDraw(frame, cg)
            cg.restoreGState()
 
            let visible = CTFrameGetVisibleStringRange(frame)
            currentRange.location += visible.length
            firstPage = false
        } while currentRange.location < bodyText.length
    }
    return url
}

Three things matter here. First, pagination works by asking CTFrameGetVisibleStringRange how many characters actually fit, then carrying the remainder to the next page. Second, Core Text's coordinate system has its origin at the bottom-left, so you must flip the context or your text renders upside down. Third, non-Latin text (Japanese, in my case) embeds correctly with the system font — no font-bundling work required.

Generating PDFs (2): ImageRenderer — a SwiftUI View as a Single Page

On iOS 16 and later, SwiftUI's ImageRenderer can turn a view directly into a PDF. The idea is to treat a screen you've already laid out in SwiftUI as the "paper":

import SwiftUI
 
@MainActor
func exportViewAsPDF<V: View>(_ view: V, size: CGSize) -> URL {
    let url = FileManager.default.temporaryDirectory
        .appendingPathComponent("summary.pdf")
    let renderer = ImageRenderer(content: view.frame(width: size.width,
                                                     height: size.height))
    renderer.proposedSize = .init(size)
 
    renderer.render { rendered, draw in
        var box = CGRect(origin: .zero, size: rendered)
        guard let context = CGContext(url as CFURL, mediaBox: &box, nil) else { return }
        context.beginPDFPage(nil)
        draw(context)
        context.endPDFPage()
        context.closePDF()
    }
    return url
}

But ImageRenderer has a hard limit: it has no concept of pages. Long content becomes one very tall page. My own decision criteria:

1. Single-screen documents like monthly summaries or receipts → ImageRenderer. It's a few lines of code, and design changes stay entirely in SwiftUI.
2. Content of unpredictable length, like notes or meeting minutes → UIGraphicsPDFRenderer. Owning pagination is the deciding factor.
3. Annotating or merging existing PDFs → PDFKit's PDFAnnotation and PDFDocument.insert(_:at:). If you want handwritten annotations, this combines naturally with the approach in building a handwriting note app with PencilKit.

Password Protection and the Share Sheet — Finishing the Export Path

When people export work records, password-protected export comes up regularly. It's a single call — pass encryption options to PDFDocument.write(to:withOptions:):

if let document = PDFDocument(url: exportedURL) {
    let protectedURL = FileManager.default.temporaryDirectory
        .appendingPathComponent("protected.pdf")
    document.write(to: protectedURL, withOptions: [
        .userPasswordOption: userPassword,    // for opening
        .ownerPasswordOption: ownerPassword   // for permissions (use a different value)
    ])
}

For sharing, hand the URL to SwiftUI's ShareLink and the share sheet opens. Write exports to temporaryDirectory and clean them up after sharing or on next launch so they never pile up in storage. If you'd rather show an in-app preview before sending, the pattern from calling Quick Look safely from your app slots in nicely — people appreciate seeing exactly what they're about to send.

Pitfalls I Hit in Production

In the order I stumbled into them:

1. ImageRenderer resolution: the default scale is 1.0, which looks blurry in print. When rendering images, set renderer.scale = displayScale. (Text drawn into the PDF context stays vector and is unaffected, but embedded images are not.)
2. Encryption applies to the copy: write(to:withOptions:) doesn't change the already-open PDFDocument. Always write the protected version to a separate URL, and decide up front what happens to the original.
3. Diffing on documentURL: replacing document on every updateUIView call resets the reading position. Compare URLs and only swap when the file actually changed.
4. The filename shows up in the share sheet: whatever you name the file in temporaryDirectory is what recipients see. A mechanical name like notes-1751522400.pdf makes a very different impression than one with a date or title in it.

The week I shipped the export feature, the "why can't I send this as a PDF" reviews stopped — and the app's name started traveling through share sheets to people who had never seen it. It's an unglamorous feature, but a file that leaves your app as a finished deliverable doubles as a small advertisement.

Your Next Step

Start by exporting one record from your own app onto a single A4 page with UIGraphicsPDFRenderer. Pagination and passwords can wait. Once you've seen information from inside your app become a properly formatted document out in the world, your users' reactions will tell you which feature to build next.