I am assigned to an iOS project at my new job. All the earlier developers had left the company so there is not really anybody I can ask. Our company's Apple developer program includes the max number (3) of "Apple Distribution" certificate which can exist at a time. Unfortunately I cannot use these 3 "Apple Distribution" certificate to sign anything locally, because even though I can download them I don't have the related private key. (Our CI/CD pipeline have those private keys so there those certs can be installed on the build agents.) In my Xcode (version 14.3.1, macOS Ventura 13.2.1) I see that all the projects within the xcworkspace configured to be automatically signed when compiled for "Debug" and manually signed when compiled for "Release". Provisioning profiles are already existing and valid, and the app has been submitted to app store and TestFlight several times before. All the used provisioning profiles include one of these already existing "Apple Distribution" certificates. When I try to build the app locally for "Release" configuration, Xcode is complaining that it doesn't find "iOS Distribution" certificate. Even though I change the "code_sign_identity" to "Apple Distribution" for all targets, Xcode still requires the "iOS Distribution" certificate. In CI/CD we have the same error, except there one of this "Apple Distribution" cert is installed already on the agent. (So then I generated an "iOS Distribution" certificate, included it into the already existing provisioning profiles and could build (and sign) the app with Xcode.) My question is that why does Xcode require these "iOS Distribution" certificates, despite the provisioning profiles include "Apple Distribution" certificate and from Xcode 11 these new "Apple Development" and "Apple Distribution" certificates are advised to be used. Am I missing something here? As I mentioned, the problem is already solved by creating a new "iOS Distribution" certificate, I am asking it just out of curiosity that why do I need to generate an "old" type of cert because the newest Xcode does not accept the "new" type. Or am I missing/misunderstanding something? Thanks for the help in advance!

Hi, I've recently tested my custom AuthorizationPlugin on macOS 15 (Sequoia) and I'm seeing a significant change in rendering (or precisely not rendering) the control returned by my SFAuthorizationPluginView's subclass' viewForType method comparing to macOS 14. (I developed and tested my solution on macOS 14 earlier this year). I use SFAuthorizationPluginView to present a NSView (Custom view) which contains a NSSecureTextField and a NSImageView. I show my custom plugin after the user successfully entered username and password (or only the password if the List of Users is configured in System Settings) into the builtin fields provided by loginwindow:login, so injecting my plugin:mechanism pair into the system.login.console after loginwindow:success. (I need to run my mechanism after builtin:authenticate,privileged since my plugin relies on the authentication result coming from my custom PAM module). This setup now however doesn't seem to be working: after entering the (username and) password, the circular spinner appears and my NSView never gets rendered. I've found a workaround to place my plugin:mechanism pair after loginwindow:done, so in the end of the whole authorization chain. I tried to run the good old NameAndPassword bundle, injecting it into the place of the loginwindow:login. Controls are being rendered correctly, but if I place it even right after loginwindow:login it doesn't get rendered as my custom plugin. Is anybody aware if there's anything has intentionally been changed in macOS 15? Or may it be a bug? I guess the original intention of the SFAuthorizationPluginView class was to overwrite/redefine the UI instead of the builtin username + password field, so if I look at it that way it's expected that the view it contains only gets rendered if we use it instead of loginwindow:login. On the other hand this hasn't been the case until now. Thanks for any help!