UserDefaults store app-related settings, and I am just worried that if an SDK also writes to the UserDefaults, that there could be potentially some key collisions between the host app and the SDK. Is the concern just in my head or does it have merit?

I have an app with a Widget Extension. Both the main app and the widget extension link against the same Swift Package, which contains a localization bundle (String Catalog) used by SwiftUI views inside the package. To make the package's views follow the app's configured language (rather than the system language), I set CFBundleAllowMixedLocalizations to NO in the Info.plist of each target (main app and widget extension). Behavior in the main app: This works as expected. If the app only supports Korean, the package's views display Korean text even when the system language is set to English. Behavior in the widget: The same views (from the same package) display English instead of Korean, even though the widget extension has the identical CFBundleAllowMixedLocalizations = NO setting and the widget's view code lives entirely in the package — not in the widget extension target itself. Question: As far as I understand, widgets are supposed to follow the host app's language setting. Given that both targets have the same Info.plist configuration, why would the widget extension resolve localized strings differently from the main app for code in the same package? Is this expected behavior for widget extensions specifically, or a bug? Is there a recommended workaround to force a widget extension (and by extension, the Swift Package code it runs) to use the app's language instead of the system language?

This was confirmed as a framework gap in an accepted answer from an Apple Vision Pro engineer in June 2024 (https://developer.apple.com/forums/thread/758014?answerId=792769022#792769022): .background fires identically whether the user taps a window's close button or the system backgrounds a window that's been out of the field of view for ~61 seconds, and there's no app-visible signal that distinguishes the two. The recommendation at the time was to use a gesture/affordance to reopen the window, and to file an enhancement request. Two years on, with the window-management APIs that have shipped since, I want to confirm whether the situation has changed as of visionOS 26. My case: VisionBlazer, a native spatial 3D creation tool (TestFlight beta, August 2026 launch). Users routinely work with several SwiftUI WindowGroup tool windows open at once — drawing tools, materials, timeline, properties, lighting — parked spatially around an ImmersiveSpace. Parking a window behind or beside you is core to the workflow. The app should terminate when the user closes the primary window, but must not terminate when a secondary window (or the primary) is simply parked out of view. What I've verified on-device (visionOS 26.5): scenePhase == .background fires identically for a user close tap and for the ~61s out-of-FoV backgrounding (SurfBoard: "…is out of FOV after 60.99 seconds. Backgrounding"). The phase sequence (active → inactive → background) and timing (~0.2–0.4s gap) are indistinguishable between the two cases. scenePhase on visionOS reflects visibility, not focus — a parked window stays .active while the user edits elsewhere, until the out-of-FoV timer fires. The session identifier reachable from the window's view hierarchy (view.window!.windowScene.session.persistentIdentifier) never matches the identifier reported by application(_:didDiscardSceneSessions:) or UIScene.didDisconnectNotification for that same close. The view-visible session stays in UIApplication.shared.openSessions indefinitely after the close. Those disconnect/discard callbacks arrive ~10–15s late and only ever carry foreign session identifiers, so they can't be attributed to a specific window. Stale-session discards from prior launches pollute the signal further. onDisappear does not fire on user close. Five strategies tried, all failed: (1) scene-object identity captured at didMoveToWindow; (2) session.persistentIdentifier matching against openSessions; (3) live re-capture of scene/session from the view hierarchy on every lifecycle change; (4) temporal correlation of didEnterBackground/didDisconnect; (5) a focus-recency heuristic on scenePhase transitions. All fail on the identifier mismatch and the visibility-not-focus semantics above. Questions: As of visionOS 26, is there now any supported way to detect that the user intentionally closed a specific window, distinct from system backgrounding? Is there a SwiftUI or scene-delegate callback tied to a window's own scene that fires only on user close? Is there a dismissalReason (or equivalent) anywhere on the close path? If none of the above exists, is an explicit in-app Quit button still the intended pattern for "quit when the main window is closed"? I have a focused test project reproducing all of this and can link it. Thanks.

I have a project that builds fine in macOS 26 with Xcode 26. On macOS 27 b4 and Xcode beta, the same project can't build because of a framework that should be pulled from a Swift Package from a package-registry (named Registry, for example below), hosted on JFrog. I have the registry set up and have the token in keychain. The resolution of the packages works. But when I build, I get error like this: error: Missing package product 'Registry.Package_Package.Package' (in target 'Target' from project 'Project') . The real package should just be 'Registry.Package'. Any help with that? Is it a bug?

Xcode 27 beta 4: how do I create a local package for my project? The menu path File > New > Package no longer exists.

Following up on my last question, I noticed that when we build, if there's a failure to resolve package dependencies, if previously package dependency resolution succeeded, then the failure is not treated as an error but only as a warning.

This may be an Xcode problem not with SPM, but when I add a package into my App project, as a local package, whenever I change the dependencies of the package, even if the change to the version conflicts with the app's version constraints, the Xcode build the app just fine. I have to close and reopen the project again before the Xcode detects the change and raise an error during the build process. Why can't SPM/Xcode just detect the change while the app is opened, and raise an error instead of using whatever cache it is using? Currently, the workaround is to never edit the package in the app project (even though I should be able to), but to open the package as separate project to make edits, then reopen the app project to build the app. Another workaround I'm trying out is to add the xcodebuild -resolvePackageDependencies as a step during the build process, to force the build to cancel if theres package dependency resolution errors. But why is Xcode just ignoring resolution errors ??

I have an iOS project based on SwiftUI in which almost all code is organised in Packages. With Xcode 26.2 and 26.3, I can preview all SwiftUI views without issues. With Xcode 26.4, the same previews don't work, in the canvas appears this error message: "Cannot preview in this file. Could not find target description for “TaskListView.swift”". The explanation is: "The list of source files that produce object files did not contain this file to be previewed. Check to make sure it is not excluded using the EXCLUDED_SOURCE_FILE_NAMES build setting." If I add a SwiftUI view to the main project files (not in a package), the preview works as expected. Is it an Xcode 26.4 regression? Or do I need to modify some configuration file?

I am testing an existing iOS app with Xcode 27 beta 3. The build succeeds, but I am seeing a new linker warning from Swift Package product targets. ld: warning: address=0xF496F points before section(28) start and the target atom is ambiguous Environment: Xcode 27.0 beta 3 Build version: 27A5218g Platform: iOS Simulator Configuration: Debug Project type: iOS app with Swift Package dependencies, also embedding a watchOS app Build command: DEVELOPER_DIR=/Applications/Xcode-beta.app/Contents/Developer \ xcodebuild -project MyWeight/MyWeight.xcodeproj \ -scheme MyWeight \ -configuration Debug \ -destination "generic/platform=iOS Simulator" \ build The build succeeds: ** BUILD SUCCEEDED ** Warnings: MyWeight/MyWeightKit/Package.swift: MyWeightKit-watchOS-product: ld: warning: address=0xF493F points before section(28) start and the target atom is ambiguous MyWeight/MyWeightKit/Package.swift: MyWeightKit-iOS-product: ld: warning: address=0xF496F points before section(28) start and the target atom is ambiguous Both warnings appear during the link step for Swift Package product framework targets. Is this a known issue in Xcode 27 beta 3? Does it indicate a real issue in the produced simulator binary, or is it likely a linker/debug-info diagnostic?

Xcode tells me Previewing in executable targets now requires a new build layout for unoptimized builds. Either set ENABLE_DEBUG_DYLIB to YES for this target, or break out your preview code into a separate framework with its own scheme. How do enable that in Package.swift. swiftSettings don't work (.define and unsafeFlags with -D ...). Creating a library product that the executable then depends on doesn't help either. I have two targets, one is an executable target. The #Preview macro is in the non-executable target.

I’ve been experimenting with Foundation Models and built a small Swift package that wraps LanguageModelSession with simple context management. The current approach checks the transcript token count using tokenCount(for:), compacts the transcript when it reaches a threshold, and retries once if exceededContextWindowSize is thrown. I’d appreciate feedback on whether this is a sensible use of Foundation Models APIs, especially around rebuilding a session from a compacted Transcript. GitHub: https://github.com/ricky-stone/FoundationContext

Is there a known workaround (other than forking) for watchOS builds in Xcode 27 that depend on packages without a declared watchOS 9.0 floor? I depend on several Apple SPM packages with no minimum deployment target, such as https://github.com/apple/swift-algorithms. My project's minimum is 26.0. Xcode 27 will not build watchOS targets with these packages because watchOS 8.0 is below its range of supported targets. /.../SourcePackages/checkouts/swift-algorithms/Package.swift The watchOS Simulator deployment target 'WATCHOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 27.0.x.

Hi, I'm trying to archive my xcode project. There is a build error. Warning: unable to build chain to self-signed root for signer "Apple Development: JOHN WILLIAM BAKER (VCZ7S72JNR)"

I'm trying to test my StoreKit package using local "Consumable.storekit" configuration added to test target as a .copy() resource. I receive various errors. On purchase attempts I receive StoreKitError.unknown. In the console I see this diagnostic messages: [SKTestSession] Error saving configuration file: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error setting value to 1 for identifier 2 for com.apple.dt.xctest.tool: Error Domain=SKInternalErrorDomain Code=3 "(null)" I these last two cases product loading failed. It feels like session require mutable .storekit file? Also, some people mention that Host Application must be selected, but it's related to Xcode projects. What is the correct way to test StoreKit within a Swift Package?

It seems that the behavior of the .copy rule in SPM packages has changed in Xcode 27. This change now results in raw files being copied into the bundle without compilation, resulting in crashes and missing resources since uncompiled resources cannot be used by the OS. More specifically, in Xcode 26, when .copy was applied to resources such as storyboards, asset catalogs, etc. it would cause Xcode to compile those resources into the respective storyboardc or Assets.car before copying. Xcode 27 does not do this and instead copies the raw files. I do understand that there is a difference between .process and .copy, and the documentation does state that the process rule needs to be used for those files. Is this a regression in Xcode 27 or is copy not compiling anything expected behavior? Submitted FB23115950

Xcode 27 refuses to build common Swift Packages for watchOS, such as swift-algorithms or swift-collections. ... 'WATCHOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 27.0.x. The error disappears by explicitly declaring in the SPM manifest "platforms: [.watchOS(.v9)]". (Patching the "SwiftStdlib" availabilities in swift-collections is insufficient.) Is there a better workaround than mirroring our whole SPM graph to declare the platform minimum? Our projects' minimums are correctly set at 11 or 26. (Also happens in the hello world Xcode 27 watchOS only project.) FB23037701 ref: https://developer.apple.com/forums/thread/829540

I get this error for every APM package that targets WatchOS, but the package did not set any versions: The watchOS Simulator deployment target 'WATCHOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 27.0.x.

Can't able to run the Create ML for training and I upgraded to MacOS 26.3 beta and I have tried older and newer

import AVFoundation var player: AVAudioPlayer? func playBackgroundAudio() { do { try AVAudioSession.sharedInstance().setCategory(.playback, mode: .default) try AVAudioSession.sharedInstance().setActive(true) } catch { print("Audio session setup failed: (error)") } if let url = Bundle.main.url(forResource: "background_music", withExtension: "mp3") { do { player = try AVAudioPlayer(contentsOf: url) player?.numberOfLoops = -1 player?.play() } catch { print("Error playing audio: \(error)") } } } playBackgroundAudio()

With Xcode 26.5, I've switched from using SwiftLint in a "Run Script" phase to using the SwiftLintPlugins package and running it as a build plugin. This works fine on one Mac, in a small project, where the warnings from the build plugin show up in the issue navigator as expected. But on another Mac, in a large project, I can see the SwiftLint build plugin warnings in the build log but they don't appear in the Xcode issue navigator. Is there some Xcode setting that could influence this, or what else can I check?