I tried using somewhat simpler printing code, which I've seen work in other apps: - (IBAction) doPrint: (id) sender { NSPrintOperation* printOp = [NSPrintOperation printOperationWithView: _webView]; printOp.jobTitle = @"Help"; NSPrintInfo* info = printOp.printInfo; info.verticallyCentered = NO; printOp.printInfo = info; [printOp runOperationModalForWindow: _webView.window delegate: self didRunSelector: nil contextInfo: nil ]; } But no go here. I tried the same thing in another window, this one using WKWebView, with the same blank result. This is a sandboxed app, and the com.apple.security.print entitlement is on. I'm working in Xcode 15.2 on macOS 13.8.8. I took a project that wouldn't print on this machine to a newer machine running a Tahoe beta, and there it worked. So then I'm asking myself, is printing just broken on this machine? No, printing from other apps shows the preview just fine.

OK, I seem to have solved it. I had a .xcconfig file at the project level that specified INFOPLIST_KEY_NSPrincipalClass = NSApplication Apparently the test target is not supposed to specify a principal class. So, thanks for suggesting that I try a newly created project, which I should have thought of.

I'm using Xcode 15.2 on macOS 13.7.7. A new app project does not reproduce the problem, but I'm not yet seeing the relevant difference. At first I thought it might be because I was using a nonstandard build location, but changing that back to the default didn't fix it. With a breakpoint on -[NSApplication init], the first break has this backtrace frame #0: 0x00007ff81702f9ac AppKit`-[NSApplication init] frame #1: 0x00007ff81702f78e AppKit`+[NSApplication sharedApplication] + 120 frame #2: 0x00007ff81702df79 AppKit`NSApplicationMain + 409 frame #3: 0x000000010e442a91 PlainCalc`main(argc=5, argv=0x00007ff7b1ae7e68) at main.m:14:9 frame #4: 0x00007ff813b93418 dyld`start + 1896 And the second is frame #0: 0x00007ff81702f9ac AppKit`-[NSApplication init] frame #1: 0x00000001103bd0df XCTestCore`-[XCTestDriver _createTestBundlePrincipalClassInstance] + 82 frame #2: 0x00000001103bb338 XCTestCore`-[XCTestDriver _runTests] + 111 frame #3: 0x0000000110381194 XCTestCore`_XCTestMain + 126 frame #4: 0x000000010fafb82d libXCTestBundleInject.dylib`__RunTests_block_invoke_2 + 13 frame #5: 0x00007ff813fc9a91 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 frame #6: 0x00007ff813fc99ca CoreFoundation`__CFRunLoopDoBlocks + 398 frame #7: 0x00007ff813fc883d CoreFoundation`__CFRunLoopRun + 898 frame #8: 0x00007ff813fc7e51 CoreFoundation`CFRunLoopRunSpecific + 560 frame #9: 0x00007ff81da52f3d HIToolbox`RunCurrentEventLoopInMode + 292 frame #10: 0x00007ff81da52b84 HIToolbox`ReceiveNextEventCommon + 199 frame #11: 0x00007ff81da52aa8 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64 frame #12: 0x00007ff8170689d8 AppKit`_DPSNextEvent + 858 frame #13: 0x00007ff817067882 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214 frame #14: 0x00007ff817059ef7 AppKit`-[NSApplication run] + 586 frame #15: 0x00007ff81702e111 AppKit`NSApplicationMain + 817 frame #16: 0x000000010e442a91 PlainCalc`main(argc=5, argv=0x00007ff7b1ae7e68) at main.m:14:9 frame #17: 0x00007ff813b93418 dyld`start + 1896 The exception is thrown from the second invocation of -[NSApplication init].

I found a solution to my problem. In the OTHER_LDFLAGS build setting, I added: -Xlinker -reexported_symbols_list -Xlinker /path/to/list_of_symbols_I_want

Adding an exported symbols file seems rather painful, since it's a large C++ framework that I don't maintain. And the maintainers have taken the trouble to mark things up with __attribute__( ( visibility( "default" ) ) ). I found that Xcode has a build setting REEXPORTED_LIBRARY_PATHS that seems like it ought to do exactly what I want, but doesn't. Also, in the man page for ld, I found -exported_symbol symbol, but when I tried adding -exported_symbol _FreeImage_Rescale to "other linker flags", I get an error no such file or directory: '_FreeImage_Rescale'

