iOS: Playing with Static Libs, Fat Frameworks, Static/Dynamic Frameworks with Swift & Objective-C classes mixed up
Recently, I got to know few facts on how exactly Static Library(SL), Fat Frameworks(FF), Static/Dynamic Frameworks(SDF) actually works while I was working on a legacy code base which had a ton of all of the above stuff working altogether.
This article is to log the few notes on the struggles we faced with having all these above things mixed up altogether with both Swift & Objective-C mixed up.
Static Library(SL):
Static Libraries was the initial(Way too Older now) way of code distribution where any project integrating the library would include .a file(Which contains the implementation classes) and all the header '.h' files separately along with the .a file in order for them to work in conjunction.
Fat Frameworks(FF):
Fat Frameworks are nothing but just the Static Library compressed as a framework, which was a means of distributing the code before Xcode6 when Apple introduced Static/Dynamic Frameworks(SDF).
Static/Dynamic Frameworks(SDF):
In Frameworks world, Umbrella Header file serves 2 purposes:
It acts as the Bridging header between Swift & Objective-C.
It acts as the interface between the Framework itself & other modules/projects.
In order to create a SDF, you simply expose all the header files in the Framework's Umbrella Header file and Integrate the Framework into the other projects/modules and start using/accessing the Framework classes/files.
But, in order to integrate non-modular frameworks(SL or FF) with both Swift & Objective-C files in it, you need to have a custom .modulemap file where you should explicitly expose all the headers that you're willing to expose to the user of the Framework. These changes applies with recent Xcode9+ updates.
And there is a caveat even with this approach when you're dealing with SL or FF.
We've seen it working very well when you have to deal with just one level deeper encapsulation like this:
Project --> FF
But, when you're in a situation such as below:
Project --> FF --> SL
or
Project --> FF --> FF --> SL
or
any other combinations of deeper layer that goes with SL or FF, then it becomes so much complicated and you'd have to do a lot unneccesary hard work to make them work altogether.
At any bigger cost, it is always better to get out of that older techniques(SL or FF), since they're kinda becoming a burden to maintain the legacy code bases because it literally costs you more energy/time/money to have SL or FF going forward rather than switching to the SDF.
Thus, going with the new SDF way is the wise advise to make the code bases less vulnerable, easily scalable and futuristic.
Hope it helps someone struggling in that way. Cheers!
This article is to log the few notes on the struggles we faced with having all these above things mixed up altogether with both Swift & Objective-C mixed up.
Static Library(SL):
Static Libraries was the initial(Way too Older now) way of code distribution where any project integrating the library would include .a file(Which contains the implementation classes) and all the header '.h' files separately along with the .a file in order for them to work in conjunction.
Fat Frameworks(FF):
Fat Frameworks are nothing but just the Static Library compressed as a framework, which was a means of distributing the code before Xcode6 when Apple introduced Static/Dynamic Frameworks(SDF).
Static/Dynamic Frameworks(SDF):
In Frameworks world, Umbrella Header file serves 2 purposes:
It acts as the Bridging header between Swift & Objective-C.
It acts as the interface between the Framework itself & other modules/projects.
In order to create a SDF, you simply expose all the header files in the Framework's Umbrella Header file and Integrate the Framework into the other projects/modules and start using/accessing the Framework classes/files.
But, in order to integrate non-modular frameworks(SL or FF) with both Swift & Objective-C files in it, you need to have a custom .modulemap file where you should explicitly expose all the headers that you're willing to expose to the user of the Framework. These changes applies with recent Xcode9+ updates.
And there is a caveat even with this approach when you're dealing with SL or FF.
We've seen it working very well when you have to deal with just one level deeper encapsulation like this:
Project --> FF
But, when you're in a situation such as below:
Project --> FF --> SL
or
Project --> FF --> FF --> SL
or
any other combinations of deeper layer that goes with SL or FF, then it becomes so much complicated and you'd have to do a lot unneccesary hard work to make them work altogether.
At any bigger cost, it is always better to get out of that older techniques(SL or FF), since they're kinda becoming a burden to maintain the legacy code bases because it literally costs you more energy/time/money to have SL or FF going forward rather than switching to the SDF.
Thus, going with the new SDF way is the wise advise to make the code bases less vulnerable, easily scalable and futuristic.
Hope it helps someone struggling in that way. Cheers!
Comments