Hello, I'm experimenting with the PortalComponent and clipping behaviors. My belief was that, with some arbitrary plane mesh, I could have the entire contents of a single world entity that has a PortalCrossingComponent clipped to the boundaries of the plane mesh. Instead, what I seem to be experiencing is that the mesh in the target world of the portal will actually display outside the plane boundaries. I've attached a video that shows the boundaries of my world escaping the portal clipping / transition plane, and also show how, when I navigate below a certain threshold in the scene, I can see what appears to be the "clipped" world ( here, it is obvious to see the dimensions of the clipping plane ), but when I move above a certain level, it appears that the world contents "escape" the clipping behavior. https://scale-assembly-dropbox.s3.amazonaws.com/clipping.mov ( I would have made the above a link but it is not a permitted domain - you can follow that link to see the behavior tho ) It almost seems as if "anything" with PortalCrossingComponent is allowed to appear in the PortalComponent 's parent scene, rather than being clipped by the PortalComponent 's boundary. For reference, the code I'm using is almost identical to the sample code in this document: https://developer.apple.com/documentation/realitykit/portalcomponent with the caveat that I'm using a plane that has .positiveY clipping and portal crossing behaviors, and the clipping plane mesh is as seen in the video. Do I misunderstand how PortalComponent is meant to be used? Or is there a bug in how it currently behaves?

In Xcode 16 beta 1 and 3, when running a VisionOS 2 simulator on an SwiftUI app that ran successfully in VisionOS 1, I received the following crash at startup: Thread 1: "*** -[NSProxy doesNotRecognizeSelector:plane] called!" I've gone through my code attempting to find any references to a plane method, but I have no such calls in my code, leading me to suspect that this is somehow related to VisionOS beta simulator code. Has anyone else run into this bug and worked around it somehow?

I'm currently developing an application where the models present inside a volumetric window may exceed the clipping boundaries of the window. ( Which I currently understand to be a maximum of 2m ) Because of this, as models move through the clipping boundaries, the interior of the models becomes visible. If possible, I'd like to cap these interiors with a solid fill so as to make them more visually appealing. However, as far as I can tell, I'm quite limited in how I might be able to achieve this when using RealityKit on VisionOS. Some approaches I've seen to accomplish similar effects seem to use multiple passes of model geometries rendering into stencil buffers and using that to inform whether or not a cap should be drawn. However, afiact, if I have opted into using a RealityView and RealityKit, I don't have the level of control over my render pipeline such that I can render ModelEntities and also have multiple rendering passes over the set of contained entities to render into a stencil buffer that I then provide to a separate set of "capping planes" ( how I currently imagine I might accomplish this effect ). Alternatively ( due to the nature of the models I'm using ) I considered using a height map to construct an approximation of a surface cap, but how I might use a shader to construct a height map of rendered entities seems similarly difficult using the VisionOS RealityView pipeline. It is not obvious to me how I could use a ShaderGraphMaterial to render to an arbitrary image buffer that I might then pass to other functions to use as an input; ShaderGraphMaterial seems biased to the fact that all image inputs and outputs are either literal files or the actual rendered buffer. Would anyone out there have already created an effect like this that might have some advice? Or, potentially correct any misunderstandings I have with regards to accessing the Metal pipeline for RealityView or using ShaderGraphMaterial to construct a height map?

I'm attempting to regularly interact with ApplicationMusicPlayer in MusicKit, even while in the background. I'd like to allow for changes in the network to allow me to change songs. While this works fine while the application is in the foreground, due to idiosyncrasies with how ApplicationMusicPlayer does not in fact "count" for your application actively playing audio while in the background my network connection becomes lost. I would like to check the network again while the app is in the background, and it seems like I could do so with BGAppRefreshTask. However, the frequency that I'd like to request would be on the order of sub-30s refresh timelines. This seems...excessive, given how BGAppRefreshTask seems to be documented. Are there best practices in terms of what is an appropriate interval for BGAppRefreshTask being executed? Is there an upper or lower bound on intervals that is known? Should I consider using something different to achieve what I'm after? Thanks for any help.

I'm attempting to create a service that: Listens on iOS device A using NWListener Broadcasts the NWService ( using NWListener(service:using:)) ) on Bonjour Allows a separate device, iOS device B, to receive information about that service via an NWBrowser Connect to that service using the information contained in NWBrowser.Result 's NWEndpoint I've been able to successfully do this using a SwiftNIO service, in the following environments: iOS device A and iOS device B are physical iOS devices on the same WiFi network. This works. iOS device A and iOS device B are iOS simulators on the same machine. This works. iOS device A is a physical device, and iOS device B is a simulator. iOS device A is not connected to a WiFi network, iOS device B is connected to a WiFi network. This works. However, when iOS device A and iOS device B are physical devices that are not connected to a WiFi network, I encounter the following behavior: The Bonjour service is correctly advertised, and iOS device A and iOS device B are able to observe the advertisement of the service. In both cases, iOS device A and iOS device B, while able to resolve an NWEndpoint for the Bonjour service, are not able to connect to each other, and the connection attempt hangs. My setup for the listener side of things looks roughly like: let opts: NWParameters = .tcp opts.includePeerToPeer = true opts.allowLocalEndpointReuse = true let service = NWListener.Service(name: "aux", type: BONJOUR_SERVICE_TYPE, domain: "") try bootstrap.withNWListener(NWListener(service: service, using: opts)).wait() // bootstrap is an artifact of using SwiftNIO Similarly, my setup on the discovery side of things looks like: let params: NWParameters = .tcp params.includePeerToPeer = true let browser = NWBrowser(for: .bonjour(type: BONJOUR_SERVICE_TYPE, domain: BONJOUR_SERVICE_DOMAIN), using: params) browser.browseResultsChangedHandler =  { (searchResults, changed) in // save the result to pass on its NWEndpoint later } and finally, where I have an NWEndpoint, I use SwiftNIO's NIOTSConnectionBootstrap.connect(endpoint:) to initialize a connection to my TCP service ( a web socket server ). The fact that I am able to get P2P networking (presumably over an awdl interface?) between the simulator and the iOS device suggests to me that I haven't done anything obviously wrong in my setup. Similarly, the fact that it works over the same WiFi network and that, in P2P, I am able to at least observe the Bonjour advertisement, strikes me that I'm somewhere in the right neighborhood of getting this to work. I've also ensured that my Info.plist for the app has a NSLocalNetworkUsageDescription and NSBonjourServices for the Bonjour service type I'm browsing for. I've even attempted to exercise the "Local Network Permission" dialog by using a hacky attempt that sends data to a local IP in order to trigger a permissions dialog, though the hack does not appear to actually force the dialog to appear. Is there some trick or other piece of knowledge regarding allowing the use of P2P w/ Network.framework and TCP connections to services?