I'll go back to updating to the new group approach, but I want to finish fixing the race condition (?) the update seems to have caused to SwiftUI tables displaying rapidly updating data from a Deque collection.

It looks like the switch to the new groups was made when changing the minimum target OS from macOS 13.1 to macOS 14.6 and accepting recommended build settings changes. Recommended changes included "Remove Embed Swift Standard Libraries Settings" and "Target 'app' - Enable Register App Groups". I rolled back to the old code, rolled forward and unchecked the "Enable Register App Groups" for now. It made the scary red text for groups go away. 🙂 Now, fixing the race condition this caused.

Huh? I forced my code back to the 1.0 release, added my latest developer provisioning profile, and the red app groups went away and the strange grayed out group went away. Maybe I had corrupted something along the way? (Meanwhile, the 1.0 code base, which runs fine when I download from the App Store on Tahoe is freezing when recompiled with Xcode 26 and Tahoe RC; this is going to be my priority for a while. 🙁)

I am using macOS style that starts with Team ID, but I noticed there is a grayed out group that begins with the name "group" that I do not remember adding. Did Xcode add this? (I'll screenshot as an image in a comment below) The current OS and Xcode versions are "macOS Tahoe Version 26.0 (25A353)" and "Xcode Version 26.0 (17A321)". However, I also saw the red text for the App Group names last week before switching to Tahoe beta and running the previous version of Xcode.

Thanks! I was clicking on the button on the right for "Spatial Browsing" and not the button on the left and choosing "Open Web Environment"

Ah, the portal works a little differently when it is attached to a window (e.g., in the shared space) as opposed to the portal being a free-standing ModelEntity in an immersive space. When attached to a window, moving the window with portal also moves the world behind the portal. But, when the portal is a stand-alone entity in an immersive space, moving the portal does not move the world behind the portal. That might make it a fun way for someone to explore the hidden, parallel world.

Thanks! I activated a clipping plane to the portal ModelEntity's PortalComponent, and that helped clarify where the world's origin is with respect to the portal window (I added screenshots in a post below). I still have lots of stuff to learn, but this got me jump started.