11
votes

I noticed that running strip -S -x (remove all debug and all local symbols) on the binaries in my app's 'Frameworks' folder makes them ~25% smaller, even when I have enabled stripping of debug symbols in my build settings.

Also note that this makes the Swift support libraries smaller as well, and it appears that there's no build setting to strip those. Plus, I'm not even 100% sure if my "Strip debug symbols" settings are correct (i.e. actually cause debug symbols to get stripped), given that nm --debug-syms still shows plenty of symbols for them, and strip -S (remove the debug symbols table) still makes them smaller. My strip settings do seem to be the recommended ones you find on the Internet:

  • Deployment Postprocessing: Yes
  • Strip Debug Symbols During Copy: No (has no effect anyway, because the frameworks are already code signed at that point)
  • Strip Linked Product: Yes
  • Strip Style: Debugging Symbols

But are there any adverse side effects to running strip -S -x, such as not being able to symbolicate stack traces later?

Also, how can I automate this stripping as part of the build process, while keeping the final code signature intact? It appears that adding -Xlinker -x -Xlinker -S to my "Other Linker Flags" applies this process to the current project's binaries (including frameworks), but not to the frameworks in my dependency projects (e.g. CocoaPods). This is particularly relevant because it is not easy to modify the build settings for my included CocoaPods projects accordingly. As mentioned above, it is also relevant to the Swift support library dylibs, which do not have such linker options either, but still benefit from this stripping.

1

1 Answers

0
votes

The best (i.e. most aggressive while being reliable) linker flags I have found for Release builds can now be found at https://stackoverflow.com/a/63188437/153354.