The following behavior seems like a bug in the swift compiler that ships with Xcode 16 beta 6. Add the following code snippet to a new iOS app project using Xcode 16 beta 6 and observe the error an warning called out in the comments within the itemProvider() method: import WebKit extension WKWebView { func allowInspectionForDebugBuilds() { // commenting out the following line makes it so that the completion closure argument of the trailing closure // passed to NSItemProvider.registerDataRepresentation(forTypeIdentifier:visibility:loadHandler:) is no longer // isolated to the main actor, thus resolving the build issues. It is unexpected that the presence or absence of // the following line would have this kind of impact. isInspectable = true } } class Foo { func itemProvider() -> NSItemProvider? { let itemProvider = NSItemProvider() itemProvider.registerDataRepresentation(forTypeIdentifier: "", visibility: .all) { completion in Task.detached { guard let url = URL(string: "") else { completion(nil, NSError()) // error: Expression is 'async' but is not marked with 'await' return } let task = URLSession.shared.dataTask(with: url) { data, _, error in completion(data, error) // warning: Call to main actor-isolated parameter 'completion' in a synchronous nonisolated context; this is an error in the Swift 6 language mode } task.resume() } return Progress() } return itemProvider } } Now, comment out the line isInspectable = true and observe that the error and warning disappear. Also filed as FB14783405 and https://github.com/swiftlang/swift/issues/76171 Hoping to see this fixed before Xcode 16 stable.

Platform and Version iOS Development environment: Xcode 16.0 beta 5 (16A5221g), macOS 14.6.1 (23G93) Run-time configuration: iOS 18.0 beta 5 (22A5326g) Description of Problem Starting with iOS 18 SDK, test bundles containing a +load method that accesses UIScreen.mainScreen result in deadlock during test bundle injection. Also filed as FB14703057 I'm looking for clarity on whether this behavior is considered a bug in iOS or whether we will need to change the implementation of our app. Steps to Reproduce Create a new iOS app project using Objective-C and including unit tests Add the following code snippet to any .m file in the test target: @interface Foo: NSObject @end @implementation Foo + (void)load { UIScreen * const mainScreen = UIScreen.mainScreen; NSLog(@"%@", mainScreen); } @end Run the tests Expected Behavior As with iOS 17 & Xcode 15, the tests run to completion. Actual Behavior With iOS 18 & Xcode 16, deadlock during test bundle injection. stack_trace.txt

We've recently increased our use of SPM in our iOS app's Xcode project. However, we've noticed that if the Xcode project is open when we switch to a different git branch using another tool (e.g. git on the command line or in a 3rd-party GUI), the Package.resolved file is modified unexpectedly. We've received some conflicting advice about the purpose and appropriate treatment of the Package.resolved file. Some say to add it to .gitignore. On the other hand, the docs say: …be sure to commit your project’s Package.resolved file to your Git repository. This ensures a reliable CI workflow that always uses the expected version of a package dependency. For now, our workaround is to use Xcode to switch git branches, but this seems like an unusual limitation. We're on Xcode 15.3/15.4. There is discussion on the Swift Forums of potentially related problems: https://forums.swift.org/t/xcode-automatically-updating-package-resolved/41900

I just read Quinn "The Eskimo!"'s great post on UIApplication Background Task Notes. A couple further points of clarification that would be useful: Is it guaranteed that the expiration handler will only be invoked after beginBackgroundTask(expirationHandler:) returns? Is it safe to invoke endBackgroundTask(_:) more than once for a given identifier?

Are mergeable libraries compatible with digital signatures and privacy manifests? If so, what happens to the privacy manifests from each merged library? Do they get merged?

Relevant background: WWDC23: Get started with privacy manifests WWDC23: Verify app dependencies with digital signatures Upcoming third-party SDK requirements Many of the SDKs that will require privacy manifests and signatures are distributed as source and integrated via Swift Package Manager. I recently studied the progress made by ~10 of the listed SDKs and it seems like there's a growing consensus that the solution to including a privacy manifest when distributing via source is to list the manifest as a bundled resource. However, I've seen little discussion of the signing requirement. This is understandable since, as the forum post Digital signatures available for Swift Packages? points out, the dependency signing talk was focused on binaries. Yet, I'm curious whether signing of some kind will actually be required for SDKs distributed as source (e.g. to enable validating the authenticity of the privacy manifest). Clarification on this point would help tremendously as we work to ensure we'll be compliant as soon as the new requirement begins to be enforced.