I am creating an iOS app that needs to parse the text from a PDF document. I can read the entire PDF document's text using the string property, but if it's a large PDF document, this could cause delays for users. From the documentation, I came across the beginFindString function, which seems to asynchronously, with no return? https://developer.apple.com/documentation/pdfkit/pdfdocument/beginfindstring(_:withoptions:)) Unfortunately I cannot find examples on how to use this function or its intended purpose/functionality, so any guidance would be appreciated. My goal is to read the PDF document one line at a time, searching for newlines ('\n'), then parsing that line as needed. I'm hoping the beginFindString function will be useful.

Reading text out of PDFs with PDFKit results in some text being returned way out of order when using .string or .attributedString functions. Way out of order means not just wrong sorting of words on a line or wrongly showing up on the next line (as has happened with PDFKit on older iOS releases, e.g. 17.x), but some text (one or more words) may show up near the end of a page of text, while it should show near the beginning. As Page.characterBounds(at:) is buggy in iOS 18.x returns wrong bounds, devs cannot correct such faulty PDFKit behaviour programmatically. I believe it is on Apple to fix this iOS 18 bug asap. Thank you for giving it priority as this is killing apps that need PDFKit to get and parse text data out of PDFs. I have filed Feedback FB16264926.

I’m encountering an issue with the page.selectionForWord(at:) method in my application. This method has stopped working in Mac Designed for iPad mode. The functionality works fine on physical devices such as iPhone and iPad, as well as on Mac, but in this specific mode, the method no longer works, and the application crashes. It is crucial for me that this functionality works in Mac Designed for iPad mode, as rewriting the entire code for Mac would be too time-consuming, especially considering the size of the application. Interestingly, a similar method, page.selectionForLine(at:), works perfectly with the same parameters in all environments, including the Mac Designed for iPad mode. This makes the issue even more puzzling. The issue began after the latest update. The app no longer responds to the page.selectionForWord(at:) method, which causes the application to crash. I have attached a test app to reproduce the error.

When added a PDFAnnotation to a pdf file which already have type stamp annotation type annotation showing in PDFKit but in QLPreviewController not coming

My app uses PDFKit, but I don't know how to solve this bug at all. Under the same IOS system and device model, some users' devices may experience crashes, while our own devices are functioning normally. The following is the stack information for crashing: 0 libsystem_platform.dylib__os_unfair_lock_recursive_abort + 36 1 libsystem_platform.dylib__os_unfair_lock_lock_slow + 308 2 CoreGraphics_CGPDFPageCopyRootTaggedNode + 56 3 PDFKit-[PDFPageViewAccessibility accessibilityElements] + 76 4 UIAccessibility-[NSObject(AXPrivCategory) _accessibilityElements] + 56 5 UIAccessibility-[NSObjectAccessibility accessibilityElementCount] + 68 6 UIAccessibility-[NSObject(AXPrivCategory) _accessibilityHasOrderedChildren] + 44 7 UIAccessibility-[NSObject(AXPrivCategory) _accessibilityFrameForSorting] + 216 8 UIAccessibility-[NSObject _accessibilityCompareGeometry:] + 116 9 UIAccessibility-[NSObject(AXPrivCategory) accessibilityCompareGeometry:] + 52 10 CoreFoundation___CFSimpleMergeSort + 100 11 CoreFoundation___CFSimpleMergeSort + 248 12 CoreFoundation_CFSortIndexes + 260 13 CoreFoundation-[NSArray sortedArrayFromRange:options:usingComparator:] + 732 14 CoreFoundation-[NSMutableArray sortedArrayFromRange:options:usingComparator:] + 60 15 CoreFoundation-[NSArray sortedArrayUsingSelector:] + 168 16 UIAccessibility___57-[NSObject(AXPrivCategory) _accessibilityFindDescendant:]_block_invoke + 268 17 UIAccessibility___96-[NSObject(AXPrivCategory) _accessibilityEnumerateAXDescendants:passingTest:byYieldingElements:]_block_invoke + 140 18 UIAccessibility-[NSObject _accessibilityEnumerateAXDescendants:passingTest:byYieldingElements:] + 244 19 UIAccessibility-[NSObject _accessibilityFindFirstAXDescendantPassingTest:byYieldingElements:] + 272 20 UIAccessibility-[NSObject(AXPrivCategory) _accessibilityFindDescendant:] + 100 21 UIAccessibility__axuiElementForNotificationData + 276 22 UIAccessibility__massageAssociatedElementBeforePost + 36 23 UIAccessibility__UIAXBroadcastMainThread + 292 24 libdispatch.dylib__dispatch_call_block_and_release + 32 25 libdispatch.dylib__dispatch_client_callout + 20 26 libdispatch.dylib__dispatch_main_queue_drain + 980 27 libdispatch.dylib__dispatch_main_queue_callback_4CF + 44 28 CoreFoundation___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 29 CoreFoundation___CFRunLoopRun + 1996 30 CoreFoundation_CFRunLoopRunSpecific + 572 31 GraphicsServices_GSEventRunModal + 164 32 UIKitCore-[UIApplication _run] + 816 33 UIKitCore_UIApplicationMain + 340 34 SwiftUIclosure #1 (Swift.UnsafeMutablePointer<Swift.UnsafeMutablePointer<Swift.Int8>?>) -> Swift.Never in SwiftUI.(KitRendererCommon in _ACC2C5639A7D76F611E170E831FCA491)(Swift.AnyObject.Type) -> Swift.Never + 168 35 SwiftUI SwiftUI.runApp(A) -> Swift.Never + 100 36 SwiftUI static (extension in SwiftUI):SwiftUI.App.main() -> () + 180

I am using PDFPageOverlayViewProvider from pdfkit. I would like to detect changes in the overlaid view and refresh PDFPageOverlayViewProvider. Currently, it does not refresh even when the overlaid view changes. Is there a way to refresh it?

In XCode15, if you specify mediaBox for PDFDisplayBox, the page will be shrunk to fit the specified range. However, in XCode16, the page is cropped to fit the specified range, as when cropBox is specified for PDFDisplayBox. I think it's a bug because the setBounds documentation hasn't been updated, but has anyone had the same problem? Please let me know if there are any workarounds.