“Visual Studio Maui IOS”

iOS 26 still doesn't work lol

Had the same problem, testing an iOS app on macOS via TestFlight which previously worked, did recently stop working. But I found a setting in App Store Connect, under each testing group, that says Test iPhone and iPad Apps on Apple Silicon Macs. Enabling this setting made testing on macOS work again.

Thanks for those crash reports. Are you able to find a JSON crash report (.ips) for this? If so, please post it, because it may allow me to learn more about the issue. In the absence of that then, yeah, at first blush this is looks like an Apple problem rather than a problem with your code. Consider the crashing thread from your first crash report: Thread 22 name: Thread 22 Crashed: 0 CoreFoundation … __CFCheckCFInfoPACSignature + 4 (CFRuntime.c:559) 1 CoreFoundation … CFRunLoopSourceSignal + 28 (CFRunLoop.c:4312) 2 Foundation … performQueueDequeue + 484 (NSThread.m:1063) 3 Foundation … __NSThreadPerformPerform + 88 (NSThread.m:1077) 4 CoreFoundation … __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1970) 5 CoreFoundation … __CFRunLoopDoSource0 + 172 (CFRunLoop.c:2014) 6 CoreFoundation … __CFRunLoopDoSources0 + 332 (CFRunLoop.c:2059) 7 CoreFoundation … __CFRunLoopRun + 840 (CFRunLoop.c:2969) 8 CoreFoundation … CFRunLoopRunSpecific + 572 (CFRunLoop.c:3434) 9 Foundation … -[NSRunLoo

Thanks for your reply!We have successfully connected an iOS device with a non-iOS device via Wi-Fi Aware, and established multiple TCP connections. However, we still have a throughput issue: when the iOS device acts as a Subscriber, and sends an HTTP request over an already-established TCP connection to download resources from the non-iOS device, we observe slow download speeds — only around 20 MB/s. We compared iOS system logs and found: When the non-iOS device connects to iOS, the timeslot bitmap used is ff ff 00 00 ff ff. When iOS connects to iOS, all timeslots are used. Could this be the reason for the large difference in transmission rates? Is this caused by configuration, or what leads to the reduced timeslot allocation? Log 1: Non-iOS device connecting to iOS default 16:33:33.204715+0800 kernel wlan0:com.apple.p2p.nan0: Availability: map 0, channel 6 (20M), timeBmap: 1111 1111 1111 1111 0000 0000 0000 000

[quote='819926021, craigc123, /thread/819926, /profile/craigc123'] is there any way to programmatically trigger “realtime” mode? [/quote] No. Well: Not as an API that’s documented to have that effect. It might be possible to find some API that does it as a side effect, but that would be an implementation detail and thus not something you’d want to rely on. And there’s the Wi-Fi Aware option, but you’ve ruled that out. I think you should create a prototype based on Wi-Fi Aware and see if it achieves the latency goals that you need. If it does, you can then factor that into your decision as to how to proceed here. And apropos that, you wrote: [quote='819926021, craigc123, /thread/819926, /profile/craigc123'] I am looking for a solution that works … on previous OS versions. [/quote] Note that Wi-Fi Aware requires iOS 26 and specific hardware. The main framework doc page has the list. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm encountering the same issue as you; currently, I've implemented a 1.5-second delay. I hope Apple can resolve this soon. Recently, I tried upgrading to StoreKit 2, but on iOS 26.4, Transaction.updates does not return unfinished transactions upon launch, which is causing some problems.

iOS has a limited set of Wi-Fi APIs. See TN3111 iOS Wi-Fi API overview for a summary of what’s available. Regarding signal strength specifically, I address that head on in iOS Network Signal Strength. In short, you’re unlikely to be able to achieve your goal here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Kevin, Thank you for the troubleshooting steps. To clarify the current state of the environment: Testing Environment: I am testing exclusively on a physical iOS device (iPhone [Model] running iOS [Version]); I am not using the simulator for these tests. Framework: The implementation is already built using UIKit. I am managing the accessory lifecycle within a standard UIViewController and AppDelegate structure. Integration Status: Despite being in a pure UIKit environment, I am still facing the issue where [mention the specific symptom, e.g., the accessory is not appearing in the picker / the session fails to open]. Since I have already ruled out SwiftUI lifecycle interference and simulator limitations, are there specific logging categories in Console.app or internal ExternalAccessory states you recommend I monitor to diagnose why the connection is failing?

Hello iOS Developer Community, I have two apps stuck in Waiting for Review and would appreciate any advice from developers who have faced a similar situation. 📱 App 1 — BookAstors (User App) Submission ID: 33bc446c-42aa-425d-9eba-2b79e88e9c9f Version: iOS 1.0.4 (Build 15) Date Submitted: March 17, 2026 Waiting since: 6+ days 📱 App 2 — Admin BookAstors (Admin Panel) Submission ID: c8af128f-0666-492a-bd88-3a2cad64d74c Version: iOS 1.0.5 (Build 8) Date Submitted: February 28, 2026 Waiting since: 23+ days Both apps are live on the App Store with an active user base. These updates contain critical bug fixes that our users and business operators are waiting on. The delay is directly impacting user experience and platform operations. I submitted an Expedited Review Request for both apps and received Apple's confirmation: We'll expedite review for BookAstors / Admin BookAstors. However, even after the expedited request was accepted, neither app has moved from Waiting for Review to In Revi

This error occurs on iOS 26.0 -> 26.0.1. By version 26.1, the problem no longer exists, perhaps Apple has fixed it. Can you confirm for me that Apple fixed it correctly? And is there any note about whether this bug has been fixed?