Swift compiler is dumb for these cases, even 3 years later. Just temporarily change the Group or ForEach into eg. VStack, and you'll see the actual problem's error message.

Thanks, I filed FB17064989

Hello everyone, I wrote a comment under one of the above posts, but as the comments are hidden by default, I add it here: Ah, the dreaded "Efficiency awaits: Background tasks in SwiftUI" talk. I believe part of the features from that talk are still not implemented as of March 2025 (the talk probably describes features Apple hoped to release by WWDC 22, but then scrapped or delayed them). The .backgroundTask(.urlSession(...)) {} call described in the later part of the talk is entirely non-existent, and the presented has a placeholder code inside that callback, as there is no valid code which would compile there. Imo the whole talk should be retracted and replaced with a correct info, as I find traces of many developers spending hours and days trying to implement the described solution that doesn't work. See https://developer.apple.com/forums/thread/726443?answerId=823711022#823711022

Can we get a retraction for the whole Efficiency awaits: Background tasks in SwiftUI talk from WWDC 2022 please? I believe it is completely wrong, and the author knows it. it uses the following code, which crashes the app when executed, so clearly the code hasn't been ever run and it leaves this section empty because there seems to be no code that could work there - the only mechanism for handling the background downloads is delegate based! I just wasted two days trying to make the above code work, before arriving here to document this futility. Is this some kind of work in progress code, that was started for iOS 16 and never finished, while the remnants remain in the codebase?

This is a slide from Efficiency awaits: Background tasks in SwiftUI from WWDC 2022. It literally uses this code, which crashes with the above error when actually used. Can we get some retraction here?

If this is intentional, it’s a really bad decision, I made my own receipt validation just to get rough semi-realtime sales without waiting :/

I am not sure if the problem was ever resolved, but it definitely happens on iOS 18 & macOS Sequoia

It seems that when I build for iOS 14.1, the new linker is not used. I had to switch the project to iOS15+, and then it started linking. EDIT: Nope - once I removed the "-Wl -ld_new" (renamed from -ld_prime) flags to let the Xcode 14 build the project without error, I get "Unknown option: -make_mergeable" error again in Xcode 15 beta 8, suggesting that Xcode 15 for some reason decides to not use the new linker without being forced to :(.

According to https://speakerdeck.com/kateinoigakukun/the-new-linker-in-xcode-15, it seems that in my case xcode doesn't call the new ld-prime linker, I have no idea why, though.

Meanwhile I had to add this workaround for broken product purchase/restore on the watch: do the purchase or restore on the iPhone that syncs up the purchases to iCloud and later on the restore on the watch also fetches the purchases from the iCloud and uses those I cannot migrate to StoreKit 2, as I have WatchOS 7 and iOS 14 as a baseline.

I added my info to FB11788741 (StoreKit 1 seems broken on WatchOS 9 & 9.1 - all purchase restores fail with StoreKit error 0) I sent previously.

Same here, this seems to have been happening since the WatchOS 9 release for StoreKit 1 API, but today I finally diagnosed it. When ran in a debug build on a real WatchOS 9.1 watch, this is the error message: 2022-11-18 22:47:26.140173+0900 Weathergraph Watch Extension[438:63411] <SKReceiptRefreshRequest: 0x16515030>: Finished refreshing receipt with error: Error Domain=ASDErrorDomain Code=507 "Invalid container for application: file:///private/var/containers/Bundle/Application/4D199ED0-A419-44DD-BAB6-4C418926BD30/Weathergraph.app/PlugIns/Weathergraph%20Watch%20Extension.appex/" UserInfo={NSDebugDescription=Invalid container for application: file:///private/var/containers/Bundle/Application/4D199ED0-A419-44DD-BAB6-4C418926BD30/Weathergraph.app/PlugIns/Weathergraph%20Watch%20Extension.appex/, AMSServerErrorCode=0}

Update: From a quick test it seems that ClockKit widgets can't be updated to WidgetKit widgets at all. Even if they share the same kind, the old widget just disappears when updating from a clockkit version to the widgetkit version of the app. I am now making a 'Sorry, you will need to redo all your watchfaces because that's how Apple wants it' update screen.

Thank you, I installed the profile, and holding the side buttons caused the watch to lock up for a few seconds (UI stopped responding) and then it restarted - no idea if that is what should happen (latest GM WatchOS 9.1). However, even after an hour on charger, no logs appeared in iPhone analytics settings. I found out though, that the only way of getting the complications to refresh again, was to: Delete all complications of my app from all the watchfaces (!!!) And only then setting them up again. I verified this on two different watches with WatchOS 9.1 (by installing the previous app store version, and then a TestFlight update over that). Without a moment when none of my app's complications aren't active on any of the watchfaces, the new (extensionless) watchfaces won't refresh. Only replacing a single complication for another app's one, and then back, won't help, until I remove all of them at once. You can imagine how thrilled I am to tell this to my users. This is not how a migration should work. Feel free to reproduce this and file a radar, I am not wasting any more of my time with this. I will try tomorrow deleting the whole CLKComplicationDataSource, and trying WidgetKit only. I really hope there is a better migration story there.

iOS 16.0 RTM, still happening with a plain SwiftUI Toggle.