“DTiPhoneSimulatorErrorDomain Code 2”

In response to your comment above ~ Glad it was helpful! Both apps build on the same public AVFoundation framework — capture session, devices, photo/video outputs. That's the starting point for any iOS camera, system Camera included. The differences are mostly what's layered on top: Proprietary processing. Smart HDR, Deep Fusion, and the Photonic Engine are Apple-named features in the system Camera's capture pipeline. Some of the technologies behind these features are exposed as public APIs (applied automatically when you use the standard AVFoundation paths); other internal details aren't exposed. Advanced features that are public APIs. Cinematic mode, ProRes recording, spatial video, ProRAW, Live Photos — all available to your own camera app via AVFoundation. Each has additional Apple sample code if you want to dig deeper. System integrations. The Lock Screen camera button, Control Center shortcut, and writing to standard DCIM/IMG_XXXX paths historically belonged only to the system Camera. With Lock

Hi soykanozcelik, A few things on your follow-up. On a clean install: updating Rider to the version that fixes the iOS-device-listing issue is reasonable — that's a JetBrains-side question and using their latest stable is the standard advice there. The dyld code-signing crash on the simulator is a separate issue: that crash originates in how the bundle is signed, which the .NET iOS workload is responsible for — not Rider or Xcode. A clean reinstall of Xcode and the simulator runtimes is unlikely to fix the crash by itself. Updating the .NET iOS workload is more likely to address the signing failure (use dotnet workload list to check the current version, then dotnet workload update). On the WebView debugging: yes, the JavaScript is failing inside your app's WebView, and that's where the diagnostic information needs to come from. The NOTE-1 test you described — opening the page in Safari on the iPhone via the Develop menu — loads the page in Safari's own process, separately from your MAUI app's WebView

Thank you.. Update with revised connection topology: Connection setup: Monitor 1: Mac built-in HDMI 2.1 port → LG-supplied Ultra High Speed HDMI cable (48 Gbps certified) → LG 27GM950B HDMI input set to HDMI 2.1 PC mode Monitor 2: Mac TB5 port → Silkland DP80 USB-C cable → LG 27GM950B USB-C input (DP Alt Mode, monitor's USB-C input is limited to DP 1.4 per OSD) Initial state (both monitors connected, no third-party software intervention): Monitor 1 (HDMI): 5120x2880 @ 120Hz HiDPI, YCbCr 4:4:4 Limited Range, 27,400 Mbps allocation. Monitor 2 (USB-C): 3840x2160 @ 120Hz HiDPI, RGB Full Range, 13,700 Mbps allocation. The kernel selected 4K HiDPI as the default mode on the smaller-allocation pipe — 5K HiDPI was not offered by macOS natively. After forcing HiDPI 5K on Monitor 2 via BetterDisplay 4.3.3: Monitor 2 transitioned to: 5120x2880 @ 60Hz HiDPI (VRR 48-60Hz), HDR10 RGB Full Range, 13,700 Mbps allocation. So the dual 5K HiDPI configuration is only achievable when a third-pa

Confirmed the configuration behavior with the first monitor manually set to 5120x2880 @ 120Hz before connecting the second monitor. How did you make this change? The problem here is that what matters ISN'T the monitors specific setting at a given moment, it's what the mac sees as it's valid configuration range. This can't really be done via software on that mac, or do I think most displays behave in a way that would make this work[1]. That's why I suggested a physical adaptor- it prevents the mac from knowing that the monitor is capable of a higher resolution Is the WindowServer assertion failure (r.170248892) expected to be addressed in a future macOS update, Per long standing policy, DTS generally doesn't talk about if/when any given bug will be fixed. However, as a general comment, WindowServer bugs, particularly crashes, are taken very seriously since their functional impact is broadly similar to a kernel panic (basically, the whole system goes away). In practice, that means two things: Fixing th

Confirmed the configuration behavior with the first monitor manually set to 5120x2880 @ 120Hz before connecting the second monitor. Test results (both monitors connected, BetterDisplay 4.3.3 reports): First monitor (dispext0@B0000000): Current Mode: 5120x2880 @ 120Hz Maximum Source Bandwidth: 27,400 Mbps Maximum Source Width: 7680 Allocation maintained after second monitor hotplug Second monitor (dispext1@90000000): Current Mode: 3840x2160 @ 120Hz Preferred Mode at connection level: 3840x2160 @ 120Hz, 13,700 Mbps Maximum Source Bandwidth: 13,700 Mbps Maximum Source Width: 6720 Cannot negotiate 5120x2880 at any refresh rate on the smaller pipe Observations: The 120Hz cap on the first monitor prevents the runtime reallocation that previously occurred on second-monitor hotplug. However, the second monitor's connection-level preferred mode caps at 3840x2160 / 13,700 Mbps regardless of the first monitor's bandwidth consumption — the smaller pipe does not appear to receive additional bandwidth when the larger pipe

Xcode 26.5 is running insanely slow and throwing up errors on code that has no errors. The code will finally compile but it takes forever. It's almost unusable.

[quote='888338022, Madhuri_Ramapure, /thread/826318?answerId=888338022#888338022, /profile/Madhuri_Ramapure'] How do the custom notification buttons … continue to work even after the applications have been manually force-quit or killed? [/quote] I’ve no idea, sorry. I’m not familiar with those products, so I don’t know what those buttons actually do. And even if I did, there’s no guarantee I’d be able to work out how they do it. However, I can offer some general titbits: Removing an app from the multitasking UI is a strong indication from the user that the app should not run in the background again until they manually relaunch it. Some subsystem, like URLSession, honour that request scrupulously; others less so. So the exact behaviour varies by subsystem. And even within a subsystem it changes over time. Testing Background Session Code explains one change in URLSession, but other subsystems have their own unique history. And some stuff that happens in the background doesn’t involve background executi