Using swift enums in C++ isn't an issue, and it indeed does that weird'ish naming for the cases. What bothers me is that the Swift functions that I define that take a C++ enum or enum class just don't get interop at all. If the function is a global function, I get the // Unavailable in C++: Swift global function 'swiftFunctionWithCppEnum(_:)'. comment in the generate header. What's worse is that if the function is member for a Swift class, it just gets ommitted entirely without any indication that it is not compatible. It just doesn't show up at all in the generate Swift header. Upon further reading the C++ interop documentation I came across this: If I understand it correctly, this indicates that it actually should work? But it clearly doesn't.

Upon further experimentation I've discovered that you must set fileSize to 0 to make the BAURLDownload function as expected. Setting it to -1, or slightly different filesize will yield a download failure. So setting both fileSize to 0 and essential to false is required to download assets that you don't have a proper filesize for.

Further experimentation yields the following findings. When the iOS device is set to English (US), both SFSpeechRecognizer.isAvailable and .supportsOnDeviceRecognition return true. If we then set the SFSpeechAudioBufferRecognitionRequest’s requiresOnDeviceRecognition to true, we observe the stated issue where speechrecognition tasks fail with “Siri and Dictation are disabled” errors, while according to the SFSpeechRecognizer, it should work.

I found this in iOS 17's Beta release notes: Fixed: Gestures could be misaligned if an app was backgrounded while a sheet was presented. (99202394). Hopefully this is referring to this particular issue.

Having the same problem.

Apple responded to my reported Issue in the Feedback Assistant with: 'Investigation complete - Works as currently designed.' with no further explanation given. Highly disappointed about this. I'm just hoping they won't do the same thing in future iPad Pro iterations and it gets fixed in iPhone 15.

Not entirely sure we are seeing the same problem, but the depth data from iPhone 13 and newer is highly inaccurate as well. I've create a post about it too: https://developer.apple.com/forums/thread/728992

This is still broken on iOS 16.4 and XCode 14.3

@Apple Any feedback on this? Can we expect a fix on this or do I need to implement a workaround for this in our upcoming release? Btw, this is my current workaround. You can add this to any View you show within the sheet, popover, etc... and when it gets dismissed, it will 'reset' the layout. public func body(content: Content) -> some View { content .onDisappear { let scene = UIApplication.shared.connectedScenes.first as? UIWindowScene if let viewFrame = scene?.windows.first?.rootViewController?.view.frame { scene?.windows.first?.rootViewController?.view.frame = .zero scene?.windows.first?.rootViewController?.view.frame = viewFrame } } } } public extension View { func syncLayoutOnDissappear() -> some View { modifier(SyncLayoutOnDissappear()) } }

Ok, made a copy-paste error. first line is missing: public struct SyncLayoutOnDissappear: ViewModifier {

I already created a issue in the feedback assistent at the same time as posting this on the dev forums -> FB11983439

Yup, for me the problem still persist as well in 14.1 beta 3. HumanReadableSwiftError SettingsError: noExecutablePath(<IDESwiftPackageStaticLibraryProductBuildable:ObjectIdentifier(0x0000600014106940):'AppCenterAnalytics'>) Updated FB11515571 with new error report.

Not sure @Dasoga mistyped, but I can confirm that the issue is NOT fixed entirely in 14.1 beta 1. Reported new issue: FB11515571

I can also confirm this is still a problem in Xcode 14 beta 6. My error report points to the same issue as what @Gong mentioned.

Bump Nobody have any idea why SwiftUI is misbehaving here?