“Visual Studio Maui IOS”

An update:This weird visual corruption only happens when the app is being debugged from Xcode 11.It does not happen if you start the app from the Dock.So I was able to release my app when it was built with Xcode 11.I have just learned to ignore the visual corruption when debugging the app from Xcode.

[quote='758546021, SpeakCuba, /thread/758546, /profile/SpeakCuba'] One interesting thing that I noticed is that for Xcode projects, the simulator runs perfectly, but when I use Android Studio, the simulator doesn't work properly at all. [/quote] It sounds like this is due to your third-party environment and frameworks. You should check with the support resources provided by those products to get assistance with their software and how it runs when deployed to the iOS Simulator.

Same issue Mac Studio & M1 MacBook Pro with iphone 13 pro and 11 inch iPad Pro

Have you tried this? It works for me: prefs:root=General&path=SOFTWARE_UPDATE_LINK — WindowsMEMZ @ Darock Studio let myEmail = memz + 1 + @ + darock.top

It requires macOS 26 as well as Xcode 26. With that installed, I have it working with both Claude and local LLMs (via LM Studio).

I have the same problem. I primarily use an LG 32UN880 on my Mac Studio M1 MAX, and a Dell 2515H as a second monitor. About a week ago I replaced the Dell with an LG 32UN880P and promptly encountered this problem. The 32UN880 always goes to sleep, the 32UN880P does not. The problem occurs via DisplayPort to USB-C cable, but via USB-C. The 32UN880P also has a MacBook Pro 13 M1 connected to it via USB-C, in addition to the Mac Studio, and the monitor does not go into standby here either. The screen is black, but the backlight stays on. It only helps to send the Mac into standby, as it has already been described by others here. I upgraded the Mac Studio to macOS Sonoma for testing, again the problem still exists. Could someone tell which log you are viewing? Thanks!

@Frameworks Engineer Has there been any update on whether this issue will be resolved in a future update or perhaps best practices you can share on how to best build for this issue? Our team built our entire app on the iOS 14 beta with a robust menu for the visually impaired. In the beta everything worked perfectly, however since the public release version we were frankly devastated when the latest version of the OS presented this massive interaction change. Could you please share any resources on how a developer can best create custom navigation menus with this new system? For example, our app has horizontal menus, we built an entire, voiceover based, menu system so visually impaired users can navigate the items in these menus in the correct order. With a standard vertical order menu system, one that is default in this new screen recognition feature, the order of the menu items are entirely incorrect, making the experience terrible for our visually impaired users. So much

You can contact Apple for TestFlight to get help. — WindowsMEMZ @ Darock Studio let myEmail = memz + 1 + @ + darock.top

So I think I have found the reason for this difference in behavior on various hardware platforms. It has to do with a System Setting found in the Keyboard settings section named: Keyboard Navigation. if it is enabled then the program works as expected and if it is disabled then the program doesn't work as expected. In my case, for some reason, my Mac Studio desktop had this setting enabled (so it worked); my MacBook pro had the setting disabled (so it didn't work). When I enabled on MBP it worked; when I disabled on Mac Studio it stopped working.

No not really considering it was working fine with it enabled in beta 1, 2 and 3. These effects are not motion effects but visual effects. If anything they made it this way for users who may not want the new visual effects in their messages can turn them off.

Unfortunately, that didn't work for me. IntelliJ 2019.1 works like a charm, Android Studio crashes with the same .vmoption file. 😟

For whatever reason, I'm getting the expected 2.0 with my Studio Display. (There's also pixelLength, which returns the length of one pixel in points.)

Same exact issue here, on my MacBook Air. On my Mac Studio, it works a charm. Both just updated to Tahoe, and both running Xcode 26 RC.

To clarify: this happens only for apps using the Metal 4 API. I can profile pre-Metal 4 apps on the Studio just fine.

I'm the same boat. I have a new Mac Studio Ultra but my iOS app's main dependency currently only builds for x86 for simulators. I can't seem to force all the SPM packages it relies on to build x86 simulator versions :( Apple really needs an Xcode setting to tell SPM how to build. It seems CocoaPods can do this https://blog.sudeium.com/2021/06/18/build-for-x86-simulator-on-apple-silicon-macs/