My Enterprise app's provisioning profile became invalid yesterday. I renewed it via Xcode, but now the app on won't launch on any devices, and it's unable to download. Do I need to re-package the app and make all users download the update? The app has 3000+ users and making them all download it again would be a huge pain. Is there any way to update the profile, but not need to re-download the app? Shouldn't the device check against Apple's server and see the profile is now valid again?
If you have 3000 users, you really need to look into using an MDM / MAM platform to automate this. Every year when the provisioning profile expires, you will need to re-sign the app, and then re-distribute the app to all the users.
You can do something in-app, like check for a new version, and prompt the user on launch that they must download the new version. If you do this, make sure you push it out early enough that all users will launch the app and download the new version before the profile expiration date. So every year, 1 month before the profile expires, you push a new version to a particular location. Users will then get a pop up saying they must get the new version. They click OK and it fires off the install from the .plist, replacing the current version. We do it for a much smaller user base and it has been effective.
Related
I began developing iOS apps under my father's developer account due to the age restriction, but now I have my own, and have transferred my apps over to it. I now want to update an app of mine that creates and maintains data on the device local to the app.
Since my father's account is still active, I can still sign the app via that account's "Team" in Xcode, and everything works fine when installing on a device. However, I want to sign it with my own account in case my father ever decides to stop renewing his membership, but if I do, whenever I try to install it over top of the old version I get an error in Xcode with the title "App installation failed" and the message "Could not write to the device".
After googling around, people suggest to simply delete the old version of the app from the device and install the new version, but since the app utilizes its local documents directory, this would mean that all the user's files would be deleted when deleting the app, which is unacceptable, since this is the main feature of the app.
Since the app has iTunes File Sharing enabled, users could copy all their files off the device via iTunes, delete the app, install the new version, and copy all their files back. However, some users do not have computers, owning solely phones or tablets, so this is also unacceptable since they would not be able to download the update without losing everything. Plus, many of the apps users are older folks that aren't great with technology, which would just make this a massive pain for everyone.
I haven't tried anything except changing the signing team because I don't want to mess anything up by polluting my account with manually created certificates and provisioning profiles that end up not working. It seems strange to changing the team doesn't work since we have to get a new distribution certificate every year which still changes how the app was signed when releasing an update. I must be missing something since it seems like this is a common enough scenario that Apple would have a process to do it.
What else do I need to do?
Notes:
Xcode usually automatically creates provisioning profiles for apps (assuming the "Automatically manage signing" checkbox is checked, which it is), but has not created one for this app on my account, every though when I roll my mouse over the info icon next to the "Xcode Managed Profile" line in Targets -> myApp -> General, it says it has a provisioning profile under my account's development certificate.
I have access to the certificates and provisioning profiles of my father's account on my computer, so grabbing the p12 of the certificate used to sign the current release isn't applicable.
It's been a while since I asked this question, but if I remember correctly, I think the answer was that I simply didn't have to do anything.
The issue stemmed from the fact that I was trying to install an app that was signed with different credentials than the currently installed version was signed with. For example, if I have an app installed that is signed by account1, then installing any app with the same bundle ID but signed with anything other than account1 (let's call it account2) will fail. In my case, account1 was my father's account and account2 was my account.
When it comes to the App Store, after reviewing your app, Apple signs it and publishes it to the App Store. As a result, everything on the App Store is signed by Apple.
This means that the version of the app submitted under account1 is Apple-signed, and after being transferred to account2, any versions account2 submits will also be Apple-signed. From the final user's perspective, since the old version (submitted by account1) and the new version (submitted by account2) are signed by the same entity (Apple), there is no conflict and the user never knows that the app was transferred to another account.
So even if you see conflicts on your end, the end user won't. To stop seeing them, simply uninstall any versions of the app that were signed with account1 and install your new version signed with account2. Everything should work just fine.
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.
According to this link in the section "In-house apps | Providing updated apps", I should be able to just distribute a new .mobileprovision file instead of forcing users to install a new version of the app:
For users who already have the app, you may want to time your next
released version so that it includes the new provisioning profile. If
not, you can distribute just the new .mobileprovision file so users
won’t have to install the app again. The new provisioning profile will
override the one that’s already in the app archive.
How is that even possible? Isn't the distribution profile necessary for compiling/singing the app? I would like the convenience of just being able to distribute a new certificate, but I'm very skeptical this can even work. Does anyone know for sure? Or am I mis-interpreting this wording? If not, how can I make this work?
Apple said Provisioning profiles can be installed and managed using MDM, downloaded and installed by users from a secure website that you provide, or distributed to users as an email attachment to open and install.
So you can distribute only mobile provision profile and test the things.
One thing I observed that In case of Enterprise Distribution profile Device udid does not need to add in portal. The ipa file will install across all devices. It happens in case of Enterprise developer profile cases.
For Managing Updates Apple has said that:

"In-house apps that are distributed internally aren’t automatically updated. You’ll need to notify employees of the update and instruct them to install the app. If the application identifier assigned to the app in Xcode is unaltered, it will recognize the app as an existing app and install the update while retaining locally stored app data or preferences. For greater convenience, consider developing a function within the app that contacts the server for updates at runtime."
So I am guessing to send the users a push notification which would notify them about the update and ask them to install, once the click ok you can redirect them to your server where the app is hosted and they can install from there
So I took over an existing iOS app from a client, that is currently available for public use through the App Store. When I was given the project in xcode, I noticed that all provisioning profiles associated with the app had expired and all were under the name of the previous developer.
So, I added myself as a developer and joined the team and code signed the development copy under my credentials. I created a new ad hoc provisioning profile for testing, and released a version through TestFlight to some registered devices. No problems. The app is greenlighted to go live.
Can someone please help me out with the release process from this point on? Do I create a third new provisioning profile for App Store release, and tie it to the code signing in XCode? Is this going to be problematic considering the version that is live now is under completely different (expired) profiles from a different developer? Is there some alternative way I need to do it through Apple? I'm trying to be super cautious here... if for some reason I release the app and its crashing because of some step I didnt take by accident, the poop will hit the fan.
You're going to have to release it under a new name on the App Store and forfeit all the ratings and reviews. Apple won't let you swap developer profiles on an existing app.
Other developers may disagree, but it looks like a huge PITA. See here
Transferring ownership of an iPhone app on the app store
The official answer seems to be NO
I didn't interpret the question as regarding change of ownership of an app.
I read the question as: I've inherited maintenance of an app and we'll want to submit an update as the same seller.
In this case, you can generate your own certificates and distribution profiles, and you can then build and submit the app.
I have done this numerous times. That is, I have inherited responsibility for an app that I did not necessarily craft originally. I easily created new signing and provisioning credentials, appropriate for the app the be submitted as the seller (not me) on their behalf.
And for what it's worth, the App Store Distribution profile is necessary, but only used when the app is submitted, so Apple can ensure that it is coming from a developer that has the right to submit it. (Remember, these profiles are signed with the same certificates used to sign your app package.) If that Distribution profile should expire or change, it has no bearing on an app already in the App Store.