I would also like to know this.

I am having the same problem.

Please add this to the documentation of scrollEdgeAppearance The description on that page says "The appearance settings to use when the edge of any scrollable content reaches the matching edge of the navigation bar." The word "any" is misleading, because it is not true. Thank you.

I've just written code which makes the same assumption about AVAudioEngine thread safety, and I'd like to know the answer as well. I share the similar concerns about the general lack of documentation about thread safety. When I had less iOS experience, I created a project based on GameKit and struggled with unreliable behavior. Years later I wondered if the problems might have been caused by various GameKit network request completion handlers being called on threads other than the main thread, and I didn't know enough yet to consider this possibility, as it was not mentioned in the documentation. Now I write assert(Thread.isMainThread) everywhere I suspect there's even the slightest chance an API completion handler might not be called on the main thread. Based on my past experience with other parts of AVFoundation, my instincts tell me that it might be safe to restrict all interaction with a single AVAudioEngine object to a background thread. If my code blows up in the next few months, I'll post again here.

You might be able to override this behavior by assigning a blank view to tableView.tableHeaderView with the height that you'd like, but there's more to this rabbit hole. The visual style of table views in popovers is inconsistent across Apple's apps, like Calendar, Pages, and Numbers, so it's unclear what the right thing to do is. Depending on the context, the table view's background color may be a flat gray instead of systemGroupedBackground, as recommended by the HIG. The padding you mentioned may or may not be present. The popover's drop shadow may be darker than the default. When view controllers are pushed in the context of a navigation view controller in a popover, the popover may elegantly change size during the transition, compared to the default behavior which is to change size only after the push transition has completed. Animating the popover's size in concert with the push transition is tricky to achieve and requires a lot of experimentation. I haven't looked at iOS 16 yet.

Somewhat related, the documentation for setNeedsUpdateOfSupportedInterfaceOrientations https://developer.apple.com/documentation/uikit/uiviewcontroller/4047535-setneedsupdateofsupportedinterfa states "By default, this method animates any changes to orientation. To perform a nonanimated update, call this method from performWithoutAnimation(_:)." and when I attempt to use performWithoutAnimation, it randomly doesn't have an effect half of the time, and I see the unwanted interface orientation change animation.

You are all misinterpreting this log message. I have found it to be a daily source of inspiration.

Thank you! : - )

For Swift, I believe you should add ACCELERATE_NEW_LAPACK=1 and ACCELERATE_LAPACK_ILP64=1 in Build Settings > Preprocessor Macros. This made the warnings go away for me. However, once you do that, then it seems you are required to target iOS 16.4 and later.

Hi @tracyhenry did you ever make any progress on this issue? I'm in the same situation. It appears to me that the visionOS simulator doesn't support grounding shadows. It's possible that they'll work on a physical headset, but there's no way to tell yet. Also with respect to lighting, where do you see that the docs say that DirectionalLight is actually supported on visionOS? I first looked into this on Monday July 31 and the DirectionalLight doc page didn't include visionOS in the list of supported platforms for DirectionalLight (or any other light types). I've also seen a WWDC Slack Q&A post that strongly implies that any sort of traditional lights or depth map shadows aren't supported on visionOS, only environment lighting and the grounding shadows. I haven't yet seen evidence that grounding shadows will work in any context. fwiw, even if grounding shadows work, I assume they're going to put a shadow of your ground plane square on the floor below it, and your rocket won't cast shadows onto your ground plane square.

Never mind, I was trying ARKIt grounding shadows, not the RealityKit grounding shadows. I will continue investigating...

I tried setting GroundingShadowComponent on a ModelEntity read from a USDZ file and it didn't work for me either in Xcode 15 beta 2.

@tracyhenry I think I figured it out. I think I figured out the problem through experimentation, and GroundingShadowComponent actually does work. I think when you read a model from a USDZ file, you can't simply assign the GroundingShadowComponent to the root entity of the entity hierarchy that's in the USDZ file. GroundingShadowComponent must be assigned to each ModelEntity that's in the USDZ file hierarchy. This would explain why GroundingShadowComponent worked when directly assigned to sphereEntity in your code, because it's a ModelEntity. Assuming the existence of Entity/enumerateHierarchy, defined below, you could write something like this after you load the entity from the USDZ file: usdzFileEntity.enumerateHierarchy { entity, stop in if entity is ModelEntity { entity.components.set(GroundingShadowComponent(castsShadow: true)) } } This worked for me when I tried it. import RealityKit extension Entity { /// Executes a closure for each of the entity's child and descendant /// entities, as well as for the entity itself. /// /// Set `stop` to true in the closure to abort further processing of the child entity subtree. func enumerateHierarchy(_ body: (Entity, UnsafeMutablePointer<Bool>) -> Void) { var stop = false func enumerate(_ body: (Entity, UnsafeMutablePointer<Bool>) -> Void) { guard !stop else { return } body(self, &stop) for child in children { guard !stop else { break } child.enumerateHierarchy(body) } } enumerate(body) } }

The size of the first window an app presents is defined by the UILaunchPlacementParameters and PreferredLaunchSize keys in the Info.plist file. This size is also used while the app is still loading. I couldn't find this documented anywhere, so it's possible it will change in the future.

By "if I later update the attachment to display a different set of controls", what I meant is that the reality view's RealityViewAttachments and my attachment's corresponding entity remains unchanged, but my attachment's view is repopulated with a different set of controls depending on several if/then statements. The set of controls can also change dynamically over time in response to user action. (I only ever have one attachment.) I should have time tomorrow to experiment with this more. Thank you for the suggestions.