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.
Post not yet marked as solved
Same problem here with Xcode 12.5 & iOS 14.5.
Post not yet marked as solved
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.
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.
@Claude31 I don't see that feature either. I hope it was just overlooked.
@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.
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
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.
Post not yet marked as solved
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).
Post not yet marked as solved
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.
Post not yet marked as solved
I've had nothing but problems trying to keep CarPlay hierarchies in sync. Problems I regularly observe include:1. reloadData not doing anything (your issue).2. MPContentItems don't update on screen when their display properties are changed. This leads to users tapping one thing and getting something else since the presentation is stale.3. MPContentItems that are no longer present continue to display at the end of a list.The frequency of all these bugs seems to vary by hardware and is least likely to occur in the simulator. Because of that, the arbitrary delay you're using as a workaround may or may not be good enough on other hardware. You *could* beef up your workaround by:When you need to call reloadData...1. Start a timer with a reasonable expiration time like 2s? 3s? What's reasonable depends on your app.2. Call reloadData2. When numberOfChildItemsAtIndexPath: is executed, cancel the timer if it is running.3. If the timer expires before numberOfChildItemsAtIndexPath: is executed, repeat at step 1. You'll probably want to set some limit on the number of times you repeat this.
Yep, that was it, thank you!
