USSD calls with * and # dont work iOS

Question

Created Apr ’24

Replies 6

Boosts 0

Views 1.6k

Participants 5

I have an application that needs to make a USSD call, but on some devices the * and # don't work on the dialer, on others it does.

if let phoneNumber = ussdNumberTextfield.text {
    let encoded = "telprompt:\(phoneNumber)".addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)!
            if let url = URL(string: encoded) {
                if  application.canOpenURL(url){
                    DispatchQueue.main.async {
                        self.application.open(url, options: [:]) { success in
                            
                        }
                    }
                }
            }
        }

Answer 1

jlilest OP

Apr ’24

Have you tried percent encoding the # and *? %23 and %2A

Answer 2

Regadas OP

Apr ’24

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

Answer 3

DTS Engineer OP

Apple

Apr ’24

USSD codes are an ongoing source of weird compatibility problems. I’d like to clarify what you mean by “some devices”. Have you hit a case where two iPhones running identical versions of iOS are showing different behaviour? That is, one works and one fails?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 4

jaysack OP

Jan ’26

I’d like to follow up on that issue, it’s been 2 years now and it’s still not resolved.

this is really frustrating for our users as USSD is the main way of doing things in certain markets.

Any ETA on when we can expect a fix for it?

Answer 5

DTS Engineer OP

Apple

Jan ’26

Hello jaysack,

Sorry for not following up on the additional info provided. The inconsistent behavior across two identical iPhones that @Regadas reported does sound like a bug.

If you're seeing this issue as well, please file a bug report so our engineering team can investigate it in full. Do include device model, iOS version, and if possible, a focused test sample app that reproduces the issue. Once you open the bug report, please post the FB number here for our reference.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

Filing a bug report will allow Feedback Assistant to notify you if and when the bug gets fixed. That is the case even if it is a duplicate of an existing known issue. If anyone else in this thread is experiencing this USSD dialer issue, please don't hesitate to file a report as well.

Once again, we apologize for not replying sooner to this thread. For future reference, it's generally advisable to post replies rather than comments (which are usually reserved for short messages), see #5 of Quinn’s Top Ten DevForums Tips.

Thank you for your patience,

Richard Yeh  Developer Technical Support

Answer 6

Regadas OP

13h

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:

completionURLDialer presented?

`tel://` (empty)	✅ Yes — opens Phone app	`true`
`tel:123456789`	✅ Yes — dialer pre-filled	`true`
`tel:*123`	❌ No	`true`
`tel:*144#`	❌ No	`true`
`tel:10518199958229619736647344044238212#`	❌ 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)