Has anyone tried submitting to App Store yet? I have a critical update ready to go, but I can’t risk this same bug happening with hundreds of thousands of users.

https://mastodon.social/@brianmueller/116564966499241821 There are some +1 replies to this post. So far, I'm aware of this issue affecting CARROT Weather, Overcast, Pedometer++, and Parcel.

I've since heard of two other popular apps affected. There aren't all that many Apple Watch apps compared to the number of iPhone apps, and this may only be affecting ones that are set to run independently of their iPhone counterpart (so an even smaller percentage).

Ah that's right, I forgot they had separate provisioning profiles. Been a long time since I did an ad hoc build!

Ad hoc working is encouraging at least, doesn't that use the production version of the provisioning profile?

I’m seeing what appears to be the same issue with my watch app distributed through TestFlight. For a small subset of users, the watch app icon stops opening entirely after the app has been installed and working for a while. Complications/widgets continue to work, but tapping the app icon does nothing. There’s no normal crash report. I pulled a sysdiagnose from one affected user, and the watch logs showed repeated launch denials for the main watch app bundle with messages like: signature state: Profile Missing, reason: Provisioning Profile Not Found Unable to launch because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user cannot launch untrusted application I also saw MobileInstallation log: _InstallProvisioningProfile: Could not install embedded profile: 0xe800801f (Attempted to install a Beta profile without the proper entitlement.) What’s especially confusing is that: the same TestFlight build works fine on many other watches complications still work on affected watches reinstalling sometimes fixes it temporarily, then it can come back later Have any of you pushed updates to the App Store/production version after seeing this? If so, did you see any similar issues there, or does this seem limited to TestFlight/beta installs? I’m trying to judge whether this is mainly a TestFlight/watch install-trust problem or something that could affect production users after an app update. I really don't want to submit this update I've been working on to the App Store then have this be an issue for a huge number of users, so if anyone can reassure me on that it would be appreciated!

Fixed in Xcode beta 5, which released a day after iOS beta 5.

Waiting on this as well.

That worked! Do you know which result type opens a URL? I couldn't find one.

I'm unable to get the app to open with OpenIntent, even when my ControlWidgetButton's class is added to both the main app and the extension targets. What code did you use to get that to work?

Ah, I just figured out how to do this, but it's only on watchOS 11 and iOS 18 unfortunately - .widgetAccentedRenderingMode(.desaturated)

I'm seeing the same thing in WidgetKit on iOS 18. I wonder if this is a bug in WidgetKit, as I can't imagine this is working as intended. Are you doing this on watchOS 11? What's the behavior on watchOS 10?

In the last month or so (probably since the release of iOS 17.2), I've started getting a lot of reports of users losing all their NSUserDefaults as well. I never had a problem with the prewarming stuff from iOS 15 - this is a completely new issue. Has anyone else been experiencing anything like this on iOS 17? @eskimo - have there been any recent changes to iOS that might affected NSUserDefaults?

How did you manage to archive a build for visionOS? When I archive, it seems to always archive just the iOS version, even though I've added visionOS as a supported destination. When I try to archive for the visionOS simulator, it says "invalid run destination".

This appears to be fixed in the 10.1 beta.