I have a repeating timer installed like this: _cmdTimer = [NSTimer timerWithTimeInterval: 0.5 target: self selector: @selector(timedTask:) userInfo: nil repeats: YES]; [NSRunLoop.mainRunLoop addTimer: _cmdTimer forMode: NSModalPanelRunLoopMode]; [NSRunLoop.mainRunLoop addTimer: _cmdTimer forMode: NSDefaultRunLoopMode]; The first time the timer fires, it opens a modal dialog. But then the timer does not fire again until the dialog is closed. I don't get that, since I scheduled the timer in NSModalPanelRunLoopMode. To verify that the dialog was running in that mode, just before opening the dialog I said [self performSelector: @selector(testMe) withObject: nil afterDelay: 0.7 inModes: @[NSModalPanelRunLoopMode] ]; and the testMe method did get executed while the dialog was open.

As an exercise in learning Swift, I rewrote a toy C++ command line tool in Swift. After switching to an UnsafeRawBufferPointer in a critical part of the code, the Release build of the Swift version was a little faster than the Release build of the C++ version. But the Debug build took around 700 times as long. I expect a Debug build to be somewhat slower, but by that much? Here's the critical part of the code, a function that gets called many thousands of times. The two string parameters are always 5-letter words in plain ASCII (it's related to Wordle). By the way, if I change the loop ranges from 0..<5 to [0,1,2,3,4], then it runs about twice as fast in Debug, but twice as slow in Release. func Score( trial: String, target: String ) -> Int { var score = 0 withUnsafeBytes(of: trial.utf8) { rawTrial in withUnsafeBytes(of: target.utf8) { rawTarget in for i in 0..<5 { let trial_i = rawTrial[i]; if trial_i == rawTarget[i] // strong hit { score += kStrongScore } else // check for weak hit { for j in 0..<5 { if j != i { let target_j = rawTarget[j]; if (trial_i == target_j) && (rawTrial[j] != target_j) { score += kWeakScore break } } } } } } } return score }

I'm trying to do a piecemeal conversion of a big macOS Objective-C++ code base to use Automatic Reference Counting (ARC), and started with a fairly complex modal dialog. I converted all the classes involved to use ARC. When the dialog closes, the window itself, and some of the controller objects, get deallocated as they should, but some do not. When I look at the memory debugging graph in Xcode, I see a bunch of things of the form NSKVONotifying_MyClassName. Here's an example: It does not look as though any of my objects have strong references to GRMorphController, so what am I to make of this?

I'm getting a runtime assertion failure like this: "<FFRender3DView 0x616000271580> has reached dealloc but still has a super view. Super views strongly reference their children, so this is being over-released, or has been over-released in the past." Looking at the code, I can't see any strong reference to the view except by its superview, so I can't see how it could be released other than by removal from its superview. My first instinct was to override release and set a breakpoint there, but that's not possible in ARC code.

I'm looking at a case where a handler for NSWindowDidBecomeMain gets the NSWindow* from the notification object and verifies that window.isVisible == YES, window.windowNumber &gt; 0 and window.screen != nil. However, window.windowNumber is missing from the array [NSWindow windowNumbersWithOptions: NSWindowNumberListAllSpaces] and from CGWindowListCopyWindowInfo( kCGWindowListOptionOnScreenOnly, kCGNullWindowID ), how can that be? The window number is in the array returned by CGWindowListCopyWindowInfo( kCGWindowListOptionAll, kCGNullWindowID ). I'm seeing this issue in macOS 15, maybe 14, but not 13.

If I use [UTType exportedTypeWithIdentifier:] to get one of the types in my app's Info.plist, and then ask for the preferredFilenameExtension of that UTType, I get the wrong extension, i.e., not the first file extension listed for that UTI in my Info.plist. Is this one of those situations where AppKit is looking in some database that can get out of sync with what's actually in the Info.plist?

I have a document-based macOS app written in Objective-C, and each document window contains a scrollable NSTextView. I know that printing can get complicated if you want to do nice pagination, but is there a quick and dirty way to get basic printing working? As it is, the print panel shows up, but its preview area is totally blank. Here's the current printing part of my NSDocument subclass. - (NSPrintInfo *)printInfo { NSPrintInfo *printInfo = [super printInfo]; [printInfo setHorizontalPagination: NSPrintingPaginationModeFit]; [printInfo setHorizontallyCentered: NO]; [printInfo setVerticallyCentered: NO]; [printInfo setLeftMargin: 72.0]; [printInfo setRightMargin: 72.0]; [printInfo setTopMargin: 72.0]; [printInfo setBottomMargin: 72.0]; return printInfo; } - (void)printDocumentWithSettings:(NSDictionary<NSPrintInfoAttributeKey, id> *)printSettings showPrintPanel:(BOOL)showPrintPanel delegate:(id)delegate didPrintSelector:(SEL)didPrintSelector contextInfo:(void *)contextInfo { NSPrintInfo* thePrintInfo = [self printInfo]; [thePrintInfo setVerticallyCentered: NO ]; NSPrintOperation *op = [NSPrintOperation printOperationWithView: _textView printInfo: thePrintInfo ]; [op runOperationModalForWindow: _docWindow delegate: delegate didRunSelector: didPrintSelector contextInfo: contextInfo]; }

In trying to convert some Objective-C to Swift, I have a subclass of NSWindowController and want to write a convenience initializer. The documentation says You can also implement an NSWindowController subclass to avoid requiring client code to get the corresponding nib’s filename and pass it to init(windowNibName:) or init(windowNibName:owner:) when instantiating the window controller. The best way to do this is to override windowNibName to return the nib’s filename and instantiate the window controller by passing nil to init(window:). My attempt to do that looks like this: class EdgeTab: NSWindowController { override var windowNibName: NSNib.Name? { "EdgeTab" } required init?(coder: NSCoder) { super.init(coder: coder) } convenience init() { self.init( window: nil ) } } But I'm getting an error message saying "Incorrect argument label in call (have 'window:', expected 'coder:')". Why the heck is the compiler trying to use init(coder:) instead of init(window:)?

I'm trying to use -[SMAppService loginItemServiceWithIdentifier:] API, and after creating the SMAppServiceInstance, its status is SMAppServiceStatusNotFound. That means it didn't find the helper app? The documentation is a little mixed up. It says that the parameter is "The bundle identifier of the helper application", but also says "The property list name must correspond to a property list in the calling app’s Contents/Library/LoginItems directory". So which is it, a property list name or a bundle identifier? And it the thing in the LoginItems directory a helper application or a property list? What I have is an app bundle inside the Contents/Library/LoginItems of the app that's calling the SMAppService API. Or in other words, the given bundle identifier parameter is the CFBundleIdentifier value in Caller.app/Contents/Library/LoginItems/Helper.app/Contents/Info.plist. Is that not the right way to do it?

I can't find any documentation on CGRequestPostEventAccess or its friend CGRequestListenEventAccess, except for the API declarations in CGEvent.h. The fact that it returns a boolean and doesn't have a completion callback or anything like that suggests that it should be synchronous, i.e., not return until the user has decided to grant or deny permission. Experimentally, that doesn't seem to be the case, but then what does the return value mean?

If I enter a feedback ID like FB11832484, the last digit does not get highlighted, and is not part of the automatically-generated URL linked to the text. Looks like someone assumed that there will never be more than 7 digits in the feedback ID.

In macOS 13.2, the NSTrackingEnabledDuringMouseDrag flag for NSTrackingArea is broken, i.e., mouse-entered and mouse-exited events are not sent during a drag. This problem did not exist in macOS 12. I've filed a bug report, FB11973492, just wondering if anyone knows a workaround.

I'm getting a code signing crash when I try to register a helper app as a login item, and I think this is new with macOS 13.4. That is, the crash log contains this: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CODESIGNING 4 Launch Constraint Violation I'm seeing one suspicious message in the system log: tccd Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for accessing={TCCDProcess: identifier=com.jwwalker.AutoPairs.uiapp, pid=91471, auid=501, euid=501, binary_path=/Applications/AutoPairs 4.0.1a1/AutoPairs4.0.1a1.app/Contents/MacOS/AutoPairs}, requesting={TCCDProcess: identifier=com.apple.appleeventsd, pid=531, auid=55, euid=55, binary_path=/System/Library/CoreServices/appleeventsd}, I can't figure out why the OS would think that I need an Apple Events entitlement. I've looked a the thread Resolving Code Signing Crashes on Launch, but it hasn't enlightened me. One problem I ran into is at the step certtool d "authorised0.cer" I get the output CSSM_CL_CertGetAllFields: CSSMERR_CL_UNKNOWN_FORMAT

Yesterday and today, when I try to notarize a Mac app, it fails in the upload stage. And yet Apple's system status page shows a green dot next to Developer ID Notary Service. I've tried relaunching Xcode and even rebooting the Mac. Xcode 14.3, macOS 13.4.1 Feedback filed, FB12570950

Why is it that I can open a symbolic link, but can't read it? I am aware that I can get the contents of a symlink file using the readlink function, but still, it seems like this ought to work. Here's example code: #include <iostream> #include <unistd.h> #include <fcntl.h> int main(int argc, const char * argv[]) { // Make sure there is not already a file where we will create the link unlink( "/tmp/ReadSymLink-test" ); // Create a symlink int result = symlink( "../usr", "/tmp/ReadSymLink-test"); int err; if (result == 0) { std::cout << "created file /tmp/ReadSymLink-test\n"; } else { err = errno; std::cerr << "symlink failed with error " << err << "\n"; return 1; } // Open it for reading int fd = open( "/tmp/ReadSymLink-test", O_RDONLY | O_SYMLINK ); if (fd < 0) { err = errno; std::cerr << "open failed with error " << err << "\n"; return 2; } std::cout << "open succeeded\n"; // and read it char buffer[200]; ssize_t bytesRead = read( fd, buffer, sizeof(buffer) ); if (bytesRead < 0) { err = errno; std::cerr << "read failed with error " << err << "\n"; return 2; } else { buffer[ bytesRead ] = '\0'; std::cout << "read of symlink result: " << buffer << "\n"; } return 0; } The result, running under Sonoma 14.2 (beta) is created file /tmp/ReadSymLink-test open succeeded read failed with error 1