Introduction

Making an iPhone vibrate can mean two different things: enabling vibration for alerts as a user, or triggering haptic feedback from an app as a developer. The technical side is worth understanding because older vibration APIs, modern haptic generators, and device settings all affect what the user actually feels.

User Settings Come First

If a device never vibrates, no amount of app-side code will make the experience feel correct. Before debugging code, confirm that vibration and haptics are enabled in the system settings for the alert type you care about.

For example, a notification can be configured correctly in the app, but the device may still feel silent if the user has disabled haptics or alert vibrations for that context. This is why app developers should treat vibration as a hint to the system, not a guaranteed physical outcome.

The Old Direct Vibration API

The classic way to trigger a simple vibration on iPhone is through Audio Toolbox. Apple exposes the constant kSystemSoundID_Vibrate, which can be used with system sound functions.

1import AudioToolbox
2
3func vibratePhone() {
4    AudioServicesPlaySystemSound(kSystemSoundID_Vibrate)
5}

This is easy to call and still useful for simple legacy behavior. It is not a flexible haptics API, though. You do not control intensity, timing, or custom patterns with this approach.

Prefer UIKit Feedback Generators for App UX

For most interface feedback, modern iOS apps should use UIKit haptic generators instead of treating everything like a raw vibration request. These APIs better match user interface events such as success, failure, selection, or impact.

A notification-style haptic looks like this:

1import UIKit
2
3func notifySuccess() {
4    let generator = UINotificationFeedbackGenerator()
5    generator.prepare()
6    generator.notificationOccurred(.success)
7}

An impact-style haptic for a tap or collision can use:

1import UIKit
2
3func playImpact() {
4    let generator = UIImpactFeedbackGenerator(style: .medium)
5    generator.prepare()
6    generator.impactOccurred()
7}

These APIs are better choices for buttons, toggles, drag interactions, and in-app confirmation moments because they describe intent instead of just "vibrate now."

When to Use Each Approach

Use kSystemSoundID_Vibrate when:

• you are maintaining older code
• you need a very simple device vibration behavior
• you do not need fine control over the haptic feel

Use UIKit feedback generators when:

• the haptic is part of normal app interaction
• you want semantic feedback such as success or failure
• you want code that aligns with modern iOS UI patterns

If you need advanced, custom-designed haptic patterns, Core Haptics is the next step. That API is more powerful, but it is also more complex than many apps need.

A Small Demo in a View Controller

Here is a simple example that triggers feedback when a button is tapped:

1import UIKit
2
3final class DemoViewController: UIViewController {
4    @IBAction func didTapSave(_ sender: UIButton) {
5        let generator = UINotificationFeedbackGenerator()
6        generator.prepare()
7        generator.notificationOccurred(.success)
8    }
9}

This example is more representative of real app behavior than calling the old vibration constant globally. It also communicates why the haptic is being played.

Testing on Real Hardware

The simulator is not enough for haptic work. Real feel, timing, and system behavior need to be tested on an actual iPhone. Even when code compiles and runs in the simulator, there may be no meaningful haptic output to evaluate there.

That matters during bug reports. "No vibration" could mean:

• the code path never ran
• the device settings disabled haptics
• the feature was tested only in the simulator
• the app used the wrong feedback API for the scenario

Physical device testing is the only reliable way to separate those cases.

Designing Good Haptic Feedback

More vibration is not better. Good haptics are short, intentional, and tied to meaningful events. Repeating haptics on every tap quickly makes the interface feel noisy.

A practical rule is:

• use selection feedback for subtle changes
• use impact feedback for physical interactions
• use notification feedback for success, warning, or failure states

That keeps the feedback aligned with user expectations and platform conventions.

Common Pitfalls

One common mistake is assuming the old vibration API gives you modern haptic design control. It does not. It only triggers a basic vibration behavior.

Another issue is testing only in the simulator and concluding the code is broken. Haptics need real hardware evaluation.

Developers also overuse feedback. If every action vibrates, users start ignoring it. Strong feedback should be reserved for events that deserve attention.

Summary

• iPhone vibration behavior depends on both app code and user device settings.
• 'AudioServicesPlaySystemSound(kSystemSoundID_Vibrate) triggers a simple legacy vibration.'
• UIKit feedback generators are the better default for modern app interactions.
• Test haptics on real hardware, not only in the simulator.
• Choose haptic styles based on user intent instead of adding vibration everywhere.