add

add.

@Vision Pro Engineer As you can see from the attached image, NSMainCameraUsageDescription is already present in the Info.plist, at the same level as Application Scene Manifest. So I do not understand what your recommendation to “add NSMainCameraUsageDescription to your Info.plist” is supposed to address in this case. The key is already configured, yet I still receive the failed to request an authorization error. Moreover, the exact same issue occurs with Apple’s own sample code. Given this situation, why was adding NSMainCameraUsageDescription suggested as a workaround? The attached image clearly shows that it is already configured. When there is a time difference and I receive an answer that does not appear to address the actual issue, it is difficult to know what I should investigate next. Your response has unfortunately left my development completely blocked. Please investigate why the authorization request is failing even though NSMainCameraUsageDescription is already configured, especially considering that the issue is also reproducible with Apple’s sample code. My development environment is Xcode 27 beta 5, running on an Apple Vision Pro (M5) with visionOS 27 beta 8.

This update includes a deadline for visionOS 26 compatibility, and I have also included some questions regarding that matter. Could you please take a look? https://developer.apple.com/forums/thread/814972

I have also submitted this request via Feedback Assistant. FB Number: FB19350167

@DTS Engineer Thank you for your response. From your explanation, I understand that RealityKit itself does not support ray marching and that the Compositor Services framework is only applicable for apps that leverage Metal-based rendering. I also acknowledge that my original question lacked details regarding the intended use of ARKit features. My assumption is to utilize ARKit capabilities other than hand tracking or world tracking. To confirm, is it correct to understand from your official guidance that, under these conditions, there is currently no supported approach to implement ray marching in visionOS with RealityKit?

@DTS Engineer On visionOS, RealityKit does not support CustomMaterial (Surface Shader / Geometry Modifier), so your advice isn’t applicable and is off-target. Please provide the optimal guidance for visionOS, assuming Shader Graph Material (ShaderGraphMaterial), and include concrete API names, sample code, and references to the latest official documentation / WWDC session numbers.

@DTS Engineer Thank you for your reply. I understand that your advice about using Metal ray tracing to render parts of the scene suggests integrating it with RealityKit. Are you referring to using low-level meshes in this context? To be honest, this answer alone doesn’t give me any clear idea of what to do. I have very little experience with Metal itself.

FB18991542.

@Vision Pro Engineer Thank you very much for your advice. Would it be correct to say that this issue will not be resolved unless we update to visionOS 26 beta? This project is currently being developed using the official release version of visionOS, not the beta version. The reason is that we have a trial operation scheduled in the near future, and therefore we are refraining from using the beta version. If this issue cannot be resolved on the development side, we are also considering alternative approaches. So if it’s clear that this can only be resolved with visionOS 26 beta, we would like to proceed with an alternative plan. We have observed that this issue occurs regardless of whether image-based lighting is used. With that in mind, could you please confirm whether our understanding is correct that this issue no longer occurs across portal boundaries in visionOS 26?

@radicalappdev Thank you for the suggestion! Yes, I did try using EnvironmentLightingConfigurationComponent as described in the WWDC 2024 session. I also experimented with different values such as intensityExponent and applied the component to both the virtual space entity and the world entity. However, unfortunately it didn’t resolve the issue. The lighting still shifts noticeably when crossing the portal — especially when going from the virtual environment back into the real-world view. The CG objects appear much darker after crossing, even with environment lighting configured. I also tried adding an ImageBasedLightComponent to the world, which helped a bit with consistency, but the lighting discontinuity through the portal still remains quite visible. It seems like the lighting system doesn’t fully preserve consistency across portal boundaries, or maybe there’s some additional configuration I’m missing? If you’ve seen a case where this worked seamlessly, I'd love to know more about the setup.

I just checked, and I received an email notification from TestFlight, allowing me to successfully install the app. Has this issue been resolved? Will this problem no longer occur for the time being?

I am experiencing the same issue. Not only myself, but multiple users on X are also reporting the same problem. Additionally, this issue has been occurring for several days now without any signs of improvement. https://x.com/search?q=testflight&src=typed_query&f=live TestFlight Issues Encountered Uploaded apps remain in the "Processing" state without any progress. It takes an unusually long time for uploaded apps to transition from "Processing" to "Completed." Status change notifications are not being sent via email during testing. Even when the app status changes during testing, the corresponding version does not appear in the TestFlight app's list. As of March 20, TestFlight was functioning normally. For reference, I am encountering this issue with a visionOS app. I urge Apple to promptly investigate the cause of this issue and provide an update on the current status, as well as an estimated timeline for resolution.

I am experiencing the same issue. Not only myself, but multiple users on X are also reporting the same problem. Additionally, this issue has been occurring for several days now without any signs of improvement. https://x.com/search?q=testflight&src=typed_query&f=live TestFlight Issues Encountered Uploaded apps remain in the "Processing" state without any progress. It takes an unusually long time for uploaded apps to transition from "Processing" to "Completed." Status change notifications are not being sent via email during testing. Even when the app status changes during testing, the corresponding version does not appear in the TestFlight app's list. As of March 20, TestFlight was functioning normally. For reference, I am encountering this issue with a visionOS app. I urge Apple to promptly investigate the cause of this issue and provide an update on the current status, as well as an estimated timeline for resolution.

I ran into the same event, though with Volume. Is this a bug after all?