This appears to have something to do with the IconComposer .icon file containing png / rasterized layers that have transparency.
Making it a single layer .icon file with a single layer with a non-transparent PNG appears to have resolved the app store connect errors.
Sometimes it says this:
lstat(
/Volumes/workspace/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/<TARGETNAME>/IntermediateBuildFilesPath/<TARGETNAME>.build/Release-iphoneos/<APPNAME>.build/Metal/PageCurl.dat
): No such file or directory (2)
Still occurring 2 days before when RC app submissions are likely to occur. Maybe this gets fixed via a backend rollout but im not confident.
My FB has ”no similar reports”
I don’t think you can undo the creation of a version, but you can change the version number to whatever you want.
So maybe you don’t wanna do 4.0.05, but you can change it to 3.4.71.
I’m not sure if you can straight up remove it from the list. Maybe there’s a delete button in a special spot you need to hover over, like there are in some other places.
We should not be expected to all file feedbacks for Apple to fix a critical bug that should not have shipped in the first place.
CloudKit is opaque and difficult enough to implement and test that there is sometimes no way to know if we are at fault or if it’s some quirk of the system.
Only apple could have caught this bug with certainty and they should be performing a root cause analysis about why it shipped at all. Apple’s own sample app fails. Why is that not an automated test?
Try taking to social media and “hash tagging” with popular SwiftUI or other App Development related tags.
That seems to get traction faster than using official channels.
This appears to have something to do with the IconComposer .icon file containing png / rasterized layers that have transparency.
Making it a single layer .icon file with a single layer with a non-transparent PNG appears to have resolved the app store connect errors.
Sometimes it says this:
lstat(
/Volumes/workspace/DerivedData/Build/Intermediates.noindex/ArchiveIntermediates/<TARGETNAME>/IntermediateBuildFilesPath/<TARGETNAME>.build/Release-iphoneos/<APPNAME>.build/Metal/PageCurl.dat
): No such file or directory (2)
Still occurring 2 days before when RC app submissions are likely to occur. Maybe this gets fixed via a backend rollout but im not confident.
My FB has ”no similar reports”
I don’t think you can undo the creation of a version, but you can change the version number to whatever you want.
So maybe you don’t wanna do 4.0.05, but you can change it to 3.4.71.
I’m not sure if you can straight up remove it from the list. Maybe there’s a delete button in a special spot you need to hover over, like there are in some other places.
We should not be expected to all file feedbacks for Apple to fix a critical bug that should not have shipped in the first place.
CloudKit is opaque and difficult enough to implement and test that there is sometimes no way to know if we are at fault or if it’s some quirk of the system.
Only apple could have caught this bug with certainty and they should be performing a root cause analysis about why it shipped at all. Apple’s own sample app fails. Why is that not an automated test?
Try taking to social media and “hash tagging” with popular SwiftUI or other App Development related tags.
That seems to get traction faster than using official channels.