We've recently updated our build server to macOS 15.1.1 and ever since notarization sporadically fails. Notarytool says No Keychain password item found for profile: foo, even though that item is present. I found out it works when I either log in using Remote Desktop (don't need to do anything else, just login and wait) or when running security unlock-keychain via SSH (but that one's not persistent, either). We're using GitLab (via gitlab-runner on the build server) and so far notarization hasn't had much problems with the keychain. That started with macOS 15.1. Are there any changes in 15.1 that we need to be aware of to make this stable?

In macOS 15 Sequoia (tested on 15.0 and 15.0.1), the icon of our network extension (and of other third party apps) is missing. See the attached screenshot, instead of the generic app icon there should be the icon of our app. Is this a bug, or is there something we developers can/should do? I tried adding an asset catalog with the app icon, and specifying that using ASSETCATALOG_COMPILER_APPICON_NAME like we do in the main app. Even though the icon is added to the Resources folder of our .systemextension, and is referenced in the Info.plist using CFBundleIconFile and CFBundleIconName, the icon is still not showing in the System Settings.

Documentation for System Extensions talk about an "appropriate" Applications directory, but doesn't specify what this is. /Applications and its subdirectories qualifies, but are there more? Did this change in macOS 15 Sequoia? Installing System Extensions and Drivers : Your app is installed in an appropriate Applications directory of the system. OSSystemExtensionErrorUnsupportedParentBundleLocation: The app itself must be in one of the system’s Applications directories. Background: while testing one of our apps with a VPN Network Extension on the current Sequoia beta, it seems that the restrictions got tighter. I'm able to run this app in my user's ~/Applications on macOS 14.6.1, but on macOS 15.1 beta I get this error now: Error Domain=OSSystemExtensionErrorDomain Code=3 "App containing System Extension to be activated must be in /Applications folder. Current location: file:///…

I've tried to submit a bug for the Xcode project using Feedback Assistant on macOS 13.4.1 and also via web, three times, and all resulted in a broken feedbacks which can't be viewed in either the Feedback Assistant or web. FB12424944, FB12425488, FB12425504 My colleague has been able to send a feedback for a different project just fine. Instead of trying to file yet another feedback (this time for the Feedback Assistant project), I guess it's better to ask here: how to proceed?

I'm working on an iOS widget and it seems @Environment does not work here at all. I tried using @Environment(\.widgetFamily) but always got .systemMedium. So far not one environment value seems to work in my widget: neither the ones provided by the system, nor custom environment values. Example: struct WidgetEntryView : View { @Environment(\.widgetFamily) private var widgetFamily @Environment(\.controlSize) private var controlSize var body: some View { Text("\(String(describing: self.widgetFamily))/\(String(describing: self.controlSize))") } } @main struct MainWidget: Widget { let kind: String = "Widget" var body: some WidgetConfiguration { return IntentConfiguration(kind: kind, intent: MyWidgetIntent.self, provider: MyTimelineProvider()) { (entry) in WidgetEntryView() .controlSize(.large) } .configurationDisplayName("Widget Title") .description("Widget Description") } } Using Xcode 14.0 on an iOS 15.5 device, this always prints "systemMedium/regular", no matter which widget size I use or which control size I manually set. (I can also reproduce this with other views inside my view hierarchy, it's not just affecting the top-level view.) Is this a known problem? Is there a workaround, apart from passing the values I care about as explicit parameters/properties?

We're working on Packet Tunnel Provider on iOS and I was wondering about the process life cycle, in particular when a connection is stopped. There's some house-keeping I'd like to do when the connection has stopped, which may take up to a few seconds. It seems on iOS, the Network Extension process is terminated shortly after the completion handler of - stopTunnelWithReason:completionHandler: has been called. Since the house-keeping is not strictly a part of stopping the connection and I would like to allow the user to start a new connection as soon as possible: is there a way to tell the Network Extension to keep the process alive (for a while)? Or do I have to do it before calling the completion handler of - stopTunnelWithReason:completionHandler:? Related question: when there's an error and we need to stop the connection "from within" the NE, we're supposed to call - cancelTunnelWithError:. What's the lifecycle here? Do we need to tear everything down, do the house-keeping, and only then call - cancelTunnelWithError:? Or can we call - cancelTunnelWithError: and then continue to clean everything up?

This is about macOS Big Sur. Sometimes, our SysExt seems to get into a "degenerated" state. NETunnelProviderSession.startVPNTunnel(options:) returns without an error, but the call is not "arriving" at the SysExt (we've got logging there), and NETunnelProviderSession.sendProviderMessage(_:,responseHandler:) calls the handler with nil (again, no log on SysExt side about this). (The manager was queried with NETunnelProviderManager.loadAllFromPreferences.) When this happens, sometimes it works by just trying those calls again, but often that doesn't work. During the betas, we found out that simply killing the SysExt with SIGQUIT would respawn the process and everything was fine again. However, that doesn't seem to work any more (or at least not reliably). What are the options when the SysExt process is running but doesn't seem to respond? Would trying to get a fresh manager via NETunnelProviderManager.loadAllFromPreferences help in some way, or is there some way to restart the SysExt process? What can cause this in the first place, apart from us deadlocking some vital thread in the SysExt?

I just tried to update from Big Sur Developer Beta 3 to Beta 4, but the update is not happening. What happens is that in System Preferences, I get offered the update to Beta 4. I press "Update Now" and the system reboots. I see then normal boot progress bar, except it's slow/seems to be stuck. After a while the login window appears. I login and "About this Mac" says I'm still running Beta 3. System Preferences still offers to update to Beta 4. Tried it again, same result. No error or other message is shown about why the update failed. What can I check/do to install the update?

We're writing a VPN system extension for use with Big Sur. As far as I know, there may be several instances of our system extension if we're running multiple connections. I've reached a point were I need to set up XPC communication. I managed to get it working like it's demonstrated in the Filtering Network Traffic sample project - https://developer.apple.com/documentation/networkextension/filtering_network_traffic. So far so good, that works fine with one instance running: the UI is able to create an XPCConnection to the system extension, which is then able to communicate back. But how are we supposed to handle multiple system extension instances? All instances would have the same Mach service name as it's hard-coded in Info.plist using the NEMachServiceName entry, right? Thus the only way I see to communicate with a specific instance seems to be sendProviderMessage(_:responseHandler:) - https://developer.apple.com/documentation/networkextension/netunnelprovidersession/1406409-sendprovidermessage. I tried serializing a NSXPCListenerEndpoint in handleAppMessage(_:completionHandler:) - https://developer.apple.com/documentation/networkextension/netunnelprovider/1406545-handleappmessage, but that doesn't work as only NSXPCCoder may encode the endpoint. So, how should I set up bidirectional communication with the System Extension instances? I can also do old-school Mach IPC communication if that's what needs to be done, by the way.