Hi all, We're seeing an intermittent issue in a native SwiftUI + RealityKit app on Vision Pro (visionOS 27.0.1, still there on 27.2). When we open a mixed ImmersiveSpace, roughly 1 in 10–30 opens, everything ends up offset from where it should be. Sometimes it's 50 cm, sometimes several meters, sometimes it's rotated. Holding the Digital Crown to recenter fixes it immediately. We are attaching things to the camera, like we have a window following the user and that is offset in these rare cases which makes the app not usable. In the device logs, a good open looks like this: backboardd (recenter) Setting new world origin with anchor ... backboardd ARWorldTrackingProcessor: Added world anchor ... successfully (x4) backboardd (recenter) Finished (error: (null)) setting set new world origin ... A bad open looks like this: backboardd (recenter) Setting new world origin with anchor ... arkitd SLAMAnchorUpdate: Failed to add anchor request ... NSPOSIXErrorDomain Code=4 backboardd ARWorldTrackingProcessor: Failed to add world anchor ... com.apple.arkit Code=200 "Adding an object failed." (x4) backboardd (recenter) timeout exceeded. Forcing fade in. Like whenever the bad state occurs it is because adding a world anchor seems to fail. I haven't tested with visionOS26 but the same app didnt run into that problem ever. So the system seems to fail adding its own origin anchors, gives up after 2 seconds and shows the space anyway. Has anyone else run into this? And is there any way to detect it from the app or trigger a recenter in code? Thanks!

I'm looking to find the best setup for a game on AVP that gives the best quality environment with gameplay but there seems to be a mix of possible solutions each with their own drawback. My ideal scenario is a high fidelity room/environment while making use of the PS VR2 Sense controllers to track the user's hands and give them more inputs via the controllers. Eg they hold a weapon tracked to the controllers with the buttons able to use the weapon, shooting and hitting enemies in the room. I want to aim more for highest qualtiy gaming than cartoony so opted for foveated streaming from the Mac as my ideal, but this seems limited to only having some base inputs from the hands and no controller inputs for hand and positional tracking from the controller movement (as they need the data from the Vision Pro camera but the game is technically running on the Mac and streamed to the VP) The only real solution for what I want here is to go via RealityKit as a native Vision Pro app but this reduces the game quality I had in mind as the entire thing is now rendering on the VP instead of the Mac. Am I missing something here or is this a real limitation today? To reitarate I'm looking for: highest fidelity game quality (rendering as much as possible on the Mac) tracking the VR2 Sense controller's positions (to track a weapon) in 3D space

I was wondering whether there is a way to authenticate a CloudXR connection without using a QR code in a local deployment scenario. If the server is running in a headless environment, QR code-based authentication would not be practical. I reviewed the documentation but could not find any information on alternative authentication methods. Is a non-QR authentication workflow similar to the remote case supported?

Hello, I'm currently trying to make a collaborative app. But it just works only on Reality View, when I tried to use Compositor Layer like below, the personas disappeared. ImmersiveSpace(id: "ImmersiveSpace-Metal") { CompositorLayer(configuration: MetalLayerConfiguration()) { layerRenderer in SpatialRenderer_InitAndRun(layerRenderer) } } Is there any potential solution too see Personas in Metal view? Thanks in advance!

We are developing MadnessBot as a business-only Vision Pro automotive inspection app for professional mechanics and repair shops, intended for private business distribution. Main Camera access is essential for analyzing the vehicle and component in front of the technician. A native development app is running on our physical headset, and chat plus OBDLink CX diagnostics have been tested. Our existing Apple Developer Program membership is enrolled as Individual. We contacted Developer Support on October 6, 2026, with a follow-up on October 9, for assistance converting it to Organization. The conversion form asks for the type of tax ID historically associated with the Individual membership; the Account Holder does not know that record and has asked Support to verify it before selecting an answer. The enterprise API request form remains inaccessible until organization enrollment is confirmed. We have not submitted a camera entitlement request yet. Our planned initial request is Development Only Main Camera access for registered test devices. Feedback reference: FB25132939. Could the Enterprise APIs for visionOS team help route this prerequisite blocker to membership support, or advise the correct escalation path so we can complete conversion and apply for Development Only access?

