Starting in iOS 27, opening a tel: URL that contains a call-forwarding MMI code from an app shows a system alert and dials nothing:
Malicious Link Blocked: This link was blocked because it contains malware that will forward all of your incoming messages and calls to 1 (XXX) XXX-XXXX. Scammers often provide malicious links that look legitimate via email, text, or chat.
On iOS 26 the same call showed the normal call confirmation prompt and the carrier applied the forwarding.
Repro (in response to a button tap):
UIApplication.shared.open(URL(string: "tel:*21*XXXXXXXXXXX%23")!)
Typing *21*XXXXXXXXXXX# into the Phone app's keypad by hand still works on iOS 27, so the capability is still there; only the in-app handoff is blocked.
This breaks setup for call-screening and visual-voicemail apps whose onboarding depends on carrier forwarding (*21*, *61*, *67*, *71*, *72). It also blocks the disable codes (##21#, ##004#, *73), so users can't turn forwarding off from inside the app, which works against the user's own safety.
The anti-hijack intent makes sense for links arriving from Messages, Mail or Safari. For a user tap inside an installed App Store app, a confirmation sheet ("Forward calls to ...? Allow") seems like the right balance, and disable codes should always be allowed.
Filed as FB24843805. Questions:
- Is this block meant to apply to links opened by an installed app in response to a user tap?
- Is there a supported API, entitlement or URL form to hand a forwarding code to the Phone app with user confirmation?
Our current workaround is to copy the code to the clipboard and ask the user to paste it into the keypad, which is a real drop-off point for our (mostly older) users. If you're affected too, please file your own feedback and reference FB24843805.