Skipping Copy Phase Strip

If your app contains frameworks or extensions you are recently beginning to notice a new warning popping up when building for releases: “skipping copy phase strip, binary is code signed”. Here’s how to fix it.

For the longest time, only on OS X you could have extra binary code in your app bundle. App bundles have a dedicated location for frameworks, but Apple didn’t want anybody to create dynamic frameworks for iOS. This changed at WWDC 2014, when Apple needed to permit additional binaries.

Now that the Apple Watch is out, we know that those extra binaries can take these forms:

• Dynamic Frameworks
• iOS Extensions (like for Sharing or Today)
• WatchKit Extensions

Xcode is evolving to better support the patterns necessary for creating modern apps which make use of these technologies.

Embedded Binaries

Before Xcode 6.3 you needed to have an extra step in your build phases to copy a dynamic framework into the app bundle.

If you forgot this then your app would build and link, but crash as soon as your code was accessing any of the framework functions. This extra build step was somewhat similar to copying bundle resources. You could already see the checkbox to insure that the copied framework would also be code signed.

In Xcode 6.3, this framework copying was moved to a different location. Apple deemed this process important enough to warrant its own Embedded Binaries section on the General tab.

Now you no longer need to mess with the path of the binary product, but rather you can pick it from a list of products. This is especially handy if you have the framework code in a sub-project.

There is still a separate box for linking which can still include static and dynamic libraries and frameworks, even though it makes little sense to include an embedded framework without linking to it.

Stripping

Compiled code usually contains debug information. This debug stuff is helpful for inspecting running code in debugger, but less so for the optimized code you would ship in distribution builds. Therefore it gets stripped out when doing an Archive build.

The problem here is that PBXCp is unable to strip out debug symbols from signed binaries because this would invalidate the digital signature. So if you have a project that was created before Xcode 6.3 you will now get a warning like this:

It does not matter which of the above mentioned methods you are using for the embedding. There is no stripping for either of them. Before Xcode 6.3 the default setting for “Strip Debug Symbols During Copy” was set to NO for Debug builds and YES for Release builds.

This explains why you are only seeing this pesky warning when doing release builds (via Archive for TestFlight or App Store).

To fix the warning simply change both values to NO. Removing them does not work because the default value is still YES for both. The project templates that came with Xcode 6.3 have these turned off by default. Only projects that were started with older templates still have YES on the Release line.

Conclusion

Ever now and then Xcode improves and changes default settings of project templates. New warnings appear and we get annoyed by them. But every fixed warning teaches us something new the inner workings of the build process. So don’t go about ignoring warnings, but take a minute to figure out what their reason is and how to fix them.

Categories: Recipes