Releasing an iOS app developed by a third party

I work for a company that has a few apps in the store that me and my team develop and maintain. However, they now want to also release a handful of apps developed by third parties.

They have tasked me with finding out what the best way to do this is. But I am having a really hard time finding even a single method that is supported by Apple.

So far I have mostly focussed on:

Having them build an ipa/xcarchive and sign it with a dev certificate, them sending the ipa/xcarchive to me and me resigning it with our distribution certificate I have tried to do this with our own app, but I get dozens of signing errors when I try to transport it to TestFlight.

Adding some from the external developers to our Team in AppStoreConnect and having them upload a build signed with a dev certificate. Followed by us somehow promoting this dev build to a production build. So in essence this would mean resigning the app inside AppStoreConnect; I don’t know if this is possible. But it would be a nice solution. I have read some forum posts hinting at this, but I haven’t been able to find any documentation on it.

Giving the external developers our distribution certificate (and ipa key); This has been all but ruled out by the company, for fear of it leaking and messing with our main apps.

Having the external developers provide me with access to their source code, so that I am in control of the whole build process and can do so with the right certificates. Understandably, the external developers don’t want to give us access to their source code.

Can someone advise me on a way forward? We would strongly prefer a way that is supported by Apple, where we don’t have to make any compromises on security with regards to certificates and keys.

Thanks in advance!

You might find it useful to read @eskimo's recent comment on this thread:

I work for a third party company that provides apps on behalf of other companies and have not found any easy solution to this.

What we have been doing is building an archive using their developer profiles/certificate (which they have to provide us with) and then they sign it for distribution using their distribution profile/certificates.

This means we have the ability to build and run the app but we don't have the ability to publish it nor have access to their Apple account.

However, the downside of this is, during the development and testing process before the archive is delivered, we can only build/install the app on phones if they are registered with Apple. And the limit for this is 100. The company we provide the app for is a very large well known company who have quite a lot of publishes apps and therefore Apple's limit of 100 development phones is too small, we have managed to get a couple of our phones registered with their Apple account, however our team of developers and testers and not to mention it needs testing on a wide range of devices means this is unsatisfactory.

So what we decided to do is have two versions of the app - create two workspaces which are identical to each other and share the same source code. The only difference being one of the apps has an apple bundle id registered to our Apple account and signing is automatic with our developer profiles, and the other workspace has an apple bundle id registered to the other company and signing is manual using their developer profiles.

Then for development and testing everything is done using the app registered to our Apple account, and it can be installed/run on as many iPhones as we want. Then when its time for a release to be made, as a final sanity check the app with their bundle id can be installed and tested on one of the iPhone registered to their Apple account before an archive of that app is build and given to them.

Releasing an iOS app developed by a third party
 
 
Q