Never mind, apparently Xcode 15 can't deal with a .icon file correctly. Wish I could delete my post.

Never mind! Looking up printOperationWithPrintInfo: in the Xcode help viewer was actually taking me to WebFrameView, not WKWebView.

[quote='861468022, Frameworks Engineer, /thread/803249?answerId=861468022#861468022'] Which is exactly what the createPDF: API is for. That asks the WKWebView to draw into a PDF the exact same way it would draw to the screen or to print, and it results in a nice vectorized PDF instead of rasterized images. [/quote] Yes, I tried that, but it produced a PDF with one ridiculously tall page. Is there another way to produce a PDF with pagination? I'll work on distilling this down to a good test app for a bug report.

[quote='861471022, DTS Engineer, /thread/803249?answerId=861471022#861471022'] Can you provide some URLs to content you're having trouble printing? [/quote] My content is available here: https://github.com/jwwalker/PlainCalc/blob/master/PlainCalc3/Resources/Help/PlainCalcHelp.md.html This is a "MarkDeep" file. It mostly looks like MarkDown, but functions as HTML, and displays correctly in a WKWebView.

@Etresoft : In my code, I'm using fit pagination for both horizontal and vertical. I think that may fix your ridiculously tall pages. Safari also generates such pages when exporting to PDF, so perhaps "automatic" is what's doing that. When you export to PDF, that's not the same as printing to PDF. There is no opportunity to set a pagination option.

[quote='861547022, Etresoft, /thread/803249?answerId=861547022#861547022, /profile/Etresoft'] horizontal overview inside a div [/quote] No idea what you mean by that?

[quote='861468022, Frameworks Engineer, /thread/803249?answerId=861468022#861468022'] We'd be interested to see a test app/content where it is failing in the way you describe. [/quote] I've posted a test app here: https://github.com/jwwalker/WKWebView-print-test By the way, although I titled this post with "Sequoia", I just now tested on a different machine running a Tahoe 26.1 beta, and observed the same behavior.

Bug report: FB20581927

It turns out that I can reproduce some bogus include directory warnings if I set the warning flag -Wmissing-include-dirs. Bug report: FB20716700

P.S., I find that if I instead use the ancient but not deprecated function LSOpenFromURLSpec, then it works. So at least I have a workaround.

@DTS Engineer Thank you for the detailed reply! It may take me a while to respond to all of your points, but here is a start: Yes, the issue here is that "nothing" (no app launch and/or document open) is happening. The target app is a copy of BBEdit in my ~/Applications folder. Using the open command to open the same text file with the same copy of BBEdit works fine. Regarding "How did your app "get" that file URL? Is your app able to open the file? And is the file already downloaded or is it still dataless?" The file is downloaded. My app gets the URL by drag and drop from the Finder. My app does not attempt to open the file on its own, it just forwards the URL to be opened by another app, BBEdit in this case, somewhat like what the Dock does. Dang, now all of a sudden it's working. Obviously I need to do a lot more testing.

[quote='868376022, DTS Engineer, /thread/809171?answerId=868376022#868376022'] To be clear, you specifically meant: /Applications ...not the standard Applications directory? That's not actually one of our standard directories, which opens the possibility that the system "missed" the existence of the app, so it wasn't registered with LaunchServices. [/quote] The Launch Services Programming Guide says that A built-in background tool, run whenever the system is booted or a new user logs in, automatically searches the Applications folders in the system, network, local, and user domains and registers any new applications it finds there. The one in the user domain is ~/Applications. Also note that the Finder gives that one the standard Applications icon, whereas if you create an Applications folder in some random location, it gets a generic folder icon. So at least by some measures it is one of your standard directories. I'll see if I can replicate in a VM.

@DTS Engineer It turns out that I cannot sign in to my Apple account within a macOS 26.1 VM. "Could not communicate with the server." So I can't test anything with iCloud Drive in a VM.

Oh, now I see why I couldn't use iCloud Drive in a 26.1 VM. The 26.1 release notes say "The serial number published for the virtual machine is 0, which prevents iCloud and related applications from functioning correctly. (163294564)".

@ssmith_c Thanks! I thought I needed to override init(coder:) because I was getting some error message saying so, but that was just because I had stored properties without default values. Once I supplied default values to my properties, I was able to implement neither designated initializer, just my convenience initializer.