I googled and finally came across this SO answer. ("Best answer" seems to be outdated but this answer looks more up-to-date.)
https://stackoverflow.com/a/59216151/3652888
It states:
Static framework contain a static library packaged with its resources.
But I think it's a wrong definition. Resouces are still needed to be bundled separately inside app package.
So still cannot differenciate "static library" and "static framework".
Is there any advantages or disadvantages when choosing either of them?
There is a difference between the flags used for them:
For a static library when you have swiftmodule files or headers those end up somewhere beside it (or literally anywhere) and you have to pass -L for the library search path and -I for the include paths.
With a framework all you need is a single -F for the framework search path and it will, by convention, find the swiftmodule, headers, and modulemap, in the expected paths.
So that simplified those flags a bit. This also means you can swap out a dynamic framework for a static framework and it's 1 for 1 with flags changes (ignoring resources as you mentioned). This would actually be true for dynamic libraries to static libraries on iOS but since dynamic libraries aren't really used for non-system things on iOS it doesn't really apply.
We also find the organization of having a single directory vs putting all the related files beside each other in some path nice for understanding that they're all related.
Thank you @keith !!
I understood that, from linking perspective, static framework is simpler.
How about from Xcode GUI perspective though? Those linker flag difference is hidden under the hood of Xcode, right?
After asking this question, I thought static framework is more complicated because there is no way to set productType: framework.static from Xcode GUI.
How about from Xcode GUI perspective though? Those linker flag difference is hidden under the hood of Xcode, right?
I'm not sure actually, it might!
After asking this question, I thought static framework is more complicated because there is no way to set productType: framework.static from Xcode GUI.
Yea, we never minded adding the single build setting to make this work, but we were often controlling lots of these flags ourselves so we felt more pain from having the extra compile / link flags
Most helpful comment
There is a difference between the flags used for them:
For a static library when you have swiftmodule files or headers those end up somewhere beside it (or literally anywhere) and you have to pass
-Lfor the library search path and-Ifor the include paths.With a framework all you need is a single
-Ffor the framework search path and it will, by convention, find the swiftmodule, headers, and modulemap, in the expected paths.So that simplified those flags a bit. This also means you can swap out a dynamic framework for a static framework and it's 1 for 1 with flags changes (ignoring resources as you mentioned). This would actually be true for dynamic libraries to static libraries on iOS but since dynamic libraries aren't really used for non-system things on iOS it doesn't really apply.
We also find the organization of having a single directory vs putting all the related files beside each other in some path nice for understanding that they're all related.