Ah the error had some nested hints: use 'gnu++20' for 'ISO C++ 2020 DIS with GNU extensions' standard use 'c++2b' for 'Working draft for ISO C++ 2023 DIS' standard use 'gnu++2b' for 'Working draft for ISO C++ 2023 DIS with GNU extensions' standard

@eskimo - @zentrope has a good point. What IS the desired behavior within specifically the Xcode console? I can see arguments for and against showing private variables by default. Maybe you don't want sensitive data like that ever appearing on-screen, but maybe you do want to have those debugging regardless.

@eskimo I think that in cases in which objc has successfully printed, I’ve called that code from Swift. I wonder why I’m seeing this behavior. Is it possible that something is enabled only in the Swift runtime that enables jumping to line numbers?

@Saijanai I suggest filing feature requests with specific use cases. My guess from the outside is that they’re starting from a very conservative featureset to avoid a dangerous future in which we have those future glasses that look like ordinary glasses, but which can surveil environments and so on. I certainly hope that functionality could be opened-up via explicit permissions as on other platforms. I personally think a happy medium needs to be reached too.

@jroome Thanks, got it. This helps. I do think they’re eventually going have to figure out a way to be more permissive so at least we can use the data for custom renderers in passthrough mode, not for ”evil” things. :)

@sha921 The app crashes with a console log stating that the XCTest framework could not be found, even if I add it to build phases. Could you elaborate on how to enable this?

@Saijanai Then why do we have e.g. Tobii eye tracking for research and medical rehabilitation purposes? What if you want to make a system that wants to help you look in the right direction? Anything can be evil if in the wrong hands. There's no point in blocking something that'll be hacked anyway, in my opinion. The key is to enable as strict-as-possible permissions systems and detection of intent. Maybe ways to block malicious data transfer/restrictions on network transmission of the data.

@mtoon Metal's currently only allowed in fully immersive mode. Also, I found an example online if you search around. However, I think it's important that Apple include a fully-runnable example, on principle, even if we figure it out ourselves.

Oh, that is too bad. (It got my hopes up.) Thanks for confirming. I also noticed some RealityRenderer CameraOutput-related functionality. Is that also unavailable, or is that not referring to hardware cameras?

Great! @Graphics and Games Engineer Can we expect to see some advanced examples using this in the near-term? I think it’ll be very useful, but without an example, it’s unclear exactly how the code should look.

@Graphics and Games Engineer Yes, it’d be good to have more advanced examples since this is all pretty new. I’d be happy to file a report between today and tomorrow, sure! Also related: I’m trying to figure out how to use existing textures created from Metal with RealityKit. i.e. It would be great to be able to give RealityKit depthstencil textures so I could compose existing Metal textures into the scene. I posted here with my use case: https://developer.apple.com/forums/thread/732634

@Claude31 I am not sure what you mean. Apple has said clearly that they're not exposing eye tracking information. (It's a bit of a let-down exactly since it makes @aberens 's use case impossible.) @aberens I recommend filing a feature request in the feedback system with a clearly-worded description of your use case and the benefits overall. If Apple ever plans to try opening-up access to the eye-tracking data, they're going to want to see strong feedback and do work to ensure user consent.

@Graphics and Games Engineer I’m seeing (pun intended) a lot of medical and research labs needing accurate eye tracking data to benefit the researchers, medical practioners, and patients. e.g. AR-supported surgery and patient analytics. That said, always-on unlimited eye-tracking is scary. One thought might be to add a PLIST for eye tracking AND an additional rigorous review for app store submissions. The key is for the user in control. I hope Apple is thinking about these things.

I would argue that it‘s what you do with the data that counts. On the one hand, one can create an advertiser-controlled nightmare. On the other, tons of research labs and medical practioners are adopting XR technologies and eye tracking to help people. The core problem is to make sure the data are in the person’s control and can’t be so easily abused for surveillance, supposing the system is compromised. Maybe limited network access and sandboxing?