Make Themis a static framework #731
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
First of all, to get this thing out of sight, remove all trailing whitespace that got recently added to the file.
Tell CocoaPods to build ObjCThemis as a 'static framework'. That is, your usual framework bundle but with a static library inside, not a dynamic one as you would have normally use. Using static linkage greatly simplifies our life on iOS platforms which tend to be very picky about dynamic linkage and loading of frameworks. These issues are not really visible until you archive the app for distribution, actually install it on the device, and try launching it. Debugging these issues takes enormous amount amount of time which we don't have. Let Apple engineers fiddle with dynamic linkage for system frameworks. That at least makes sense. Using static linkage for Themis has advantages, such as improved startup time (no extra symbol resolution) and improved app size (unused parts of Themis and its dependencies could be cut out by the linker). As Themis is distributed under a permissive license, there are no legal downsides of including it as an integral part of an application, it does not have to be a completely separate binary. On the other hand, there are not many advantages of dynamic linkage. We don't get to share the memory and storage as Themis is not a system framework. The only real advantage is that it's easier to verify that Themis binaries have not been tampered with and to check Themis version, but iOS deployment process is know to heavily process the binaries, making this point mostly moot.
ilammy
added
O-iOS 📱
vixentael
approved these changes
Oct 27, 2020
wow, interesting. didn't know about that. did you read about it or measured it somehow? |
I don't have iOS devices so I cannot measure it properly. It's a pretty marginal gain in our case, at best, but it's a common suggestion to avoid having lots of dynamic frameworks. The speedup here is gained by skipping all the dynamic linking and loading time. If dynamic frameworks are used, the app has to locate, verify, load Themis, resolve symbols used by the app, then move on to locating, verifying, loading, and resolving OpenSSL symbols. If static frameworks are used them everything has been pre-linked into the application and does not affect loading time much. |
.. and crash because rpath is wrong :D |
ilammy
added a commit
to ilammy/themis
that referenced
this pull request
Oct 28, 2020
* Clean up whitespace First of all, to get this thing out of sight, remove all trailing whitespace that got recently added to the file. * Make Themis a static framework Tell CocoaPods to build ObjCThemis as a 'static framework'. That is, your usual framework bundle but with a static library inside, not a dynamic one as you would have normally use. Using static linkage greatly simplifies our life on iOS platforms which tend to be very picky about dynamic linkage and loading of frameworks. These issues are not really visible until you archive the app for distribution, actually install it on the device, and try launching it. Debugging these issues takes enormous amount amount of time which we don't have. Let Apple engineers fiddle with dynamic linkage for system frameworks. That at least makes sense. Using static linkage for Themis has advantages, such as improved startup time (no extra symbol resolution) and improved app size (unused parts of Themis and its dependencies could be cut out by the linker). As Themis is distributed under a permissive license, there are no legal downsides of including it as an integral part of an application, it does not have to be a completely separate binary. On the other hand, there are not many advantages of dynamic linkage. We don't get to share the memory and storage as Themis is not a system framework. The only real advantage is that it's easier to verify that Themis binaries have not been tampered with and to check Themis version, but iOS deployment process is know to heavily process the binaries, making this point mostly moot. (cherry picked from commit 3f858f4) Signed-off-by: Alexei Lozovsky <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tell CocoaPods to build ObjCThemis as a 'static framework'. That is, your usual framework bundle but with a static library inside, not a dynamic one as you would have normally use.
Using static linkage greatly simplifies our life on iOS platforms which tend to be very picky about dynamic linkage and loading of frameworks. These issues are not really visible until you archive the app for distribution, actually install it on the device, and try launching it. Debugging these issues takes enormous amount amount of time which we don't have. Let Apple engineers fiddle with dynamic linkage for system frameworks. That at least makes sense.
Using static linkage for Themis has advantages, such as improved startup time (no extra symbol resolution) and improved app size (unused parts of Themis and its dependencies could be cut out by the linker). As Themis is distributed under a permissive license, there are no legal downsides of including it as an integral part of an application, it does not have to be a completely separate binary.
On the other hand, there are not many advantages of dynamic linkage. We don't get to share the memory and storage as Themis is not a system framework. The only real advantage is that it's easier to verify that Themis binaries have not been tampered with and to check Themis version, but iOS deployment process is know to heavily process the binaries, making this point mostly moot.
Checklist
Required reviews: