On iPadOS 26, PDFKit runs VNRecognizeDocumentsRequest over the pages of a PDFDocument when those pages are rendered. The analysis pipelines are never released. Measured on an iPad Pro 12.9-inch 4th gen (iPad8,11), iPadOS 26.6, with a 61-page image-only scanned score: each newly-created-and-rendered PDFDocument costs about 2.7 OS threads and 20 MB, permanently. Repeatedly loading the same file from disk reached 153 threads and 1519 MB in under seven minutes, then died of an allocation failure. Nothing releases it: not replacing PDFView.document, not deallocating the PDFView entirely, not releasing the PDFDocument, and not time. With every code path in the app stopped, the thread count does not fall — it continues to rise. The stack -[PDFView visiblePagesChanged:] → +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] → -[VNImageRequestHandler performRequests:gatheredForensics:error:] → -[VNRecognizeDocumentsRequest internalPerformRevision:inContext:error:] → -[VNDetector processUsingQualityOfServiceClass:options:regionOfInterest:…] → -[VNControlledCapacityTasksQueue dispatchSyncByPreservingQueueCapacity:] Thread census at 1519 MB — 153 threads total, after 66 document loads: 66 PDFKit.PDFDocument.formFillingQueue 64 com.apple.VNRecognizeDocumentsRequestRevision1 10 ANEServicesThread 66 orphaned pipelines for 66 loads, all blocked on Vision's capacity limiter. The console also emits Invalid permutation index when reordering subregions. Index N must be less than number of subregions 1 continuously, with N increasing — and these keep arriving after all application activity has stopped. Isolation Each row is a separate run on the same device and OS, one variable changed. Counts are OS threads; baseline is 13. Configuration Result Page-stepping only on a stable document (~1000 visiblePagesChanged: events) No growth; footprint declines Recreating PDFThumbnailView on every load No growth Creating a PDFDocument and never rendering it No growth Creating + rendering, assigned to a PDFView +2.0 to +2.7 threads / +20 MB per load Creating + rendering, never assigned to any PDFView Same growth Creating + rendering, entire PDFView destroyed and rebuilt per load Same growth Two points worth drawing out: The leak occurs with no PDFView involved at all — plain PDFPage.thumbnail(of:for:) or PDFPage.draw(with:to:) on a freshly created document is sufficient. Destroying the PDFView releases nothing. Whatever retains the analyses outlives every object the application can reach. Also, for anyone who arrives here from the other PDFPageAnalyzerV2 threads: the usePageViewController(true, withViewOptions: nil) workaround does not help this. It reduces visiblePagesChanged: frequency, and page changes on a stable document leak nothing. The variable is newly rendered documents, not new pages. The switch already exists PDFView implements -setDocumentAnalysisEnabled: and -isDocumentAnalysisEnabled, plus -handleAnalysisCompletionOfPage:resultTypes:. None of these appear in any public header. With document analysis disabled, the leak disappears completely — 28 consecutive document loads with zero thread growth, and after stopping, the process released down to 6 threads and 64 MB, below its own idle baseline. It also suppresses the leak for documents never assigned to that PDFView, so whatever the flag gates is not scoped to a single view. For completeness, the per-page -setCandidateForOCR: / -setDidPerformOCR: accessors do not help: the writes land and read back correctly, and the analysis runs anyway. They appear to be state rather than policy. Request Either: Fix the leak — cancel and release analyses when the document or the view goes away; or Make documentAnalysisEnabled public on PDFView (or add an equivalent on PDFDocument). Ideally, please do both. The second costs Apple nothing: the property exists, it works, and it is exactly the control that is needed. Applications that render sheet music, engineering drawings, or any other content where document understanding provides no value are currently paying for it with unbounded memory growth and no supported way to decline. Filed as FB24211659. Happy to share the isolation harness with anyone from the PDFKit team. Related: 825803 (crash in PDFPageAnalyzerV2, FB22409977), 827781 (deadlock in the same class), 838272 / 837282 (PDFTileSurface over-release), 107007 (CGContextDrawPDFPage thread safety, open since 2018).

Hello. Some users of my app experience crashes that mention PDFKit. I managed to find out what specific PDF file caused the crash and created a sample that demonstrates the issue and created a bug report in Feedback Assistant (FB22409977). Unfortunately I didn't get any answer for over a month, hence I'm writing it here so others can see that this is a known issue. The crash repro sample is very simple, it's just a PDFView that opens a bundled PDF file upon application lanunch. To cause the crash it is only needed to zoom-in and move around the page that has a table. The crash happens when the system tries to do some sort of OCR. The original crash report came from iPhone 11 user running iOS 26.3.1. Recently another user with iPhone 16 Pro Max running 26.5 experienced the same crash. Thread 12 Queue : PDFKWit.PDFDocument.formFillingQueue (serial) #0 0x000000018d320bd8 in PageLayout::GetBoundsForRangeWithinLine () #1 0x000000018d320c88 in PageLayout::GetBoundsForTextRange () #2 0x000000018d393028 in CGPDFTaggedNodeCreateCopyWithStringRange () #3 0x000000018d316630 in invocation function for block in TaggedParser::InsertLinkAnnotationsIntoStructureTree(CGPDFTaggedNode*, CGPDFPage*, PageLayout&) () #4 0x000000018d104f00 in CGPDFPageEnumerateAnnotations () #5 0x000000018d106968 in CGPDFPageCopyRootTaggedNode () #6 0x000000018d106710 in CGPDFPageInsertTableDescriptions () #7 0x00000001957a65b8 in +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] () #8 0x00000001957a3030 in +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] () #9 0x000000019584c018 in __31-[PDFView visiblePagesChanged:]_block_invoke () When CG_PDF_VERBOSE env variable is set, "New text range needs to be within the original node's text range." warning is printed to console several times before the crash happens.

最常见的是这个： Thread 1 Queue : com.apple.main-thread (serial) #0 0x0000000190bcb3c4 in CFRelease.cold.2 () #1 0x0000000190a2c50c in CFRelease () #2 0x00000001d194ad38 in -[PDFTileSurface releaseSurface] () #3 0x00000001d194c230 in -[PDFTilePool releasePDFTileSurface:] () #4 0x00000001d194f618 in -[PDFPageLayerTile dealloc] () #5 0x0000000190a4778c in -[__NSArrayI_Transfer dealloc] () #6 0x000000018d5d57f8 in AutoreleasePoolPage::releaseUntil () #7 0x000000018d5d5684 in objc_autoreleasePoolPop () #8 0x000000019668d43c in -[UIScrollView setContentOffset:] () #9 0x000000018dd70918 in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] () #10 0x000000018ddd1298 in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] () #11 0x000000018ded5b28 in _NSSetPointValueAndNotify () #12 0x0000000196c49af0 in -[UIScrollView _smoothScrollSyncWithUpdateTime:] () #13 0x0000000196c491a0 in -[UIScrollView _smoothScrollWithUpdateTime:] () #14 0x0000000196c490b0 in -[UIScrollView smoothScrollDisplayLink:] () #15 0x000000026186a66c in -[DYDisplayLinkInterposer forwardDisplayLinkCallback:] () #16 0x00000001914cc77c in CA::Display::DisplayLinkItem::dispatch () #17 0x00000001914a4388 in CA::Display::DisplayLink::dispatch_items () #18 0x00000001914bb2b8 in CA::Display::DisplayLink::dispatch_deferred_display_links () #19 0x000000019671e2a8 in _UIUpdateSequenceRunNext () #20 0x000000019671b834 in schedulerStepScheduledMainSectionContinue () #21 0x00000002a437256c in UC::DriverCore::continueProcessing () #22 0x0000000190a3f1d8 in __CFMachPortPerform () #23 0x0000000190a81824 in CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION () #24 0x0000000190a8174c in __CFRunLoopDoSource1 () #25 0x0000000190a4c6e4 in __CFRunLoopRun () #26 0x0000000190a4b54c in _CFRunLoopRunSpecificWithOptions () #27 0x0000000235da7498 in GSEventRunModal () #28 0x0000000196744244 in -[UIApplication _run] () #29 0x00000001966af158 in UIApplicationMain () #30 0x00000001968bb618 in ___lldb_unnamed_symbol_1893835b0 () #31 0x0000000105a7a308 in static UIApplicationDelegate.main() () #32 0x0000000105a7a278 in static AppDelegate.$main() () #33 0x0000000105a7a3cc in main () #34 0x000000018d659c1c in start ()

I'm using PDFKitView: NSViewRepresentable to present the pdf page in SwiftUI. Seems we already have some useful built-in functions in the context menu. However, the highlight manipulation functions are not functional - I can neither delete the highlight annotation nor change the color/type of the current pointed highlight annotation. The "Add Note" and other page display changing functions work well.

Recurring fatal crash inside PDFKit's private tile-rendering pool. Exception is EXC_BREAKPOINT trapped inside CFRelease.cold.2, called from -[PDFTileSurface releaseSurface], reached via -[PDFTilePool releasePDFTileSurface:] <- -[PDFPageLayerTile dealloc]. Symptom matches an over-release / stale-reference bug in PDFTilePool's internal bookkeeping, not app-level misuse. This is a DIFFERENT app/codebase than the one already reported in Developer Forums thread 837282 (https://developer.apple.com/forums/thread/837282?answerId=896871022#896871022), hitting the identical 3-frame private call chain. That report used PDFView + a PKCanvasView overlay and speculated PencilKit/DYDisplayLinkInterposer overlay timing might be a factor. Our app uses a plain PDFView with NO PencilKit/PKCanvasView overlay of any kind, which rules that out as a necessary trigger -- the bug reproduces on stock PDFKit alone. Crash signature (symbolicated, from production Crashlytics): #0 CFRelease.cold.2 #1 CFEqual (also seen as plain CFRelease in the other report -- same release path) #2 -[PDFTileSurface releaseSurface] #3 -[PDFTilePool releasePDFTileSurface:] #4 -[PDFPageLayerTile dealloc] ... (see "Independent trigger paths" below for what appears above frame #4) blameFrame: CFRelease.cold.2, CoreFoundation, owner: PLATFORM (Crashlytics-attributed, no app frames anywhere in the crashing thread across any sample). Independent trigger paths observed (all converge on the same 3-frame chain above): Async tile-render completion (our most common variant, ~57% of our occurrences): -[PDFPageLayerTile recievePDFTileSurface:] -> -[PDFPageLayer tileDrawingComplete:] -> old tiles array dealloc -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 Page-turn animation completion: -[PDFDocumentViewController pageViewController:didFinishAnimating:previousViewControllers:transitionCompleted:] -> -[PDFPageView clearTiles] -> -[PDFPageLayer _releaseTiles] -> -[__NSArrayM removeAllObjects] -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 CATransaction commit / layer teardown: CA::Transaction::commit() -> CA::release_root_if_unused(...) -> CA::release_objects(...) -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 (from forum thread 837282, different app) UIScrollView content-offset smooth scroll: -[UIScrollView setContentOffset:] -> smooth-scroll display link -> autorelease pool drain -> -[PDFPageLayerTile dealloc] -> ... -> CFRelease.cold.2 Four independent call sites funneling into the same release path strongly suggests the bug is inside PDFTilePool/PDFTileSurface's own reference counting, not any one caller's usage pattern. Diagnostic instrumentation (our own investigation, not yet submitted anywhere): We swizzled -[PDFTileSurface releaseSurface] in a debug build and logged every call (thread, surface pointer identity, re-entrancy count via a weak-keyed NSMapTable) during normal PDF navigation (page turns, scroll, zoom) on an affected device model. Across all observed calls: every surface was released exactly once, always on the main thread -- no Objective-C-level double-call or cross-thread race was observed at the releaseSurface entry point itself. This suggests the over-release is not "PDFTilePool calling release twice" but more likely a race between PDFTilePool's single, correctly-ordered release call and a separate system-level reclaim of the tile's backing store (e.g. IOSurface/purgeable memory eviction under memory pressure) that PDFTilePool's bookkeeping doesn't account for -- consistent with the device skew below. Device / OS distribution (production Crashlytics, 90-day window, 51 events, ~37 impacted users): iPad12,1 (iPad 9th gen): 45 events (88%) iPad11,7 (iPad 8th gen): 4 events iPad15,4 (iPad Air 11" M3): 1 event iPad11,4 (iPad Air 3rd gen): 1 event 100% on iPadOS 26.5.0 within this window This matches forum thread 837282's own report of "iPad 8, iPad 9 ... lower-end devices heavily affected" on iOS 26.4.2/26.5, "not affected on iOS 18.x" -- independent corroboration from two unrelated codebases of a regression concentrated on lower-RAM iPads specifically on 26.x. Expected Result: PDFKit's internal tile pool releases each rendered tile surface exactly once and does not trap inside CFRelease regardless of memory pressure, device tier, or which internal code path (render-complete, page-turn, layer-commit, scroll) triggers the release. Actual Result: App crashes with EXC_BREAKPOINT inside CFRelease.cold.2 during ordinary PDF viewing (page turns, scrolling, or async tile-render completion), concentrated on lower-RAM iPads (iPad 8th/9th gen) running iPadOS 26.4.2/26.5. Configuration: Plain PDFView (paged, .singlePage, displayDirection .horizontal), no PKCanvasView/PencilKit Affected iPadOS versions: 26.4.2, 26.5 (not reproduced on iOS 18.x per forum thread) Most affected devices: iPad 8th/9th generation (3GB RAM tier) Related report: https://developer.apple.com/forums/thread/837282?answerId=896871022#896871022 (same 3-frame private call chain, different app, DTS could not reproduce with vanilla PDFKit+PencilKit under stress testing as of that thread; no FB filed there yet)

Environment Device: iPad Pro 11-inch 2nd gen (iPad8,9 / A12X) OS: iPadOS 26.5 (23F77) Xcode: 26.3 Issue App crashes with EXC_BREAKPOINT / SIGKILL when user scrolls through a PDF in PDFView on iPadOS 26.5. Crash Log (ASI) "BUG IN CLIENT OF LIBPLATFORM: Trying to recursively lock an os_unfair_lock" Abort Cause 259 Root Cause (from .ips) Two threads deadlock on os_unfair_lock inside CGPDFPageInsertTableDescriptions: Thread 0 (main): _os_unfair_lock_recursive_abort CGPDFPageInsertTableDescriptions [PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:]_block_invoke_2 _dispatch_async_and_wait_invoke ← main thread waiting Thread (PDFKit.PDFDocument.formFillingQueue): _dispatch_sync_f_slow ← background queue waiting for main thread +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] -[PDFView visiblePagesChanged:] ← triggered by scrolling PDFPageAnalyzerV2 dispatches_sync back to the main thread from PDFKit.PDFDocument.formFillingQueue, while the main thread is already blocked in dispatch_async_and_wait for the same operation. This results in a recursive lock on os_unfair_lock in CGPDFPageInsertTableDescriptions → SIGKILL. Notes PDFPageAnalyzerV2 appears to be a new iOS 26 Vision-based table analysis feature No public API found in PDFKit headers to disable this analysis Workaround: pdfView.usePageViewController(true, withViewOptions: nil) appears to reduce frequency of visiblePagesChanged: triggers Question Is there an official API to disable PDFPageAnalyzerV2 table analysis on iOS 26? Is this a known issue with a fix planned?

I've run into what appears to be a bug in PDFKit's radio button serialization. When creating a radio button group with PDFAnnotation, only the first annotation added via page.addAnnotation() gets a correct /AS entry in the written PDF — all other annotations always get /AS /Off, regardless of buttonWidgetState. Minimal reproduction func makeRadioButton(optionId: String, isSelected: Bool) -> PDFAnnotation { let ann = PDFAnnotation(bounds: CGRect(x: 0, y: 0, width: 20, height: 20), forType: .widget, withProperties: nil) ann.widgetFieldType = .button ann.widgetControlType = .radioButtonControl ann.fieldName = "Choice" ann.buttonWidgetStateString = optionId ann.buttonWidgetState = isSelected ? .onState : .offState return ann } let pdf = PDFDocument() let page = PDFPage() pdf.insert(page, at: 0) // Intend to select B page.addAnnotation(makeRadioButton(optionId: "A", isSelected: false)) page.addAnnotation(makeRadioButton(optionId: "B", isSelected: true)) page.addAnnotation(makeRadioButton(optionId: "C", isSelected: false)) _ = pdf.dataRepresentation() // Result: /AS is /Off for all three — B is not selected in the PDF What I observed Selecting A (first annotation added): /AS /A written correctly works Selecting B or C: /AS /Off for all buttons Additionally, dataRepresentation() corrupts the in-memory state as a side effect: buttonWidgetState of the selected annotation is .onState before the call and .offState after. Root cause During serialization, dataRepresentation() internally calls setButtonWidgetState:.onState on each annotation in turn to generate appearance streams. This triggers PDFKit's radio-group exclusivity logic, which silently clears all other annotations — so by the time /AS is written, only the first annotation's selection survives. Workaround It took a while to track this down, so I'm documenting the workaround here in case it helps others. Add the annotation that should be selected first via page.addAnnotation(): // Add selected annotation first page.addAnnotation(makeRadioButton(optionId: "B", isSelected: true)) page.addAnnotation(makeRadioButton(optionId: "A", isSelected: false)) page.addAnnotation(makeRadioButton(optionId: "C", isSelected: false)) Tested on macOS 26.3 / Xcode 26.3. Filed as Feedback FB22167174. Full code including workaround is here: radio_bug_swift.txt Has anyone else hit this? Is there a cleaner method I'm missing?

In Swift, iOS, I have a pdf file. I want to take the pages 2 by 2 and put them side by side, on the new page. For this, I have to scale initial pages half size and rotate .pi/2. I managed to achieve this by converting pdf pages to UIImages and using a UIGraphicsImageRenderer. But with a critical loss of resolution. I've tried improving the resolution by creating images as jpegData(withCompressionQuality: 1.0), to no avail. So I would need to work directly on the pdf pages using CGPDFDocument format. The code structure is as follows, to insert a single scaled page: for iPage in … { if let _page = theCGPdfDocument.page(at: 1) { var _pageRect: CGRect = _page.getBoxRect(CGPDFBox.mediaBox) writeContextInDestination!.beginPage(mediaBox: &_pageRect) // translate to compensate for the flip caused displacement writeContextInDestination!.translateBy(x: _pageRect.size.width, y: _pageRect.size.height) Scale (-1, -1) // rotate 180° // add rotate as needed writeContextInDestination!.scaleBy(x: -1, y: -1) writeContextInDestination!.clip(to: _pageRect) writeContextInDestination!.drawPDFPage(_page) writeContextInDestination!.endPage() // end the current page } } writeContextInDestination!.closePDF() But I do not succeed in inserting the drawing of the second page. I've tried repeating lines 7 to 11 for a second page at line 13. No success. What is the direction to look for ?

I have a MacOS app which displays PDFs, and I want to create a New document from the Clipboard, if the clipboard contains valid graphical data. My problem is that even if it doesn't, I still get a blank new document window. AppKit always creates a new document. I've tried overriding the newDocument function; I've tried avoiding the built-in functions altogether. Are there any general recommendations for going about this?

In PDFKit on MacOS, if you create a PDFView and matching Thumbnail View, and then set the PDFView to Horizontal: selecting the thumbnail no longer move the PDFView to the correct page. It works for all styles of View (Two Page Continuous, etc) in Vertical orientation.

Hello, We are experiencing on some occasions a wrong behavior with PDFDocument method: func page(at index: Int) -> PDFPage? With certain PDF files, this method returns the wrong PDFPage. This occurs on iOS 18.3, 18.5 and 18.6.2 (an maybe on other versions). Try this PDF for instance (page 81 is returned when index = 2): https://drive.google.com/open?id=1MHm2wjfsbWB8OiRmARUMmvODYxp4DIqP&usp=drive_fs Also, I mention that this doesn't occur systematically with this PDF. When making a copy of this file we don't observe the issue. Could this be linked some kind of internal cache issue ?

I'm experiencing an issue with PDFKit where page.removeAnnotation(annotation) successfully removes the annotation from the page's data structure, but the PDFView no longer updates automatically to reflect the change visually. Issue Details: The annotation is removed (verified by checking page.annotations.count) The PDFView display doesn't refresh to show the removal This code was working correctly before and suddenly stopped working No code changes were made on my end

