“Visual Studio Maui IOS”

After additional testing, I found that the issue is specifically related to the system font: When using: UIFont* font = [UIFont systemFontOfSize:20]; or UIFont* font = [UIFont systemFontOfSize:20 weight:UIFontWeightRegular]; the text is rendered incorrectly (appearing right-aligned or partially clipped) on iOS 26.4. When switching to a named font such as: UIFont* font = [UIFont fontWithName:@Arial size:20]; the exact same drawing code produces correct results. I also tested multiple system font variants (including different weights and monospaced digit system fonts), and all system font variants exhibit the same incorrect behavior. This strongly suggests that the issue is related to system font rendering in combination with drawAtPoint:withAttributes: (and drawInRect:) on iOS 26.4. Important: switching to a different font is not a viable workaround for me. The affected drawing routine is a central part of multiple apps and is used in hundreds of places. Changing the font would significantly

[quote='881565022, amepatil, /thread/769640?answerId=881565022#881565022, /profile/amepatil'] I see these issues still happening in iOS 26. [/quote] Sadly, that doesn’t surprise me. None of the bugs mentioned above (FB16052660, FB16058654, FB16058772, FB16060769) are marked as resolved. Regarding ExtensionKit, AFAIK the situation there hasn’t changed in iOS 26, that is, things are still as I described them on this thread. However, I don’t understand how that is related to CryptoTokenKit extensions. ExtensionKit was designed so that third-party apps can expose their own extension points, allowing other third-party developers to create extensions that attach to those points (and, indeed, that’s how things are working on macOS today). System frameworks, like CryptoTokenKit, generally hide this underlying mechanism from third-party developers. That is, third-party developers can extend the system without dealing with the underlying extension infrastructure, be that ExtensionKit or the older mech

First up, have a read of TN3134 Network Extension provider deployment. This explains your deployment options for this technology. Specifically, for an app proxy on iOS the device must be managed. That’s because the MDM system is used to associate your app proxy with the apps that it proxies, by matching up the VPNUUID properties on both. During development you can use NETestAppMapping to establish this mapping. You’ll still need a configuration profile to enable your app proxy, because of the requirement to provide a VPNUUID property with the configuration. [quote='820572021, Davidbaraff2, /thread/820572, /profile/Davidbaraff2'] Is an app proxy the right tool for this? [/quote] Before you can answer that you have to first see if an app proxy will actually work. That is, in production: Are the target devices managed? Is the target app installed via MDM? If either of those is false, an app proxy won’t work and thus it’s definitely not the right tool (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer

Hi, I would appreciate any feedback - either confirming or contradicting our observation above, that Audio cannot be protected from being captured on Safari/iOS. Thanks.

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