For those of you that do not get the challenges of living in the Apple Developer world, a bit of background:
To deploy an iOS app outside of the Apple App Store, either as a “beta” with an Ad-Hoc Distribution profile, or as an Enterprise with an Apple Enterprise Developer account, a Provisioning Profile is required. This profile is built on Apple’s Developer Web site and requires a developer certificate (“trust” the developer!), a list of devices (up to 100) or the domain of the Enterprise (depending on whether this is for Ad-Hoc or Enterprise Distribution), and an app ID. This information is used to generate the provisioning profile, which is distributed along with the app to identify which devices are allowed to utilize the app.
For reasons only known to Apple, provisioning profiles, even Enterprise Provisioning profiles, expire once a year. Perhaps this is Apple’s way of ensuring that Enterprise’s keep up with their $299 annual fee to keep their Enterprise Developer License.
Recently, Apple extended the time validity of the certificates generated under the Enterprise Developer License to three years. But the profiles all still expire after one year.
This has spawned a huge marketplace for MDM (Mobile Device Management) solutions, used to help deploy (or redeploy, in the case of an expired profile) apps in an Enterprise.
It is easy to see what day a profile expires (it is visible on the device under Settings/General/Profiles, generates pop-up warning on the device, and it visible in your Apple Developer account page). But, because of a last minute customer call, we needed to know when would it really expire. This customer did not have an MDM solution, and, though we had built into our app and forced upgrade functionality, if the profile expires, the app stops working.
This is obviously a major issue with Enterprises deploying Apple apps internally. When given enough warning, it can be handled, even without an MDM.
But, given less than 24 hours notice, what we really needed to know was not only the data, but the time the profile would expire.
When you build a profile, you need to get it into XCode (the Apple IDE) to use it. This can be done from XCode, or you can download the profile as a file, then double click on it and open it in XCode.
In other words, the profile (shown to the right) is just a file. It is in the format of a “plist file”, a properties list file.
Since we were trying to determine what time the profile expired, and we could not find that information anywhere, we decided to look into the file. We opened it with a simple text editor (right click, select “Open With” and select your favorite editor.
Most of it was quite easy to read, as plist files are XML. You can tell it is a plist file as it starts with this information:
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
The file contains the developer certificate, which is a long character string that looks like garbage. But after that data string, there is more information, including the follow nugget we had been looking for:
Not only the date, but the time (in GMT, or Zulu time).
Hope this helps anyone else who has the need to look for the same information. Obviously, the best practice is to avoid waiting until the last minute. But if you do, it is good to know how much time you have.
Originally published on our CEO’s blog