Fileprivate vs private in Swift: The differences explained

Fileprivate and private are part of the access control modifiers in Swift. These keywords, together with internal, public, and open, make it possible to restrict access to parts of your code from code in other source files and modules.

The private access level is the lowest and most restrictive level whereas open access is the highest and least restrictive. The documentation of Swift will explain all access levels in detail to you, but in this blog post, I’m going to explain the differences between two close friends: fileprivate and private.

When to use fileprivate

Although the keywords are almost the same, there is a clear difference in their use cases. Fileprivate access restricts the use of an entity within the same defined source file. The only reason you would use fileprivate is when you want to access your code within the same file from different classes or structs.

In the following example, we have an ImageProvider and an ImageViewController. We can use fileprivate if they’re defined within the same file and we want to allow access to the image view from the image provider.

final class ImageViewController: UIViewController {

    fileprivate var imageView: UIImageView!

}

struct ImageProvider {

    let newImage: UIImage

    func updateImage(in viewController: ImageViewController) {
        // As we used fileprivate, we can now access the imageView property.
        viewController.imageView.image = newImage
    }
}

However, if we would create a separated file for the `ImageProvider` struct, we would get a compiler error:

Inaccessible image view due to fileprivate
Inaccessible image view due to fileprivate

In my opinion, this makes it a tiny use case as it’s often better for the structure of your project to define entities in their own files. If you ever ask yourself again: “When to use fileprivate”, think about the word “file” in fileprivate, which refers to “private access within the file itself”.

When to use private

The private keyword is used a lot more and restricts the use of an entity to the enclosing declaration and its extensions. The extensions, however, have to be defined within the same file. In other words, private declarations will not be visible outside the file. You can use this keyword to only expose the minimal code needed to interact with the entity. This will improve readability and makes it easier to use and understand your code for others.

Fileprivate vs private

It’s best to explain the differences by taking the image provider example. Declared within the same file, they will result in the following compiler error:

The keyword differences explained in code
The keyword differences explained in code

As you can see, the fileprivate declared image view is accessible within the same file. The private image view, however, is not accessible as it’s only visible within the entity itself. An extension to the ImageViewController would have had access to this private declared image view:

extension ImageViewController {
    func updateImage(_ newImage: UIImage) {
        privateImageView.image = newImage
        filePrivateImageView.image = newImage
    }
}

Defining access levels for setters only

In some cases, you might only want to define access to the setter of properties. This can be useful if you’ve defined modifiers within the file itself.

The way to do this looks as follows:

class ImageViewController: UIViewController {

    fileprivate(set) var filePrivateSetterImageView: UIImageView = UIImageView()
}

The filePrivateSetterImageView can now be accessed from any file and any instance, but it’s setter is only accessible from within the file itself. This can be a great flexibility when working with access levels and works with any access level keyword.

Conclusion

Unless you’re defining several instances in one file you’re not going to use fileprivate that often. The keyword describes itself quite clearly in that it’s access level is linked to the file its defined in. Defining methods and properties as private is more commonly done and allows you only expose the code that’s allowed to be used from outside of the instance.

If you like to learn more tips on Swift, check out the Swift category page. Feel free to contact me or tweet to me on Twitter if you have any additional tips or feedback.

Thanks!