Our DNA is written in Swift

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.

Old-Style Embedding

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.

Embedded Binaries

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.


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:

Strip Warning

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.

Strip Settings

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.


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


  1. “Removing them does not work because the default value is still YES for both.”

    It depends on what is set on project level. When we remove a setting on target level, it will be derived from project settings. Thus, we can select NO (for Debug and Release) on project settings and remove the setting for targets.

  2. Just wanted to say thanks, this was really useful ๐Ÿ™‚

  3. Nice Explanation and I like your philosophy about not ignoring warnings!

  4. Hey, thanks for this info. Those debug symbols where really annoying!

  5. My question now is, what does the strip debug symbols during copy does?, cause If I check my binary it stays the same size no matter if I set strip debug symbols during copy to yes or no.

  6. Thanks! Much obliged. This was really helpful.

  7. kplfkkl