Updated for Xcode 15
Most people learning Swift immediately see the value of regular properties and methods, but struggle to understand why static properties and methods would be useful. It’s certainly true that they are less useful than regular properties and methods, but they are still fairly common in Swift code.
One common use for static properties and methods is to store common functionality you use across an entire app. For example, I make an app called Unwrap, which is a free iOS app for folks learning Swift. In the app I want to store some common information, such as the URL to the app on the App Store, so I can reference that anywhere the app needs it. So, I have code like this storing my data:
struct Unwrap {
static let appURL = "https://itunes.apple.com/app/id1440611372"
}
That way I can write Unwrap.appURL
when someone shares something from the app, which helps other folks discover the app. Without the static
keyword I’d need to make a new instance of the Unwrap
struct just to read the fixed app URL, which isn’t really necessary.
I also use both a static property and a static method to store some random entropy in the same struct, like this:
static var entropy = Int.random(in: 1...1000)
static func getEntropy() -> Int {
entropy += 1
return entropy
}
Random entropy is some randomness collected by software to make random number generation more effective, but I cheat a little in my app because I don’t want truly random data. The app is designed to give you various Swift tests in a random order, but if it were truly random then it’s likely you’d see the same question back to back sometimes. I don’t want that, so my entropy actually makes randomness less random so we get a fairer spread of questions. So, what my code does is store an entropy
integer that starts off random, but increments by 1 every time getEntropy()
is called.
This “fair random” entropy is used throughout the app so that duplicates won’t appear, so again they are shared statically by the Unwrap
struct so everywhere can access them.
Before I move on, there are two more things I want to mention that might interest you.
First, my Unwrap struct doesn’t really need to be a struct at all – I could and in fact should declare it as an enum rather than a struct. This is because the enum doesn’t have any cases, so it’s a better choice than a struct here because I don’t ever want to create an instance of this type – there’s no reason to. Making an enum stops this from happening, which would help clarify my intent.
Second, because I have a dedicated getEntropy()
method, I actually ask Swift to restrict access to the entropy
so that I can’t access it from anywhere. This is called access control, and look like this in Swift:
private static var entropy = Int.random(in: 1...1000)
We’ll be looking more at access control soon.
TAKE YOUR SKILLS TO THE NEXT LEVEL If you like Hacking with Swift, you'll love Hacking with Swift+ – it's my premium service where you can learn advanced Swift and SwiftUI, functional programming, algorithms, and more. Plus it comes with stacks of benefits, including monthly live streams, downloadable projects, a 20% discount on all books, and free gifts!
Sponsor Hacking with Swift and reach the world's largest Swift community!
Link copied to your pasteboard.