Calling a phone number in swift
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Calling a phone number from an iOS app is technically simple, but the user experience and device constraints matter more than the one-line API call. The action should be user-initiated, the number should be sanitized, and the app should handle devices that cannot place calls. A safe implementation combines tel: URLs with validation and graceful fallback.
The Core Mechanism
iOS uses the tel: URL scheme for phone calls. You build a URL, ask UIApplication whether it can be opened, and then open it.
This works on real iPhones with calling capability. It will not place a call on the simulator.
Sanitize the Input
Phone numbers often come from contacts, CMS content, or user input, so they may contain spaces, parentheses, or dashes. Removing formatting before building the URL avoids failed calls.
If the data source is inconsistent, normalization should happen in one helper rather than repeated ad hoc in buttons.
Let the User Confirm the Action
Phone calls should feel intentional. A confirmation alert is often a better experience than immediately jumping to the Phone app.
This is especially useful when the UI contains several tappable contact actions close together.
Handle Unsupported Devices
Not every Apple device can place a call. iPads without cellular calling, simulators, and some managed environments will fail canOpenURL.
That means your UI should handle failure cleanly:
- disable the call button when call capability is unavailable
- show the number so users can copy it
- offer alternative actions such as message or email
Treat calling as a feature that may not exist, not a guaranteed capability.
SwiftUI Bridge Example
If your app is SwiftUI-based, you can still use the same URL scheme through openURL.
The logic is the same. The only change is the UI framework.
Testing the Behavior
Testing should cover:
- number normalization
- unsupported-device handling
- alert presentation flow
A small unit test for normalization is easy and worthwhile:
You do not need to automate an actual phone call. You need to automate the decision logic around it.
Common Pitfalls
- Building a
tel:URL from uncleaned text such as spaces and punctuation. - Assuming the simulator or every iPad can place calls.
- Triggering a call without clear user intent or confirmation.
- Forgetting to check
canOpenURLbefore callingopen. - Duplicating phone-number cleanup logic across multiple screens.
Summary
- Use the
tel:URL scheme to start a phone call from Swift. - Normalize phone numbers before building the URL.
- Check device capability with
canOpenURL. - Prefer a confirmation step for better UX.
- Test the sanitization and fallback logic even if the real call stays manual.

