20

I got this warning when I added share extension to my project and archiving it warning: skipping copy phase strip, binary is code signed: /Users/xxxx/xxx/xxxx/Build/xxxx/Build/Intermediates/ArchiveIntermediates/xxxx/IntermediateBui ldFilesPath/UninstalledProducts/XXX.appex/XXXX

The old question does not provide and insight to correct this . So I decided to ask again. Warning during archive App with iOS 8 Extension in Xcode 6

Can someone please explain why this is happening ? Is it because the extension target is already code signed? If so, how to solve it ?

I knew that setting "Strip debug symbols during copy" to "NO" can clear this warning . But it is not actually solve the problem. And what is the drawback of not "stripping debug symbol"? Because my archive size is still the same whether I set this to YES or NO

mfaani
  • 33,269
  • 19
  • 164
  • 293
Kong Hantrakool
  • 1,865
  • 3
  • 20
  • 35

5 Answers5

20

Do not disable Strip Debug Symbols During Copy in your application project. This will bloat your app (if you have other unsigned dependencies).

It occurs because building the application project attempts to strip the framework but it can't since the framework is already codesigned. However the framework has already been stripped during it's build, so the warning is harmless. Xcode isn't doesn't seem to detect that the codesigned framework has already been stripped.

You should leave it as is.

Monstieur
  • 7,992
  • 10
  • 51
  • 77
  • 1
    Thanks for your answer. Can you elaborate on the detail that setting "No" on Strip Debug Symbols During Copy will bloat the app ? – Kong Hantrakool Apr 23 '15 at 19:02
  • The release version of the app should not contain debug symbols. – Monstieur Apr 24 '15 at 08:46
  • 4
    I think you are confusing [`COPY_PHASE_STRIP`](https://developer.apple.com/library/ios/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW143) (displayed in the Xcode build settings as "Strip Debug Symbols During Copy") and [`STRIP_INSTALLED_PRODUCT`](https://developer.apple.com/library/ios/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW4) ("Strip Linked Product"). – Daniel Rinser Jun 05 '15 at 19:41
  • 4
    The former only affects *copied binaries*, not the linked product itself. From the documentation: "YES: Copied binaries are stripped of debugging symbols. This does not cause the binary produced by the linker to be stripped. Use `STRIP_INSTALLED_PRODUCT` to have the linker strip the binary.". – Daniel Rinser Jun 05 '15 at 19:41
  • As you say, the framework has already been stripped, so there is no need to do this again in the copy phase. – Daniel Rinser Jun 05 '15 at 19:42
  • But when debugging my app, I do not want my debug build of the framework to be stripped during copy either. – Monstieur Feb 17 '16 at 10:32
  • 2
    It looks to me like Daniel is right here. The default on Xcode projects now is to have COPY_PHASE_STRIP to NO for both Debug and Release. But STRIP_INSTALLED_PRODUCT is set to YES for both Debug and Release. This setup silences the errors, and still strips debug info for releases. – Simone Manganelli Aug 24 '17 at 01:27
  • So should we leave it as it is, or set `COPY_PHASE_STRIP` release to NO? – Van Du Tran Sep 15 '17 at 16:08
  • 1
    I Daniel were right, we would need to set STRIP_INSTALLED_PRODUCT to NO for Debug. By default STRIP_INSTALLED_PRODUCT (Strip Linked Product) is YES for all, but debug symbols are still present. – cyanide Aug 19 '18 at 00:43
14

"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.

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."

Source: https://www.cocoanetics.com/2015/04/skipping-copy-phase-strip/

Luis Ascorbe
  • 1,985
  • 1
  • 22
  • 36
9

I experienced the same warning and solved it by setting "Strip Debug Symbols During Copy" to "NO" in Build Settings of the containing app(not the extension), as you knew.

On the other hand, changing the same setting of the extension had no effect. This make clear the actual meaning of the warning. That is, stripping symbol does not mean the symbols "of the target" will be striped, but does mean the target will try to strip symbols "of embedded binaries".

Consequently, I believe the actual meaning of the warning would be that Xcode can't strip out debug symbols of the extension binary while archiving the container app, because the extension binary which need to be embedded in the container app "was" already compiled and frozen by code-signing before Xcode tries to strip out symbols of the extension binary while archiving the container app.

It seems like Xcode's default build settings related to striping debug symbols of the embedded extension binaries needs to be correctly updated not to show this warning.

NeonBerry
  • 372
  • 2
  • 6
1

In my case was related with 2 AppIcons (I forgot the fill them) , check if you have all the AppIcons in the xxx.xcassets file with the right xxpt. From here I beg Apple to improve this check or enable an auto-tool to complete all the AppIcons set. It is crazy.

1

If you are using Xcode 9.34.1, click in the project settings. Use the filter to find the correct setting: type "strip debug". You will find the settings COPY_PHASE_STRIP. Probably is set to "Yes". Set to "No" to remove the warning.

Lorenzo
  • 3,293
  • 4
  • 29
  • 56