Hello! I have found a weird behavior change when running xcodebuild -create-xcframework in Xcode 15 compared to running it in Xcode 14.3.1. If I run the command like this in Xcode 15: xcodebuild -create-xcframework -framework "pathToFrameworkInATemporaryDirectory" -debug-symbols "pathToDebugSymbols" -output "Something.xcframework" I get this error: error: cannot compute path of binary 'Path(str: "temporaryPathToTheUnixExecutableFile")' relative to that of 'temporaryPathToTheFramework' But if I trace that path to the unix executable file in the framework, it is present. If I run that same command in Xcode 14.3.1, it works fine. I can create the xcframework successfully in Xcode 15 if I don't copy the framework to a temporary directory before calling xcodebuild -create-xcframework and I use that original path. Why is this problem happening now in Xcode 15? Any help is appreciated, thank you.

Hello, we recently added a build plugin to our swift package and we have a Xcode project that uses the swift package as a dependency and we build that Xcode project from the command line using xcodebuild build-for-testing. After we added that build plugin to the swift package, xcodebuild now fails and says this: If I remove that build plugin from the swift package then xcodebuild build-for-testing will build successfullly. It is also worth noting then when we run the xcodebuild build-for-testing command we pass in multiple -destination flags. If we pass one -destination flag then xcodebuild succeeds even with the build plugin. So it seems like the issue is around having multiple destination flags and a build plugin added. This sounds like a bug within xcodebuild. Any thoughts or ideas on why this isn't working would be helpful! Here is an example of what our full xcodebuild command looks like: xcodebuild build-for-testing -project “SomeProject” -scheme “SomeScheme” -configuration Debug -destination ‘SomeDestination1’ -destination ‘SomeDestination2’ -destination ‘SomeDestination3’ -disableAutomaticPackageResolution -onlyUsePackageVersionsFromResolvedFile -skipPackageUpdates -skipPackagePluginValidation -allowProvisioningUpdates DEVELOPMENT_TEAM=SomeTeam Thank you!

Hello, I have a swift package that supports visionOS and one of its targets is a xcframework that also support visionOS and when I try to archive that swift package (using xcodebuild archive) I get this error: note: '<xcframework path>' is missing architecture(s) required by this target (x86_64), but may still be link-compatible. (in target '[library name]' from project '<swift package name>') But starting in Xcode 15.2 (I have Xcode 15.4 installed), you cannot develop for visionOS on Intel machines. So why does it require that the xcframework needs x86_64 support for the visionOS simulator? Any help would be great. Thanks!

We followed this documentation https://developer.apple.com/documentation/compositorservices/drawing_fully_immersive_content_using_metal to display a fully immersive map using our metal rendering engine, which worked great. But this part of the article: https://developer.apple.com/documentation/compositorservices/drawing_fully_immersive_content_using_metal#4193614 mentions how to use the onSpatialEvent callback to receive gesture events. We are receiving the gesture events but the location property of the event (https://developer.apple.com/documentation/swiftui/spatialeventcollection/event/location) is always coming back as (x: 0, y:0) which is not helpful. We are unable to get a single valid location of any gesture, therefore, we are unable to hook up these gestures. We tried this on a simulator and a Vision Pro device.

I can get the fully immersive rendering working with metal and composite services but in WWDC 24 rendering metal with passthrough was announced: https://developer.apple.com/wwdc24/10092. I watched the video and downloaded the test project. I noticed that the passthrough was showing up in the demo project but not in my metal project. After debugging I found out it was this key: Preferred Default Scene Session Role in my Info.plist that was set to Compositor Services Immersive Space Application Session Role (like the video said) but it needed to be set to Window Application Session Role for the passthrough to come in. Is this a bug?

Hello! I noticed that after WWDC 24 there was support added for MTKView in visionOS 1.0+. This is great! But when I use an MTKView in anything before visionOS 2.0 it doesn't work and the app ends up crashing. Console error when running on a device that is on visionOS 1.2: Symbol not found: _$s27_CompositorServices_SwiftUI0A5LayerV13configuration8rendererAcA0aE13Configuration_p_ySo019CP_OBJECT_cp_layer_G0CScMYcctcfC Expected in: <EFD973D2-97E1-380B-B89A-13CC3820B7F7> /System/Library/Frameworks/_CompositorServices_SwiftUI.framework/_CompositorServices_SwiftUI Looks like MTKView may be using compositor services under the hood? Any help would be great. Thank you!

Hello! I have an iOS app where I am looking into support for visionOS. I have a whole bunch of gestures set up using UIGestureRecognizer and so far most of them work great in visionOS! But I do see something odd that I am not sure can be fixed on my end. I have a UITapGestureRecognizer which is set up with numberOfTouchesRequired = 2 which I am assuming translates in visionOS to when you tap your thumb and index finger on both hands. When I tap with both hands sometimes this tap gesture gets kicked off and other times it doesn't and it says it only received one touch when it should be two. Interestingly, I see this behavior in Apple Maps where tapping once with both hands should zoom out the map, which only works sometimes. Can anyone explain this or am I missing something?

Hello, I have an iOS app that is using SwiftUI but the gesture code is written using UIGestureRecognizer. When I run this app on visionOS using the "Designed for iPad" destination and try to use any of my gestures I see this warning in the console: Trying to convert coordinates between views that are in different UIWindows, which isn't supported. Use convertPoint:fromCoordinateSpace: instead. But I don't see any visible problems with the gestures. I see this warning printed out after the gesture takes place but before any of our gesture methods get kicked off. So now I am wondering if this is something we need to deal with or some internal work that needs to happen in UIKit. Does anyone have any thoughts on this?

Hello, I have a simple SwiftUI view that shows this bottom bar in the view and I noticed that in SwiftUI previews the 2D window is squared off while in the simulator it has rounded edges. This effects the bottom bar because as you can see in the simulator the text is cut off. I am using Xcode 16 beta and visionOS 2 beta. Why do the two windows look different? And I am surprised the text is getting cut off in the rounded window. SwiftUI Preview: Vision Pro Simulator

Hello. When displaying a simple app like this: struct ContentView: View { var body: some View { EmptyView() } } And run the Leaks app from the developer tools in Xcode, I see a memory leak which I don't see when running the same application on iOS. You can simply run the app and it will show a memory leak. And this is what I see in the Leaks application. Any ideas on what is going on? Thanks!

With this sample code here: import SwiftUI struct ContentView: View { var body: some View { Text("Hello world") .hoverEffect(isEnabled: true) } } private extension View { func hoverEffect(isEnabled: Bool) -> some View { if #available(iOS 17.0, *) { // VisionOS 2.0 goes in here? return self .hoverEffect(.automatic, isEnabled: isEnabled) } else { return self } } } You would expect if the destination was visionOS it would go into the else block but it doesn't. That seems incorrect since the condition should be true if the platform is iOS 17.0+. Also, I had this similar code that was distriubted via a xcframework and when that view is used in an app that is using the xcframework while running against visionOS there would be a runtime crash (EXC_BAD_ACCESS). The crash could only be reproduced when using that view from the xcframework and not the local source code. The problem was fixed by adding visionOS 1.0 to that availability check. But this shouldn't have been a crash in the first place. Does anyone have thoughts on this or possibly an explanation? Thank you!