Introduction

In iOS, the usual way to start a phone call from Swift is to open a URL with the tel: scheme. The system then hands control to the Phone app and lets the user continue the call flow. The implementation is small, but it still needs basic validation and realistic expectations about what an app is allowed to do.

The Basic tel: Approach

The simplest implementation is to build a tel: URL and ask UIApplication to open it.

1import UIKit
2
3func call(phoneNumber: String) {
4    let cleaned = phoneNumber.filter { "0123456789+".contains($0) }
5    guard let url = URL(string: "tel:\(cleaned)") else {
6        print("Invalid phone number")
7        return
8    }
9
10    UIApplication.shared.open(url, options: [:], completionHandler: nil)
11}

Call it like this:

call(phoneNumber: "+14165551234")

This is the core answer for iOS 10 and later as well. The important part is the tel: URL scheme.

Validate Before Opening

Phone numbers often contain spaces, dashes, or parentheses in display form. A minimal cleaning step makes the URL more reliable.

let raw = "+1 (416) 555-1234"
let cleaned = raw.filter { "0123456789+".contains($0) }
print(cleaned)

You should also check that the URL can be opened.

1func callIfPossible(phoneNumber: String) {
2    let cleaned = phoneNumber.filter { "0123456789+".contains($0) }
3    guard let url = URL(string: "tel:\(cleaned)") else {
4        return
5    }
6
7    if UIApplication.shared.canOpenURL(url) {
8        UIApplication.shared.open(url)
9    } else {
10        print("This device cannot place calls")
11    }
12}

This matters on devices such as iPads or simulators where phone calling is not supported.

What the App Can and Cannot Do

An iOS app can request that the system open the phone call URL. It cannot silently place a call on behalf of the user the way a private telecom app or system component might.

That means your app should treat phone calling as a user-initiated action, usually from a visible button such as Call Support or Call Sales.

You should also test on a real device. The simulator is not a meaningful environment for real phone-call behavior.

A Button Example in a View Controller

1import UIKit
2
3final class ContactViewController: UIViewController {
4    @IBAction private func callSupportTapped(_ sender: UIButton) {
5        callIfPossible(phoneNumber: "+14165551234")
6    }
7
8    private func callIfPossible(phoneNumber: String) {
9        let cleaned = phoneNumber.filter { "0123456789+".contains($0) }
10        guard let url = URL(string: "tel:\(cleaned)") else {
11            return
12        }
13
14        guard UIApplication.shared.canOpenURL(url) else {
15            print("Phone calls are not supported on this device")
16            return
17        }
18
19        UIApplication.shared.open(url, options: [:], completionHandler: nil)
20    }
21}

This keeps the behavior close to the UI event that triggered it, which is usually the clearest design.

Avoid Outdated Tricks

Older code examples sometimes mention alternate schemes or hacks intended to skip confirmation or change the UX flow. Those approaches are brittle and not where you should anchor app behavior.

For normal app code, use tel: and let iOS handle the call transition. That is the stable public API path.

Common Pitfalls

The most common mistake is testing only in the simulator and assuming call support is broken. The simulator cannot act like a real phone-capable device.

Another issue is passing a raw display string with spaces and punctuation directly into the URL. Clean the number first.

Developers also sometimes forget that the app is only opening the Phone app flow, not directly controlling the call itself. Build the UX around user intent, not around forced automation.

Finally, do not use undocumented or legacy URL tricks when the public tel: scheme already solves the supported use case.

Summary

• Use a tel: URL and UIApplication.shared.open to start the phone-call flow.
• Sanitize the displayed phone number before building the URL.
• Check canOpenURL and test on a real device.
• Treat the action as user-initiated system handoff, not silent call automation.
• Prefer the public tel: scheme over outdated undocumented approaches.