Code signing problems due to Apollo framework

[stephensilber]

Code signing problems due to Apollo framework

[maxsz]

I've created a pull request which should fix this for Cocoapods and Carthage.

[stubailo]

Interesting, is there anything we can do to make this work out of the box?

[maxsz]

@stephensilber What was wrong with the codesigning? Can you provide the output of codesign -dvvv <IPA>?

[stephensilber]

I haven't had a chance to look into this, but I'll be submitting another build either today or tomorrow and will make note of anything that may be useful, including the output of codesign -dvvv <IPA>

[martijnwalraven]

@stephensilber: Did you find out anything more about this?

[stephensilber]

@martijnwalraven to work around it, I have been manually removing the custom build phase run script and the check-and-run-apollo-codegen.sh script from the Apollo target before archiving. I just left both of those there to test this. I archived a build and then exported it as an IPA for distribution, and here's the ouput for the command you mentioned above:

➜  Verse 2016-11-18 12-32-28 codesign -dvvv Verse.ipa
Verse.ipa: code object is not signed at all

Sorry for the late response. Let me know what else I can help do to debug this on my end

[fruitcoder]

Holy ****. I was also fighting with codesigning today for a TestFlight submission and got the same error, which didn't give me any clue what was going wrong. I will try to remove the run script, but that's probably not sufficient. I'm using Carthage, so I really don't know how to automate this 🤔

[stephensilber]

Can that .sh script be moved into the build phase run script* so it's not a piece of
the Apollo project? Not the most ideal solution due to updates maybe needing
to change that script, but there could be a version check that points to an
updated script? Still somewhat manual, but only when the framework changes
the script.

**fixed some typos from posting this on mobile

On Mon, Nov 21, 2016 at 2:31 PM Alex Hüllmandel [email protected]
wrote:

Holy ****. I was also fighting with codesigning today for a TestFlight
submission and got the same error, which didn't give me any clue what was
going wrong. I will try to remove the run script, but that's probably not
sufficient. I'm using Carthage, so I really don't know how to automate this
🤔

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzmuUa1SpUqetd1cnk08_QzXs3KdRxdks5rAfGpgaJpZM4KqTdI
.

[fruitcoder]

I'm still unsure how to tackle this and I have no reference project to look into.
Updating carthage, manually deleting the install-or-update-starwars-server.sh and copying check-and-run-apollo-codegen.sh over to my target + customizing the run script fixed the signing issue, but it's rather cumbersome.
Copying the script directly in the run script phase sounds like an idea, but didn't you also have to delete the install-or-update-starwars-server.sh to make signing work?

[maxsz]

I think the correct way to not have check-and-run-apollo-codegen.sh added to the app bundle by cocoapods is to change the podspec from

[...]
s.resource = 'scripts/check-and-run-apollo-codegen.sh'
[...]

to

[...]
s.preserve_path = ''scripts/check-and-run-apollo-codegen.sh'
[...]

Thus preserving the check-and-run-apollo-codegen.sh file, so people can run it in a build phase, but not adding it to the target app bundle.

@stephensilber can you try that and see if it helps?

Update:
I've just created a new minimal test project with Apollo and there are no codesigning issues at all. I can't think of any reason why the check-and-run-apollo-codegen.sh script should break codesigning, it's just a resource in the framework, which is build before any codesigning steps.

The above comment is still valid, though, because I don't think we want to ship this script in the released app IPA.

[fruitcoder]

If the script wasn't in the targets I could also reference it through the Carthage/Checkouts directory without any extra setup after updating dependencies.

[martijnwalraven]

I came across this, so it seems it is a known issue and affects other frameworks as well.

Not sure yet what the root cause is and whether there are any workarounds that don't involve removing the script from the bundle.

[fruitcoder]

Yeah, I read the same thing :)
In the end, I will have a custom action in fastlane that could remove the script before uploading to iTC, but we should look for a solution that works for everyone.

[nubbel]

Not sure about Carthage, but for Cocoapods the solution is what @maxsz suggested.
Using preserve_path instead of resource prevents that the script ends up in the bundle.

[fruitcoder]

Yeah, this definitely works for Cocoapods

[nubbel]

We've figured it out!
@maxsz is preparing a PR right now that fixes this issue for both Cocoapods and Carthage.