Either I am going crazy or Xcode behaves at least very different from the previous versions. Checked with Xcode 12.2 and 12.3 beta. Issue 1 You can do something like this without @implementation @interface Bar : NSObject (void)foo; @end and project compiles Issue 2 (or part of issue 1). Foo is just an empty object with one no-op method -(void)bar. Foo.m is not included in compiled sources. #import "ViewController.h" #import "Foo.h" @interface ViewController () @property (nonatomic, strong) Foo *fooProperty; @end @implementation ViewController (void)viewDidLoad { 		[super viewDidLoad]; /** Issue #2 (or maybe 1 part deux) The star of the show is Foo *fooProperty. Foo.m is not included in compiled sources. But for some reason, there is no mention of it during the linking stage. Uncomment next two lines and compilation fails Foo *fooInstance = [Foo new]; [fooInstance bar]; Or you can uncomment this self.fooProperty = [Foo new];*/ 		[self.fooProperty bar]; }

Hi We are working on an authorization plugin. Privileged mechanisms in our setup store/retrieve items to/from system keychain. We add trusted applications for these keychains items via SecTrustedApplicationCreateFromPath , though it's now marked as deprecated. The problem via facing atm is that if the user installs our plugin on macOS 10.14 and then makes an upgrade to 10.15, our plugin loses access to these keychain items. As far as we understood, it happens because starting from 10.15 authorizationhost uses xpc helper to access system keychain items. We tried to add explicitly SecTrustedApplicationRef with /System/Library/Frameworks/Security.framework/Versions/A/MachServices/authorizationhost.bundle because, according to SecTrustedApplicationCreateFromPath doc: For application bundles, use the path to the bundle directory. Pass NULL to refer to yourself, i.e. the application or tool making this call but it didn't help. Is there is a way for us to achieve what we want without lifting ACL restrictions?

Hi guys.I've searched the forum, and while there are some similar questions, I was not able to find an answer. I am are working on an authentication plugin, and now I need show our plugin even on a screensaver. I've changed 'system.login.screensaver' rule to 'authenticate-session-owner-or-admin', and added our plugin in 'authetication' mechanisms. Screensaver UI drops to an older version, my plugins are getting invoked, and everything is as expected, but one thing. I am not able to present our NSWindow on lock screen. I've tried to play around with level property and some other stuff, but for no avail. According to my logs window is created, centered, and orderedFront. But it's invisible. I would really appreciate any suggestions on how to solve it or where to look?

Hi folksWe are working on auth plugins. We wrapped it in .pkg, codesign, notarize everything worked like a charm. Then we added a shell script to clean up all the traces of our plugins. We dropped both .pkg and sh script in dmg, codesigned, etc., everything is fine.The problem is that now we decided to add a "proper" uninstaller. By proper, we mean something that is going to be launched by double-clicking on it without any additional steps. And thus began our struggle with notarization. So far, I've tried:1) Simply changed .sh to .command. But didn't find a way to notarize it.2) I've moved the script in command-line tool, wrap it in AppleScript. Sign executable with Developr ID Application, even notarize it within zip just in case, put it in dmg, notarize and staple dmg. But when I attempt to launch uninstaller, I get "<Uninstaller> can't be opened because the identity of the developer cannot be confirmed."3) Tried some other weird things like wrapping .command in .app, point to this .command as Executable file in .plist etc.So the question basically, is there is a proper way to do it? I don't want to create another .pkg to uninstall plugins because .pkg interface is tightly coupled with the installation process and not uninstallation.

Hi We are working on an authentication plugin. It uses two privileged mechanisms, the first one invokes before our main unprivileged mechanism, and the second one after it allows login. We want to use them to communicate with a system keychain. The first mechanism should read from a keychain, and the second should write some data. What we want to achieve is to make this reads and writes obviously without a dialog to enter admin name and password. What is the proper way to do it? Our first mechanism is launched just before "builtin:login-success" and the second one just before "loginwindow:success", if this plays any role.