Hi, I'm updating our app to use Xcode 16 and Swift 6 language mode. I'm stuck on updating our live activity code. I looked at the Emoji Rangers sample project and after switching it to Swft 6 mode, it has the exact same errors as our project. The main problem seems to be that Activity is not Sendable, which prevents us from passing it to child tasks to await things like activityStateUpdates and contentUpdates (those are also not Sendable). Is there any guidance on this? Updated sample code? Another project?

Reposting (after a while) from the Swift forums - the build timeline for our project has a lot of weird gaps in the beginning - almost 15 seconds in total, which is quite a big chunk of the total build time. Is there any way to determine why they exist or how I could fix them? I hope it's just something hidden and not the build system literally doing nothing... This is on Xcode 15.4.

I already filed feedback FB13777941 for this, but wanted to ask if anyone has the same problem, since I can't find anything on google or SO. I created a new package in Xcode (15.3) and added this to it: import SwiftUI struct Test: View { var body: some View { Text("Hello world") } } #Preview { Test() } The package builds, tests can run. Previews don't work. This is more or less the error I get from the diagnostics button (formatted for readability): LoadingError: failed to load library at path ”PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/PACKAGE_NAME_63097C4A372B9C87_PackageProduct”: Optional(dlopen(PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/PACKAGE_NAME_63097C4A372B9C87_PackageProduct, 0x0000): tried: 'PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (no such file), 'PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (mach-o file, but is an incompatible architecture (have 'arm64', need 'arm64e')), '/System/Volumes/Preboot/Cryptexes/OSPATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (no such file), 'PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (mach-o file, but is an incompatible architecture (have 'arm64', need 'arm64e')), 'PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/Versions/A/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (no such file), 'PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/Versions/A/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (mach-o file, but is an incompatible architecture (have 'arm64', need 'arm64e')), '/System/Volumes/Preboot/Cryptexes/OSPATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/Versions/A/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (no such file), 'PATH_TO_DERIVED_DATA/Build/Intermediates.noindex/Previews/macos/PACKAGE_NAME/Products/Debug/PackageFrameworks/PACKAGE_NAME_63097C4A372B9C87_PackageProduct.framework/Versions/A/PACKAGE_NAME_63097C4A372B9C87_PackageProduct' (mach-o file, but is an incompatible architecture (have 'arm64', need 'arm64e'))) I don't remember ever having this problem. The arm64 vs arm64e makes no sense to me - why would Xcode get that wrong... and only for previews? I've tried restarting, deleting derived data, the usual rain dances. Any ideas?

Hi, I'm trying to implement a type conforming to WKScriptMessageHandlerWithReply while having Swift's strict concurrency checking enabled. It's not been fun. The protocol contains the following method (there's also one with a callback, but we're in 2024): func userContentController( controller: WKUserContentController, didReceive message: WKScriptMessage ) async -> (Any?, String?) WKScriptMessage's properties like body must be accessed on the main thread. But since WKScriptMessageHandlerWithReply is not @MainActor, neither can this method be so marked (same for the conforming type). At the same time WKScriptMessage is not Sendable, so I can't handle it in Task { @MainActor in this method, because that leads to Capture of 'message' with non-sendable type 'WKScriptMessage' in a `@Sendable` closure That leaves me with @preconcurrency import - is that the way to go? Should I file a feedback for this or is it somehow working as intended?

Sometimes when running UI tests, the tests fail on keyboard input because the "Speed up your typing" keyboard tutorial overlay obscures the keys. This happens randomly, but sometimes repeatedly. Is there a way to turn this off? Checking for this tutorial before any keyboard input would significantly complicate tests just to check for one edge case...

My app setup is similar to https://forums.developer.apple.com/thread/133495 - I have an app target, some frameworks and local Swift packages. I added the package tests to the test plan.Now, when "gather code coverage" is just "on" in the test plan, I get code coverage from the package targets. But when I selectively add only the targets I want (including the package targets), the package targets don't show up in the code coverage results at all.Gathering code coverage for all targets isn't really what I want, because that includes a lot of third-party code that I'm not interested in.