Visual Studio Maui IOS

Seeing the same thing, here's a small reproduction: import SwiftUI struct ContentView: View { @State private var text = @FocusState private var isTextFocused @Environment(.accessibilityReduceMotion) private var reduceMotion var body: some View { List { TextField(Input, text: $text) .focused($isTextFocused) .onSubmit { isTextFocused.toggle() } Text(Focus the text field then dismiss the keyboard) Text(Observe how the safe area doesn't change when dismissing the keyboard in iOS 26 with the below accessibility settings enabled.) Label(Reduce Motion? (reduceMotion ? true: false), systemImage: accessibility) Label( Prefer Cross-Fade Transitions? (UIAccessibility.prefersCrossFadeTransitions ? true: false), systemImage: accessibility ) } .scrollDismissesKeyboard(.immediately) .textFieldStyle(.roundedBorder) .border(.red) .safeAreaInset(edge: .bottom) { HStack { Text(This is in the safe area insets) Spacer() Button(Close Keyboard) { isTextFocused.toggle() } .buttonStyle(.borderedProminent) } .padding() .bord

Yes, it’s a known regression in iOS 26 betas — Apple seems to have changed how voice preferences are exposed to third-party apps. No reliable workaround yet, since the API ignores Accessibility settings. For now, you’ll need to manually set the voice using its identifier until Apple fixes it.

I’m currently shipping a production app using .tabViewBottomAccessory in SwiftUI (tested and stable on iOS 26.0). After testing on iOS 26.1, I’ve noticed that when the accessory view is conditionally hidden, the space it occupies remains visible — an empty gap appears right above the tab bar. This regression will negatively impact users once iOS 26.1 rolls out. FB20772048

Here is a simple way to reproduce the issue: struct KeyboardToolbarItem: View { @State var text: String = foobar var body: some View { Form { TextField(Foo, text: $text) .toolbar { ToolbarItem(placement: .keyboard) { Button { } label: { Image(systemName: chevron.down) } } } } } } #Preview { KeyboardToolbarItem() } One would expect there to be some padding at the bottom of the button. This is on Xcode 26.1 Beta 3 & iOS 26.1 beta 4

thank you for pointing me to the right feedback location. I submitted one for iOS in general but didn't feel like the right place so I used your link and just submitted another one with this ID: FB20768616

Thank you for this discussion, @AhmedSeerefine and @Marawan. Please try testing your Live Activity experience again in iOS 26.1 Beta 4.

Thank you for your post @elnjensen. Please try testing your Live Activity experience again in iOS 26.1 Beta 4.

Yeah, converting AttributedString to NSAttributedString and then to Data with NSAttributedString.DocumentType.rtf will lose SwiftUI attributes (because SwiftUI attributes aren't represented in an ObjC-based NSAttributedString), unless you convert the SwiftUI attributes to UIKit / AppKit attributes with your own code. You can convert AttributedString directly to RTF / RTFD data using AttributedTextFormatting.Transferable, which was newly introduced in iOS 26 and friends. The following code example shows how to do that: struct ContentView: View { @Environment(.self) private var environment ... private func attributedStringToRTF() async { var attributedString = AttributedString(inputText) attributedString.backgroundColor = .red print(Input: attributedString = (attributedString)) let transferable = AttributedTextFormatting.Transferable(text: attributedString, in: environment) guard let rtfData = try? await transferable.exported(as: .rtf) else { return } guard let transferrable2 = try? await AttributedTex

Hello, It is possible for Metal (on iOS) to render Gaussian splats based on the contents of a USDZ file. That said, there isn't any intentional restriction. Further, ARKit isn't a renderer and it interoperates well with Metal. AR Quick Look on the other hand may not support this technique directly so if that's what you need then we'd greatly appreciate an enhancement request.