Resigning an app

Question

I know there's a bunch of questions out there about this but most of the solutions either haven't worked for me or are obsolete.

I work for an app vendor - usually our customers provide us with their certificates and profiles so we can do the app submission for them. I have one customer who does not want to do so for security reasons, and is asking for an unsigned IPA that they can resign themselves and submit.

... is there a non-hacked way to do that? I managed to create an unsigned IPA and resign it but I can't install it on device as I get a message that its integrity could not be verified. If I run codesign -f -s with the appropriate cert it passes. But then if I try to verify it with code sign -v I get no identity found.

security find-identity gives me almost 9 valid identities.

Anyone do this successfully in the past year? Does the provisioning profile need to be a specific type(adhoc vs App Store). I used an adhoc profile with a device that I verified is in the profile.

Is it a matter of exporting an xcarchive from Xcode and giving it to them? Should that archive be signed with my own stuff and then they can resign?

Code Signing

5.9k

Posted by

abushnaq-work

Reply

Add a Comment

Answer 1

Would it be possible to do the following

An Xcode archive is just a directory full of files. It’s possible to monkey with it however you like. What you’re really asking here is whether that’s supported, and the answer is “No, that’s not supported.” It’ll probably work (at least it did the last time I tried it :-) but the supported path is for your customer to add you to their team.

Keep in mind that the Xcode archive is only part of this problem; you also have to worry about App IDs. An App ID consists of a prefix, typically the Team ID, and a bundle ID. The developer web site ensures that the App ID is unique as a whole but also that the bundle ID is unique. If your customer wants to ship the app, their team must ‘own’ its bundle ID. However, if you want to develop the app then your team must own that very same bundle ID. You can get around this by monkeying with the bundle ID of the app in the Xcode archive but that gets really ugly really fast.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 2

I have one customer who does not want to do so for security reasons

That is a wise customer IMO.

is there a non-hacked way to do that?

Yes. Well, not exactly that, but something that achieves the same goals. The approach I recommend is:

The customer maintains their own developer account and signing credentials in Xcode.
You ship them an Xcode archive.
They add that to their Xcode Organizer.
They submit from there.

This avoids the gnarly business of trying to re-sign an .ipa. When they submit from the Organizer, they use exactly the same signing process that you would have used.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 3

Hi @eskimo

Thank you for your response. So to make sure I understand the workflow:

1) My release bundle ID should match what they would use
2) From Xcode select archive
3) From the organizer select the app and pick distribute
4) pick App Store connect for method of distribution
5) Select export for destination
6) This is where I get stuck. It asks me for a certificate and profile. Is that because I need to change my project to not require signing? Or should I use my release bundle ID, cert, and profile in this process?

If I need to change my project to not require signing how do I do that?

Posted by

abushnaq-work

Add a Comment

Answer 4

My release bundle ID should match what they would use

Yes. And you’ll want to have them invite you to their team so that you can work with that App ID. They should, of course, set up the permissions so that you can’t release software on their behalf.

From the organizer select the app and pick distribute

No, you’re off in the weeds here. This is what your customer would do. What you do is:

Choose Product > Archive.
Select the archive in the Organizer.
Control click on it and select Show in Finder.
Zip up the .xcarchive directory and send it to your customer.

They can unpack it, add it to their Organizer, and distribute the app from there.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 5

Hi @eskimo

Thank you for your answer. There's even a hesitation to invite me to their team at the moment. Would it be possible to do the following: Use my own AppID and create the xcarchive, send it to them, have them replace the info.plist that's in the xcarchive with their own and distribute the app from there?

Posted by

abushnaq-work

Add a Comment

Answer 6

Would it be possible to do the following

An Xcode archive is just a directory full of files. It’s possible to monkey with it however you like. What you’re really asking here is whether that’s supported, and the answer is “No, that’s not supported.” It’ll probably work (at least it did the last time I tried it :-) but the supported path is for your customer to add you to their team.

Keep in mind that the Xcode archive is only part of this problem; you also have to worry about App IDs. An App ID consists of a prefix, typically the Team ID, and a bundle ID. The developer web site ensures that the App ID is unique as a whole but also that the bundle ID is unique. If your customer wants to ship the app, their team must ‘own’ its bundle ID. However, if you want to develop the app then your team must own that very same bundle ID. You can get around this by monkeying with the bundle ID of the app in the Xcode archive but that gets really ugly really fast.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Resigning an app

Accepted Reply

Replies