|< What’s the point of static properties and methods in Swift?||Why does Swift have both classes and structs? >|
Updated for Xcode 14.2
Swift’s access control keywords let us restrict how different parts of our code can be accessed, but a lot of the time it’s just obeying the rules we put into place – we could remove them if we wanted and bypass the restrictions, so what’s the point?
There are a few answers to that, but one is particularly easy so I’ll start there: sometimes access control is used in code you don’t own, so you can’t remove the restriction. This is common when you’re building apps with Apple’s APIs, for example: they place restrictions about what you can and cannot do, and you need to abide by those restrictions.
In your own code, yes of course you can remove any access control restrictions you put in place, but that doesn’t make it pointless. Access control lets us determine how a value should be used, so that if something needs to accessed very carefully then you must follow the rules.
Previously I’ve mentioned Unwrap, my Swift learning app, and I want to use another example from there. When users learn different parts of Swift, I store the name of the thing they learned in a private
Set inside a
User struct, declared like this:
private var learnedSections = Set<String>()
It’s private, which means no one can read or write to it directly. Instead, I provide public methods for reading or writing values that should be used instead. That’s intentional, because learning a section needs to do more than just insert a string into that set – it needs to update the user interface to reflect the change, and needs to save the new information so the app remembers it was learned.
If I hadn’t made the
learnedSections property private, it’s possible I might forget and write things to it directly. That would result in my UI being inconsistent with its data, and also not saving the change – bad all around!
So, by using
private here I’m asking Swift to enforce the rules for me: don’t let me read or write this property from anywhere outside the
One other advantage to access control is that it lets us control how other people see our code – known as its “surface area”. Think about it: if I gave you a struct to use and it had 30 public properties and methods, you might not be sure which ones are there for you to use and which ones are really just for internal use. On the other hand, if I mark 25 of those as private then it’s immediately clear that you shouldn’t be using them externally.
Access control can be quite a thorny issue, particularly when you take into account external code. So, it’s not a surprise Apple’s own documentation on it is quite long – you can find it here: https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html
SPONSORED Play is the first native iOS design tool created for designers and engineers. You can install Play for iOS and iPad today and sign up to check out the Beta of our macOS app with SwiftUI code export. We're also hiring engineers!
Link copied to your pasteboard.