Introduction

In Swift, you usually do not change the device locale from inside the app. What you can change programmatically is the locale used by your own formatting, parsing, sorting, or view logic. That distinction matters because system locale is a user setting, while formatter locale is an application choice.

If your goal is to display a date in French, format currency in Canada, or preview another region for testing, create the appropriate Locale and assign it where needed. Do not try to override the phone’s global regional settings.

Using Locale With Formatters

Most locale changes happen through DateFormatter, NumberFormatter, or related APIs.

1import Foundation
2
3let amount = 1234.56
4let formatter = NumberFormatter()
5formatter.numberStyle = .currency
6formatter.locale = Locale(identifier: "fr_CA")
7
8let output = formatter.string(from: NSNumber(value: amount))
9print(output ?? "Formatting failed")

That changes how the value is displayed without changing any system setting.

The same pattern applies to dates:

1import Foundation
2
3let formatter = DateFormatter()
4formatter.dateStyle = .full
5formatter.timeStyle = .none
6formatter.locale = Locale(identifier: "de_DE")
7
8print(formatter.string(from: Date()))

Choosing a Locale Identifier

Locale identifiers usually follow a language and region pattern such as en_US, en_GB, fr_CA, or ja_JP. The exact locale affects separators, month names, currency symbols, and other formatting conventions.

You can inspect the current locale at runtime:

1import Foundation
2
3print(Locale.current.identifier)
4print(Locale.autoupdatingCurrent.identifier)

Locale.current reflects the locale at the time it is read. Locale.autoupdatingCurrent tracks system changes while the app is running.

Applying Locale to Specific Operations

Locale is not just for display. It also affects parsing and comparison behavior in some APIs.

1import Foundation
2
3let formatter = DateFormatter()
4formatter.locale = Locale(identifier: "en_US_POSIX")
5formatter.dateFormat = "yyyy-MM-dd"
6
7let parsedDate = formatter.date(from: "2026-03-07")
8print(parsedDate as Any)

The en_US_POSIX locale is commonly used for stable machine-readable date parsing because it avoids user-region surprises.

Locale in SwiftUI

In SwiftUI, you can inject a locale into the view environment.

1import SwiftUI
2
3struct PriceView: View {
4    let amount: Double
5
6    var body: some View {
7        Text(amount, format: .currency(code: "EUR"))
8    }
9}
10
11struct ContentView: View {
12    var body: some View {
13        PriceView(amount: 49.99)
14            .environment(\.locale, Locale(identifier: "fr_FR"))
15    }
16}

That changes how the view renders localized values without affecting the rest of the system.

What You Cannot Reliably Change

An app cannot generally force the user’s entire device locale to a new value. Older workarounds involving UserDefaults keys such as Apple language settings are brittle and not recommended for normal application behavior.

If your app supports an in-app language or region preference, store that preference yourself and apply the selected locale to the parts of the UI that need it.

Common Pitfalls

The biggest mistake is assuming Locale changes translation strings automatically. Locale affects formatting and some text behavior, but localized strings usually come from your app’s localization resources.

Another issue is using the current user locale for fixed-format machine data. That can break date parsing and server communication. Use a stable locale such as en_US_POSIX for machine formats.

Be careful when caching formatters. If the locale should respond to user preference changes, cached formatters may need to be rebuilt.

Finally, do not confuse locale with language, calendar, or time zone. They are related concepts, but they are not interchangeable.

Summary

• In Swift, you usually set locale on formatters or views, not on the entire device.
• Use Locale(identifier:) to choose a specific regional format.
• Assign that locale to DateFormatter, NumberFormatter, or SwiftUI environment values.
• Use en_US_POSIX for stable machine-readable parsing.
• Treat system locale as a user preference rather than something the app should override globally.