Post not yet marked as solved
I managed to avert the problem by adding DispatchQueue.main.asyncAfter(deadline: .now() + 0.2) { ... before deleting the object and saving the context. I guess that gives the underlying view time to coalesce all the updates properly. Still feels like a little hacky, so would be great if there was a better solution to this.
Post not yet marked as solved
I discovered that the limit is 400 records at a time (just like CKModifyRecordsOperation).
Post not yet marked as solved
After much time wastage, it turns out that the problem is caused by setting the window's backgroundColor (for some reason). So it works fine after commenting out this line:
self.mainWindow.backgroundColor = [UIColor systemBackgroundColor];
Post not yet marked as solved
The issue still persists with Xcode 15.2 Beta 1. Just to reiterate: I created FB13325773 with a sample project
Post not yet marked as solved
This is still not resolved with Xcode 15.1 Beta3. I created a I created FB13325773 with a sample project, so it's a problem for 'new' projects as well.
Post not yet marked as solved
Thanks. The firstScene object isn't nil, until it's windows or keyWindow properties are both nil. Could that be the problem?
This is what the object looks like in the debugger:
<UIWindowScene: 0x106b0ef40; role: UIWindowSceneSessionRoleApplication; activationState: UISceneActivationStateForegroundActive> {
session = <UISceneSession: 0x600001793200; persistentIdentifier: com.myapp.name> {
configuration = <UISceneConfiguration: 0x600001794c40; name: 0x0>;
};
delegate = (nil);
screen = <UIScreen: 0x10711b1a0; bounds: {{0, 0}, {1366, 1024}}; mode: <UIScreenMode: 0x600000268bc0; size = 2732.000000 x 2048.000000>>;
}
I never adopted the UIScenes and UIWindowsScene APIs from iOS13+, and I run my iOS app as a single-window app. Would I have to change that to be able to run my app as a native VisionOS app?
Post not yet marked as solved
I can actually able to occasionally reproduce the problem in the Development environment as well, running my app in the simulator with Xcode. I can inspect the error given, and it seems to contain a couple of interesting things in the userInfo dictionary:
[0] (null) @"ContainerID" : @"BXXXXXXX.com.mycontainer.identifier"
[1] (null) @"NSUnderlyingError" : domain: @"CKInternalErrorDomain" - code: 2000
[2] (null) @"CKHTTPStatus" : (long)500
[3] (null) @"NSDebugDescription" : @"CKInternalErrorDomain: 2000"
[4] (null) @"RequestUUID" : @"2DCA0896-557A-4F0C-A331-4F58BC6EB86D"
[5] (null) @"OperationID" : @"19F0BF027F05095D"
Just recreating the same operation and sending to CloudKit seems to work ... but will continue testing.
I fixed it by resetting the "Location and Privacy" settings on my iPhone!
Post not yet marked as solved
Hi Quinn,
Thank you for the feedback! Since my app is already in the App Store, and this is happening on an update, this isn't the option for me. But I'm planning to release it now with as 'phased update' so that it rolls out slowly, and I can directly check against my own App Store installations once it rolls out. In case there's a problem I can pause the update, that'll give me 30 days to come up with another solution. Not the best way to move forward, but I do strongly believe that this is just a TestFlight issue so it hopefully shouldn't be a problem.
I'll update the thread when I get the update approved and tested.
Thanks!
Post not yet marked as solved
In my case, the issue turned out to be the fact that I enabled the VisionOS SDK for my main app target, but it was still set for iOS compatibility mode for all my frameworks. Changing the frameworks to also build for visionOS SDK fixed this issue for me.
Post not yet marked as solved
Some more findings:
after running into this issue with the TestFlight build, I create a Developer-ID (notarized) copy of the app, export it and save it in Applications (overwriting the TestFlight build). When I run this, I don't get any prompts, and it runs as expected.
if I run the app from Xcode with the debugger (using Mac Developer identity), I do run into the same prompts, but that's probably because the code signing is very different between a debug build and an App Store / DeveloperID build.
So it just looks like a TestFlight issue to me. But I can't really properly confirm it myself, and I'm a bit hesitant to test it out by releasing the update on the App Store, because it would lead to a lot of problems and confusion for my users if it ended up prompting them to enter in their credentials.
Your feedback here would be really valuable.
Post not yet marked as solved
A couple of weeks in, and no one has replied to the Feedback I filed. I know there's no guarantees when filing these, but it really puts the brakes on any progress I can make with my development.
Post not yet marked as solved
I also filed a feedback with the sysdiagnose attached: FB12482242
Post not yet marked as solved
I've ran the 'codesign -d -r -' tool on both the App Store and the TestFlight builds, and there's some difference there that I don't understand:
App Store:
Executable=/Applications/Contacts Journal CRM.app/Contents/MacOS/Contacts Journal CRM
designated => (anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists / or anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] / exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = ) and identifier "com.zaal.cjournalmac"
TestFlight:
Executable=/Applications/Contacts Journal CRM.app/Contents/MacOS/Contacts Journal CRM
designated => anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.25.1] /* exists */ and identifier "com.zaal.cjournalmac"
Is this expected / unrelated to the problem, Or is there something to this that might explain the issue I'm having?
Post not yet marked as solved
Thank you for the detailed response! So I have recreated this on 3 different systems ... my own, a macOS Sonoma partition, plus my spouse's machine. In each case, I downloaded the app from the App Store (so in Release configuration), then wrote something to the keychain, then downloaded the updated app through TestFlight (again, Release configuration) and tried to access the same item. I do use the file-based keychain, since I haven't been using the kSecUseDataProtectionKeychain. In fact, part of the update is to first read the values without the Data Protection flag, and then save it again with the flag so that it can use the data protection keychain.
Can you check if the TestFlight fix is still in place, or it was it overwritten? I'm using TestFlight 3.3.0, on macOS 13.4.
Should I expect to run into this if I use a Developer-ID signed app (just to test if it was indeed a TestFlight issue)?
