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?

Since our 1.3.20 update reached users on Sept 11, 2026, a handful of devices terminate at launch right after the App Store auto-update. Restarting the device does not help; deleting the app and reinstalling it from the App Store does. Filed as FB24755993 with 9 crash reports, the delivered package's SC_Info/Manifest.plist and a per-binary fingerprint. What the crash reports say (all identical) Exception Type: EXC_CRASH (SIGABRT) Termination: namespace DYLD, code 1, "Library missing" (terminated at launch; ignore backtrace) Library not loaded: @rpath/FBSDKCoreKit.framework/FBSDKCoreKit Referenced from: <DDB434B7-...> /Volumes/VOLUME/*/Runner.app/Runner Reason: tried: '/private/var/containers/Bundle/Application/<UUID>/Runner.app/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit' (could not register fairplay decryption, mremap_encrypted() => -1) Backtrace: dyld4::prepare -> dyld4::halt -> abort_with_payload Devices so far: iPhone XR / iOS 18.7.10 (22H374), iPhone 16 / iOS 26.6, iPhone 16 / iOS 18.7.7, plus one more not yet identified. The same package launches normally on the large majority of the ~12,000 devices that updated that day. Delivered Info.plist: DTAppStoreToolsBuild 27A261, DTXcodeBuild 17F113, MinimumOSVersion 15.0. What we established The main executable decrypts fine (dyld reaches dyld4::prepare); the failure is on the first @rpath framework in the load order, which is also the first FairPlay-encrypted embedded binary. It is not specific to the Facebook SDK. The package Apple delivers (pulled with Apple Configurator) is structurally consistent: every binary with LC_ENCRYPTION_INFO_64 has cryptid 1 and SC_Info/<name>.supp/.supf/.supx/.v4.supp/.v5.supf (main executable, App, Flutter, FBSDKCoreKit, FBAEMKit, FBSDKCoreKit_Basics, objective_c, sqlite3, the widget appex); the Firebase/Google frameworks are cryptid 0. SC_Info/Manifest.plist has SinfPaths = [SC_Info/Runner.sinf] and SinfReplicationPaths for all 12 binaries. Only the main Runner.sinf ships; the framework-level .sinf files have to be produced at install time from SinfReplicationPaths. The symptom looks like that replication not being applied to the frameworks after the delta update on the affected devices, while a fresh full install performs it. Nothing in our bundle changed between 1.3.19 and 1.3.20 except Dart code (App.framework): same Xcode 26.6 (17F113), same Flutter engine, byte-identical Facebook SDK 18.1.1 binaries (the only fat arm64+arm64e binaries in the bundle), same Firebase SDK. Both versions run normally from TestFlight and Xcode. The 1.3.20 encrypted variant carries SC_Info timestamps about 18 h after Ready for Sale, coinciding with the start of the auto-update wave. We could not obtain the delivered 1.3.19 package for comparison. Questions Has anyone seen this class of failure since early September, or with packages processed by DTAppStoreToolsBuild 27A261? Is there anything about a bundle (fat arm64+arm64e embedded frameworks? many encrypted frameworks?) that makes the framework .sinf replication on the delta-update path fragile? Is there any developer-side mitigation other than telling users to delete and reinstall? The closest earlier report I found is thread 718950 (2022, iOS 15.7–16.1, ~1 in 200 installs, "reinstall fixes it"); this looks like the same failure but concentrated on one update. fingerprint-1.3.20.json

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.

I am reporting a reproducible performance issue in iOS 18.6 where synchronizing the scroll position of two Chart views via chartScrollPosition(id:) causes a complete redraw loop when custom AxisMarks are used. This occurs even when the axis marks are technically "hidden," leading to significant frame drops and stuttering on modern hardware like the iPhone 15. Environment Device: iPhone 15 OS: iOS 18.6 (22G86) Frameworks: SwiftUI, Swift Charts, Observation The Issue When using a shared @Observable state to sync two charts, the scrolling is fluid only if the axes are at their default settings. As soon as a custom AxisMarks block is added to either chart, the following behavior is observed: Diffing Failure: The framework appears unable to maintain the identity of the axis components during the scroll update. Redraw Loop: Instead of an incremental scroll translation, the diffing algorithm triggers a full reload/re-render of both charts on every scroll offset change. Impact: CPU spikes to 100% and the UI becomes unresponsive. This happens even if the custom AxisMarks is used solely to hide the axis (e.g., AxisMarks { _ in }), suggesting the issue is with the custom declaration itself rather than the complexity of the marks being rendered. Steps to Reproduce Create two Chart views in a VStack. Bind both to a single @Observable property using .chartScrollPosition(id: $state.pos). Add any .chartXAxis { AxisMarks(...) { ... } } modifier. Scroll either chart; observe the stuttering. import SwiftUI import Charts import Observation @Observable class ChartState { var scrollPos: Date = .now } struct PerformanceBugView: View { @State private var state = ChartState() var body: some View { VStack { Chart(data) { ... } .chartScrollPosition(id: $state.scrollPos) .chartXAxis { // This custom mark triggers the performance issue AxisMarks { _ in AxisValueLabel() } } Chart(data) { ... } .chartScrollPosition(id: $state.scrollPos) } } } Questions for the Community/Apple Engineers: Is there a way to provide a stable identifier to AxisMarks to prevent them from being treated as "new" during a scroll update? Why does even an empty AxisMarks block (used for hiding) trigger a layout invalidation that standard axes do not? Are there internal optimizations for chartScrollPosition that are bypassed when the axis layout is customized?

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?

I would like to be able to use an SPM registry to access the various open source packages that my app uses. I want to do this so that I can use JFrog's Artifactory as a registry proxy, and manage my app's dependencies through it. I've found an announcement in 2019 that GitHub Package Registry was going to support Swift packages, but I have found no newer info. All the other things I've found which call themselves Swift package registries do not conform to SE-0292. Are there any public SPM registries? Will there be any in the near future?

i cant use mlx on swift for some reason, i would like for them to add the support to add it as a package

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?

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.

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

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