iOS frameworks built with Carthage cannot be submitted to the App Store #188

Closed
jspahrsummers opened this Issue Dec 2, 2014 · 60 comments

Comments

Projects
None yet
@jspahrsummers
Member

jspahrsummers commented Dec 2, 2014

From @soffes in #174 (comment):

I've been dragging the projects into my project and setting up dependencies in Xcode for building. You can't submit iOS frameworks with x86. Couldn't find a way to do a "release build" in carthage so that was my work around.

IOW, our fat binary is inadmissable to the App Store, apparently.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 2, 2014

So, we are going to have separate artefacts for the device and simulator and will be forced to integrate them via the -framework linker flag?

Bad news if so...

dodikk commented Dec 2, 2014

So, we are going to have separate artefacts for the device and simulator and will be forced to integrate them via the -framework linker flag?

Bad news if so...

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 2, 2014

Carthage setting up some workspace (like CocoaPods does) is not good either (imho).
P.S. Not sure which solution is worse.

dodikk commented Dec 2, 2014

Carthage setting up some workspace (like CocoaPods does) is not good either (imho).
P.S. Not sure which solution is worse.

@AlexDenisov

This comment has been minimized.

Show comment
Hide comment
@AlexDenisov

AlexDenisov Dec 2, 2014

I guess it's possible to strip 'redundant' archs for release build...

I guess it's possible to strip 'redundant' archs for release build...

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 2, 2014

Member

This is just an issue describing a bug that exists. It has not prescribed a solution, and we do not know what it will be yet.

Member

jspahrsummers commented Dec 2, 2014

This is just an issue describing a bug that exists. It has not prescribed a solution, and we do not know what it will be yet.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 2, 2014

I guess it's possible to strip 'redundant' archs for release build...

@AlexDenisov , are you talking about keeping fat frameworks and tweaking only the application an extension projects?

Do you know which flags exactly should be used?

  • STRIP_INSTALLED_PRODUCT
  • STRIP_STYLE = all
  • Anything else?

dodikk commented Dec 2, 2014

I guess it's possible to strip 'redundant' archs for release build...

@AlexDenisov , are you talking about keeping fat frameworks and tweaking only the application an extension projects?

Do you know which flags exactly should be used?

  • STRIP_INSTALLED_PRODUCT
  • STRIP_STYLE = all
  • Anything else?
@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 2, 2014

tweaking only the application an extension projects?

I'm afraid, such approach will not work since dynamic frameworks are copied to the application bundle as a whole. Unlike the static frameworks which are compiled into the application binary.

Which means that most likely we'll end up with two separate sets or artefacts (which is painful for both the users and the maintainers).

dodikk commented Dec 2, 2014

tweaking only the application an extension projects?

I'm afraid, such approach will not work since dynamic frameworks are copied to the application bundle as a whole. Unlike the static frameworks which are compiled into the application binary.

Which means that most likely we'll end up with two separate sets or artefacts (which is painful for both the users and the maintainers).

@mbuchetics

This comment has been minimized.

Show comment
Hide comment
@mbuchetics

mbuchetics Dec 4, 2014

This should be mentioned in the readme.

This should be mentioned in the readme.

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 4, 2014

Member

@mbuchetics We would appreciate a pull request to that effect!

Member

jspahrsummers commented Dec 4, 2014

@mbuchetics We would appreciate a pull request to that effect!

@DenHeadless DenHeadless referenced this issue in CocoaPods/CocoaPods Dec 6, 2014

Merged

Support for Frameworks / Swift #2835

13 of 15 tasks complete
@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 9, 2014

Member

