The core idea that could justify the absence of `protected` is proper encaspulation and the [principle of the least knowledge][1]: * either a member is public and can be used by anybody` * or the member is private and needs to be protected against external access. And derived class written by another programmer are as much subject to misuse private details as any other unrelated class. In fact, protected members create a high risk of breaking the **history rule** of [Liskov Substitution principle][2]: > We think it ought to be sufficient for a user to only know about the > “apparent” type of the object; the subtype ought to preserve any > properties that can be proved about the supertype.<br/> > - Barbara Liskov & Jeanette Wing in [*A behavioral notion of subtyping*][3] Without going into formal details of the quoted article, the protected members allow a derived class (subtype) to change the state of the base class object (supertype) without using one of its public operations. This being said, beware of the appearances and false promises. The Swift `private` is in-between `private` and `protected` in other languages: > Private access restricts the use of an entity to the enclosing > declaration, **and to extensions of that declaration that are in the > same file**. (...).<br/> > - Apple, in *[The swift programming language][4]* [1]: https://en.wikipedia.org/wiki/Law_of_Demeter [2]: https://en.wikipedia.org/wiki/Liskov_substitution_principle [3]: https://dl.acm.org/citation.cfm?doid=197320.197383 [4]: https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html