Introduction

On iOS, "device model" can mean two different things. UIDevice.current.model gives only a broad class such as iPhone or iPad, while the precise hardware identifier is something like iPhone15,2. If you need the exact model family for debugging or analytics, you have to read that hardware identifier and map it yourself.

The Simple API Only Gives a Generic Name

The most obvious API is UIDevice.current.model.

1import UIKit
2
3let model = UIDevice.current.model
4print(model)

This returns values such as iPhone, iPad, or iPod touch. That is useful if you only need the broad device category, but it is not enough to distinguish one iPhone generation from another.

Read the Hardware Identifier

For the exact device identifier, use utsname.

1import UIKit
2
3func hardwareIdentifier() -> String {
4    var systemInfo = utsname()
5    uname(&systemInfo)
6
7    let mirror = Mirror(reflecting: systemInfo.machine)
8    let identifier = mirror.children.reduce(into: "") { result, element in
9        guard let value = element.value as? Int8, value != 0 else { return }
10        result.append(String(UnicodeScalar(UInt8(value))))
11    }
12
13    return identifier
14}
15
16print(hardwareIdentifier())

That returns identifiers such as iPhone15,2, iPad13,4, or x86_64 on older simulators.

Map the Identifier to a Marketing Name

The identifier itself is not user-friendly, so most apps map it to a human-readable name.

1func deviceModelName() -> String {
2    switch hardwareIdentifier() {
3    case "iPhone14,2":
4        return "iPhone 13 Pro"
5    case "iPhone15,2":
6        return "iPhone 14 Pro"
7    case "iPhone15,3":
8        return "iPhone 14 Pro Max"
9    case "arm64", "x86_64":
10        return "Simulator"
11    default:
12        return hardwareIdentifier()
13    }
14}
15
16print(deviceModelName())

In a real app, that switch table usually lives in a utility file and is updated as new devices appear.

Why UIDevice.current.name Is Not the Same Thing

Developers sometimes reach for UIDevice.current.name, but that is the user-assigned device name, not the hardware model.

Examples:

• 'Alice's iPhone'
• 'QA iPad'

That can be useful for debugging locally, but it is not a device model check.

Simulator Behavior Needs Special Handling

On the simulator, the machine string often reports an architecture such as arm64 or x86_64 rather than a real iPhone identifier. If you need the simulated device model, you may also inspect simulator environment variables, but for most app logic it is enough to treat simulator as its own category.

This is one reason device-model-specific code should be kept narrow and well-documented.

Use Cases and Caution

Exact device model detection is most common for:

• diagnostics and logging
• internal support tooling
• analytics segmentation
• hardware-specific bug workarounds

It is usually not a great foundation for product logic. Prefer capability checks where possible. For example, if the real goal is to know whether a device supports a feature, API or hardware capability detection is usually better than maintaining a long model-name table.

A Small Utility Wrapper

Here is a compact utility that exposes both forms.

1import UIKit
2
3struct DeviceInfo {
4    static func genericModel() -> String {
5        UIDevice.current.model
6    }
7
8    static func exactIdentifier() -> String {
9        hardwareIdentifier()
10    }
11}

Keeping model lookup in one place makes later updates much easier.

Common Pitfalls

• Expecting UIDevice.current.model to tell you the exact iPhone generation.
• Confusing the user-assigned device name with the hardware model.
• Hard-coding a long mapping table and never updating it for new Apple devices.
• Using exact model checks where a capability check would be more robust.
• Forgetting that simulator identifiers differ from real hardware identifiers.

Summary

• 'UIDevice.current.model gives only a broad device category such as iPhone.'
• Use utsname to read the hardware identifier when you need the exact model code.
• Map that identifier to a marketing name yourself if human-readable output matters.
• Treat simulator output as a separate case.
• Prefer feature or capability checks over exact model matching when possible.