Since iPadOS 27, Apple Pencil strokes that were drawn and saved through the system markup UI in QLPreviewController can no longer be erased with the pixel eraser once the PDF is saved and reopened. They can only be selected and deleted as whole annotations. On iPadOS 26 the same flow kept saved strokes erasable. Reproduction (no custom code needed — Files app shows it too): Files app → long-press a PDF → Quick Look → Markup Draw a few strokes with Apple Pencil, tap Done/save Reopen the same PDF in Quick Look → Markup Eraser (Erase Strokes mode) does nothing on the saved strokes The same happens in our app, which presents PDFs via QLPreviewController with editingModeFor = .createCopy. Newly drawn strokes in the current session erase fine; only saved-and-reloaded ones are affected. The new Preview app is NOT affected — the same PDF edited there stays fully re-editable. Digging into the saved files: Quick Look writes each stroke as a /Stamp annotation whose /AAPL:AKExtras contains only legacy AnnotationKit data (AKAnnotationObject with a flattened AKImageAnnotation, or AKAnnotationV2/AKInkAnnotation2) — and no /PPK entry. The Preview app embeds the PencilKit drawing data (/PPKType = "draw", /PPK with a "crdt" stream, plus page-level /AAPL:PPK + /AAPL:PPKHash), which is what makes its output re-editable. It looks like the iPadOS 27 markup editor only restores erasable strokes from /PPK, while the Quick Look save path still writes the old format — so Quick Look can no longer round-trip its own output. Questions: Is this an intentional behavior change or a regression? I couldn't find anything in the iPadOS 27 release notes about Quick Look / markup persistence. Is there any way for a host app to opt QLPreviewController's markup into the new PencilKit-based persistence?

Hello, I'm hoping someone from the App Review team can take a look at our submission. App name: Happyy UAE Latest submission date: 10 September 2026 Current status: Waiting for Review We have been trying to publish this app for more than two months. We addressed the feedback from previous reviews before resubmitting, but the latest submission has now been waiting for 11 days with no feedback, questions, or status change. This delay is holding up our launch. Could someone please check whether the submission is stuck, or let us know if anything else is needed from our side? Thank you for your help.

Hi all! I am seeing the following problem while developing a Quick Look extension to preview Markdown files on iOS and macOS: On iOS 26, Quick Look invokes an installed data-based Quick Look preview extension for .md files resolved as net.daringfireball.markdown, and the extension renders the Markdown correctly. On iOS 27, the same document and the same installed extension no longer work. Quick Look still resolves the file as net.daringfireball.markdown, but it does not invoke the extension and instead displays the raw Markdown source using the generic plain-text preview. Also the same extension runs perfectly on macOS 26 and macOS 27. The extension subclasses QLPreviewProvider, has QLIsDataBasedPreview enabled, and includes net.daringfireball.markdown in QLSupportedContentTypes. As a control, the same installed extension correctly launches and renders equivalent document content when it is presented through a custom Uniform Type Identifier. This confirms that the extension is embedded, installed, and otherwise invocable; the failure is specific to Quick Look's provider selection for Markdown on iOS 27. Reproduction: Install an app containing the data-based preview extension described above. On iOS 26, open an .md document in Quick Look and observe that the extension is launched and renders the Markdown. On iOS 27, open the same document with the same extension installed. I reproduced this through Files, although the issue concerns Quick Look provider selection rather than Files-specific behavior. Observe that the extension is not launched and the raw Markdown source is shown. Open an equivalent document registered with a custom content type supported by the same extension. Observe that Quick Look launches the extension and displays the rendered preview. The attached screenshots show the same Markdown case rendered by QuickMark on iOS 26 and falling back to plain text on iOS 27. Is there a supported way for a third-party preview extension to handle net.daringfireball.markdown on iOS 27, or is this an unintended provider-selection regression? Tested with iOS 27.0 (24A5408d) on an iPhone 17 Pro Max Simulator using Xcode 27.0 (27A5237l). Feedback filed as FB24481377.

I'd like to create a Quick Look extension for a file type for which a location or region on a Map should be shown as preview. However the MapView would only show a grid without any map. From within the MapKit delegate I can see from the "Error" parameter (a server with this domain can not be found) that this seems to be a network issue. The Quick Look extension seems to have no access to the internet and therefore the MapView can not load any map data. I've then also done some other tests via URLSession, which also only fails with connection errors. I haven't seen any limitations or restrictions mentioned in the API documentation. Is this the expected behavior? Is this a bug? Or am I missing something?

