“Visual Studio Maui IOS”

I've noticed the same contrast issue on iOS 26 with dark wallpapers. This appears to be a Liquid Glass regression — the frosted material doesn't adapt well to certain background luminance levels. Since the slide to answer text is entirely system-managed through CallKit, there's no app-side workaround. I'd recommend filing a Feedback (if you haven't already) under UIKit > System UI with a screenshot showing the low contrast scenario. Referencing the WCAG 2.1 AA contrast ratio requirement (4.5:1 for normal text) in your report might help prioritize it, since this is a core accessibility concern for incoming calls.

By analysis the log, seems the following 3 calls has been ended by system callkit (Not mainly trigger the end call): I'm not sure I follow the meaning of your log data. How do you know no user action was involved? Both calls are ending ~1s after the report which is with the range of human action, particularly if some kind of hardware action like pushing the side button of the phone or blocking through a headset's physical button is involved. @apple Do you have similar report that the iOS CallKit End the call withtour user action? No, not that I'm aware of. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thanks so much for this post and thanks for your patience on my replay. When Unicode characters and emojis render perfectly on a physical device but appear as blank spaces or empty boxes in the Simulator and SwiftUI Canvas, in my opinion it means the Color Emoji font is missing and this is corrupted, or failing to load inside the Simulator Runtime. Because the SwiftUI Canvas uses the exact same underlying simulator infrastructure as the standalone Simulator app, both break at the same time. We identified this a bug and I would encourage you to use the physical device or to download the latest beta simulators iOS 24.4 RC https://developer.apple.com/download/os/ and let me know it the issue has been fixed. Here are the most effective ways to resolve this issue: Open Xcode and go to Xcode > Settings (or Preferences) > Platforms. Find the iOS Simulator runtime you are currently using (e.g., iOS 26.3). Right-click (or Control-click) it and select Delete. Once deleted, click the + b

Hello @kansen We believe this was fixed in 23D120. Please verify that this is resolved in iOS 26.4 RC. Thank you,  Travis

Thanks for posting. Here are some troubleshooting steps to try ~ Verify Asset Identifier Validity Even though you're using placeholder text in your post, make sure the actual asset identifiers you're using: Come directly from previous PHPickerResult.assetIdentifier values Refer to assets that are still present in the user's library Haven't expired (asset identifiers can become invalid if the asset is deleted or modified) Implementation Check When retrieving previous selections: func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) { let identifiers = results.compactMap { $0.assetIdentifier } // Store these for future use } iOS Version Specific If this worked previously but not in newer iOS versions, there might be subtle API changes. Could you confirm which specific iOS versions you're testing with? Confirm Selection Mode Ensure your PHPickerConfiguration is set to allow multiple selections if you're trying to preselect multiple assets. If you've

Same issue with Mac Studio M2 Max and MacBook Pro M4 Gave up on MacBook and reinstalled from recovery menu. Update then worked OK. About to do the same on Studio. No response from Apple to multiple feedback reports

Thanks for the confirmation. I’ve retagged your thread with ReplayKit because that’s the only option for this sort of thing on iOS [1]. Coming back to your original questions: [quote='818940021, tylermclovin, /thread/818940, /profile/tylermclovin'] Permission Clarity [/quote] I don’t think you’ll be able to make progress on this. Broadcast extensions were designed for… well… broadcasting, and the user experience reflects that. [quote='818940021, tylermclovin, /thread/818940, /profile/tylermclovin'] Can a Broadcast Extension reliably stay active in the background … ? [/quote] Honestly, I’m not sure. I think this is something worth prototyping before you invest heavily in this project. [quote='818940021, tylermclovin, /thread/818940, /profile/tylermclovin'] App Store Guidelines [/quote] I don’t work for App Review and can’t offer any advice on that front. You could ask them here on the forums, over in the App Store Distribution & Marketing > App Review subtopic. However, I think it’d be best for

[quote='880623022, timboudreau, /thread/818192?answerId=880623022#880623022, /profile/timboudreau'] that would … probably run afoul of one or another App Store policy [/quote] I don’t work for App Review, and thus can’t give definitive answers about their policies. My only advice is that you peruse the App Review Guidelines. At a technical level, on macOS it is possible for an app extension to communicate with an app or launchd agent or daemon that you control, even in the presence of sandboxing. If you want the server side of this to be an app, the best option is for that app to listen on a Unix domain socket that’s located in an app group container. If you want it to be a launchd job, prefix the named XPC endpoint with an app group ID. Both of these are documented in App Groups Entitlement. For more on the XPC side of this, see the various links in XPC Resources. Specifically, XPC and App-to-App Communication has a bunch of backstory you’ll need. And please don’t use Mach messaging directly! [quote='8806240

[quote='880466022, jzilske, /thread/817599?answerId=880466022#880466022, /profile/jzilske'] it's not a WebView where I suspect the traffic comes from [/quote] Ah, OK, thanks for setting my straight. [quote='880467022, jzilske, /thread/817599?answerId=880467022#880467022, /profile/jzilske'] How would I go about setting that up? [/quote] Which bit? To get the source information from mitmproxy, view the request, switch to the Detail tab, and look at the Client Connection section. Getting process information from the packet trace is a small extension of the RVI process described in Recording a Packet Trace: Set up RVI per the Set Up iOS Packet Tracing section. When you get to the tcpdump command, add the -k option to cause it to dump each packet’s metadata. And tcpdump naturally logs the port numbers in each packet, so you can look for outgoing packets whose source port matches the port number you get from the proxy. Having said that, this won’t help given your clarification that the connection is not co

BTW, however I solve this, if I do, it needs to work on both Mac OS and iOS - I have no idea if there's much market for iOS Audio Units, but it was easy enough to build for both, so I will release both. It's at least likely to be a less saturated market :-)