The problem persists, and more and more users are complaining. Calling UIApplication.shared.open(_:options:completion:) with a tel: URL containing a USSD code returns success == true in the completion handler, but the system never presents the dialer. No error is surfaced to the app, the app does not transition to the background, and nothing happens from the user's perspective. This has been observed across multiple iOS versions, and affects only a subset of devices — most users are unaffected, and we have not been able to isolate what distinguishes an affected device from an unaffected one. The same USSD code dials successfully when entered manually in the Phone app on the same device, with the same SIM and carrier. Steps to Reproduce On an affected physical iPhone, install an app that calls: let url = URL(string: "tel:*105*181*99*12345662312#")! UIApplication.shared.open(url, options: [:]) { success in print("success: \(success)") } Trigger the call. Observe the completion handler. Expected Result Either: The system presents the dialer / call confirmation UI, or The completion handler returns success == false so the app can inform the user. Actual Result The completion handler returns success == true. No dialer or call confirmation UI is presented. The app remains in the foreground (no applicationDidEnterBackground is fired). No error, log, or user-visible feedback of any kind. Test Matrix Tested on the same affected physical device, same session: URL Dialer presented? completion tel:// (empty) ✅ Yes — opens Phone app true tel:123456789 ✅ Yes — dialer pre-filled true tel:*123 ❌ No true tel:*144# ❌ No true tel:*105*181*99*958229619736647344044238212# ❌ No true Same code entered manually in Phone app ✅ Dials and executes correctly n/a Percent-encoding the special characters does not change the behaviour: tel:%2A144%23 — ❌ No dialer, success == true tel:%2a144%23 — ❌ No dialer, success == true The URL.absoluteString shows the encoding is normalised back to the literal characters before reaching the system. Device Configuration Ruled Out The following were verified on the affected device and are not the cause: Screen Time / Content & Privacy Restrictions — Phone is in Allowed Apps; restrictions are not blocking the app. Default Calling App — Settings → Phone → Default Calling App is explicitly set to "Mobile Network" (WhatsApp is also installed and listed as an alternative provider, but is not selected). Voice line availability — the device has an active voice line; manual calls and manual USSD codes work normally. MDM / configuration profiles — none installed. Carrier / network rejection — ruled out, because the dialer never opens at all; the request never reaches the network. Code length — short codes such as *144# fail identically to the 40-character production code. Impact This affects a production application where USSD is part of the user registration flow. Users on affected devices cannot complete registration through the automatic path and must be given a manual fallback (copy the code to the clipboard and dial it by hand), which is a significant regression in user experience. The number of affected users has been increasing over time, but the failure is not tied to a single iOS release — it has been reproduced on multiple versions. Most users are unaffected, and the automatic path works normally for them on the same app build and the same USSD code. Notes / Open Questions The inconsistency between success == true and no UI being presented is the core problem: the app has no way to detect the failure and fall back gracefully. Even if the restriction is intentional, the completion handler should report false. If USSD codes via the tel: URL scheme are intentionally restricted for security reasons (as was introduced after the 2012 USSD exploit), this is not documented in the UIApplication.open(_:options:completion:) documentation. The behaviour is not consistent across devices: the same app build, the same USSD code, and the same carrier work correctly on most devices and fail silently on others. We have been unable to identify the distinguishing factor after eliminating the configuration causes listed above. We were unable to capture system logs (Console.app / sysdiagnose) because the affected devices belong to end users we do not have physical access to. Environment Affected iOS versions: multiple (including 26.6) — not limited to a single release Physical iPhone (not Simulator); unaffected devices run the same iOS versions Carrier: Mozambique (Vodacom / Movitel / Tmcel)

Yes, but it still doesn't work. When I put %, # or * the method (application.canOpenURL) is successful, but it does not open the dialer. only works with numbers