@DTS Engineer, Can you provide the type declaration portion of your Info.plist? When you ask for the type declaration portion, I'm going to assume you mean UTExportedTypeDeclarations, not UTImportedTypeDeclarations or CFBundleDocumentTypes. Even just UTExportedTypeDeclarations is too much text to fit in a forum reply. So here's just the part for the file type in question. <dict> <key>UTTypeConformsTo</key> <array> <string>public.data</string> <string>public.composite-content</string> </array> <key>UTTypeDescription</key> <string>FrameForge previsualization</string> <key>UTTypeIconFile</key> <string>document.icns</string> <key>UTTypeIcons</key> <dict/> <key>UTTypeIdentifier</key> <string>com.frameforge3d.frameforge.previsualization</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>previz</string> <string>s3d</string> </array> </dict> </dict>

Perhaps you may be able to get at the data you're interested in by extracting the NSBitmapImageRep from your NSImage and accessing the data you want in there. Yes, I can do that, but then I'm not sure whether I'm dealing with big-endian or little-endian data, whether alpha is first or last, maybe even whether the data is 16 bit or floating-point, so it's a pain. The trouble with vImageUnpremultiplyData_ARGB8888 is that unpremultiplying is a lossy operation. In the extreme case, if the alpha value is zero, you have no idea what the original RGB values were.

There are a couple of partial solutions here: https://stackoverflow.com/questions/75175699/get-human-readable-name-for-mac-model-on-ventura

I'm not sure if this counts as getting it "programmatically", but you can get this information using the command line tool system_profiler. (You can run a command line tool programmatically using the Swift class Process or the Objective-C class NSTask.) For instance if you parse the output of the command system_profiler -detailLevel mini -json and look for the key SPHardwareDataType, and within that machine_name, you'll find the friendly name. This will be the first part, like "MacBook Pro". The less friendly model name is under the key path SPHardwareDataType.machine_model. But I don't know how to get the user-friendly second part like "15-inch, 2018".

Bug report submitted, FB15657061

@DTS Engineer I am a little confused by your mentions of LSUIElement=0 and LSUIElement=1 in your numbered list. Do you have them backward maybe? As I read the docs, the plist key LSUIElement has a boolean value, and the true value means that the app does not appear in the Dock, as in your case 2. So case 2 should say LSUIElement=1, right?

I've gotten rid of the assertion failure, but I can't say I understand how. I had code that retrieves a view pointer via a void* output parameter of a library function, like so: NSView* theView = nil; Q3Object_GetProperty( inDC, 'PWin', sizeof(void*), nullptr, &theView ); When I changed it to the following code, the error went away: NSView* theView = nil; void* rawViewPtr = nullptr; Q3Object_GetProperty( inDC, 'PWin', sizeof(void*), nullptr, &rawViewPtr ); theView = (__bridge NSView*) rawViewPtr;

After more fooling around with deleting builds, deleting the copy from the App Store, and so forth, the problem no longer reproduces. So, that's good, I guess, but I'm not in the position of being able to file a useful bug report. But to answer your questions: The helper is an app bundle with LSBackgroundOnly set true in its Info.plist. I launch it using NSWorkspace. I granted permission to the helper, not the main app. Since the helper is background only, not a LSUIElement, I'm not sure that what you're saying there is relevant.

Well, now I'm seeing everything get deallocated properly, and I'm not even sure what I did wrong before, maybe looked at memory at a breakpoint that was too early. But thanks for the reply!

I tried it in Objective-C, and it does work, but it's not super obvious how it works. If you look up NSDirectoryEnumerationIncludesDirectoriesPostOrder in the header, comments say: NSDirectoryEnumerationIncludesDirectoriesPostOrder causes the NSDirectoryEnumerator to enumerate each directory a second time after all of its contained files have been enumerated. Use NSDirectoryEnumerator.isEnumeratingDirectoryPostOrder to differentiate a post-order enumerated directory from a pre-order one. What this means is that the enumerator visits a directory, then visits the contents of the directory, and then visits the directory again, and the second time, the isEnumeratingDirectoryPostOrder property of the enumerator is true. Maybe you should file a feedback about the documentation.