When i use the MFMailComposeViewController in visionOS, there is no cancel button for the controller. The button at the bottom closes the app. Is anyone else experiencing this? if([MFMailComposeViewController canSendMail]) { MFMailComposeViewController* controller = [[MFMailComposeViewController alloc] init]; controller.mailComposeDelegate = (id <MFMailComposeViewControllerDelegate>)view; [controller setToRecipients:toAddresses]; [controller setSubject:subject]; [controller setMessageBody:body isHTML:isHtml]; [view presentViewController:controller animated:YES completion:nil]; }

We paint a looping 360° video on the inside of a sphere with VideoMaterial(avPlayer:): an AVQueuePlayer plus AVPlayerLooper, a ModelEntity with an inward-facing equirectangular mesh, inside a .mixed ImmersiveSpace. No shaders, no VideoPlayerComponent. We could not find an official Apple sample that puts a VideoMaterial on a 360° sphere; this is the plain pattern from the VideoMaterial(avPlayer:) reference and the one used in threads like 734081. On Apple Vision Pro hardware the video renders correctly. In the visionOS Simulator (27.0, 26.5 and earlier 26.x, Xcode 27.0) the whole frame has a strong purple/magenta cast. Audio and timing are fine. The video (which we cannot share, so here is its metadata, image sample of issue on simulator provided below): MP4, HEVC Main, 8-bit 4:2:0, 3840x1920, tagged BT.2020 primaries, HLG transfer (ARIB STD-B67), BT.2020 non-constant matrix, both in the colr atom and in the SPS VUI. ffprobe -show_format -show_streams (trimmed): [STREAM] index=0 codec_name=hevc profile=Main codec_type=video codec_tag_string=hvc1 width=3840 height=1920 pix_fmt=yuv420p color_range=tv color_space=bt2020nc color_transfer=arib-std-b67 color_primaries=bt2020 r_frame_rate=30000/1001 avg_frame_rate=679200/22663 duration=37.771667 bit_rate=25030607 [SIDE_DATA] side_data_type=Stereo 3D type=2D horizontal_field_of_view=360000/1000 [/SIDE_DATA] [/STREAM] [STREAM] index=1 codec_name=aac profile=LC codec_type=audio codec_tag_string=mp4a sample_fmt=fltp sample_rate=48000 channels=2 channel_layout=stereo duration=37.758333 bit_rate=128176 [/STREAM] [FORMAT] nb_streams=2 format_name=mov,mp4,m4a,3gp,3g2,mj2 duration=37.778333 bit_rate=25160348 TAG:major_brand=mp42 TAG:minor_version=1 TAG:compatible_brands=isommp41mp42 [/FORMAT] AVFoundation's view of the track, from CMFormatDescriptionGetExtension on the loaded video track: primaries=ITU_R_2020 transfer=ITU_R_2100_HLG matrix=ITU_R_2020 bitsPerComponent=8 The playback code, reduced to the essentials: let item = AVPlayerItem(url: fileURL) let looper = AVPlayerLooper(player: player, templateItem: item) // retained player.actionAtItemEnd = .advance let material = VideoMaterial(avPlayer: player) let sphere = ModelEntity( mesh: try equirectSphere(radius: 12), // lat/long grid, normals inward, materials: [material] // UVs (u, 1 - v), inward winding ) sphere.position = [0, 1.5, 0] rootEntity.addChild(sphere) // rootEntity was added in RealityView { } player.play() What we have ruled out in a minimal sample project: Apple's own 360° HLS example (360 Lighthouse, HEVC Main 10, 10-bit, BT.709 SDR) plays with correct colours in the same sphere, same code, same simulator session. Rewriting our file's colr atom to BT.709 (three bytes, no re-encode) is honoured by AVFoundation (the track's CMFormatDescription then reports ITU_R_709_2 for primaries, transfer and matrix) but the tint stays. So the remaining differences between the failing file and Apple's working stream are 8-bit Main vs 10-bit Main 10, HLG/BT.2020 in the bitstream VUI vs BT.709, and local MP4 vs HLS. The minimal sample project (without the video) is available on request. Is this a known limitation of the simulator's VideoMaterial path with 8-bit HLG content, and is there a recommended way to get device-equivalent colour in the simulator? Feedback filed as FB24997147. Here is a sample of the result on the simulator of a cement column, painted white, but rendered purple on simulator:

