A few years ago I wrote an iPad app that was to run on only a few of the client's iPads. They're currently having issues with the app exiting upon being opened. It turns out this is due to the dev provisioning profile associated with the app being expired.
I tried renewing the provisioning profile but am unable to access the Provisioning Portal because my dev account needs to be renewed. Renewing my account is not an option right now.
I'm aware that as of Xcode 8 users are able to install apps on physical devices for free. I don't have access to the client's iPads and have been issuing out updates by archiving the .ipa file and using diawi.com for them to install.
How can I just renew my provisioning profile so that my client can successfully open the app?
Thanks
This is not possible. What you need to do is generate a new, valid provisioning profile and run the app again on your client's iPad. However, I should note that for this type of development, Apple wants you to use ad-hoc distribution through the enterprise developer program.
Also, to be able to generate a new, valid provisioning profile you will need a valid account.
Ideally, your client should have their own developer account that they maintain, preferably an enterprise dev account (enterprise accounts don't require them to manage the specific device UDIDs the app needs to run on). With that, they could manage their own certs / profiles for the signing of the app. They could then grant you access as a team member to manage those things and update the app once a year.
Or, even better for them - you could even write them a script / use tools (like fastlane) to re-sign the app themselves so they could self provision. This takes you out of the loop for ongoing support, since it doesn't seem like you will / have provided ongoing support. Keeping an internal app running requires continual work (new OS updates, code signing expiration, etc.).
If you built an app for a client, you probably should have known / let them know that iOS doesn't allow unsigned apps to run on devices, and that developer provisioning profiles last at most a year. You also need to make sure they know you can't just write a native app and expect it to work forever. At some point (probably now, but they don't know it yet) an iOS update is going to break something you did in the app. The just can't see what is broken yet because your invalid cert is making it so the app can't launch. Given your lack of understanding of iOS code signing, I would assume that you likely did something in your code that was broken in subsequent iOS updates (given that very experienced iOS developers also have things break with new iOS versions are released).
At this point, I would explain them the situation and see if they would be willing to set up their own paid account (only $299 / year for an enterprise account) to get new profiles / certs set up to get the app back up and running.
Related
We previously developed apps with dev accounts enrolled in the Apple Developer Enterprise Program. We recently made the call to cease developing in iOS but still have roughly 50 devices active, running around 15 apps that we are continuing to support to the extent of reissuing Provisioning Profiles each year.
The process for the last 12 months has been generating new Provisioning Profiles once logged into developer.apple.com and generating a new .ipa file with iResign (https://github.com/maciekish/iReSign).
Our Apple Developer Enterprise Program is up for renewal and I'm wondering, is it necessary to renew the full membership in order to simply generate new Provisioning Profiles?
Would I be able to use Ad Hoc profiles?
The apps have been reissued to devices by a server accessed through Safari on the device. We do not have the UDID for the devices but may be able to get them if necessary for Ad Hoc profiles (the devices are scattered across the country).
is it necessary to renew the full membership in order to simply generate new Provisioning Profiles?
Yes.
After a lot of back and forth with Apple, this was the definitive answer we came to. This is unfortunate given it is only to support legacy applications that are no longer receiving any updates other than Provisioning Profiles.
Hopefully this can serve as a notice to any small-time devs looking to build in iOS to consider ongoing costs.
I am trying to install my app to my iOS devices through Xcode. However after a week I the app doesn't open anymore. After doing some research I understand that on the free developer account the provisioning profile will only last 1 week, the problem is is that I actually have a personal developer account that I pay for so this shouldn't be the case?
I have set the team to "my name (Personal Team) and in my Build settings I have made sure the Code Signing Identity is set to iOS developer, if I change that to iOS Distribution I get this warning:
yourApp has conflicting provisioning settings. yourApp is automatically signed for development, but a conflicting code signing identity iPhone Distribution has been manually specified. Set the code signing identity value to "iPhone Developer" in the build settings editor, or switch to manual signing in the project editor. (in target 'yourApp')
Is it actually possible to install an app to an iOS device via Xcode that has an infinite lifetime or does it always have to go to iTunes Connect & the App Store?
Any help would be great as this is the final step to rolling my app out to my colleagues.
Edit:
When I click info next to the provisioning profile I get this:
It is not possible to build an iOS application that doesn't have an expiration (unless you distribute through the App Store). This is to prevent developers from building iOS apps and distributing them through third party app stores.
A standard development account is meant to be used by a developer to test apps for short periods on physical devices before submitting the app to Apple for real distribution. The short duration of the development provisioning profile is a reflection of this.
If you really want to do longer term distributions on devices (up to 12 months), you could sign up for an Enterprise development account ($299/year, but also requires an EIN). That allows you to create an In-house Distribution profile that will be good for 12 months from when it is created. You will still need to re-build the app (or at least repackage it with a new distribution profile) at least once a year.
In the end, you are attempting to do something Apple really doesn't care to support. I wish there was a better answer (could you write the app as a web app?), but I'm afraid there isn't.
We are building iOS apps for distribution in our own internal App Store using an Enterprise Developer Account from Apple. For building, we need to generate a provisioning profile, which expires 12 months from the creation. After expiration, the app doesn't work on the devices (crashes immediately because of expired Provisioning Profile), and each device needs to reinstall a new build of the app.
How can we provide our users an user friendly workflow in which they do not have to cope with crashing apps after 12 months?
Thanks in advance,
Bas
The expiration of provisioning profiles is a hassle with enterprise distributed apps. And it is something that will require ongoing maintenance from your internal development team, mobile support teams.
First, I want to point out that you don't mention certificates. Because they only expire every 3 years now (as of this writing - originally they expired every year), developers often forget about them. However, their expiration is actually more troublesome than the profiles. When a profile expires, you simply need to get another valid profile on the device. This can be done in multiple ways. You can use an mobile device management (MDM) solution to push just a new profile. Or if another app with a valid profile (that uses a wildcard ID) has been pushed to the device more recently, this can also get a valid profile on the device.
If the certificate expires, you will actually need to re-build the app with the new certificate. Old builds signed with the expired cert will not run unless. Technically, you can resign the old IPA, but the main thing to note is that the actual binary is invalid and will not work until a new binary with a proper code signing is generated. Fortunately this is only every 3 years, so it is less frequent, but I can almost promise you when it happens you will have a mess on your hands if you don't plan for it. Again, as with the provisioning profile, you could handle this by using MDM to push something new to the device. In this case, you would use MDM to actually replace the while app, not just the profile. A little more work, but it could be done.
Of course, there are reasons you may not want to use MDM. Cost could be a concern. Employees may not want the company to manage their personal devices (if these apps are going on personal devices). Ability to manage the MDM infrastructure / workload. If MDM is not a great solution for your organization, I would recommend another approach that isn't as ideal from a user experience, but could solve your problem. You could built your apps to be self-updating. In other words, on launch, your app checks a server to see if a new version is available. If so, it prompts the user to update. This wouldn't require the device to be managed, and you could easily build a shared framework to make this easy for app developers. One downside to this approach is if the user doesn't launch the app between the time you post the new version (with new profile / cert) and the time the profile or cert expires, the app will not launch, so the auto-update functionality can't run to tell the user to get a new version. It will just appear to the user as if the app is crashing. That is the one UX problem with this approach. But if you can manage that, it can provide an alternative to the MDM route.
You can manage this with an MDM server. Essentially the workflow looks something like this:
User installs MDM Profile and Accepts the prompts to allow the MDM Server to install apps.
The MDM Server is able to manage the device according to the permissions set in the MDM Profile. Apps managed by the MDM Server can then be installed and removed arbitrarily.
A quick google search for iOS MDM Server should get you headed in the right direction. Pricing for various paid options is somewhere around $15 / device / year, last time I looked into this (about a year ago). But there are one or two reasonable open source MDM Servers available as well.
I have an iOS app that I'm testing on my phone. I installed it through XCode. I've had the app on my phone for several weeks. After a couple of weeks the app no longer works. If I open the app it immediately closes. If I do a fresh re-install of the app, then everything works for a couple more weeks till it breaks again.
My theory is that the provisioning profile I used has expired, preventing the app from loading. This is expected as I'm installing the app through XCode and Apple probably doesn't intend for users to have a test build used on an iOS device for extended periods of time. My question is this, how can I set it so the provisioning profile doesn't expire? How would I need to adjust the code signing settings to adjust for this?
You cannot set provisioning profiles to never expire. Development provisioning profiles will expire after a set amount of time. For a free developer account with Apple, your profiles will be set to expire after 30 days. If you have a paid developer account, the profiles will last for a year from when it is created. Note that a new profile isn't created every time you build, so you have to keep an eye on the profile expiration date and generate a new one when you get to 10 months or so.
Apple will not let you go longer than this, as it would allow / encourage other distribution mechanisms. If developers could build an app and distribute it to other peoples' devices, and those apps could run indefinitely, someone would quickly develop a 3rd party app store and Apple would lose control of its ecosystem.
FYI - If a provisioning profile expires, the app will launch briefly, then shut down when iOS realizes that there is a code signing problem (also happens if your certificate has been revoked or has expired). You can check for sure by plugging the device into your Mac and monitoring the device console when you attempt to launch the app. You will likely see a code signing error in the logs.
Set device type to generic in Xcode.
Go to Product in the status bar on the top of your screen
Select Archive
Build your app as an AdHoc file
When its done, save that file somewhere, (I usually throw it on my desktop and then delete it)
Double click the .ipa file, Make sure your phone is plugged in and hooked to iTunes.
This should install the app on your phone.
I have had good luck with this, I hope it works for you.
Note: This may only be possible with a developers license, I'm not 100% sure.
I am updating in-house app for a client which they have a previous version currently on over 100+ iPads.
I want to push an update, but when i try to sign the app with the distribution provisioning profile it asks me for the private key. After searching, people suggested to revoke the old certificate and generate a new one on the machine i'm using so i can have the private key. I don't know if this is the best approach or not, but my client is concerned if I will be revoking the current In-House Distribution certificate, it will affect the applications which are currently distributed on those 100+ iPads? Thanks!
Unfortunately, yes. For enterprise distributed apps, the devices will regularly check with apples servers whether the certificate which has been used to sign them is still valid. So revoking the certificate will make those installations fail. Maybe not until the next reboot, maybe not when there is no internet connection available, but sooner or later, the app will refuse to launch.
If availability of the app must not be interrupted, you need to take precautions - for example by preparing the new version and notifying all users ahead of time that at a certain date, the old version will stop working and the new one must be installed.
Update:
I kept investigating and it appears like you can have two distribution certificates at the same time now. This is meant to eliminate gaps in app availability by allowing you to phase from one cert to another, way before the first one expires.
If this is still true, you might be able to simply create another distribution certificate without revoking the existing one. You will need to create new provisioning profiles as well (or update the old ones to use the new cert), but that shouldn't invalidate those already deployed. You would then be able to distribute the new / updated app and the existing installations will remain unaffected.
It has been some time since I last worked with enterprise distribution and right now, I don't have access to an enterprise dev account, so I can't try. But I don't think there is any risk if you just go ahead and try it - I assume the portal will either let you create a second cert or it just won't...
Toastor is correct - I recently had a discussion with Apple about this and it intentionally differs from App Store apps. When the distribution certificate is revoked (or expired) for an Enterprise app, the app stops working after expiration is reached, or revocation information is retrieved from Apple.
However if you manage several Enterprise apps, instead of requiring users to install a recompiled version of every single app with the new certificate, you may:
Push the new Provisioning Profile(s) to users over MDM (like Airwatch) **
Use a wildcard App ID for your apps and then as long as the user installs one app with the updated cert, it will apply to all apps that share that App ID
Allow users to download the updated Provisioning Profile without requiring an app install **
** CAVEAT: I don't code apps but do manage our certs, App IDs, and Provisioning Profiles. I haven't yet tested these approaches - it's my best effort based on notes from my recent discussion with Apple.