“Visual Studio Maui IOS”

It seems that the issue has been resolved with iOS 26.4 and Xcode 26.4. It least my didRegisterForRemoteNotificationsWithDeviceToken gets called.

Hi, Thank you for the suggestions. I have tested the communication using the EADemo sample app as suggested, but unfortunately, I had no luck. The app is unable to establish a stable session with the accessory, which mirrors the issues we are seeing with our own application. To move this forward, I have filed an official bug report via Feedback Assistant and attached a full sysdiagnose captured during a failed communication attempt: Feedback ID: FB22116486 Current Project Status: Certification: The accessory is currently in an early development state, so we have not opted for MFi certification yet. We are using development identifiers/chips for testing the iAP2 protocol. Prior Success: We have not yet been able to successfully maintain a functional data session between the ExternalAccessory framework and this specific hardware revision. Technical Observations from Firmware Logs: Based on our local logs, the hardware side appears to be performing correctly: Link Synchronization: The iAP2 link completes the han

I don't know if it's related, but my sample iOS app (iOS 18.5) doesn't receive a remote notification today in line with CKQuerySubscription, which it received yesterday.

I also did notice the same issue, I have a device that still running iOS 26.3 and another one with 26.4, when I make a change the 26.3 get the background notification and update the data but on the device with 26.4 it is not working. I tested also watchOS 26.4 it is working perfectly the notification is processed.

I have the same issue and filed a bug report already: FB22324179 Since updating to iOS 26.4, iCloud remote notifications (CloudKit push notifications) are no longer delivered. The same setup worked reliably on iOS 26.3 without any changes to the app or server configuration, so this a new regression from Apple. didReceiveRemoteNotification: in AppDelegate gets not called anymore.

Update with new findings: We discovered that our /g/{gameId} App Clip experience works perfectly on fresh devices via QR code scan — every time, first try. But /next-game never works on first scan for fresh devices. Both experiences show Received status in ASC. The /g experience was created earlier than /next-game. Our workaround: we deactivated the /next-game ASC experience. Now QR scans fall through to Safari, where — as you explained — the Smart App Banner reads the meta tag and cross-references the AASA locally, loading the App Clip successfully. Interesting behavior: once a device loads the App Clip binary through the Safari/meta tag path, subsequent QR scans for /next-game invoke the App Clip directly. iOS appears to cache the binary, and the direct invocation works from that point forward. So the binary, AASA, and meta tags are all correct. Something specific to the /next-game experience is preventing first-time invocation via QR scan on fresh devices, while the older /g experience works fine

Update: Even though App Store Connect is saying my domains are valid after correcting the team id, and the cdn cache has what appears to be proper values. App clips are still not working for me - meaning, every time I scan the QR code with the camera when the app isn't installed, it doesn't go to the app clip. If I get App Store to create an app code for me, it says no content to show (though this may be because the App Store is saying received for advanced app clip experiences I wrote). So I checked the CDN here: https://app-site-association.cdn-apple.com/a/v1/akin-server-side-staging.onrender.com, I can see my aasa is proper to my understanding in the CDN cache. I updated the entitlements as recommended: appclips:akin-server-side-staging.onrender.com I also reviewed several Apple Documentation pages including the Fruta, downloaded, Fruta and examined the configuration part by part. Specifically, the entitlements for both the app clips and parent target. On my iOS device, I went to Settings > Dev

I've been optimizing a similar STT-to-action pipeline on macOS 26 and found a few additional tricks beyond prepareToAnalyze that helped bring the finalization latency down: Use volatileResults aggressively for UI feedback, but trigger your downstream action (FoundationModel call) on the volatile transcript as soon as it stabilizes — don't wait for the finalized event. In my testing, the volatile transcript matches the final one ~95% of the time for short utterances. You can always correct if the final differs. Audio format matters more than you'd expect. If your input is coming through at 48kHz (common from ScreenCaptureKit or external mics), the internal resample to 16kHz adds measurable overhead. Setting up your AVAudioEngine tap at 16kHz mono from the start shaves ~200ms off the pipeline. The large variance Bersaelor observed with prepareToAnalyze (0.05s to 3s) likely correlates with whether the ANE was already warm. If other CoreML workloads are running concurrently (even system ones like Visual

I've been working with the new Swift Vision API's RecognizeTextRequest on iOS 18 and hit this exact deadlock. After profiling with Instruments, I found that the Vision framework internally uses a limited thread pool for its neural engine requests — on most devices this caps at 2 concurrent ANE inference sessions. The workaround I'm using is a semaphore-based concurrency limiter that queues requests: actor OCRPipeline { private let maxConcurrent = 2 private var running = 0 private var pending: [CheckedContinuation] = [] func recognizeText(in image: CGImage) async throws -> [String] { await acquireSlot() defer { Task { await releaseSlot() } } let request = RecognizeTextRequest() let handler = ImageRequestHandler(image) let observations = try await handler.perform(request) return observations.compactMap { $0.topCandidates(1).first?.string } } } This keeps throughput high while never exceeding the 2-concurrent-request limit. In my testing across iPhone 15 Pro and iPad Air M2, this processes ~40 images

This issue happens in the latest iOS 17, 18, and 26 simulators. I have not tested older simulators like iOS 15 or 16. I am using Xcode 26.4 (17E192), Simulator 16.0 (1063.2) (SimulatorKit 955.7, CoreSimulator 1051.49) and macOS Tahoe 26.4.