Environment: Apple Vision Pro, visionOS 27.0.1 (24M372). Magic Keyboard, with Settings › Awareness & Safety › Reveal Keyboards set to Always. Our app puts the user in an opaque virtual room while they work at their real desk, using app windows and Mac Virtual Display. A virtual desk is placed on the real desk. It is world-locked: positioned once from a PlaneAnchor (PlaneDetectionProvider), then a plain entity at fixed ImmersiveSpace coordinates. No AnchorEntity or WorldAnchor is involved. We offer two modes: .mixed, and .progressive for Digital Crown control. Each gives us only half of what desk work needs. 1. The revealed keyboard drifts in progressive immersion (FB25006789) In .progressive, the physical keyboard shown by keyboard awareness does not stay registered with the virtual desk. After the keyboard has been out of view for a few seconds (for example, while looking at a Mac Virtual Display window), it looks "floaty" when you look back: as the head turns, it slides against the desk. Turning right, the keyboard moves left farther than the desk does. What we checked: It happens in .progressive at any Crown amount, and in .full. With identical content in .mixed (no app passthrough cutout, so again only keyboard awareness shows the keyboard), it is much steadier. On 27.0.1, PlaneAnchor and DeviceAnchor coordinateSpace(correction: .rendered) are exactly equal to their .none transforms: 0 mm, 0°, scale 1. That held over 835 per-frame samples with ±50° yaw and up to 36 cm of head movement. So the rendered correction gives the app nothing to compensate with. The app's desk transform is constant while the drift is visible. upperLimbVisibility(.automatic) vs .visible and a .portrait progressive aspect ratio make no difference. Possibly related: https://developer.apple.com/forums/thread/796557 (FB19666209). 2. No immersion style combines what desk work needs (FB25006837) We need, at the same time: windows (our own and Mac Virtual Display) never covered by the room's walls, furniture or trees; the Digital Crown to bring the real surroundings back in; a passthrough cutout over the real desk, and a well-registered keyboard. .mixed: ✓ OcclusionMaterial cutouts reveal passthrough. ✓ The keyboard stays registered. ✗ RealityKit entities can render in front of windows, including Mac Virtual Display and window chrome. breakthroughEffect doesn't cover whole windows or Mac Virtual Display. ✗ The Crown can't adjust immersion. .progressive: ✓ Windows always stay in front of immersive content (as an Apple engineer confirmed in https://developer.apple.com/forums/thread/764556). ✓ The Crown adjusts immersion. ✗ OcclusionMaterial reveals nothing inside the portal, so there is no desk cutout. ✗ The keyboard drifts (issue 1). Because of issue 1 we have switched our default back to .mixed, and lost windows-in-front. Questions Is keyboard awareness in .progressive/.full expected to be registered less accurately than in .mixed? Is there a supported way to keep it registered with world-locked content, or to get the pose at which the system draws it? In .mixed, is there a supported way to keep windows (including Mac Virtual Display) in front of an app's immersive content? Or, in .progressive, a supported way to show passthrough in an app-defined region inside the portal? Any pointers or workarounds are appreciated.

Since moving to Xcode 27.0 (27A266a) with the visionOS 27.0 simulator runtime (24M362), generating a mesh with several parts through MeshResource.generate(from: MeshResource.Contents) makes the simulator go black for a couple of seconds and restart. The app does not crash; the simulator's render server does: Thread ... Crashed :: com.apple.CoreRE.ResourceFetchManager-service-queue 0 DirectResource specialized static IndexValidation._validate_neon(_:vertexCount:) 1 DirectResource DRValidateIndices 2 CoreRE re::(anonymous namespace)::validatePrivateData(id<REMeshPayload>, unsigned char const*, unsigned long) 3 CoreRE -[REMultiBufferMeshPayload initWithCoder:] 4 Foundation _decodeObject Environment: MacBook Pro (M1 Pro, 16 GB), macOS 27.0 (26A428), Xcode 27.0 (27A266a), visionOS 27.0 SDK (24M361); failing runtime visionOS 27.0 simulator (24M362); working: the visionOS 26.5 simulator runtime (23O470) under the same Xcode, and an Apple Vision Pro on visionOS 27. What I have established: It reproduces with a fully synthetic mesh: one model, three parts (1330 / 20 / 24 vertices, 9513 / 72 / 120 indices), random positions, normals, UVs and triangle indices. Only the part layout matters. The mesh is valid: every part's indices are within its own vertex count, counts are multiples of three, attribute buffers match. RealityKit's app-side validator agrees and lets it through (it does reject a broken part with REMeshPartDescriptor: index buffer payload range is invalid), then the render server's validator traps on the accepted payload. Single-part meshes of any size, primitives, and compiled .reality scenes are fine. Same mesh, same Xcode: fine on a simulator device created on the 26.5 runtime, fine on a visionOS 27 device. Only the 27.0 simulator runtime traps. FB number: FB24831983. Workarounds so far: a simulator device on the 26.5 runtime, or generating one MeshResource per part. Has anyone seen DRValidateIndices trapping on the 27.0 simulator?

If .topBarPinnedTrailing is used for the placement of a ToolbarItem, if this item is the only one in the toolbar then it is not displayed. This .topBarPinnedTrailing appeared in iOS 27.0 to allow a button to be always visible in the toolbar if when there are overflows with many buttons in the toolbar. A toolbar button should always be visible, this behaviour is a bug. It is a great issue on iPhone Duo which has less space for buttons in the toolbars, this attribute was designed to be sure the button using this attribute would always be visible. Bug is also there on Mac Catalyst and visionOS. A feedback was created FB24882292 /// Shows a View with a toolbar with a .topBarPinnedTrailing button. /// If the tool is the only one, it is not displayed. It is designed to be always visible, but it can be missing on the screen. /// If there are one or more additional buttons, then the .topBarPinnedTrailing is well displayed. /// /// Bug reproduced on iPhone 18 Pro Max simulator 27.0, iPhone Duo simulator iOS 27.1, /// Mac Catalyst 27.0, Vision Pro simulator visionOS 27.0 /// > Warning : to test this ContentView, embed it in a NavigationStack. struct ContentView: View { @State private var twoButtons = false var body: some View { VStack { Text("A toolbar should be always visible") .padding() Button { twoButtons.toggle() } label: { Text(twoButtons ? "Remove second tool" : "Add second tool") } } .toolbar { // ‼️ this button is missing if it is the only one. // ‼️ This is due to .topBarPinnedTrailing which makes it disappear if it is alone. ToolbarItem(placement: .topBarPinnedTrailing) { Button { print("topBarPinnedTrailing pressed") } label: { Label { Text("topBarPinnedTrailing") } icon: { Image(systemName: "ladybug.fill") } .labelStyle(.iconOnly) } } if twoButtons { ToolbarItem(placement: .topBarTrailing) { Button { //Barre d'icône ajouter une scène print("topBarLeading pressed") twoButtons = false } label: { Label { Text("topBarLeading") } icon: { Image(systemName: "minus") } .labelStyle(.iconOnly) } } } } } }

An incomprehensible error occurs whenever I try to access Main Camera features. I have already acquired the Main Camera entitlement and granted the required permissions, yet the error persists. To make matters worse, even Apple’s provided sample code triggers the exact same issue. The error message is far too uninformative to diagnose the root cause, and I urgently need a resolution as this is completely blocking progress. Multiline [C:1-2] Error received: Invalidated by remote connection. failed to observe with mask <BLSXPCBacklightProxyObserverMask: 0x108accf80; didUpdateToState: YES; eventsArray: YES> error:<XPC error received on message reply handler (3:BSServiceConnectionErrorDomain) "The operation couldn’t be completed. XPC error received on message reply handler"> non-launching port is incompatible with service identifier "com.apple.PointerUI.pointeruid.default-service" nw_socket_copy_info [C1:2] getsockopt TCP_INFO failed [102: Operation not supported on socket] nw_socket_copy_info getsockopt TCP_INFO failed [102: Operation not supported on socket] Unable to find a compatible slice for binary archive at /System/Library/Frameworks/CoreImage.framework/ci_uberwrapper_bin.metallib *** Assertion failure in void ar_session_request_authorization(ar_session_t _Nonnull, ar_authorization_type_t, __strong ar_authorization_results_handler_t _Nonnull)_block_invoke(), session.m:1491, reason: This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist. <NSXPCConnection: 0x10e68dcc0> connection to service with pid 86 named com.apple.arkit.service.authorization: Exception caught during invocation of reply block to message 'requestAuthorizations:withReply:'. Exception: This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist. ( 0 CoreFoundation 0x0000000198b756d4 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1205972 1 libobjc.A.dylib 0x000000018d3a71cc objc_exception_throw + 88 2 CoreFoundation 0x0000000198b755c0 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1205696 3 ARKitCore 0x00000002bbd640cc 53FDDDD4-8DD1-3E86-ACB0-8867D29AF781 + 479436 4 CoreFoundation 0x0000000198b7c5b4 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1234356 5 CoreFoundation 0x0000000198b79558 686CE4EB-CE52-3DD5-8B23-EF6A6BBFACEA + 1221976 6 Foundation 0x000000019de4220c 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2109964 7 Foundation 0x000000019de41dd0 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2108880 8 Foundation 0x000000019de4651c 61E78A52-3B44-3DCE-AF6D-92C33FA0FACA + 2127132 9 libxpc.dylib 0x00000002c43d5a00 CE0BB604-B358-3F22-B1DA-FFACEFCA20AD + 150016 10 libxpc.dylib 0x00000002c43c5678 CE0BB604-B358-3F22-B1DA-FFACEFCA20AD + 83576 11 libdispatch.dylib 0x00000002c41045fc 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 108028 12 libdispatch.dylib 0x00000002c41083ec 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 123884 13 libdispatch.dylib 0x00000002c40f37c0 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 38848 14 libdispatch.dylib 0x00000002c40f4450 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 42064 15 libdispatch.dylib 0x00000002c40fe3ec 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 82924 16 libdispatch.dylib 0x00000002c40fdd18 4CF750D7-AC3B-3175-9863-2F059D3D3715 + 81176 17 libsystem_pthread.dylib 0x00000002c4364e34 _pthread_wqthread + 292 18 libsystem_pthread.dylib 0x00000002c4362910 start_wqthread + 8 ) *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist.' *** First throw call stack: (0x198b756c8 0x18d3a71cc 0x198b755c0 0x2bbd640cc 0x198b7c5b4 0x198b79558 0x19de4220c 0x19de41dd0 0x19de4651c 0x2c43d5a00 0x2c43c5678 0x2c41045fc 0x2c41083ec 0x2c40f37c0 0x2c40f4450 0x2c40fe3ec 0x2c40fdd18 0x2c4364e34 0x2c4362910) *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This app failed to request an authorization. The NSWorldSensingUsageDescription / NSHandsTrackingUsageDescription / NSAccessoryTrackingUsageDescription / NSMainCameraUsageDescription keys may be missing from this app's Info.plist.' *** First throw call stack: (0x198b756c8 0x18d3a71cc 0x198b755c0 0x2bbd640cc 0x198b7c5b4 0x198b79558 0x19de4220c 0x19de41dd0 0x19de4651c 0x2c43d5a00 0x2c43c5678 0x2c41045fc 0x2c41083ec 0x2c40f37c0 0x2c40f4450 0x2c40fe3ec 0x2c40fdd18 0x2c4364e34 0x2c4362910) libc++abi: terminating due to uncaught exception of type NSException Xcode has killed the LLDB RPC server (pid: 2210) to allow the debugger to detach from your process. BlockQuote visionOS 27 beta 5

After updating to visionOS 27.0, WorldTrackingProvider.allAnchors returns WorldAnchor.originFromAnchorTransform values that do not match what anchorUpdates delivers for the same anchor, read at the same moment, both isTracked == true, with no .updated event in between. The difference is a rigid frame change, not drift: Same vertical offset on every anchor: -1.173 m. Identical across two apps and two days with the head at 1.13 m and 1.22 m, so a constant, not head height. Horizontal deltas vary per anchor, but inter-anchor distances are preserved, so it is a yaw plus translation. Stable over time, same across launches. anchorUpdates matches the ImmersiveSpace frame RealityKit draws in. allAnchors does not. On visionOS 26 both agreed. Same anchor, same instant: allAnchors (0.1486, -0.7143, 0.2231) anchorUpdates (0.1316, 0.4590, -1.0955) device pose (0.0073, 1.2195, -0.0038) Four other anchors, delta = allAnchors - anchorUpdates: ( 2.6933, -1.1733, -0.2514) (-0.0810, -1.1733, 1.1339) ( 0.1878, -1.1733, 0.9891) ( 2.6289, -1.1733, -0.1809) In our app this showed up as a placed model vanishing after a scene switch: we re-pinned the model root from allAnchors, and it landed below the floor behind the user. A standalone sample (one provider, one anchor, a green sphere from anchorUpdates, a red sphere from allAnchors) shows two spheres on visionOS 27.0, the red one below the floor: added F21942C4-… at (-0.031, 0.712, -0.976) update added F21942C4-… tracked=true at (-0.031, 0.712, -0.976) MISMATCH delta (-0.211, -1.173, 1.444) m allAnchors (-0.243, -0.461, 0.468) anchorUpdates (-0.031, 0.712, -0.976) tracked=true device (0.000, 1.129, -0.001) Questions: Is allAnchors now intentionally expressed in a different frame on visionOS 27, for example related to the new ARKitCoordinateSpaceProviding / coordinateSpace(correction:) API? The documentation for allAnchors does not mention it. If so, which frame is it, and how should it be converted to the ImmersiveSpace frame? Workaround we use: read transforms only from anchorUpdates into a per-id cache and never position from allAnchors. Filed as FB24799304. Minimal repro project attached to the feedback.

I am trying to create an app where I have multiple users modifying an entity at runtime similar to collaborative digital sculpting using SharePlay on VisionOS. When creating a collaborative experience using other 3D engines I have utilized an external server that devices send and update their state from serving as a global "source of truth". This doesn't seem to be the intended workflow for SharePlay which seemingly only allows for device to device messaging. While this works for a variety of apps it doesn't provide a smooth experience when multiple users are interacting with and manipulating the same 3D entity. Is there an intended way to do this for SharePlay? Would the best practice be to have one user serve as a host and establish a "source of truth" based on their app state? The closest example in documentation I have found is an example for using SharePlay in a drawing app. When a user is drawing they send the information for their realtime stroke through unreliable SharePlay messages and then, when they've finished, they send a reliable message with the final line. This technique makes sense for the given example since there is no scenario where multiple users would be drawing the same line, but it seemingly falls short for my use case since multiple users can sculpt in the same area of a given mesh. What would the intended approach be to achieve this with SharePlay? Is it simply a limitation of this type of networking? Thanks!

I'm currently in the WWDC26 Group Lab for Icon Composer and they will not allow questions about the newest features in Icon Composer and visionOS app icons. Why are visionOS app icons not supported? Why are they so different that this isn't possible? Are there any plans to include them? In an age where Apple is increasingly encouraging developers to create apps across multiple platforms (resizability), this becomes an even more reasonable question to ask. Why is this one platform not getting the love??

Good Evening, I have some old code that uses the CameraFrameProvider successfully when run through Xcode versions 26.0 and 26.2, but not for 26.6. I have double checked all Custom iOS Target Properties in the project's info tab to make sure all required capabilities are added. I also updated the enterprise license by adding a new entitlements file approving main-camera-access. Somewhere between Xcode 26.2 and Xcode 26.6 what has changed that affects the ability to use CameraFrameProvider and access the Main Camera? Thank you.

I’m developing two complementary developer tools: Reality Prep Pro on macOS and Reality Prep Preview on visionOS. The workflow I’m trying to solve is: Mac: prepare and validate a USDZ Vision Pro: verify that exact USDZ on-device Mac: bring the device evidence back and associate it with the exact asset revision I currently use the USDZ’s SHA-256 as the authoritative identity. If the asset bytes later change, the previous Vision Pro evidence is treated as stale and a re-test is recommended. Existing USDZ→USDZ preparation is package-preserving, so non-texture payloads such as animation/rigging data are not unnecessarily re-authored. I’d be interested in hearing from other RealityKit / Reality Composer Pro developers: Is this similar to how you currently handle asset provenance between desktop preparation and real-device testing? Are there any Apple frameworks or established visionOS practices you would recommend for strengthening this kind of revision-to-device-evidence workflow?

My app has one App Store Connect listing with released iOS, tvOS, and native visionOS versions. I have temporarily discontinued native visionOS development due to very limited adoption and no access to a physical Vision Pro for ongoing testing. I would like Vision Pro users to receive my iPad app through “Designed for iPad” compatibility instead. Xcode is configured with “Apple Vision (Designed for iPad)” and correctly produces an iOS build. I am not trying to generate another native visionOS build. The obstacle is the existing published visionOS version. Apple’s documentation says that iPad compatibility is unavailable when the app already supports native visionOS, and that a platform cannot be deleted once a build has been uploaded. Has anyone successfully made this transition while keeping the same App Store Connect record? Specifically: Is there a supported way to retire the native visionOS version and offer the compatible iPad app? Can Apple Developer Support enable this if App Store Connect cannot? What happens to existing native visionOS installations? I would appreciate any firsthand experience or clarification from Apple on whether this transition is supported.

I am getting FoundationModels.LanguageModelError error -1 when trying to use Foundation Models on the visionOS 27 simulator. It works on the iOS 27 simulator. Is this a bug with the visionOS 27 simulator specifically?

Summary A SpotLightComponent with SpotLightComponent.SurroundingsLight() (and a ProjectiveTexture) lights the flat part of my ceiling and the walls, but never the two sloped ceiling surfaces of a converted attic room, at any angle, intensity, attenuation radius or falloff. The lit area stops in a hard straight line exactly where the flat ceiling meets each slope, even though the beam clearly extends past that line. The sloped surfaces are fully present in SceneReconstructionProvider's mesh, and their faces point into the room. So this doesn't look like a scene understanding coverage problem. It looks as if physical space lighting only considers surfaces classified as horizontal ceiling, wall or floor, and skips slanted ones. Steps to reproduce Open a mixed immersive space in a room with a sloped ceiling (a converted attic, or any vaulted ceiling). Add an entity with SpotLightComponent(color: .white, intensity: 40_000, innerAngleInDegrees: 44.5, outerAngleInDegrees: 45, attenuationRadius: 10), SpotLightComponent.SurroundingsLight(), and a SpotLightComponent.ProjectiveTexture carrying a labelled grid texture so the beam's extent is visible. Place it near the floor under the wearer and aim it straight up. Run SceneReconstructionProvider alongside and draw each MeshAnchor as a wireframe (or as a solid material with faceCulling = .back) to confirm the mesh covers the slopes and faces inward. Expected The projected pattern conforms to every surface in the scene understanding mesh inside the cone, including the sloped ceiling, as it does for the flat ceiling and walls. Actual The pattern appears only on the flat ceiling strip and on the walls. Both slopes stay completely dark, with a hard straight cut at the crease. Tilting the light to aim directly at a slope, raising intensity to 200,000, and changing attenuation radius and falloff make no difference. The wireframe shows continuous mesh across the crease and onto the slopes; the back-face-culled solid view shows the slope faces pointing into the room. Screenshots attached: (1) the projected grid stopping at the crease, (2) the reconstruction wireframe covering the slopes, (3) the solid front-faces-only mesh showing the slopes are front-facing. (4) an additional image of the projected grid with both ceiling and walls in view Code let spot = Entity() spot.components.set(SpotLightComponent.SurroundingsLight()) var light = SpotLightComponent(color: .white, intensity: 40_000, innerAngleInDegrees: 44.5, outerAngleInDegrees: 45, attenuationRadius: 10) light.attenuationFalloffExponent = 0.5 spot.components.set(light) spot.components.set(SpotLightComponent.ProjectiveTexture(texture: gridTexture)) spot.look(at: from + SIMD3(0, 1, 0), from: from, upVector: SIMD3(0, 0, -1), relativeTo: nil) root.addChild(spot) Questions Is physical space lighting limited to horizontally and vertically classified surfaces by design? If so, could this be documented on SurroundingsLight, and is there a way to include slanted surfaces? If not by design, is there anything an app can do to have the light use the full reconstruction mesh?