For what it's worth, I produced a shorter program that no longer depends on CoreFoundation but still produces the same static analyzer warning. #include <algorithm> #include <string> #include <strings.h> #include <vector> int main(int argc, const char * argv[]) { std::vector<std::string> names{ "obey", "Zorro", "can" }; std::sort( names.begin(), names.end(), [](const std::string& a, const std::string& b) { return strcasecmp( a.c_str(), b.c_str() ) < 0; } ); return EXIT_SUCCESS; }

@DTS Engineer The error points to line 24. I'm not sure what you mean by "output box", but here is a screenshot of the Issue Navigator.

@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.

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)".

@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.

[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 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.

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.

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

Bug report: FB20581927

[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.

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

@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='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.

[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.