This seems to work at least as a proof-of-concept, (not sure if I'm doing this right):

Instead of a Copy File phase, I've added this Run Script phase:

screen shot 2014-12-09 at 01 25 07

#!/bin/bash

copy_framework ()
{
    local framework=$1
    local frameworks_folder="${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"

    mkdir -p "$frameworks_folder"
    rsync -av "$framework" "$frameworks_folder"

    local file_path="$frameworks_folder/`basename $framework`/`basename $framework .framework`"

    if [[ ! "$VALID_ARCHS" =~ "$i386" ]];
    then
        lipo -remove i386 "$file_path" -output "$file_path"
    fi

    if [[ ! "$VALID_ARCHS" =~ "$x86_64" ]];
    then
        lipo -remove x86_64 "$file_path" -output "$file_path"
    fi
}

export -f copy_framework
Member

robb commented Dec 9, 2014

This seems to work at least as a proof-of-concept, (not sure if I'm doing this right):

Instead of a Copy File phase, I've added this Run Script phase:

screen shot 2014-12-09 at 01 25 07

#!/bin/bash

copy_framework ()
{
    local framework=$1
    local frameworks_folder="${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"

    mkdir -p "$frameworks_folder"
    rsync -av "$framework" "$frameworks_folder"

    local file_path="$frameworks_folder/`basename $framework`/`basename $framework .framework`"

    if [[ ! "$VALID_ARCHS" =~ "$i386" ]];
    then
        lipo -remove i386 "$file_path" -output "$file_path"
    fi

    if [[ ! "$VALID_ARCHS" =~ "$x86_64" ]];
    then
        lipo -remove x86_64 "$file_path" -output "$file_path"
    fi
}

export -f copy_framework
@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 9, 2014

Member

Unfortunately, codesigning/provisioning/app IDs/iTunes Connect is such a large clusterfuck that I can't even get into a place where I can validate a test application, so I'm unable to verify the original issue or any potential fix.

@robb How were you confirming that the resulting app can pass submission?

Member

jspahrsummers commented Dec 9, 2014

Unfortunately, codesigning/provisioning/app IDs/iTunes Connect is such a large clusterfuck that I can't even get into a place where I can validate a test application, so I'm unable to verify the original issue or any potential fix.

@robb How were you confirming that the resulting app can pass submission?

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

@robb Since you are doing lipo -remove , you don't seem to have found a way to use fat frameworks as is.
I guess, it would be more natural to not invoke the lipo create instruction during the build

This will require some changes in Carthage.build directory structure. And the users will integrate frameworks in a bit different way.

dodikk commented Dec 9, 2014

@robb Since you are doing lipo -remove , you don't seem to have found a way to use fat frameworks as is.
I guess, it would be more natural to not invoke the lipo create instruction during the build

This will require some changes in Carthage.build directory structure. And the users will integrate frameworks in a bit different way.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

@robb , @jspahrsummers , @AlexDenisov I have another idea that might solve this issue.

Signing a fat binary after lipo create

As far as I understand, this is what happens :

  1. The user creates a signed binary for iOS device
  2. lipo create takes only symbols and does not care of the signature.
  3. So the fat framework either lacks a signature or uses an incorrect one.
  4. ITunesConnect (or whatever) cannot verify the signature (or fails to verify it as the CRC of "device only" is different from the CRC of a "fat framework"

dodikk commented Dec 9, 2014

@robb , @jspahrsummers , @AlexDenisov I have another idea that might solve this issue.

Signing a fat binary after lipo create

As far as I understand, this is what happens :

  1. The user creates a signed binary for iOS device
  2. lipo create takes only symbols and does not care of the signature.
  3. So the fat framework either lacks a signature or uses an incorrect one.
  4. ITunesConnect (or whatever) cannot verify the signature (or fails to verify it as the CRC of "device only" is different from the CRC of a "fat framework"
@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

Basically, these instructions should be repeated after the lipoTask completion

CodeSign /Users/dodikk/Library/Developer/Xcode/DerivedData/ESLocale-euslyiudlfemxibysvpgrdcjoflb/Build/Products/Release-iphoneos/ESLocale.framework
    cd /tmp/1/Carthage.checkout/ESLocale
    export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/dodikk/projects/tools/git-tf/git-tf-2.0.2.20130214:/Users/dodikk/projects/tools/oclint/oclint-0.8.dev.d09e807/bin:/opt/X11/bin:/Users/dodikk/.rvm/bin"

Signing Identity:     "iPhone Developer: Chewbacca (arrraarrarrr)"

/usr/bin/codesign --force --sign BBBED9A55E1282613135A3FDB79F0F06461185C0 /Users/dodikk/Library/Developer/Xcode/DerivedData/ESLocale-euslyiudlfemxibysvpgrdcjoflb/Build/Products/Release-iphoneos/ESLocale.framework

dodikk commented Dec 9, 2014

Basically, these instructions should be repeated after the lipoTask completion

CodeSign /Users/dodikk/Library/Developer/Xcode/DerivedData/ESLocale-euslyiudlfemxibysvpgrdcjoflb/Build/Products/Release-iphoneos/ESLocale.framework
    cd /tmp/1/Carthage.checkout/ESLocale
    export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/dodikk/projects/tools/git-tf/git-tf-2.0.2.20130214:/Users/dodikk/projects/tools/oclint/oclint-0.8.dev.d09e807/bin:/opt/X11/bin:/Users/dodikk/.rvm/bin"

Signing Identity:     "iPhone Developer: Chewbacca (arrraarrarrr)"

/usr/bin/codesign --force --sign BBBED9A55E1282613135A3FDB79F0F06461185C0 /Users/dodikk/Library/Developer/Xcode/DerivedData/ESLocale-euslyiudlfemxibysvpgrdcjoflb/Build/Products/Release-iphoneos/ESLocale.framework
@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 9, 2014

Member

@jspahrsummers I've only checked the result .app using codesign -v but it turns out that we need to resign the frameworks after stripping, too. I've updated the script thusly:

#!/bin/bash

copy_framework ()
{
    local framework=$1
    local frameworks_folder="${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"

    mkdir -p "${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"
    rsync -av "$framework" "$frameworks_folder"

    local framework_path="$frameworks_folder/`basename $framework`"
    local file_path="$framework_path/`basename $framework .framework`"

    if [[ ! "$VALID_ARCHS" =~ "$i386" ]];
    then
        lipo -remove i386 "$file_path" -output "$file_path"
    fi

    if [[ ! "$VALID_ARCHS" =~ "$x86_64" ]];
    then
        lipo -remove x86_64 "$file_path" -output "$file_path"
    fi

    if [[ "$CODE_SIGNING_REQUIRED" -eq YES ]];
    then
        codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" --preserve-metadata=identifier,entitlements,resource-rules "$framework_path"
    fi
}

export -f copy_framework

I've then verified the app and the enclosed frameworks like so:

$codesign -v -v Test.app
Test.app: valid on disk
Test.app: satisfies its Designated Requirement
$codesign -v -v Test.app/Frameworks/LlamaKit.framework
Test.app/Frameworks/LlamaKit.framework: valid on disk
Test.app/Frameworks/LlamaKit.framework: satisfies its Designated Requirement
$codesign -v -v Test.app/Frameworks/ReactiveCocoa.framework
Test.app/Frameworks/ReactiveCocoa.framework: valid on disk
Test.app/Frameworks/ReactiveCocoa.framework: satisfies its Designated Requirement

That being said, codesigning being what it is, the ultimate proof would be a submission to Apple. I don't currently have a store app I could use as a guinea pig, maybe @soffes could do us the honor?

Member

robb commented Dec 9, 2014

@jspahrsummers I've only checked the result .app using codesign -v but it turns out that we need to resign the frameworks after stripping, too. I've updated the script thusly:

#!/bin/bash

copy_framework ()
{
    local framework=$1
    local frameworks_folder="${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"

    mkdir -p "${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"
    rsync -av "$framework" "$frameworks_folder"

    local framework_path="$frameworks_folder/`basename $framework`"
    local file_path="$framework_path/`basename $framework .framework`"

    if [[ ! "$VALID_ARCHS" =~ "$i386" ]];
    then
        lipo -remove i386 "$file_path" -output "$file_path"
    fi

    if [[ ! "$VALID_ARCHS" =~ "$x86_64" ]];
    then
        lipo -remove x86_64 "$file_path" -output "$file_path"
    fi

    if [[ "$CODE_SIGNING_REQUIRED" -eq YES ]];
    then
        codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" --preserve-metadata=identifier,entitlements,resource-rules "$framework_path"
    fi
}

export -f copy_framework

I've then verified the app and the enclosed frameworks like so:

$codesign -v -v Test.app
Test.app: valid on disk
Test.app: satisfies its Designated Requirement
$codesign -v -v Test.app/Frameworks/LlamaKit.framework
Test.app/Frameworks/LlamaKit.framework: valid on disk
Test.app/Frameworks/LlamaKit.framework: satisfies its Designated Requirement
$codesign -v -v Test.app/Frameworks/ReactiveCocoa.framework
Test.app/Frameworks/ReactiveCocoa.framework: valid on disk
Test.app/Frameworks/ReactiveCocoa.framework: satisfies its Designated Requirement

That being said, codesigning being what it is, the ultimate proof would be a submission to Apple. I don't currently have a store app I could use as a guinea pig, maybe @soffes could do us the honor?

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 9, 2014

Member

I think I prefer stripping invalids architectures as part of the copy process over having more specific build artifacts because the latter will only complicate matters with stuff like #6, where I assume the .framework we download will contain both x86 and arm code?

As far as I can tell, we still need a configuration-aware copy script either way.

Member

robb commented Dec 9, 2014

I think I prefer stripping invalids architectures as part of the copy process over having more specific build artifacts because the latter will only complicate matters with stuff like #6, where I assume the .framework we download will contain both x86 and arm code?

As far as I can tell, we still need a configuration-aware copy script either way.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

As far as I can tell, we still need a configuration-aware copy script either way.

Actually, if a non stripped but re-signed fat framework works and is App Store compatible (which also needs checking)... Why should your user bother with some sort of "Run Script" build phases?

I prefer stripping invalids architectures as part of the copy process

Okay, the binary will have some extra symbols. But is this gain worth the tradeoff for the carthage user's (iOS developer's) workflow complication? I mean, the application bundles with static linking do not use disk space optimally either.

dodikk commented Dec 9, 2014

As far as I can tell, we still need a configuration-aware copy script either way.

Actually, if a non stripped but re-signed fat framework works and is App Store compatible (which also needs checking)... Why should your user bother with some sort of "Run Script" build phases?

I prefer stripping invalids architectures as part of the copy process

Okay, the binary will have some extra symbols. But is this gain worth the tradeoff for the carthage user's (iOS developer's) workflow complication? I mean, the application bundles with static linking do not use disk space optimally either.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

I really enjoy the way carthage works now :

  1. carthage update
  2. Drag the framework to a proper build phase
    Profit.

And I'd really like things to remain the same. As long as it's possible to upload apps to the store.

dodikk commented Dec 9, 2014

I really enjoy the way carthage works now :

  1. carthage update
  2. Drag the framework to a proper build phase
    Profit.

And I'd really like things to remain the same. As long as it's possible to upload apps to the store.

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 9, 2014

Member

Actually, if a non stripped but re-signed fat framework works and is App Store compatible (which also needs checking)... Why should your user bother with some sort of "Run Script" build phases?

From what I understand of realm/realm-cocoa#1163, the x86_64/i386 part of the binary may contain symbols that aren't admissible to the iOS App Store. /cc @pietbrauer

Okay, the binary will have some extra symbols.

Comparing the size of the stripped and unstripped ReactiveCocoa.framework/ReactiveCocoa binaries, those make up roughly half of the size of the unstripped binary.

Member

robb commented Dec 9, 2014

Actually, if a non stripped but re-signed fat framework works and is App Store compatible (which also needs checking)... Why should your user bother with some sort of "Run Script" build phases?

From what I understand of realm/realm-cocoa#1163, the x86_64/i386 part of the binary may contain symbols that aren't admissible to the iOS App Store. /cc @pietbrauer

Okay, the binary will have some extra symbols.

Comparing the size of the stripped and unstripped ReactiveCocoa.framework/ReactiveCocoa binaries, those make up roughly half of the size of the unstripped binary.

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 9, 2014

Member

Of course, I don't see why Xcode couldn't strip all this for us as part of the Copy Frameworks phase, but I may be missing something.

Member

robb commented Dec 9, 2014

Of course, I don't see why Xcode couldn't strip all this for us as part of the Copy Frameworks phase, but I may be missing something.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

From what I understand of realm/realm-cocoa#1163, the x86_64/i386 part of the binary may contain symbols that aren't admissible to the iOS App Store.

The Realm.framework has been built by Carthage. Which did not sign the fat framework back then (neither it does now as far as I can see). My point was : "the reason of the app rejection may be not having x86 symbols but rather an improperly signed binary. "

dodikk commented Dec 9, 2014

From what I understand of realm/realm-cocoa#1163, the x86_64/i386 part of the binary may contain symbols that aren't admissible to the iOS App Store.

The Realm.framework has been built by Carthage. Which did not sign the fat framework back then (neither it does now as far as I can see). My point was : "the reason of the app rejection may be not having x86 symbols but rather an improperly signed binary. "

@neonichu

This comment has been minimized.

Show comment
Hide comment
@neonichu

neonichu Dec 9, 2014

Contributor

The Realm.framework has been built by Carthage.

Nope, it has its own build script: https://github.com/realm/realm-cocoa/blob/master/build.sh

Contributor

neonichu commented Dec 9, 2014

The Realm.framework has been built by Carthage.

Nope, it has its own build script: https://github.com/realm/realm-cocoa/blob/master/build.sh

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

I don't see why Xcode could strip all this for us as part of the Copy Frameworks phase

Xcode won't strip any dynamic stuff. However, it may be possible to ship an app with non-stripped frameworks in case they are signed properly.

P.S. That's just my guess, an idea to investigate

dodikk commented Dec 9, 2014

I don't see why Xcode could strip all this for us as part of the Copy Frameworks phase

Xcode won't strip any dynamic stuff. However, it may be possible to ship an app with non-stripped frameworks in case they are signed properly.

P.S. That's just my guess, an idea to investigate

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 9, 2014

Member

Which did not sign the fat framework back then (neither it does now as far as I can see).

Isn't this take care of by the Code Sign on Copy checkbox in the Copy Files phase? E.g.:

screen shot 2014-12-09 at 13 26 50

Member

robb commented Dec 9, 2014

Which did not sign the fat framework back then (neither it does now as far as I can see).

Isn't this take care of by the Code Sign on Copy checkbox in the Copy Files phase? E.g.:

screen shot 2014-12-09 at 13 26 50

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

Nope, it has its own build script: https://github.com/realm/realm-cocoa/blob/master/build.sh

But they have not signed it after lipo create either.
https://github.com/realm/realm-cocoa/blob/master/build.sh#L110

dodikk commented Dec 9, 2014

Nope, it has its own build script: https://github.com/realm/realm-cocoa/blob/master/build.sh

But they have not signed it after lipo create either.
https://github.com/realm/realm-cocoa/blob/master/build.sh#L110

@pietbrauer

This comment has been minimized.

Show comment
Hide comment
@pietbrauer

pietbrauer Dec 9, 2014

I built it using carthage alone. Not using the build.sh script.

I built it using carthage alone. Not using the build.sh script.

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 9, 2014

Member

Again, the error @pietbrauer got makes it look like the use of __bzero on iOS is already a no go:

Then there's still the artificial size inflation of the app

Member

robb commented Dec 9, 2014

Again, the error @pietbrauer got makes it look like the use of __bzero on iOS is already a no go:

Then there's still the artificial size inflation of the app

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

Isn't this take care of by the Code Sign on Copy checkbox in the Copy Files phase? E.g.

Not sure but it seems you're right and my idea is not helpful. Thanks for sharing the logs and the other discussion.

dodikk commented Dec 9, 2014

Isn't this take care of by the Code Sign on Copy checkbox in the Copy Files phase? E.g.

Not sure but it seems you're right and my idea is not helpful. Thanks for sharing the logs and the other discussion.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

the use of __bzero on iOS is already a no go:

I guess, this is an iOS example and it uses bzero() just fine. http://iphoneappcode.blogspot.com/2012/04/aes-encryption-and-decryption.html

Still not sure about this point and apple's error message.

dodikk commented Dec 9, 2014

the use of __bzero on iOS is already a no go:

I guess, this is an iOS example and it uses bzero() just fine. http://iphoneappcode.blogspot.com/2012/04/aes-encryption-and-decryption.html

Still not sure about this point and apple's error message.

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

Then there's still the artificial size inflation of the app

@robb, come on. Is it really that much critical? Application bundles are all about "wasting" the disk space for convenience. And statically linked applications are too. Just think of how many copies of the AFNetworking there are in your pocket at the moment (Across all the apps you have installed).

dodikk commented Dec 9, 2014

Then there's still the artificial size inflation of the app

@robb, come on. Is it really that much critical? Application bundles are all about "wasting" the disk space for convenience. And statically linked applications are too. Just think of how many copies of the AFNetworking there are in your pocket at the moment (Across all the apps you have installed).

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 9, 2014

Member

The issue is not with bzero() itself, which is of course a legal function call. The App Store validation seems to barf on (some?) non-ARM symbols. Again, since I can't get as far as validating an app, I can't confirm exactly what the issue is.

However, a few things are clear to me:

  1. This seems like Apple's bug, so there's a small chance it could get fixed in an Xcode update. We need to file a Radar if there's not one already.
  2. I would dearly like to avoid splitting built iOS frameworks into device and simulator binaries, because it makes everything more complicated. You'll get warnings on every build (because one or the other will be invalid for your current architecture), and it becomes more difficult to copy the binaries into the app bundle correctly.

So far, I think @robb's solution is the best available, at least while this bug exists in Xcode.

@robb Perhaps we could bundle this functionality into a new carthage command, so users' Run Script phases can just invoke carthage, and don't need to involve any custom scripting? We can do this by making use of the Input/Output Files stuff. Wanna start a PR?

Member

jspahrsummers commented Dec 9, 2014

The issue is not with bzero() itself, which is of course a legal function call. The App Store validation seems to barf on (some?) non-ARM symbols. Again, since I can't get as far as validating an app, I can't confirm exactly what the issue is.

However, a few things are clear to me:

  1. This seems like Apple's bug, so there's a small chance it could get fixed in an Xcode update. We need to file a Radar if there's not one already.
  2. I would dearly like to avoid splitting built iOS frameworks into device and simulator binaries, because it makes everything more complicated. You'll get warnings on every build (because one or the other will be invalid for your current architecture), and it becomes more difficult to copy the binaries into the app bundle correctly.

So far, I think @robb's solution is the best available, at least while this bug exists in Xcode.

@robb Perhaps we could bundle this functionality into a new carthage command, so users' Run Script phases can just invoke carthage, and don't need to involve any custom scripting? We can do this by making use of the Input/Output Files stuff. Wanna start a PR?

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

So, we (the users) will have to integrate using linker flags. Right?
OTHER_LDFLAGS=-framework ReactiveCocoa -framework MyXyzFramework

dodikk commented Dec 9, 2014

So, we (the users) will have to integrate using linker flags. Right?
OTHER_LDFLAGS=-framework ReactiveCocoa -framework MyXyzFramework

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 9, 2014

Member

@dodikk No. What makes you say that?

Member

jspahrsummers commented Dec 9, 2014

@dodikk No. What makes you say that?

@dodikk

This comment has been minimized.

Show comment
Hide comment
@dodikk

dodikk Dec 9, 2014

What makes you say that?

Sorry. I'm not getting how Xcode will know which framework (a stripped one vs. a fat one) to use (link, search for headers, etc.) Unless I take some explicit actions for this.

dodikk commented Dec 9, 2014

What makes you say that?

Sorry. I'm not getting how Xcode will know which framework (a stripped one vs. a fat one) to use (link, search for headers, etc.) Unless I take some explicit actions for this.

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 9, 2014

Member

It doesn't matter if it links against the fat binary and uses it for finding headers. The only problem that needs to be solved is the removal of embedded i386/x86_64 symbols from the App Store submission.

Member

jspahrsummers commented Dec 9, 2014

It doesn't matter if it links against the fat binary and uses it for finding headers. The only problem that needs to be solved is the removal of embedded i386/x86_64 symbols from the App Store submission.

@robb

This comment has been minimized.

Show comment
Hide comment
@robb

robb Dec 10, 2014

Member

Wanna start a PR?

I'm on it

Member

robb commented Dec 10, 2014

Wanna start a PR?

I'm on it

@pietbrauer

This comment has been minimized.

Show comment
Hide comment
@pietbrauer

pietbrauer Dec 17, 2014

Yeah, would make sense. Last time it went ok when the realm project was in my project.

Yeah, would make sense. Last time it went ok when the realm project was in my project.

@justinmakaila

This comment has been minimized.

Show comment
Hide comment
@justinmakaila

justinmakaila Dec 20, 2014

I have the latest of the script from @robb, and I've added

source "${SRCROOT}/Carthage.build/copy_framework.sh"

IOS_BUILD_DIR="${SRCROOT}/Carthage.build/iOS/"

copy_framework "$IOS_BUILD_DIR/Alamofire.framework"
copy_framework "$IOS_BUILD_DIR/Bolts.framework"
copy_framework "$IOS_BUILD_DIR/EmitterKit.framework"
copy_framework "$IOS_BUILD_DIR/FacebookSDK.framework"
copy_framework "$IOS_BUILD_DIR/Haneke.framework"
copy_framework "$IOS_BUILD_DIR/Nimble.framework"
copy_framework "$IOS_BUILD_DIR/PresentAPIClient.framework"
copy_framework "$IOS_BUILD_DIR/PresentPrePermissions.framework"
copy_framework "$IOS_BUILD_DIR/Quick.framework"
copy_framework "$IOS_BUILD_DIR/ReactiveCocoa.framework"
copy_framework "$IOS_BUILD_DIR/Swell.framework"
copy_framework "$IOS_BUILD_DIR/SwifteriOS.framework"
copy_framework "$IOS_BUILD_DIR/SwiftyJSON.framework"
copy_framework "$IOS_BUILD_DIR/Prelude.framework"

echo "Finished stripping architectures."

to a run script build phase, yet I keep getting

screen shot 2014-12-19 at 7 35 13 pm

archive log here

I have the latest of the script from @robb, and I've added

source "${SRCROOT}/Carthage.build/copy_framework.sh"

IOS_BUILD_DIR="${SRCROOT}/Carthage.build/iOS/"

copy_framework "$IOS_BUILD_DIR/Alamofire.framework"
copy_framework "$IOS_BUILD_DIR/Bolts.framework"
copy_framework "$IOS_BUILD_DIR/EmitterKit.framework"
copy_framework "$IOS_BUILD_DIR/FacebookSDK.framework"
copy_framework "$IOS_BUILD_DIR/Haneke.framework"
copy_framework "$IOS_BUILD_DIR/Nimble.framework"
copy_framework "$IOS_BUILD_DIR/PresentAPIClient.framework"
copy_framework "$IOS_BUILD_DIR/PresentPrePermissions.framework"
copy_framework "$IOS_BUILD_DIR/Quick.framework"
copy_framework "$IOS_BUILD_DIR/ReactiveCocoa.framework"
copy_framework "$IOS_BUILD_DIR/Swell.framework"
copy_framework "$IOS_BUILD_DIR/SwifteriOS.framework"
copy_framework "$IOS_BUILD_DIR/SwiftyJSON.framework"
copy_framework "$IOS_BUILD_DIR/Prelude.framework"

echo "Finished stripping architectures."

to a run script build phase, yet I keep getting

screen shot 2014-12-19 at 7 35 13 pm

archive log here

@justinmakaila

This comment has been minimized.

Show comment
Hide comment
@justinmakaila

justinmakaila Dec 20, 2014

Never mind, it looks like I missed one of my frameworks in the build phase script.

Can't wait for the automation!

Never mind, it looks like I missed one of my frameworks in the build phase script.

Can't wait for the automation!

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 20, 2014

Member

It won't really be automated at any point—just easier.

Member

jspahrsummers commented Dec 20, 2014

It won't really be automated at any point—just easier.

@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Dec 22, 2014

Member

The workaround merged in #208 will be released with 0.4. See the updated README section for usage instructions.

Member

jspahrsummers commented Dec 22, 2014

The workaround merged in #208 will be released with 0.4. See the updated README section for usage instructions.

@dreambt

This comment has been minimized.

Show comment
Hide comment
@dreambt

dreambt Feb 26, 2015

Not work.
Must execute above, why?

lipo -remove i386 Carthage/Build/iOS/Base32.framework/Base32 -output Carthage/Build/iOS/Base32.framework/Base32
lipo -remove x86_64 Carthage/Build/iOS/Base32.framework/Base32 -output Carthage/Build/iOS/Base32.framework/Base32

dreambt commented Feb 26, 2015

Not work.
Must execute above, why?

lipo -remove i386 Carthage/Build/iOS/Base32.framework/Base32 -output Carthage/Build/iOS/Base32.framework/Base32
lipo -remove x86_64 Carthage/Build/iOS/Base32.framework/Base32 -output Carthage/Build/iOS/Base32.framework/Base32
@jspahrsummers

This comment has been minimized.

Show comment
Hide comment
@jspahrsummers

jspahrsummers Feb 26, 2015

Member

@dreambt Please open a new issue, and detail exactly what you've tried, and what's not working about it. We can't help unless you provide more information.

Member

jspahrsummers commented Feb 26, 2015

@dreambt Please open a new issue, and detail exactly what you've tried, and what's not working about it. We can't help unless you provide more information.

@ricardolpd

This comment has been minimized.

Show comment
Hide comment
@ricardolpd

ricardolpd Jul 22, 2015

hi guys, i am looking into using carthage for a set of frameworks i am building for my employee, is this issue still an issue?

hi guys, i am looking into using carthage for a set of frameworks i am building for my employee, is this issue still an issue?

@ikesyo

This comment has been minimized.

Show comment
Hide comment
@ikesyo

ikesyo Jul 22, 2015

Member

is this issue still an issue?

I think so. At the time of Xcode 7 GM, it might change or not. 😅

Member

ikesyo commented Jul 22, 2015

is this issue still an issue?

I think so. At the time of Xcode 7 GM, it might change or not. 😅

@pietbrauer

This comment has been minimized.

Show comment
Hide comment
@pietbrauer

pietbrauer Jul 22, 2015

It is not an issue anymore (that's why this issue was closed), I am successfully submitting apps that contain carthage built frameworks to the AppStore.

It is not an issue anymore (that's why this issue was closed), I am successfully submitting apps that contain carthage built frameworks to the AppStore.

@ricardolpd

This comment has been minimized.

Show comment
Hide comment
@ricardolpd

ricardolpd Jul 22, 2015

@ikesyo so how do you guys work around it? build two framewoks a fat one and a non-fat one and switching with a script??

@ikesyo so how do you guys work around it? build two framewoks a fat one and a non-fat one and switching with a script??

@ikesyo

This comment has been minimized.

Show comment
Hide comment
Member

ikesyo commented Jul 22, 2015

@ikesyo

This comment has been minimized.

Show comment
Hide comment
@ikesyo

ikesyo Jul 22, 2015

Member

I think so.

This is about the Xcode/App Store submission bug to which @jspahrsummers referred above: #188 (comment).

Member

ikesyo commented Jul 22, 2015

I think so.

This is about the Xcode/App Store submission bug to which @jspahrsummers referred above: #188 (comment).

@ricardolpd

This comment has been minimized.

Show comment
Hide comment
@ricardolpd

ricardolpd Jul 22, 2015

ikesyo, sorry i never got around reading the section of the readme file about the script. thanks it makes sense now

ikesyo, sorry i never got around reading the section of the readme file about the script. thanks it makes sense now

@ikesyo

This comment has been minimized.

Show comment
Hide comment
@ikesyo

ikesyo Jul 22, 2015

Member

No worries!

Member

ikesyo commented Jul 22, 2015

No worries!

@1ec5 1ec5 referenced this issue in mapbox/mapbox-gl-native Dec 4, 2015

Merged

Convert iOS SDK into dynamic framework #3183

@adammendoza

This comment has been minimized.

Show comment
Hide comment
@adammendoza

adammendoza Sep 19, 2016

I'm using Carthage for AFNetwork and I also have to uncheck Include app symbols for your application to receive symbolicated crash logs from Apple.

I'm using Carthage for AFNetwork and I also have to uncheck Include app symbols for your application to receive symbolicated crash logs from Apple.

@izouxv

This comment has been minimized.

Show comment
Hide comment
@izouxv

izouxv Nov 9, 2016

add shell after copy framework section
cartool strip -v $EXPANDED_CODE_SIGN_IDENTITY -a $METAL_LIBRARY_OUTPUT_DIR -os $PLATFORM_NAME
this will remove all debug info
cartool at github.com/izouxv/cartool

izouxv commented Nov 9, 2016

add shell after copy framework section
cartool strip -v $EXPANDED_CODE_SIGN_IDENTITY -a $METAL_LIBRARY_OUTPUT_DIR -os $PLATFORM_NAME
this will remove all debug info
cartool at github.com/izouxv/cartool

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment