This still seems to be an issue. Did you find a solution Mitch?

Thanks @edford, that seems to be the answer. I had to use the Legacy System otherwise the app wouldn't archive, and it worked fine in Xcode 11.3, but wouldn't build at all in 11.4.Switching to the "New" build system seems to get it at least building for now, but I've not tried archiving yet, so don't know whether that's been fixed.

Thanks @thinktapwork. Your comment helped me find what was going on for us. The Intent Definition file needs to be added to both your Intents & Widget targets, but then you end up with duplicate generated classes. The only combination that seemed to work was to change the "Target Membership" code gen settings to "Private Intent Classes" for all included targets.

It doesn't seem to be an error - at least so far. Currently, old style widgets are still available on iOS14, and they remain available even when the app is built using Xcode 12 Beta 4. You can't add them to the home screen in iOS14, but as mentioned in the quote, they are at the bottom of the Today View.

Thanks @boerni. In our testing, it definitely causes an exception if you call completion more than once, but it seems to be a little different - "No such file or directory" instead of "Invalid Argument". Terminating app due to uncaught exception 'NSFileHandleOperationException', reason: '* -[NSConcreteFileHandle fileDescriptor]: No such file or directory' terminating with uncaught exception of type NSException Having said that, I'll see if I can find any ways that ours could possibly call completion more than once and see if that helps.

Did anybody solve this yet? I've tried creating the INImage using data (both PNG & JPEG) and a URL. The image shown with the selected option is effectively just a template image that always uses the widget tint color - even though it shows using the original colour on the list screen.

@Hackenbacker - did you ever solve this? It looks like you're doing everything correctly. It is almost as if the image is meant to just be a template, and will then be coloured in the widget's tint colour - even though it shows in its original colour on the list screen.

Hopefully you've already figured this out, but in case it helps anybody else. The userActivity property of the scene seems to be nil, because the activity is actually provided in the userActivities array of the UIScene.ConnectionOptions. So, you can use something like this to get it:         if let userActivity = scene.userActivity { // Do something with the activity             handle(userActivity: userActivity)         } else if let userActivity = connectionOptions.userActivities.first { // Do something with the activity             handle(userActivity: userActivity)         }

Can you not treat the two things (purchase, and account) separately? The user can delete the account and their data if they want to (therefore fulfilling the requirements for account deletion), but there's still a purchase that you can access via Restore Purchases, so if they happen to create a new account in future (before the membership expires), then they can still re-attach that purchase/membership to their new account?

This has been bugging me for weeks, and I've just narrowed it down to this exact issue! It was so difficult to isolate because it seemed to work perfectly sometimes, even with the distance param included, but then once it stopped working, it would never work again until I removed that distance param. It then starts working again, and I can safely add the distance param back until... it stops working again at some point in future 🤬 Strangely, once it stops working, it won't work again even with complete refresh of derived data, wiping device/simulator etc, so it seems like something changes that is persisted - so a possible change in the Intent Definition file that's being made by Xcode? I take it you've not found a solution since you reported this @edorphy?

Still happening in Xcode 14.0.1 RC when using the latest macOS Ventura Beta 😩

The way I think of it is that Date doesn't have a time zone - it is a universal representation of a particular moment in time, independent of time zones. When you want to expose a date to a user, you use something else to describe the moment in time in a way that suits the context in which you're trying to expose it e.g. a Calendar in order to create DateComponents, or a DateFormatter in order to create a string representation of that time. A good general way of putting it from w3.org: Date and time values based on incremental time are time-zone-independent, since at any given moment it is the same time in UTC everywhere: the values can be transformed for display for any particular time zone offset, but the value itself is not tied to a specific location.

It should absolutely be possible. You're just uploading a new archive to AppStoreConnect, and using the same bundle id. It should just replace the existing app on users' devices when they update. Are you finding that it is not possible to do it?

It's a bit convoluted, but the only way I've found to test apps built using Xcode 14, on an iOS17 device - whilst still being able to debug is as follows: Archive the app using Xcode 14 - choose the "Any iOS Device" run destination. In organizer, select the archive, and "Show in finder". Expand the archive using "Show Package Contents", then open "Products -> Applications" to see the app - you'll need this later. Close Xcode 14, and open Xcode 15. In Xcode 15, in "Devices and Simulators", select your iOS17 device. Hit the "+" button at the bottom of "Installed Apps", and drop the application file from step #3. You should see the build number of the app update in the "Installed Apps" list. You can now run the app built from Xcode 14 manually on the iOS17 device - not using "Cmd+R" from Xcode 15 or you'll replace the app you've just installed. Still in Xcode 15, attach to the app's process using "Debug -> Attach to Process" - breakpoints don't seem to work, but you can print to the log. You can also of course deliver the app via TestFlight instead of steps 1-6, and then just attach to the app's process using Xcode 15, and your iOS17 device.

It isn't working like that for me. If I show the rendering mode (from the environment) in the widget, then it always shows "Full Color", never vibrant or accented. It doesn't seem to reload the widget at all even when the rendering mode changes, but also stays "Full Color" even if the widget is explicitly reloaded whilst in tinted mode. Logged as feedback: #14259967