Visual Studio Maui IOS

Hey, could you please follow up if you can still reproduce this issue on iOS 26 (final release), iOS 26.0.1, or iOS 26.1 beta 1? [quote='854406022, CaliforniaJay, /thread/793747?answerId=854406022#854406022, /profile/CaliforniaJay'] I filed feedback: FB19738834 [/quote]

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. we do not wish to create a driver visible by the entire system. Well, that certainly simplifies things. For example, it makes an EA-based solution feasible (although the EA-based solution still requires MFi hardware). Are there any APIs that give an application access to a raw USB interface … in userspace? Not on iOS. On macOS you can do this using the I/O Kit API [1]. And on iPadOS you can achieve similar functionality using DriverKit. But iOS has neither of those options. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] You can also do it using the KPI, but that just complicates things unnecessarily.

There are two questions here: How do you force a connection to run over a specific interface? How do you identify the correct interface? The answer to the first is straightforward: For Network framework, use the requiredInterface property. For BSD Sockets, using IP_BOUND_IF (IPv4) or IPV6_BOUND_IF (IPv6) socket options. The answer to the second question is trickier. It’s easy to get the interface list and filter it down to just the WWAN interfaces. Distinguishing between WWAN interfaces is hard. iOS doesn’t provide a general mechanism for that. It’s clear that you’re working with a customer who has very specific requirements, and it’s possible that you might be able to craft a solution that’s specific to those requirements. The most obvious solution is for them to change their server so that it’s only available over the sXGP-SIM network. That way there’s no possibility of the traffic ‘leaking’ regardless of what you do in your app. Even if that’s not possible for the real service, you could stand up

Hi Quinn, thanks for pointing that out. To clarify, what I actually meant to ask is: Is this feature limited to the combination of Xcode 26 + iOS 26 (since AppExtensionPoint is documented as available starting from iOS 26)? Or can an app built with Xcode 26 also run this feature on earlier iOS versions? Thanks again for your help!

It seems to be a general issue with the IOS 26 release. It affects other browser too. I tested on Safari, Chrome, Firefox, Edge and Bravo. With the exception of Edge, all the others display the behavior. Device: iPhone 15 Pro IOS Version: 26.0.1

I’m gonna start with your first question, for reasons that I hope will be obvious. You wrote: [quote='802846021, herman602, /thread/802846, /profile/herman602'] Can this method described in the article be built with Xcode 26 and run on iOS 26? [/quote] And then: [quote='802846021, herman602, /thread/802846, /profile/herman602'] Or is it restricted to run only on iOS 26 [/quote] Huh? I think one of those 26’s is meant to be a different number. That or I’ve completely misunderstood your point. Please clarify. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My general advice on this front is to avoid temporary exception entitlements where you can. This is critical for App Store apps, but generally a good idea for products that you directly distribute using Developer ID signing. In this case there’s a standard way for sandboxed programs to use XPC without needing temporary exception entitlements, namely an app group. If you set up an app group, grant your app and your appex access to that group, and then have your daemon publish its named XPC endpoint ‘within’ that group, the sandboxed processes should be able to access that service without the need for a temporary exception entitlement. See App Groups Entitlement for info on how that works. Well, the app certainly will be able to. The situation with the appex is more nuanced, because appexen run in a custom sandbox that doesn’t always align with the standard App Sandbox used by apps. Which is probably the reason why your temporary exception entitlement is failing. I think the app group approach will help here, b

You tagged your thread with Mac and mentioned that the app “bounces”, which seems like a Dock thing, but you then specifically called out that this is “new IOS provisioning profile”. So I’m a bit confused. What sort of app is this? And if it’s an iOS app, are you trying to run it on your Mac? That is, using the iOS Apps on Mac feature? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com