Access control along inheritance lines doesn’t really fit with the design philosophies behind Swift and Cocoa:
When designing access control levels in Swift, we considered two main use cases:
privatedetails of a class hidden from the rest of the app
internaldetails of a framework hidden from the client app
These correspond to
internallevels of access, respectively.
protectedconflates access with inheritance, adding an entirely new control axis to reason about. It doesn’t actually offer any real protection, since a subclass can always expose “protected” API through a new public method or property. It doesn’t offer additional optimization opportunities either, since new overrides can come from anywhere. And it’s unnecessarily restrictive — it allows subclasses, but not any of the subclass’s helpers, to access something.
There’s further explanation on Apple’s Swift blog.