“Visual Studio Maui IOS”

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

Update — Workaround found After further investigation I have found a workaround that resolves the inconsistent track switching behaviour described above. Observation I noticed that changing the order of EXT-X-MEDIA audio entries in the manifest produced different results. Specifically, when the DEFAULT=YES track is listed first, switching behaviour is unreliable. When the DEFAULT=YES track is placed last, switching back to the default language works correctly. Workaround Reorder the EXT-X-MEDIA audio entries so that the DEFAULT=YES rendition appears last in the manifest: #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=de,NAME=Deutsch,AUTOSELECT=YES,DEFAULT=NO,CHANNELS=2,URI=audio_DEU.m3u8 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=fr,NAME=Francais,AUTOSELECT=YES,DEFAULT=NO,CHANNELS=2,URI=audio_FRA.m3u8 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID=program_audio,LANGUAGE=en,NAME=English,AUTOSELECT=YES,DEFAULT=YES,CHANNELS=2,URI=audio_ENG.m3u8 In our case the manifest is generated programmatically, so t

Thank you for the detailed instructions, I still cannot get it to work though. My Mac is running macOS 15.7.4 and my iPhone is on iOS 26.3.1, but step 9 invariably fails. I even tried messing with the system firewall settings, allowing all incoming connections to mitmproxy and disabling the firewall altogether, but still no luck.

@Tmmn Add this code to your collectionView or another scrollView-based class: if #available(iOS 26.0, *) { collectionView.topEdgeEffect.style = .hard } If you want even more old-school style: if #available(iOS 26.0, *) { collectionView.topEdgeEffect.isHidden = true } Configure appearance for navigationItem: let appearance = UINavigationBarAppearance() appearance.configureWithDefaultBackground() appearance.backgroundEffect = UIBlurEffect(style: .systemChromeMaterial) navigationItem.standardAppearance = appearance Also it can be configured globally: UINavigationBar.appearance().standardAppearance = appearance

Thanks a lot for confirming that this is currently investigated! Can you say when this will be addressed? I have reported this horrible regression in iOS 26 beta 1 in June 2025. It’s kinda sad that this didn’t seem to have any priority for Apple to get addressed before the public version was released. In 3 months this bug report will be one year old. [quote='874099022, DTS Engineer, /thread/809410?answerId=874099022#874099022'] This is a known issue that is currently being investigated. If you have already filed a bug report for this issue, thank you. [/quote]

Hello, @Engineer Thank you very much for investigating this so quickly. I understand that the root cause has been identified and that a fix will be included in an upcoming iOS update. We appreciate your efforts and look forward to the fix. I also understand your explanation regarding the behavior of invalid tokens and the fact that the timing of receiving a Status 410 error is intentionally non-deterministic and will not change. To help us explain this issue to our app users, I would like to ask a few additional questions: Which iOS versions are affected by this issue? Under what specific conditions does this issue occur? In particular, we would like to better understand the situations in which an old token may still be treated as valid after the app has been uninstalled. Thank you for your assistance.

Hi @HAnastasovski, In iOS 18.2 and later, HCE Developers can develop and test HCE Payment Apps outside the EEA. Developers will be able to have up to 100 test devices outside the EEA. Please see the 'Testing requirements section of the following page: HCE-based contactless NFC transactions for apps in the European Economic Area (EEA) https://developer.apple.com/support/hce-transactions-in-apps/ Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hello @ShotaroAoki Thank you for this information. We were able to confirm that notifications sent to the old token are indeed being delivered to the device still. This is not the expected behavior. Once an app is uninstalled, the token it used to have should no longer result in a delivered notification. We have now found the root cause of this, and it will be fixed in an upcoming iOS update. While in the meantime this could cause some inconvenience, in the long run you can expect that once an app is deleted from a device, the token will no longer work. The rules for receiving an error (Status 410) about a no longer valid token at a random time afterwards still holds - that is by design and not going to change.