Swift version: 5.10
When working with code from another module – e.g., UIKit or a module you wrote separate from your main app – Swift differentiates between public accessibility and public overridability. That is, someone can be public for folks to use, but not public for them to extend.
Here’s an example to demonstrate the difference:
open class User {
open func login() { }
public func playGame() { }
public init() { }
}
If that were defined in its own module, any other code accessing it would be able to inherit from the User
class because it’s marked open
. Inside the child class, they could override login()
because it’s also marked open
, but they could not override playGame()
because it’s marked only as public
– it can be called, but not changed. If you remove open
from the whole User
class it can be used but not subclassed.
The open
keyword is an effective way of stopping other developers from accidentally overriding functionality that’s critical to the way your app works. If you use it selectively, subclassers can add their own functionality or perhaps replace a few non-critical components, without altering the fundamental behavior of your class.
SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure and A/B test your entire paywall UI without any code changes or app updates.
Sponsor Hacking with Swift and reach the world's largest Swift community!
Available from iOS 8.0
This is part of the Swift Knowledge Base, a free, searchable collection of solutions for common iOS questions.
Link copied to your pasteboard.