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

Please correct me if I'm wrong OP, but I think what they're actually trying to achieve is not opening other apps, but instead, giving the user a choice of timers from their own app as configuration options, so the user can configure the control widget to show (or manipulate) that timer. The "Open App" example was just illustrating the control configuration with dynamically generated options. If that's the case @Jack8898, then you need a "ControlConfigurationIntent" that has a @Parameter allowing the user to select an AppEntity representing your timers.

In case anybody comes up against this, one "solution" is to do the opposite of the hack I tried previously. Use a ZStack, and put the button or link in front of the image instead of behind it. In that case, you can achieve a quite nice "semi-desaturated" effect, by putting a .fullColor but low opacity version of the image in front, and the .desaturated version behind it. Alternatively, you can just put a Color.clear in front, constrained to the same proportions as your image, and have that as the button. e.g. ZStack { Image("puppy") .resizable() .widgetAccentedRenderingMode(.desaturated) .aspectRatio(1, contentMode: .fit) Link(destination: URL(string: "bugdemo://desaturated-now_works")!) { Color.clear .aspectRatio(1, contentMode: .fit) } } Or: ZStack { Image("puppy") .resizable() .widgetAccentedRenderingMode(.desaturated) .aspectRatio(1, contentMode: .fit) Link(destination: URL(string: "bugdemo://desaturated-now_works")!) { Image("puppy") .resizable() .widgetAccentedRenderingMode(.fullColor) .aspectRatio(1, contentMode: .fit) .opacity(0.2) } } Obviously not a fix, but a decent enough work around.

We came across this same crash recently, but it was slightly different to all the above cases I think, so hopefully this helps someone. We were actually already using cellForItemAtIndexPath: rather than directly dequeuing a cell, but were calling the UICollectionViewDataSource's implementation in our viewController instead of directly on the UICollectionView, and so of course calling the data-source's method will in turn call dequeueReusableCell e.g. [self collectionView:self.collectionView cellForItemAtIndexPath:indexPath]; instead of: [self.collectionView cellForItemAtIndexPath:indexPath]; Changing to the latter fixed the issue.

This seems to just be the shape of keyboards (both system and custom) in iOS26, so it is working as intended. This is not a gray bar at the top of the keyboard, it is the entire rounded background view of the keyboard and your content is inset vertically inside it. The idea is that your keyboard (or custom UIInputView) has a clear background, and therefore seamlessly shows the system's rounded background view. If you remove the white background of that top section in your keyboard, then it will look correct?