“Visual Studio Maui IOS”

I filed a bug report with an sample project and 2 files for testing. I confirm the problem. FB22253128 Here the message in FB (with the zipped sample project and 2 test files): Context: Xcode 26.3, iOS 18.7.6 on iPhone Xs In this iOS app, I call UIActivityViewController to let user Airdrop files from the app. When trying to send a URL whose file name contains some characters like accentuated (-, é, '), the transfer fails. Removing those characters makes it work without problem. Steps to reproduce Build and load the app on iPhone transfer the 2 pdf files ('name accentué.pdf' and 'name plain.pdf' to the Documents folder of Test app (I did it in Finder on Mac with iPhone USB connected to the Mac). The 2 files are identical except their name. Run the app Tap 'Send by AirDrop name plain.pdf' and select AirDrop to Mac : Transfer OK Tap 'Send by AirDrop name accentué.pdf' and select AirDrop to Mac : Transfer fails

Unfortunately as the issue is still being investigated, we do not have the answers you seek. We suspect the issue may have started with iOS 26. The root cause is not determined yet, but we believe there is a specific trigger for this issue to surface - that is, it does not effect all apps that get deleted and re-installed every time, all the time. All that will be part of the investigating and fixing process.

Dynamic Type is a system-level feature for iOS, iPadOS, tvOS, visionOS, and watchOS. However, all platforms support dynamic optical sizes when using system fonts. With dynamic optical sizes, you don’t need to use discrete optical sizes unless you’re working with a design tool that doesn’t support all the features of the variable font format. These sizes, like .title, caption, etc.. are discussed in Adopt the new look of macOS When using system fonts through APIs like preferredFont(forTextStyle:options:), the dynamic optical sizing behavior is automatic. Learn more about this here: The details of UI typography. For more information on typography best practices see Typgraphy design page. I hope this helps!  Travis

Yeah, the obvious way doesn't work so well if you're using auto-renewing subscriptions - forcing the user to run the outer app every three days when the grace period expires to see if the user is still subscribed is a non-starter - this needs to be transparent and just work™ once the user has bought the subscription - my target customers are mastering engineers and similar - I wouldn't put up with that from a plugin for long, so I cannot expect my customer to. I have one local beta tester I'm going to try a TestFlight version with subscription support enabled and lots of logging and see if the extension is able to see products defined for the outer app. The fact that all of this is essentially untestable by the developer (getting a StoreKit config through to the extension process seems to be a no-go, not to mention my experience with local StoreKit configs working on a much simpler iOS app spotty enough not to trust) is fairly maddening. The combinatorics in the state machine you need for definitely-

Don't use the comment feature here in the forums. It's hides your response. Unfortunately, a 256 GB with Xcode is going to be a significant challenge. I've had problems with my 1 TB drive. One of the more problematic issues with Xcode are all the iOS simulator runtimes. Perhaps you could try to delete all of those except one. Or perhaps you could look into a cloud server. Sometimes those have small drives too. If you only need it for a couple of days, AWS might be more cost effective than a monthly fee.

Albert asked me to chime in here: [quote='818807021, ImaRobot, /thread/818807, /profile/ImaRobot'] I understand that apps submitted to the App Store must use Secure Transport as the TLS backend on iOS. [/quote] That’s not right on a couple of levels: AFAIK App Review has no requirement that you use a specific TLS implementation [1]. Secure Transport is deprecated, so it’s not the recommend path for anything (-: We generally recommend that you use the built-in networking stack. You can access that using Network framework. See TN3151 Choosing the right networking API for more background and links. Note Network framework does support TLS-PSK. This recommendation is particularly relevant for TLS, where users expect the TLS behaviour of your app to match the TLS behaviour of the system as a whole, for example, in Safari. However, that’s only applies to TLS-PKI. TLS-PSK requires prior agreement between the client and the server, by definition, and so compatibility isn’t a concern. Thus, while you can use N

I have the exact same issue for both my iOS apps. Can't add them to external testers in testflight either.

I’m confused. To start, I’m concerned about this path: [quote='818938021, chapo213, /thread/818938, /profile/chapo213'] I decided to rely only on the Team Identifier. [/quote] I don’t understand how you can trust anything about the code signature, and that includes the Team ID, if you don’t first validate the code signature. Next, in cases like this I usually ask about the big picture. And on that subject you wrote: [quote='818938021, chapo213, /thread/818938, /profile/chapo213'] In my application I validate the authenticity of my own binaries [/quote] Programs can’t authenticate themselves. If an attacker is able to modify your code, they can also remove or subvert any checks that you add. What problem are you trying to solve here? ps On iOS I usually point folks at App Attest, but I’m presuming that you’re on the Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Just to confirm, you’re talking about iOS, right? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Sorry I missed, your message. Unfortunately we still get this issue with iOS 26.3 and 26.3.1. We already share the same LA context between SecItem actions.

[quote='818948021, Ere0n, /thread/818948, /profile/Ere0n'] this private key is clearly stored in the local P12 file [/quote] That’s not the caes, at least on macOS. SecPKCS12Import behaves differently on iOS and macOS: On iOS it imports the PKCS#12 file and gives you back an in-memory digital identity. On macOS, it defaults to importing the PKCS#12 file to the default keychain, and gives you back a digital identity that references that keychain. If you want the iOS behaviour on macOS, you have to opt it to that by setting kSecImportToMemoryOnly. Having said that, I’m not sure that continuing to re-import the file is the right option. In general, it’s better to store secrets in the keychain rather than in a .p12 file on disk. But that raises the question of which keychain. I generally recommend the data protection keychain, in which case the path forward is: Get an in-memory digital identity. Call SecItemAdd with the kSecUseDataProtectionKeychain to add it to the data protection keyc