Not sure if it is still an actual question but it is quite common one. There are few things here to be aware of: Your app must be trusted for accessibility. When AXIsProcessTrusted() returns false, it is a bad idea to use event taps with kCGEventTapOptionDefault. You may use kCGEventTapOptionListenOnly option (instead of kCGEventTapOptionDefault). If you're not going to prevent events from propagating further, you can use this option. It should not block any input even if AXIsProcessTrusted() is false. If you're going to prevent events from propagating, well, don't create tap until AXIsProcessTrusted() is true and make sure you remove the tap once it becomes false. Still there is a caveat. If the user revokes accessibility permission for your app by removing the app from the list (instead of unchecking the check box), AXIsProcessTrusted() continues to return true but the tap will hang.

Figured it out. The login item quits too soon. It should wait for the open operation to be completed. Something like (not the best solution, for illustrative purpose only): [workspace openApplicationAtURL: [NSURL fileURLWithPath: path] configuration: configuration completionHandler:^(NSRunningApplication* app, NSError* error) { 	if (error) { 		NSLog(@"Failed to run the app: %@", error.localizedDescription); 	} 	exit(0); }]; [NSThread sleepForTimeInterval: 10];

Also, most Audio Unit hosts do listen to NSViewFrameDidChangeNotification notifications posted on the Audio Unit's custom view.  This is resizing initiated by the Audio Unit. There is plenty of information on this. I'm looking for inverted flow. How window owner (host) can tell to the custom view it is time to resize as the user resized the window (if there is a possibility of course). There is a supportedViewConfigurations property in AUAudioUnit, which allows the host to query multiple view configurations with different sizes. Will host allow the user to resize window by grabbing window edge with these? It doesn't look like that.