We are trying to supply one of our clients with an ipa to deploy on their AirWatch. There is a lot of conflicting information on what is the best way to do that, but they all seem to agree on the fact that it needs to be signed with the certificate and private keys of some account. However, the client seems to be managing their apple enterprise account through AirWatch. Does this mean that we could supply them with an unsigned ipa file and let AirWatch do its thing?
I have been scouring the internet for a while for this information and the closest ones are similar to Renew iOS Development and APNs Production for Corporate Apps [AirWatch] which is not what i was looking for
No - AirWatch does not re-sign anything IPA-wise. It can interrogate your IPA to make sure you're not trying to accidentally update App A's IPA with the IPA for App B but that's about it.
The link you provided has nothing to do with re-signing applications within AirWatch as much as it is the general practice for renewing your Enterprise Apple Developer Cert and Provisioning Profiles.
If you try to deploy an unsigned IPA to a device not in your Developer Portal you will likely run into an issue where the app will begin installation then throw an error that it cannot be installed.
Regarding what your client is doing there may be some confusion as AirWatch does not directly tie back to the Apple Developer Portal except for the MDM APNs cert which is unrelated to IPAs.
It depends on how sophisticated AirWatch's re-signing is. A good re-signer, should be able to take anything, re-sign it AND add the correct entitlements.
That said, in Xcode unsigned feels like an unsupported path - so my conservative approach is to sign a production build of the app (Ad Hoc, Enterprise or even AppStore if that makes sense) with its entitlements being as similar as possible to those of the final app's. If the app entitlements are simple (e.g. push notifications only), then this is the way to go.
But there's a problem: matching client entitlements has recently become harder, in part due to the proliferation of App Groups (which require an explicit, globally unique App ID - thanks, Apple Watch!), so your unsigned suggestion is starting to look more attractive.
Airwatch only resigns IPAs if you wrap it with their App Wrapper, because it will alter the original IPA and invalidate the Signature.
You have to provide both the Certificate and the Provisioning Profile to allow that.
If the IPA has to be signed with the Enterprise Certificate of your customer, you either require access to their Member Center or let them do it.
Apps like AppSign or iReSign can do that for you or your customer, if you provide them with the IPA.
Related
We have a series of iOS Enterprise applications that were built with Telerik Cordova (discontinued in May 2018). Those apps are in the process of being converted to a new platform, but in the mean time they must continue to service client needs.
The distribution certificate the apps were built with is valid for another 14 months or so, but the provisioning profiles expire in a few days. Since these are Enterprise apps they will expire with the profiles.
Unfortunately, Telerik can no longer rebuild the apps using an updated profile for us. We have re-signed the apps using new provisioning profiles (using both iReSign and Terminal). When we try to side-load the resulting IPAs through the XCode Devices panel, we get an error stating that the entitlements do not match and the apps are not installed.
The question was raised as to whether or not we not need to re-sign the apps since the certificates are still valid. Perhaps it would be possible to just replace the .mobileprovision file on the device somehow? I gave it a try using iTunes Sync but I cannot confirm whether the file actually went to the device or not.
Question: Is it possible to just update the *.mobileprovision on the device without re-signing the app? If so, could someone please give me the steps or direct me to a link to perform the steps?
Alternate Question: Otherwise, any thoughts on how to resolve my Entitlements issue? The app only needs Push Notifications, but Game Center and In-App Purchases are also enabled. These are reflected in the App ID and provisioning profile, and the distribution certificate is of type Apple Push Services.
I should point out that I am not an admin on the Apple Developer portal for the project as I am an outside consultant, so my portal access is strictly read-only.
Thanks in advance for any direction provided!
If the applications were distributed to the devices by an MDM, then you can push a new provisioning profile to them using the MDM.
If the applications were installed over the air from a web server or directly using iTunes or Apple Configurator, then you need to replace the entire application package on the device. This requires the app to be re-signed, since the changed .mobileprovision file will change the package signature.
If you don't have the original, app ID with matching entitlements in the developer portal, then you will need to delete the existing application from the device before installing the new, re-signed application. You won't be able to do an in-place upgrade.
Recently I saw a website that include lots of AppStore applications and they resigned that applications via their Enterprise account and let people to download them directly to their iPhone/iPads.
I am wondering how they do this? I had resigned .ipa files that was created for Ad-Hoc via Enterprise; but how they resign AppStore applications with enterprise account too?
I am wondering for the answer because it is important and we should consider more security challenges for the case of resigning our appstore applications with enterprise accounts.
When an IPA is downloaded from the app store (including by Xcode), the binaries in that IPA are encrypted by Apple. Simply resigning these binaries will not work. One way to remove the DRM, and this may be illegal in your country, is to extract the unencrypted binary during runtime on a jailbroken device.
Note that when resigning apps, such services need to use a different provisioning profile than you originally used, and that provisioning profile will have a different bundle identifier than the one in your Info.plist. You can use tools such as TCMobileProvision to inspect and compare the two identifiers. This is a mouse and cat game, as they could actively look for that code and remove it statically, but you will most likely reduce the possibility of your app being resigned significantly.
Adding on to Leo's answer:
There are tools available such as Clutch to help decrypt the Apple signed binary on a jailbroken device at runtime. After decrypting the binary, you will need to figure out the app's bundle id and entitlements. Some versions of Theos (such as theos-jailed) come with an info tool that dumps the application entitlements. When regenerating your patched provisioning profiles, you must be sure your patched profile match the entitlements of the original profile used by the target app.
Everything after the decryption step can be accomplished without a jailbroken device. A jailbreak is required to remove the AppleFairplay DRM by dumping/decrypting the signed app by patching into the device's runtime.
There is a lot of information about iOS distribution. I think I understand the different distriubution models, but I am looking for best practice for distributing an app to a client.
I have a client who has an Enterprise developer account and uses AirWatch for MDM. Here is how I am going to recommend to them that we distribute the app to their organization since they have no one technical on staff that has any experience with Xcode or iOS development and they will not be given access to the source code:
Add me as a member of their developer account
I build the app using their certificate
I give them the .ipa and plist file to distribute either through MDM or website.
Is this the correct way to do this? What if I am going to sell this same app to three clients - would I do it a different way? Is there anything else that needs to be done to distribute through AirWatch?
Again, looking for best practice and how others are handling this situation. Please clarify if I have anything wrong.
UPDATE: Thank you all for the answers. From what I have learned how this is done depends directly on how the client wants to handle the situation. In the end the client added me as an admin on their account (we have worked together quite a bit). I was able to create the distribution profile, build, and deploy the app to them. Not all clients will do this for security reasons. In that case, they will need to provide you will a cert as stated below, or you will need to build the app on one of their machines as Buckeye said below...or go through Apple to distribute the app to them.
Feel free to correct any of this info if it is incorrect. I really think this is helpful information for a lot devs.
I am accepting Patrick's answer because it is the closest to what I actually did.
There are two ways you can do this, but for both you must be added as a member of your client's developer team. Once you have done this, you (or more likely your client) will choose weather to use their in-house certificate or your own distribution certificate that you will manage.
It can be done either way, it is only a matter of who will have authority in the future to submit apps with the same certificate under the same account. That authority resides in the possession of the associated key pair of the certificate. If you are added to the client's dev team and download their distribution certificate, you will NOT have this key and cannot sign distribution builds with associated provisioning profiles.
Therefore, you must either get a .p12 export of the certificate (which contains the key) from the client to install on your machine so that you may sign with it. This will allow you to submit from your machine, but you are then in possession of your clien'ts private key, which they would like to protect. Your other option is to use your own Certificate Signing Request to create a Distribution Certificate on the client's developer account. In this situation, only you have control over the certificate and the client must create new ones if they wish to work with other developers in the future.
Once you have done that, here is an informative guide for enterprise distribution.
As an Enterprise Agent I will tell you that unless your client lives under a rock (technically speaking regarding the Apple dev portal) I doubt they're going to give up the private key and cert. If they have zero legal/contractual access to the source code you've created the only course of action, speaking from experience, would be for you to visit their facility with the source code, compile it on their box that houses the private key & enterprise distribution cert, build & deliver the IPA and finally take the source back with you. That is how I have compiled every build with a 3rd party vendor where we don't own the source and need to deploy internally.
On the flip side of this argument if the client is, for some wild reason, willing to give up the keys to their enterprise castle and export the private key & enterprise distribution cert for you to use... for YOUR sake I would get in writing what the scope of your usage is with that cert and somehow document the fact you have deleted the key & cert after the process is over. Don't open yourself up to liability because if they share it with you there's a chance they may also share it with someone else and as we all know, not all development entities play by the rules. You wouldn't want to get accused of creating some rogue app under their name.
Regarding re-signing the IPA file... AirWatch won't let you do it. AW interrogates the IPA when you upload it and it will note that the embedded provisioning profile doesn't match the re-signed IPA and tank. It becomes a chicken & egg situation where you need the provisioning profile on the device before you install the app however AirWatch won't let you deploy the app unless the aforementioned embedded profile is correct.
Also, #Caleb is correct regarding B2B but the pricing model goes from the project to per-seat (iOS device). In other words if your contract is "you can install this app on an unlimited number of devices" the B2B approach is going to blow up in everyone's faces.
EDIT:
Below are your options when editing a Development Provisioning Profile in an Enterprise iOS Account:
Obviously here you can pick & choose developers and their devices from within the portal that can compile to that profile.
Now here are your "options" for editing the Enterprise Provisioning Profile:
As you can see you don't get an option to edit which portal users or devices can use this profile because it's tied to the Agent's CSR/private key and is deployed globally.
You would need:
Their certificate.
Their provisioning profile.
It's a quite common practise to do this.
My question is, is this the correct way to do this?
Yes.
What if I am going to sell this same app to 3 clients, would I do it a different way?
No, you'll do the same thing. You'll need to build the app separately for each client using each client's distribution certificate.
Another option is to build the app and sell it to your clients using the B2B distribution mechanism.
I am in the following situation: We have an enterprise developer account and for an app we are working with an external developer.
At the moment we do not have access to the source code so we can't make builds, but we still need to have weekly builds that can be installed on devices... therefore the external developer needs to be able to build ipa files.
The developer is now a member of the developer program and has their own developer certificate. However, there can only be one distribution certificate.
From a security point of view, is it safe/recommended for us to share the distribution certificate (and the private key) and a provisioning profile so they can build ipa files?
Are there any other (safer) choices?
PS: I was also thinking that we could resign an ipa with our distribution certificate but it still leaves us in the situation where they need to be able to build an ipa - and this is only possible with a distribution certificate + provisioning installed.
You can have your external developer to sign with whatever he wants and then you can re-sign the IPA and use it. This way the source code is "safe" in the developer's perspective and you can use your IPA signed with your certificate. I normally use this, but you can do it in the command line too...
As for your Post Scriptum part, that's not true... I have the experience of working with external agencies where they use their own certificate and provisioning and when I receive their IPA I only need to re-signed it.
They can be responsible for creating their own profile, and you can simply send them your p12 key (no big deal). You can also just give them the distribution certificate.
To be honest, I've never been in a situation where an employer or contractor was hesitant to give me their certificate & p12 file. So I've never thought much of it!
We have had a number of apps built by a 3rd party developer. I cannot remember how this was done in the past, but they have just updated 2 of our apps to work correctly with iOS 5.x
The agreement is that they will build and sign the files ready for us to upload to iTunes. We cannot build the code as the agreement doesn't include the source.
I have sent them the Distribution Provisioning Profile (.mobileprovision) but they have asked for the "Certificate for Keychain access"
Perhaps I am being overly cautious, but am I right in thinking I need to export my Developer Certificate as a .cer file and email that to them? We do trust the company, but is this the correct way to do things? Is it allowed by Apple?
The 3rd party have no access to our accounts (developer centre / iTunes connect) and we have no access to the source code.
Thank you
If they're going to build things as you, they'll need your certificate and private key as well as the provisioning profile. I don't think there's any way round that if they're going to do the building and code-signing.
I think it's a fairly typical way to do things, in a situation where the client has the dev account but the developer owns the source.
Even if the development company did have access to your iTunes account, you'd still need to send them the private key that your certificate was created with.
Not tried it myself, but seems like there is a way to re-sign the binary (IPA file). Check this link It uses a utility called iReSign