Introduction

Generating a UUID on iOS is straightforward, but the important design question is not the API call. It is whether you need a fresh identifier every time, a stable identifier for one install, or a server-issued identifier tied to business data. Once you separate those cases, the implementation becomes simple and safe.

Generate A New UUID In Swift

Modern Swift uses the Foundation UUID type. Calling UUID() creates a new value, and uuidString gives you the familiar hyphenated text form.

1import Foundation
2
3let id = UUID()
4print(id.uuidString)

You can also use it directly in models:

1import Foundation
2
3struct TodoItem: Identifiable {
4    let id: UUID
5    let title: String
6}
7
8let item = TodoItem(id: UUID(), title: "Write release notes")
9print(item.id.uuidString)

This is the standard answer when you need a unique value for records, temporary objects, offline-created entities, or correlation identifiers in logs.

Persist It If You Need Stability Across Launches

A common mistake is generating a new UUID on every startup and expecting it to represent the same app installation. If the identifier should survive app relaunches, store it the first time you create it.

For a simple app-scoped identifier, UserDefaults is often enough:

1import Foundation
2
3func installationID() -> String {
4    let key = "installation_id"
5
6    if let existing = UserDefaults.standard.string(forKey: key) {
7        return existing
8    }
9
10    let newID = UUID().uuidString
11    UserDefaults.standard.set(newID, forKey: key)
12    return newID
13}
14
15print(installationID())

This persists for the lifetime of the installed app data. If the user deletes the app and reinstalls it, the value is usually lost. If you need stronger persistence, such as surviving reinstall in some environments, store it in the Keychain instead.

Do Not Confuse UUIDs With Device Identifiers

A generated UUID is an app value, not a hardware identity. That is a good thing. Apple has steadily restricted device-tracking techniques for privacy reasons, so creating your own random identifier is usually the correct choice when you need uniqueness inside your app.

If you are looking for something device-related, there are other APIs with narrower meaning. For example, identifierForVendor is not the same as a random UUID that you generate yourself, and it can change under certain conditions. For analytics, syncing, and business objects, a random UUID or a server-side identifier is usually more honest and more robust.

When To Prefer Server IDs Instead

A UUID created on the device is excellent for local uniqueness, but it does not guarantee business meaning. If you are creating an order, invoice, or user record that must be globally authoritative, your backend may still want to issue the canonical ID.

A common pattern is:

1. Generate a local UUID immediately so the app can create objects offline.
2. Send that object to the backend.
3. Keep the local UUID as a client reference or replace it with the server ID, depending on your data model.

That gives you smooth UI behavior without making the mobile app the source of truth for domain identifiers.

Objective-C And Older APIs

If you work in older codebases, you may still see NSUUID. It is fine, but in modern Swift code UUID is the cleaner type.

NSUUID *identifier = [NSUUID UUID];
NSLog(@"%@", identifier.UUIDString);

Use this only when the surrounding code is already Objective-C. In new Swift code, prefer UUID directly.

Choosing The Right Representation

Inside Swift models, store UUID as a UUID when possible. Convert to uuidString only when you need to serialize, display, or transmit the value. Keeping the strong type in memory prevents accidental string manipulation bugs and makes intent clearer.

If your backend expects lowercase strings without braces, uuidString already matches the usual textual representation. There is rarely a reason to manually format the bytes yourself.

Common Pitfalls

• Generating a new UUID every app launch when you actually need a stable installation identifier. Persist it once and reuse it.
• Treating a random UUID as a trusted device identity. It identifies an app-generated value, not the hardware.
• Using String everywhere in Swift models instead of storing UUID as a UUID. That throws away useful type information.
• Assuming UserDefaults persistence survives uninstall. For that requirement, consider the Keychain or let the server manage identity.
• Overengineering the format. UUID().uuidString is already the standard representation for most iOS use cases.

Summary

• Generate a UUID in Swift with UUID() and read text with uuidString.
• Persist the value if it should stay stable across launches.
• Use random UUIDs for app-level uniqueness, not as a hardware fingerprint.
• Prefer server-issued IDs when the backend owns the business identity.
• In Swift models, keep values as UUID until you need a string.