We have distributed more than 50 iOS applications using a iOS Distribution Certificate (in-house, internal use apps).The apps are in house apps and distributed through our MDM solution. The iOS Distribution Certificate is going to be expire soon. When we checked the expiry of iOS Distribution Certificate in apple documentation, we got following information.
iOS Distribution Certificate (in-house, internal use apps)
Users will no longer be able to run apps that have been signed with this certificate. You must distribute a new version of your app that is signed with a new certificate
As the apps are used in many stores real time, if we are sign the app with new certificate and then we need to re distribute it and will affect all the internal network. We are thinking to move the update on a nightly time. Can you suggest any solution other than this?
You should talk to your MDM vendor regarding deployment strategy. The topics on Stackoverflow are intended to be more technical in nature. Your vendor will have a lot more experience than you on this and should be able to provide best practices to you. There are many factors involved: network capacity, devices online/offline, etc.
Related
I support a handful of enterprise iOS apps that are distributed using AirWatch MDM. Initially, the first couple of apps were distributed all sharing the same wildcard provisioning profile.
We recently rolled out a series of apps that used the App Group capability which could not use the wildcard profile so each app created its own provisioning profile.
We have run into a couple of issues with these new apps now that the profiles are expiring. Trying to distribute the new profile via AirWatch has been unsuccessful and the only thing that has a worked for us is to deploy a new app update. I worry this approach is not really sustainable as some of these apps likely will not be updated within a year or 2 of profile updates.
I have a couple of questions from an Airwatch/MDM consulting perspective:
Is it best practice to have each app in an enterprise format have its
own profile or share profiles if possible?
Is it possible to distribute a profile with capabilities remotely?
When the certificate expires, is there anyway to fix the apps without
updating every app across the enterprise using the expiring
certificate?
Can I revoke the active certificate that is used for internally published apps prior to the expiration date without impacting them?
From a certificate administration perspective, should we create a shared Apple ID with a generic login or tie it to one particular developer?
We have very few apps now but it has become a bit of a support issue each time these expiration dates roll around and I feel like there has to be a better way for an enterprise to manage this that has hundreds of internal apps.
Is it best practice to have each app in an enterprise format have its
own profile or share profiles if possible?
Yes. I always use a specific provisioning profile for every app I manage. Using wildcard may seem easier, and it takes more time to set up every single profile, but it's more manageable.
Is it possible to distribute a profile with capabilities remotely?
Yes, but distributing the new profile via Airwatch doesn't always work.
It's rather a problem of signing more than capabilities
If the new provisioning profile is signed with the same distribution certificate, pushing it via AirWatch may work. But sometimes it won't and the user will have to manually remove and reinstall the app.
If the new profile uses a new certificate the apps will NOT receive the update. Don't trust airwatch's information about app expiration in the apps list!
My advice is to create a new version of the app and sign the IPA with the new provisioning profile, then release it as an update.
And additional advantage is that you'll keep track of who has the older version (which will stop working when the profile expires) while the new version will work just fine.
When the certificate expires, is there anyway to fix the apps without updating every app across the enterprise using the expiring certificate?
No, I usually increase the version number, create a new IPA, re-generate the provisioning prodile, use it to sign the IPA, and distribute the app as an update using AirWatch.
Can I revoke the active certificate that is used for internally published apps prior to the expiration date without impacting them?
No, if you revoke a certificate every app that uses it will stop working.
Source: https://help.apple.com/developer-account/#/dev7d381a7ff
See Apple documentation on managing expired certificates, it's long but exaustive.
From a certificate administration perspective, should we create a shared Apple ID with a generic login or tie it to one particular developer?
Use roles. The team Agent is the admin of the account and is used only when you have to accept new TOS, renew the membership, etc.
Set up developer accounts (I prefer one for each developer, so that everyone has it's own developer certificate) and make the team leader admin of the develoepr account.
This way the team leader can set up the apps for the deploy while the developer will focus on coding.
I understand it may seem complex, but once you get used to this structure you'll appreciate how manageable it is, and usually the team leader can manage many developer accounts with little work.
Supporting your mobile apps, releasing updates to follow new iOS releases and bug-fixing are time-consuming activity. And so is maintaining certificates and deploying apps. You should charge your customer for these services too, if you make B2B
For implementing a app like Kidslox or Screen Time and I need to make use of MDM server. I went through various blogs for creating or setting-up the MDM server and for that MDM certificate is required. But I'm not getting the MDM CSR option while creating a new certificate.
I already have the Apple's Developer account so my biggest question is that:
Do I really need to signup for the Apple's Enterprise Program?
This answer says that we do not require enterprise account for using an MDM service but we require it for creating an MDM service? Quite confusing.
Here are the blogs & posts that I referred:
MDM protocol https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf
https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/profile-service/profile-service.html#/
Understanding certificates https://micromdm.io/blog/certificates/
generate MDM certificate
http://avibirnale.blogspot.com/2013/05/mdm-development-configuration-for-ios.html
How to develop mobile device management application in iOS
How to develop iPhone MDM Server?
https://docs.oracle.com/cd/E60418_01/doc.1210/e58650/admmdmarch.htm#OLDEP080
https://developerinsider.co/how-to-create-a-verified-ios-mobile-device-management-mdm-profile/
MDM Architecture https://docs.oracle.com/cd/E60418_01/doc.1210/e58650/admmdmarch.htm#OLDEP100
Prerequisites for MDM https://github.com/macadmins/mdm-server/blob/master/README.md#prerequisites
I went through the top questions of MDM as well: https://stackoverflow.com/questions/tagged/mdm+ios?sort=frequent
Most of these blog posts are quite old so I believe things have changed since then so I'm curious why we need the enterprise account when that program is majorly for distributing proprietary in-house apps within the company or organization while we are doing this for end-users?
Yes, in order to become an MDM vendor with Apple, you need an Enterprise Developer Program; this program requires you to register it in a company name (not a personal name), be registered with your country's tax department, and also obtain a DUNS (Dun & Bradstreet) number.
All in all, just a bit of paperwork and a few hundred dollars would set you straight.
Yes, technically you need to register with the Enterprise Developer Program, however with some clever trickery, it is possible to obtain a certificate like this for free.
Apple has maintained the "macOS Server" program for years now and it includes a service called Profile Manager. It is a rudimentary MDM server made by Apple. It uses MDM push certificates just as 3rd party vendors do, however they have made their own system for getting these certificates. I won't go too in depth here because this is kind of gray area on the terms & conditions front, but with some research on GitHub, you can find where people have uploaded scripts that use the protocol used by the macOS server program to get & renew its push certificate for free.
I reverse engineered it a while ago and have been using it to run by own personal mdm server for years. In my opinion, much cheaper and easier (and kinda fun if you're interested in this kinda stuff) than paying for an enterprise account.
EDIT: see conclusion at the end of this post.
First off, let me clarify I've found a few similar questions/answers on SO, but none that apply to my particular situation. The one that came closest is this one but it doesn't address the AirWatch aspect.
So I'll try to be very specific.
Background
I have an iOS application that's free. I also have the same app for Android and Windows 10 but those are not my concern.
The iOS app is available to anyone from the App store. But I have a few large corporate customers who use AirWatch to manage the installation/update cycle of their devices. They either have Enterprise or VPP Apple accounts. They want me to provide them with the IPA file so they can distribute it themselves through AirWatch.
In my mind, that's a perfectly legitimate request: they just want to have better control over what gets installed on their devices.
Problem
From what I understand, an Enterprise account requires that the application be signed with the customer's certificate. But if I have several such customers, that means I have to re-sign each application for each customer, every time I have a new update available. And those customers that have VPP accounts cannot use them because the VPP program only applies to paid apps, not to free ones.
Note: keep in mind that at that stage when I'm ready to provide the app to these customers, the app has already been reviewed and accepted by the App Store. So it's deemed legit.
After googling this matter for a while, I know it's possible for someone else to resign an app or to sign it for the first time if it is provided in unsigned form to start with. However, resigned apps are apparently not supported by AirWatch (and, I assume, other MDM's as well).
If that information is incorrect, then I guess all I would need to know is the recipe that I, as a coder, have to follow before providing the app to my customers and what kind of steps they have to take in order to deploy using AirWatch.
Question
So how do I get my free app to my customers so they can manage the distribution themselves, without me having to go through yet another set of hassles every time I change something.
Remember: if I only had a single corporate customer I wouldn't give it a second thought and I would just use their own certificates but I have several potential customers with the same requirements, so the point is to make it easy for all of them and for myself.
I hope my question was clear enough, thanks in advance for any help.
EDIT - Conclusion: I was able to validate that an unsigned IPA file can be signed with the customer's certificate and uploaded to their AirWatch distribution app. Which means I simply have to provide the unsigned version to any customer with the same issue and they will be able to distribute the app themselves with their MDM. Hope this information helps others.
If your customers really can't re-sign your IPA, I believe the best solution for you to do would be to sign up yourself for an enterprise account, then use your own enterprise provisioning profile to sign a single ipa for distribution to the companies that need the app. Their MDM platforms should be able to handle the "trusting" of your enterprise signing identity, so the experience for the end users would be no different than if they were installing and running one signed by their own enterprise account.
The downside of this is that you will then be on the hook for providing your customers new versions when your cert of profile is about to expire. If you have them re-sign your IPA, it would be their responsibility to keep track of that and resign / redistribute a new provisioning profile when they expire.
Also, I have never heard of any restrictions on MDM's distributing re-signed IPAs. I don't even understand how they could prevent it, as a properly re-signed IPA should look no different than an IPA that was build and signed using the new signing identity and profile. I would challenge that, as many MAM (Mobile App Management) vendors offer wrapping of apps that do re-sign the binaries and allow you to distribute those resigned IPAs through MDM systems. I would really expect any corporation with Airwatch to know how to resign an IPA using something like iReSign. That really is your easiest option. Build an IPA for each release, send it out to all your clients, and each can re-sign it with their own signing identity. That way if you stop doing development, they aren't reliant on your signing identity and profile to keep the application running.
because the VPP program only applies to paid apps, not to free ones.
You can manage free apps with VPP. It's maybe free but it's still a license. VPP manages licenses for an organization and allows admins to give and tack back these licenses.
I have right now free Apps in my AirWatch Console, in the tab "Purchased". This tab is only available if VPP is configured and displays only apps from the VPP. I can't go check in the VPP myself because I don't have any access but theses free apps wouldn't be in the tab "Purchased" if they weren't bought with the VPP.
They want me to provide them with the IPA file so they can distribute it themselves through AirWatch.
If you are ready to do that, your customers can upload the ipa file as an internal application and then deploy it to their iOS devices. As AirWatch customers, they should have access to the document VMware AirWatch Mobile Application Management (MAM) Guide with the Chatper 4 "Internal Applications". There is a particular process for iOS apps described.
I'm in charge of developing an application for my company. It'll only be used by my company. I found the Enterprise Program.
I read
iOS Developer Enterprise Program
but I also read something about MDM iOS that I need to implement.
Is MDM needed to distribute my app? Also, how will my coworkers be able to download the app? How does Apple know they are authorized, and not some random guy who found the link on Google?
You don’t need to do MDM for the enterprise program as far as I know. As for preventing people from downloading the app, I think you just have to keep the link private, or put it behind a URL that can only be accessed on your company network or VPN. And of course, require login, so someone can’t access your internal information just by downloading the app! Presumably, Apple will revoke your enterprise privileges if they find you are abusing them.
Source: I worked at a company that used enterprise distribution for internal beta distribution, among other things.
One of my clients has 30 iPads that are used with an in-house developed app. The "Ad Hoc" distribution model is easy to implement if the number of deployed devices is less than 100. This approach is sometimes described as a "Beta test" approach, but that's just one common use for it.
See these pages:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/TestingYouriOSApp/TestingYouriOSApp.html
Ad-hoc Deployment
I am currently developing iPhone app, and I use a "Apple standard program".
At the moment, I am deploying this app to users with OTA with distribution certificat and OTA (over the air) installation.
It's working but i'm limited up to 100 devices.
I read that the "Apple Enterprise Program" don't have this limit (of 100 devices).
Is it right ?
If I enroll to Enterprise program, will I need to get UUID devices in order to generate provisioning profiles to deploy my app (like I do now with standard program and my 100 devices users) ?
Thanks for feedbacks.
No you don't need to know the UDIDs for Enterprise distributed apps.
It's very important to note however that you're not allowed to distribute Enterprise Apps to People other than your employees or other members of the organization which enrolled in the Enterprise Dev Program.
You should be aware that Enterprise distributed apps are signed with a special distribution certificate and provisioning profile which only allow the app to run after the device had an opportunity to check with apples servers if your certificate is still valid. This means that Apple, should they happen to learn about illicitly distributed Enterprise apps, is perfectly able to shut these apps down by revoking the distribution certificate. Furthermore, those certificates expire each year anyway just like the regular distribution certificates do.
Unfortunately, there's no real solution to your problem - I happen to know, because the 100 device limit put a halt to a research project of one of my clients, too. In their current form, the available development programs as offered by Apple offer only a minimum of flexibility. You might want to contact them about it, if enough people do, maybe they'll change something one day.
The Apple Enterprise Program will only allow distributing within the organization. Further Apple restricts the Enterprise Program to large organizations and there are other restrictions as to membership.
If you are looking for general distribution the Apple Enterprise Program is not an option.