I am a member of two development teams in the Developer Portal. One team is no longer in existence and is not being maintained by the team's "Agent".
Now herein lies my problem. I am trying to refresh my provisioning profiles in Xcode, but continually get a message telling me to have the team agent for the non-existent team to agree to current terms. Again, that team is no longer active, the developer no longer works for the company, etc., etc.
On the other hand, the team for which I am trying to do work has all agreements current. Is there any workaround for getting past this message then?
This is happening because your Apple ID is associated with more than one developer account. The refresh operation first hits the developer portal and runs refresh on each developer program that it finds you associated with. Unfortunately, if the un-maintained account lists first then it will fail the entire refresh operation.
Now given that the agent is not maintaining the program, I'd hazard a guess that getting in touch with that individual to remove you from the program is also off the table. Your next best bet is to contact Apple Developer Support and let them know that the Team Agent is not reachable and as a result you are unable to remove yourself from that un-maintained account which is causing you pain when it comes to Xcode Organizer operations. Once you get removed from that account, that should resolve the problem with the refresh operation as it will then only find your single maintained account to refresh. It would also be a good idea to remove any stray Certificates and Provisioning Profiles associated with the unmaintained account so that Xcode doesn't have an opportunity to spaz over not being authorized for the un-maintained account.
In the interim, your only option is to use the Certificates, Identifiers, and Profiles tool to download provisioning profiles manually. When you download new files, take an extra moment to delete the old ones to minimize confusion between older and newer versions of the profiles.
Related
So I have a client who I’ve built this app for. The app had reached its MVP so we launched it and transferred the app to their developer account. Now I want to continue working on the app for them but I don’t have the proper certificate on my device to make changes to the project on the clients developer account. How do I go about getting the proper certificates set up so I can upload new app versions of the app to their App Store Connect account?
There is two solutions I can think of :
They can add your Apple developer account into their new developer account and give you the developer access (or admin access to have a bigger freedom). Therefore you will be able to recreate certificates for you in order to work on your project. (for me this is the best approach and it keep things clean). To do so, just ask one of the admin of the itunesconnect account on your client side, and he will add you as a Developer Manager in the account.
you can ask them to export their new certificates as a .p12 file (which contain the private and public keys) and their provisioning profile from their Mac OS key chain (the developer or team from your client that is handling the app nowadays if any). Then you will have no issue at all. (I do not recommend this one and vouch for the first one even if second one seems easy). Also if tomorrow they changed it or revoke it will require to do again the same update..
I have an Individual Apple Developer Program and I want my friend to help me to develop my app. My friend, himself has an Individual Apple Developer Program, so he created a new Apple ID and I added his new Apple ID to App Store Connect > Users and Access with Developer role.
But, when he added this new Apple ID in Xcode, it seems this account is DOES NOT belong to my Developer Program and he CANNOT build the project.
Xcode failed because of this:
How can I fix this? Is there any other step(s) to do?
To the best of my knowledge, only organizations and not individual Apple developer accounts are eligible for adding an additional member who has access to certificates, identifiers and provisioning profiles.
Role Permissions: Access to Certificates, Identifiers & Profile is an additional privilege for users with the App Manager, or Developer role that are members of an organization’s team. If this privilege is added, the user sees certificates, identifiers, and profiles associated with all of your apps.
A few workarounds:
This requires some trust, but you can login on the 2nd developer's Xcode with your own account which would allow Xcode to automatically manage the certificates. This is a super simple, quick way of working around this for small companies. You could also share your password, but this would require more trust.
You can request to upgrade your membership to an organization. This requires you to have a D-U-N-S numbers, which depending on the process, would take from days to months.
You can have the 2nd developer to develop on their own account with their own bundle identifier then switch it to yours. This is super slow and annoying since you may have to duplicate some of the services (like Firebase) that bind to a bundle ID.
I am looking into the possibility of signing certs and preparing provisioning profiles on my computer and emailing them over, but so far, haven't found a working solution here.
Overall, this is an unfortunate decision by Apple. It shouldn't require a creation of a legal entity and go through a month long process just to add an additional iOS engineer to the team. The situation is also exacerbated by their half-baked team management system for Individual Apple Developer program, where you can add developers, but you can't actually have them develop on device 😢
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.
Is it possible for two seperate individual Apple Developer accounts to work on one single Xcode project, using two Macs, without provisioning profiles being revoked?
I understand it is not possible for an individual Apple Developer account to have two users working on two separate machines using the single account as provisioning profiles are revoked.
As we will be using git to work on the application, the question is if we are using two Apple Developer accounts, will this ensure that provisioning profiles are not revoked and will this allow us to work on the project collaboratively using git?
I've never experienced an issue with this but I've also always used a good Xcode .gitignore by default https://github.com/github/gitignore/blob/master/Global/Xcode.gitignore that you should include in every .git that holds an Xcode project (i.e. add it to your initial commit when creating the project).
Any application can only be published to the app store under a single developer account, so you should decide now if you want create to a team for the account (business) or if only one of you will be responsible for publishing it to and maintaining it on the app store (common for side projects).
For testing, a developer can use any provisioning profile they have access to in order to push builds to test devices (though the device must be set up to trust builds from each provisioning profile that pushes to it).