There's a good reason why this feature does not exist in Swift. Swift's access levels are strictly lexical and never semantical. If you're trying to access something from another type, then you are either the author of that type and you can use fileprivate/internal access level, or you're not the author of the type and you're trying to access something that the original author didn't intend to be accessed. If you want a method to be overridable, but not callable, you're much better off abstracting it away into another type and then injecting it as a dependency which is stored as a private property, which is better than having a typeprivate access level, since it guarantees that the overriding type can't sneakily make the typeprivate method callable again by expanding its access or making a wrapper method with wider access.
In your case, the url is an integral part of the api, so it has no business being private. If it isn't an integral part of the api and needs to be private, but you still need access to it, then you're establishing a dependency on an implementation detail, which is a violation of the dependency inversion principle, meaning that you're doing something wrong.
The existence of a typeprivate/protected access level is a bad idea on a conceptual level, it shouldn't exist at all. My guess is that it was a very early attempt at facilitating the open/closed principle without violating the single responsibility principle, that didn't go as well as initially envisioned due to the fact that programming languages were in their early stages of evolution and simply didn't know any better.