Does it make sense to completely avoid using the keywords "public" and "open" in the main app's target?

Viewed 368

We have a big iOS app 150K+ of code, the quarter of its code is Swift.

Currently, I am writing a separate module: dynamic iOS framework where I carefully use public, internal, fileprivate, private. This work made me think of our application's main target as a big Swift module which could have all of its classes at most internal level of scope and the reason for that is that these classes are not accessed from outside of our app but only from inside.

I don't have time to dive into Swift internals and to make an experiment to measure the performance differences so I am asking if anyone has an insight into if:

  1. this practice of not using public or open for the app's classes make sense
  2. if it makes a performance difference, for example in incremental compilation times.

Of course, the code that bridges to Objective-C is out of the scope of this question.

Background: in Objective-C, C and C++ putting as much as possible to .cpp files and forward-declaring everything in .h files makes a big difference in terms of incremental compilation time so I am wondering if the same practice should be considered for Swift apps.

0 Answers
Related