Posted answer below

Thanks for the quick confirmation.

What about contactAccessPicker? That seems to be a view modifier. From what I can tell, I have to present a UIHostingViewController, which will then present this view on top of that (causing a double presentation). Is there a way to avoid that, to I present contactAccessPicker directly, without needing to present a separate UIViewController first?

I filed one (FB13841043) 2 months ago, and was recently updated with a message saying "the behavior you experienced is currently functioning as intended". Basically the recommendation is to use UITabBarController.isTabBarHidden API and create a custom control if you can't work with the new tab bar design. Personally, I think it's ridiculous that they would make major changes to standard behavior that's been around since UIKit was introduced in iOS2.0, without offering a simple opt-out option.

Hi ... just to confirm, if the user has granted limited access to a set of contacts, we can't rely on CNContactHistory to detect if any information was added / removed from one of the selected contacts (i.e. no CNChangeHistoryUpdateContactEvent event will be fired)?

I haven't gotten any update on the feedback request I filed 6 weeks ago (with a test sample project). Can someone comment there or here to let me know if there's any plan to fix this issue, or is it "working as expected" and I have to come up with a workaround for it?

This is not what I was asking. My question was "Is there a way to revert to the old iPad UITabBar look and placement that we've been using before?" Currently, as of Beta4, the answer is 'No', which is frankly bizarre. How can one make a change so fundamental to how many iPad apps work without offering an option to keep the old behavior? This is really terrible from both a developer and user perspective. I filed FB13841043 6 weeks ago ... as of now, it's not been acknowledged or responded to.

Hi, Thanks, and you're right ... I use the dequeReusableCellWithIdentifier: to create a cell for sizing the collectionView cell dynamically (in collectionView:collectionViewLayout:sizeForItemAtIndexPath: Using self.collectionNameCell = [[ContactNameCollectionViewCell alloc] init] does prevent the crash, but the cell isn't sized anymore so it shows as empty.

I filed FB13852136 and added a reproducible test project to it.

That's a shame

I was asking about CKFetchRecordsOperation. It turns out the limit there is 400 records at a time.

I filed this FB13300807 a month ago, and haven't heard back from anyone. This is why CloudKit is so frustrating to work with ... there's no avenue or channel to communicate with the actual CloudKit teams, other than throwing a Feedback request into the void and hoping for some (possibly helpful) response over the next few weeks.

I created FB13325773 with a sample project, if you're able to take a look. I was able to reproduce the issue in a new Xcode project, where I remove the storyboard and try to create the app's window programatically, this time with UIWindowSceneDelegate. Same problem ... app works fine on iOS simulator, but crashes on the 'makeKeyAndVisible' call when running on Apple Vision simulator.

The firstScene object isn't nil, thought the windows and keyWindow properties are both nil. The assertion I get is: *** Assertion failure in BOOL _UIWindowSceneCompatibleIsHidden(UIWindow *__strong)(), UIWindowScene.m:2732 Is there a way I can inspect it?

Thanks. I filed FB13300807 and added the container identifier as well. Is there anything else I would need to add to the ticket? Can you also confirm what the CKErrorServerRejectedRequest signifies? And whether, in this case, it makes sense to just recreate the same operation and send it over again? Thanks.