Same problem with the countsDown Timer method. But I can confirm that the bug is fixed in iOS 18.1 beta.

In Xcode 16 RC, the Simulator version is 18.0 (22A3351), and the SDK version is 18.0 (22A348). But, In the https://developer.apple.com/download/ page, iOS 18 RC id Build 22A3354. So hopefully the problem is fixed on the device even it it isn't in the simulator. EDIT: the bug is on the device too.

Problem is still there with Xcode 16 RC's simulator, so with iOS 18 RC I suppose ... No fix, no workaround, no feedback at all in FB14890220. This bug it breaking my app's main purpose to display a time based counter in a widget. Disappointing.

It only seems to appear with texts created with the .timer DateStyle . Bug can be seen with the following widget code. struct WidgetBugEntryView : View { var entry: Provider.Entry var body: some View { VStack { Text("Timer OK:") Text(entry.date, style: .timer) Text("Timer Bug:") Text(entry.date, style: .timer).minimumScaleFactor(0.3) Text("Emoji:") Text(entry.emoji) } } }

my submitted binaries are stuck in Processing. https://developer.apple.com/system-status/ does not indicate that there is a problem, but I suspect that there is one. (yesterday, there was another problem on App Store connect : sales could not be downloaded)

same problem. app AppSales cannot download sales report anymore. web data.ai cannot cannot download sales report anymore. on https://appstoreconnect.apple.com/trends/reports, the reports cannot be downloaded manually and it displays an error message. clicking on the contact us link from the web site error message leads to a broken page : https://itms6-appstoreconnect.apple.com//WebObjects/iTunesConnect.woa/wa/jumpTo?page=contactUs

Perfect, thanks for your answers. I'll be using the Caches subdirectory. It is great to be able to be able to share the cache between the app and the different app extensions.

Thank you! Just to be sure, can you confirm that you are talking about the directory for app groups created by appending "Library/Caches" to containerURL(forSecurityApplicationGroupIdentifier:) and not the NSCachesDirectory. I'm asking this, because : I don't see any mention of a "tmp" directory in containerURL(forSecurityApplicationGroupIdentifier:) the link you are referring to seems to talk about the app container and not the app groups container

I have a couple of app bundles that have been waiting for review for about 10 days. App bundle review should be pretty straightforward, but I suspect this is something very low on their priority list, so I'm afraid the wait is not over. Indeed, they must be very busy with iOS17. If they fix at least one of the iOS17 related bugs I've submitted using the feedback assistant (from which I have no feedback), then they'll be forgiven :)

I just got some feedback that my TSI will be processed soon. Thanks for forwarding the issue (I guess).

An 'easy' fix for this would be to base your seed (used by getRandom) on the current hour (more precisely, the time when your widget is not being refreshed). That way, if your timeline is refreshed during the period when your displayed data should be the same, then your randomly returned object will always be the same.

I have the same problem with quick clicks in my widget: sometimes the app opens when the button is pressed. Strangely, I can't reproduce it with the Emoji Rangers sample code from Apple (you should try if it's the same for you). I don't understand why, as I have tried to display the same content in my app as the Emoji Rangers one, but I still have the problem. I'm speculating here, but maybe the button click is ignored when the timeline provider loads the updated data, but the widget still responds to the clicks to open the app.

I also have the same problem. PHImageManager requestImageForAsset does not return an HDR image from an HDR video in the library. Note : Similarly, AVAssetImageGenerator does not return an HDR image from an HDR AVAsset.

I had the same problem with Version 14.2 (14C18). As suggested, in a previous post, "git status" (in terminal) revealed that one file was still marked as modified, although it had been comitted by Xcode. This was the problem causing Xcode crash.

4 years later, yes it helped ! Thank you :)