When using Foundation Models, is it possible to ask the model to produce output in a specific language, apart from giving an instruction like "Provide answers in ." ? (I tried that and it kind of worked, but it seems fragile.) I haven't noticed an API to do so and have a use-case where the output should be in a user-selectable language that is not the current system language.

For months now we're trying to find an issue with one of our apps, were a window suddenly becomes narrow and can't be resized horizontally any more. It's a bug that only happens sporadically and we can't provide a "focused test project" to demonstrate the issue; thus we can't ask for code-level support at this moment. To debug this issue, we've overwritten a private method on NSWindow that gets the constrained window min and max sizes (valuable hint of Kristin from the AppKit team in a WWDC 2025 one-on-one session where I was able to show it to her in my debugger). When the bug hits, the maxSize's width (usually 10000) becomes smaller than the minSize's width. One way (but not the only one) to trigger this issue is to move the window from one display to another and back. Sometimes the bug triggers after a few back-and-forth movements, sometimes it takes minutes to trigger or I give up… but for other people the bug happens seemingly out of nowhere (of course there must be a trigger but we haven't noticed common patterns yet). It looks like an AutoLayout issue since a suspicious thing happens when the bug triggers: calling constraintsAffectingLayoutForOrientation:NSLayoutConstraintOrientationHorizontal on the NSThemeFrame usually returns just two constraints. But when the bug triggers, it returns a whole bunch of constraints, related to all kind of views of our app. Asking the NSThemeFrame for its direct constraints still shows the same two constraints are present and active (NSWindow-current-width and NSWindow-x-anchor). How to proceed in hunting down this issue when we're unable to produce a demo project? We can only reproduce the bug with our big product, and only sporadically: sometimes I can trigger it in a minute, sometimes it takes me 15 minutes or even more. Issue happens on macOS 15 (currently running 15.5).

Xcode 16.2 suddenly injects the UIRequiredDeviceCapabilities key into our app's Info.plist. This results in a rejection from App Store Connect because of this key: TMS-90109: This bundle is invalid - The key UIRequiredDeviceCapabilities in the Info.plist may not contain values that would prevent this application from running on devices that were supported by previous versions. Refer to QA1623 for additional information: https://developer.apple.com/library/ios/#qa/qa1623/_index.html The setting INFOPLIST_KEY_UIRequiredDeviceCapabilities is empty in our project, yet Xcode still injects: <key>UIRequiredDeviceCapabilities</key> <array> <string>arm64</string> </array> How can we prevent that? Or is there a way to strip it out during the build process? The Info.plist seems to get generated during an invisible build step, is there a way to make this explicit?

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?