Having the exact same problem.@logicat Did you ever find a root cause or fix besides deleting & reinstalling your app?Can't create any new files.The error message is "The file couldn't be saved." and there is no underlying error in the NSError instance.errno == 17 after the write failure.The file does not actually exist, nor are there any *.tmp.****** files present in the same parent directory.Affects a very small segment of my user base, but that number is growing.In my case, I only have reports for iOS 13+.Offloading the app *does not* fix the problemDeleting & reinstalling the app fixes the problem, but is obviously undesirable.

Can you configure the deployment targets that Carthage builds dependencies with? I'm using CocoaPods and had the same problem. For me, the solution was to delete the deployment target settings for all the pod targets (most of which were iOS 9, etc) so they'd fallback to the values I have set in my configurations, which are higher (iOS 12, macOS 10.13, etc).

Same issue. Running my app from Xcode 12 gets stuck on the launch screen for about a minute. Had this same issue during the Xcode 11 beta.

This isn't Xcode 12 specific. Deleting the contents of ~/Library/Developer/Xcode/iOS DeviceSupport seems to be the fix (worked for me just now): https://developer.apple.com/forums/thread/123068?answerId=420683022#420683022

@andrewjackman The suggestion by @OOPer will work. You could also use a DisclosureGroup, but it will display a disclosure indicator, and I don't see how to suppress that. GraphicalDatePickerStyle is what you want to choose if you're trying to replicate the inline calendar style display that is seen in the Calendar app. Unfortunately, the DatePicker does not seem to size itself correctly when using the GraphicalDatePickerStyle. I tried it in a List, a Form, and a ScrollView, and it has the same problem in all of them. By default, it just gets compressed to a tiny, unusable size. The only way I could find to get it to display correctly was to *manually* provide a minHeight value for it. That is, of course, a terrible solution since that value will be different based on the container's width and the current trait collection. I tried calculating the minHeight value using a static UIDatePicker, calling sizeToFit on it. This worked pretty well for calculating the required height of a DatePicker with displayedComponents set to [.date]. Unfortunately, it doesn't calculate the correct height when using the [.hourAndMinute] or [.date, .hourAndMinute] configuration, it doesn't provide enough height for the time related views. I also tried the static UIDatePicker's systemLayoutSizeFittingSize: by passing .layoutFittingCompressedSize to it, but this did not return an accurate height at all. Maybe there's a better way to calculate it, but we shouldn't have to calculate it at all. Even when providing a minHeight, I see log statements while debugging due to the DatePicker's generated auto layout constraints being unsatisfiable. I believe all this sizing stuff is a bug. I'll be submitting a feedback report about it today.

@Claude31 I don't see that feature either. I hope it was just overlooked.

If you haven't received a response for a significant amount of time, try revoking your application and reapplying. Make sure your description of why you actually need to use the hardware is concise, honest, and compelling. I rushed my initial application and my pitch for why I needed it probably indicated as much. After not hearing anything for over a month, I followed my own advice by revoking and reapplying with a more thoughtful explanation for why I needed it. I was approved a few days later.

Sadly, setting DEAD_CODE_STRIPPING to NO does not resolve the issue for me. I'm having the issue with a dynamic library, so perhaps that setting doesn't help in that situation. I also tried setting PRESERVE_DEAD_CODE_INITS_AND_TERMS to YES. This didn't help either. UPDATE: It looks like linking against a dynamic lib from a swift package, the -dead_strip flag is added no matter what.

Same problem here with Xcode 12.5 & iOS 14.5.

The simplest way I've found to avoid this madness is to always switch to my main app's scheme and select "Any iOS Device" before staging/committing. If that results in a change for you, you'll have to commit that change, but that should be the last time you have to if as long as you always select "Any iOS Device" before staging/committing going forward.

@angarov Did you request the new entitlement? If so, did Apple approve your request promptly?

The problem continues with macOS 12.4.

Noticed the same thing just now

I filed a feedback, FB11280425, about this awful behavior on 8/16/22. Still no response from Apple and the problem persists in the latest Xcode 14.1/iOS 16.1 betas. Here's the sample project I created for it: https://github.com/gcox/SwiftUIBugs/tree/main/SwiftUI_ForEach_Behavior

This problem has been resolved in macOS 13. That said, it's concerning that whatever the underlying fix was has not been back-ported to macOS 12.x. I worry the fix was unintentional since it has been fixed since early in the macOS 13 beta cycle. If the fix was intentional, that means Apple has known about the problem for months without fixing the issue in macOS 12.x, which seems unlikely. I hope this doesn't get reintroduced.