SBS ViewPacking add a half a frame to the opposite eye. Meaning if you look all the way right you can see an extra half frame with left eye and vice versa. OU doesn't work at all, the preview just doesn't show a thumbnail and the video doesn't play. Any hints on how to fix this? I submitted a bug report but haven't heard anything.

I am writing a QuickLook extension using Swift (specifically QLPreviewingController). Extensions can be opened from both the previewer (pressing Space with a file selected) and Get Info. How do I reliably detect which mode my extension is being started from? The problem is that when it's in the Get Info window, it forces a fixed width (but not height). If I set the size statically based on that width, then when it launches in its own window (via Space), you can't resize the preview window. What am I missing? It seems like I should be getting more context about where I'm being inserted so I can lay out accordingly? Does anyone have any suggestions or have faced this problem before?

I use QLThumbnailGenerator to generate icons. After updating to macOS Tahoe 26.4 the folder color preference of the user is no longer respected. It just makes the icon default 'light blue.'

Hi, I'm encountering a weird issue on iOS that happens: for files with diacritics in their name, like "Gòmez.pdf" or "Télé.mp4", when the iPhone or iPad main language is not set to English, if the file has been created with a relatively low-level Unix function like fopen() or copyfile(). Then, the file cannot be previsualized using QuickLook or opened using other apps. Most of the time it fails silently, but on some occasions I get the following error message: "You do not have permission to save the file "filename.pdf" in the folder "myFolder"". The issue is present in, at least, iOS 16 and 26. It seems worse in iOS 26. It seems that all three conditions are required, I don't see the issue when the iPhone or iPad is set to use English as the main language. I also don't see the issue if I rename the files in the Files app. I'm probably doing something wrong, but what can it be? (it's kind of weird that my recommendation for users becomes: if you want to use international characters in your file names, you need to set the iPad language to English...)

When you have multiple Apps on the Mac which all provide Quicklook extensions for the same file type, then I would assume that if I activate one of these Quicklook extensions in the system settings, this one would be used. But this doesn't seem to be the case. It looks like the macOS just looks the very first extension it can find for a certain file type, and if this Quicklook extension is switched off, the file can not be previewed anymore. The macOS just doesn't bother to look for the other existing quicklook extension for this file, even if this other is enabled. The only option right now to get this other extension to be used by the system would be to completely delete the first App, so its extension is deleted as well. Is this really the way how it is supposed to work? How can this be fixed? Can I tell my users something else than "just delete the other App"?

Hi everyone, I’m currently experiencing unusually long review waiting times and wanted to ask if others see the same behavior this week. My situation: App Store update has been in “Waiting for Review” significantly longer than usual, my apps are pending from last 2 weeks. I’m not trying to escalate anything just looking to understand if this is currently affecting more developers. Would really appreciate hearing about your recent experiences.

It appears that starting with macOS Sequoia, Quick Look Preview extension no longer loads MapKit maps correctly anymore. Map tiles do not appear, leaving users with a beige background. Users report that polylines do render correctly, but annotations appears black. This was previously working fine in prior macOS versions including Sonoma. STEPS TO REPRODUCE Create a macOS app project, with an associated document. Ensure project has a Quick Look preview extension, with necessary basic setups. Ensure that the extension mentioned in (2) must have a MKMapView. Any other cosmetic changes, etc, does not need to be implemented to observe the base issue. Do note that it has been reported that in addition to the map tiles not loading, annotations don't render correctly as well.

On macOS 26.2 (Tahoe), the Preview app fails to render many USDZ models correctly. The issue appears inconsistent: • Some USDZ files open normally in Preview • Some USDZ files open but the viewport turns completely black (no geometry, no material, no lighting) • All the same files open correctly when opened using “Open With → Xcode” This was not the behavior on macOS 15.7.2, where the exact same USDZ files rendered consistently in Preview without failures.

My app (FindAnyFile) provides a Finder-like interface in which it also offers a QuickLook preview command, which invokes [[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil]; Now, if it shows .abcdp files, it often, but not always, crashes. This has been happening for many macOS versions, at least since 10.15, up to 26.1. Also, it does not seem to matter which SDK/Xcode I build with, as I used several and all versions lead to the crash. The issue rather appears to be inside the QLplugin for the AB file (ABCardCollectionView etc.). I am able to trace this crash in Xcode. There are a LOT of errors and warnings coming up, and eventually the qlplugin throws an ObjC exception which in turn brings down my entire app (and here I thought that the XPC system was designed to expressly avoid such crashes). Possibly significant errors are: CNAccountCollectionUpdateWatcher 0x6000025cf800: Update event received, but store registration failed. This event will be handled, but the behavior is undefined. Error using remote object proxy when fetchAnonymousXPCEndpoint: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller" UserInfo={NSDebugDescription=connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller} connection to service named com.apple.coreduetd.people … CNPropertyNotFetchedException: A property was not requested when contact was fetched. I've attached the (mostly) complete console output from such a debug run. I have also an open bug report regarding this kind of crash (back then I was not able to reproduce it myself): FB15553847 Also, when I "Quick Look" the same file in Finder, I get a "Preview not permitted" for the same items that crash in my app. If I copy the same items to the Desktop, then Finder can QL them and my app doesn't crash when viewing the item on the Desktop. So, the crash only happens with the items inside ~/Library/Application Support/AddressBook/Sources/…/Metadata/. Now, here is the weirdest part: You might think: So, if the Finder shows "Preview not permitted", then my app trying to view those items is the result of that condition (even if that's not supposed to crash). However: I have a clean 26.1 install (in an Apple ARM VM) where Finder also says "Preview not permitted" for these items in the user's Library/AB/Metadata folder, but my app can QL those items without crashing! Also, I have one user who uses 26.1 and gets the crash with files in the same location. So, the "Preview not permitted" is probably not the cause of this crash, though it's suspicious that a user gets this at all - why can't a user QL the abcdp files in the Metadata folder but when copied to the Desktop, QL works? You'd think that Finder has the necessary entitlements to access the AB, or doesn't it? Of course, my app has permission enabled under Privacy & Security / Contacts (if it's disabled, then the app can't show anything but will also not crash). And it has the "Address Book" entitlement. Would be nice if this could be looked into and eventually be fixed. Alternatively, I'd welcome any suggestions on how to prevent my app from crashing if the qlplugin throws. But if you look at the stack trace you'll see that there's no method of my own app involved where I could insert an exception catcher. I added code to my previewItemURL delegate method to make sure the NSURL item is readable, and it is, even Of course, apart from the issue with .abcdp files, the QL operation in my app works flawlessly, i.e. I have never received any other crash reports relating to any other QL plugins. QuickLook for AddressBook crash messages

After upgrading to macOS 26, I noticed that showing a Quicklook preview in my app is very slow. Showing small text files is fine, but some other files I've tried, such as a Numbers document, take about 30 seconds (during which the indeterminate loading indicator appears) before the preview is shown. When showing the preview of an app, such as Xcode, the panel opens immediately with a placeholder image for the Xcode icon, and the actual Xcode icon is shown only after about 25 seconds. During this time many logs appear: FPItemsFromURLsWithTimeout timed out (5.000000s) for: file:///.file/id=6571367.2/ (/) FPItemsFromURLsWithTimeout timed out (5.000000s) for: file:///.file/id=6571367.23684/ (/Users) FPItemsFromURLsWithTimeout timed out (5.000000s) for: file:///.file/id=6571367.248032/ (/Users/n{9}k) FPItemsFromURLsWithTimeout timed out (5.000000s) for: file:///.file/id=6571367.248084/ (/Users/n{9}k/Downloads) Failed to add registration dmf.policy.monitor.app with error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.dmd.policy was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.dmd.policy was invalidated: failed at lookup with error 159 - Sandbox restriction.} Failed to register application policy monitor with identifier 69DDBDB4-0736-42FA-BA7A-C8D7EA049E29 for types {( applicationcategories, websites, categories, applications )} with error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.dmd.policy was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.dmd.policy was invalidated: failed at lookup with error 159 - Sandbox restriction.} FPItemsFromURLsWithTimeout timed out (5.000000s) for: file:///.file/id=6571367.155797561/ (~/Downloads/X{3}e.app) It seems that Quicklook tries to access each parent directory of the previewed file, and each one fails after 5 seconds. Why is Quicklook all of a sudden so slow? It used to be almost instant in macOS 15. I created FB20268201. import Cocoa import Quartz @main class AppDelegate: NSObject, NSApplicationDelegate, QLPreviewPanelDataSource, QLPreviewPanelDelegate { var url: URL? func applicationDidFinishLaunching(_ notification: Notification) { let openPanel = NSOpenPanel() openPanel.runModal() url = openPanel.urls[0] QLPreviewPanel.shared()!.makeKeyAndOrderFront(nil) } override func acceptsPreviewPanelControl(_ panel: QLPreviewPanel!) -> Bool { return true } override func beginPreviewPanelControl(_ panel: QLPreviewPanel!) { panel.dataSource = self panel.delegate = self } override func endPreviewPanelControl(_ panel: QLPreviewPanel!) { panel.dataSource = nil panel.delegate = nil } func numberOfPreviewItems(in panel: QLPreviewPanel!) -> Int { return 1 } func previewPanel(_ panel: QLPreviewPanel!, previewItemAt index: Int) -> QLPreviewItem! { return url as? QLPreviewItem } }

I didn't really find anything in Apple docs on how to debug my extension using Xcode (so not saying it doesn't exist). I found a current Stack post on it, with several devs all stuck. In 2024 someone said run the Preview Extension, select Finder as the test app, then in a Finder window select a file of the correct type and tap space. Nothin happens when I do this (I get the file icon showing). Suggestions most welcome!

I've a QLPreviewController in the detail/secondary section of a UISplitViewController and when the user swipes down, it dismisses the entire split view. Is there a way to prevent this?

My PreviewCode app provides QuickLook previews and Finder icon thumbnails for source code files written in many popular programming languages. The only one it doesn't work will with is TypeScript, which typically uses the ts file extension. This is because Apple's CoreTypes bundle maps the ts file extension to its own MPEG-4 Transport Stream UTI. Right now I have two UTIs mapped to the ts extension: the above one and another, com.microsoft.typescript. The question is, how can I tell macOS' Launch Services to favour the latter over the former so that PreviewCode's previewer app extension is called whenever then user QuickLooks a TypeScript file and not (as currently happens) macOS' MPEG-4 previewer? I'd like to code this into PreviewCode or at the very least provide the technique in the response to the many tech support requests I get about this ts mix-up specifically.

I've been using the MacOS XCode Reality Composer to export interactive .reality files that can be hosted on the web and linked to, triggering QuickLook to open the interactive AR experience. That works really well. I've just downloaded XCode 15 Beta which ships with the new Reality Composer Pro and I can't see a way to export to .reality files anymore. It seems that this is only for building apps that ship as native iOS etc apps, rather than that can be viewed in QuickLook. Am I missing something, or is it no longer possible to export .reality files? Thanks.

Hi, I have a document-based SwiftUI multiplatform app, where the document is saved as JSON. Obviously I don't want Quick Look to show the JSON of my file, so I made a Quick Look Preview extension for each platform. The macOS one works… okay, sometimes it's tricky to test and I need to use qlmanage to empty the cache or to show the preview, but it does work. I can even debug it. But the iOS one just never seems to be run. If I show Quick Look in the Files app on iOS, or if I AirDrop a file from my app to my iPhone, it shows as JSON, with an option to open it in my app. If I run the iOS Preview Extension in the debugger and launch the Files app, and then try to use Quick Look in a file there, it shows the JSON and the debugger just stays in the state 'Waiting to Attach'. The preview extensions are not data based; in both of them I have implemented func preparePreviewOfFile(at url: URL) async throws in PreviewViewController.swift. Pretty much the same code except one is using a UIHostingController and the other is using an NSHostingController. The only difference in the Info.plists for the two extensions is that the iOS one uses NSExtensionMainStoryboard while the macOS one uses NSExtensionPrincipalClass. This is how they were set up when I created them from the relevant Quick Look Preview Extension templates. I made a sample project with a much simpler document, UI, etc. and I have the same issue there. The macOS preview works, the iOS one never runs. I have checked that the correct preview extension is embedded in the target for each OS (under Embed Foundation Extensions in the Build Phases) Is there anything I need to do differently in iOS, or anything I might have inadvertently got wrong? Is there a way to run something similar to qlmanage on iOS, since that sometimes seems to help on macOS? Incidentally, I have also added Quick Look Thumbnail extensions, and they work on both platforms.

When viewing an immersive space and I open a spatial photo in Quick Look, which hides the entire app interface to show the photo. Is there a memory limit? If the inmersive space is not active, the application keep the interface.