Hey there, I have a slight problem which is also known on the web, but I couldn't find any answers... My iOS App is working with documents like pdf and images. It is made to handle invoices and upload them to an external service. The app's job is to compress those pdfs and images. Sadly the PDFKit's PDFDocument increases its size just after importing it with pdfDocument = PDFDocument(url: url) and later exporting it to an pdf file again with data = pdf.dataRepresentation() without ever modifying it. It increases by server KB after each export. Do you have any alternatives to the renderer dataRepresentation() or a general PDFKit alternative Thanks

Dear Apple Developer Team, On iOS 26, the contents of PDF pages appear to be swapped. Could you please advise if there is a workaround or a planned fix for this issue? Steps to Reproduce: Download the attached PDF on iOS 26. Open the PDF in the Files app. Tap the PDF to view it in Quick Look. Navigate to page 5. Expected Result: The page number displayed at the bottom should be 5. Actual Result: The page number displayed at the bottom is 4. Issue: This is not limited to page 5—multiple page contents appear to be swapped. I have also submitted feedback via Feedback Assistant (FB20743531) on October 20. Best regards, Yoshihito Suezawa

Hi everyone, I faced an issue that on IOS 26 removeAnnotation method doesn't remove annotation. This code worked on previous versions (IOS 18, 17) but suddenly stopped working on IOS 26. Has anyone faced this issue? guard let document = await pdfView.document else { return } for pageIndex in 0..<document.pageCount { guard let page = document.page(at: pageIndex) else { continue } let annotations = page.annotations for annotation in annotations { page.removeAnnotation(annotation) } }

Looking for any method to quickly flatten a PDF without opening Preview and without installing 3 party software. Any ideas? Save as PDF in Preview works, but I don't want to have to open Preview each time I need to do this. The Create PDF action which appears in Finder when you select 2 or more PDFs flattens PDFs, but it requires me to select 2 or more files, and I generally don't want to combine PDFs--I simply wish to flatten a PDF. Most Automator and Shortcuts options I am aware of do not flatten PDFs, and in some cases, strip out form field data from PDFs.

I was able to mark annotations outside the page before iOS 26 update in PDFkit, but after the iOS 26 update i am able to mark the annotations(which are not visible) outside the page and save them on DB, but unable to render(show) them.

My IOS app generates pdf files. Every time my users open the generated pdf files, the autofill popup jumps out, but my pdf file is NOT for interacting. I'm here to ask if there's a way to mark my pdf files as "not a form", like in metadata or anywhere else?

Getting this crash after I do this in PDFKit a lot: PDFSelection *nextSelect = [self.pdfView.document findString:currentSearchString fromSelection:currentSelction withOptions:NSCaseInsensitiveSearch]; if (nextSelect != nil) { self.pdfView.currentSelection = nextSelect; [self.pdfView scrollSelectionToVisible:nil]; } Which often leads to: 0 CoreFoundation 0x000000019ced4770 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000019c9b2418 objc_exception_throw + 88 2 CoreFoundation 0x000000019cfffe10 -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 724 3 CoreFoundation 0x000000019cfa1ae4 +[NSDictionary dictionaryWithObjects:forKeys:count:] + 52 4 PDFKit 0x00000001cb56e0fc -[PDFView _axPostPageChangeNotification:] + 348 5 Foundation 0x000000019e6a25e4 __NSFireDelayedPerform + 372 6 CoreFoundation 0x000000019ce92290 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 7 CoreFoundation 0x000000019ce91f50 __CFRunLoopDoTimer +

Hello, I’m using PDFKit to display PDFs with a large number of annotations. However, when there are many annotations, I’m experiencing serious performance issues while zooming in/out with PDFView. • During pinch zoom, it seems like continuous re-rendering occurs. • Memory usage spikes dramatically while zooming, then drops back down repeatedly. • As a result, zooming feels laggy and not smooth. What I’d like to achieve is the following: 1. Prevent unnecessary re-rendering while zooming is in progress. 2. Trigger a single re-render only once the zoom gesture ends (e.g., in scrollViewDidEndZooming). 3. At the very least, avoid the memory spikes during zoom. Is there any way to control how annotations are re-drawn during zooming in PDFKit, or to throttle/debounce rendering so it happens only after the gesture completes? I’d really appreciate any advice from others who have encountered similar issues, or guidance from Apple on the recommended approach. Thanks in advance!