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.

We build a call-screening app for VoIP-forwarded calls. Inbound calls are forwarded to our service, screened, and surfaced to the user via CallKit (reportNewIncomingCall) with includesCallsInRecents = true and a CXHandle(type: .phoneNumber, …) carrying the real caller number. Because the call is forwarded at the network before it reaches the handset, the user's native carrier call log never records it — CallKit is the only way the call appears in Recents. The gap: When the user taps "call back" on one of these entries (in the native Phone app or in CarPlay), iOS delivers an INStartCallIntent to our app. Our app's only way to then place a normal cellular/PSTN call is to open a tel: URL, which requires the app to be foregrounded. On the phone this works (with an app launch + the system "Call?" confirmation). On CarPlay it cannot work at all, because CarPlay does not foreground third-party apps or open tel: URLs, and there is no API to initiate a PSTN/cellular call from the background. There is currently no way for an app-logged (CallKit) call to be called back as a native PSTN call — the callback is always routed back into the app, and the app has no sanctioned PSTN-dial path on CarPlay. Requested enhancement (any of these would solve it): A way to mark a CallKit-logged call (e.g., a flag on CXProviderConfiguration or per-call on the handle) such that calling it back from Recents/CarPlay dials the cellular line directly (treating it like a native carrier-logged number), instead of routing INStartCallIntent to the app; or An API to write a call to Recents as a native, PSTN-dialable entry associated with the cellular line; or A sanctioned way, when handling the callback INStartCallIntent on CarPlay, for the app to request a PSTN cellular callback (with the standard user confirmation) rather than only a VoIP call. Why existing APIs don't suffice: CXHandle(type: .phoneNumber) + includesCallsInRecents correctly display the number, and INStartCallIntent correctly delivers the callback — but the callback can only become a VoIP call (via CXStartCallAction) or an app-foregrounded tel: open. Neither yields a native PSTN call on CarPlay. Routing the callback through VoIP is not viable for us: it would present our trunk's caller ID (or require per-user STIR/SHAKEN caller-ID verification), so the user's own number would not appear to the person they call back. User impact (safety & accessibility): Our users skew older (55–65) and rely on the app to screen scam/spam calls. A user driving with CarPlay currently cannot safely return a legitimate screened call — they must pick up the phone, wait for the app to open, and tap a confirmation. This defeats the hands-free safety purpose of CarPlay for exactly the population most exposed to phone scams. For comparison: On Android, a self-managed ConnectionService with EXTRA_LOG_SELF_MANAGED_CALLS lets a screened call appear in the system dialer and be carrier-dialed back with a single tap from Android Auto, no app launch and no confirmation — preserving the user's own caller ID natively. iOS has no equivalent for app-logged calls. Steps to reproduce (current behavior): App reports an incoming call via CallKit with includesCallsInRecents = true and a .phoneNumber handle. End the call so it lands in Recents. In CarPlay, open Recents and tap the entry to call back. Observed: the callback is delivered to the app as INStartCallIntent; the only PSTN path (tel:) cannot open on CarPlay, so no call is placed. Expected: a native PSTN/cellular callback (one confirmation at most), as with a carrier-logged number. Wondering...can this be considered for a future update?

I’ve attempted uploading screenshots with the specified required dimensions and none seem to be working. Anybody else experiencing this problem?