I have a question about updating an app on appstore:
I have to update an app that was published by another developer. I have been given id/mdp to the developer portal, so I can download certificates and provisioning profile for distribution.
However, I know that to use these signing, I must use the identity used by the previous developer :
according to apple:
Transferring Your Identities
Once you have a healthy working code signing configuration set up it is recommended that you follow the steps in section Transfer Your Developer Profile to Another Computer of the Xcode 4 User Guide to create a backup of them. The backup can be used to restore your working code signing configuration from hardware failure, or to enable code signing on additional Macs, partitions, or OS X user accounts of your choice.
I can't contact the previous developer...
So here is my question :) If I generate new certificates, and publish the update:
First, is it possible? ^^
Second, if it is possible, will it appear like a normal update (a notification in the appstore update tab, and just a clic to update?) - my fear is that it is impossible because of different signing and the user have to reinstall the app
I really thank you if anyone have the answer.
Nice day,
Jer
If you are the administrator or the team leader of the same iOS Developer account under which the app was previously submitted, then you can revoke and re-generate all the certificates and provisioning profiles necessary to submit an update to that app.
Related
Now that the app I created last year has enjoyed a year's worth of functional success, my Enterprise users are beginning to see alerts indicating that the provisioning profile is about to expire.
The Code Signing business of the app gave me tremendous difficulty in the beginning, and now it's doing it again. I think it's because all the information I can find about it refers to apps to be distributed in the App Store, but not for Enterprise apps. The "Tools Workflow Guide for IOS" seems only to be helpful for App Store distribution.
I did finally get it working just by trial and error, by setting all of the Code Signing Identities to "iPhone Developer," but I really need to understand the proper way to do it and why it works that way. And I need the "Idiot's Guide" version.
First, I think what is hanging me up is understanding the Distribution aspect. Is "Distribution" only in reference to an app that is bound for the App Store? This being an Enterprise app, does Distribution apply? Any time I try to create a Distribution profile and include it in Distribution/Release for the Code Signing Identity, compile fails. It works ok if all Code Signing Identities are set as "iPhone Developer." Does that mean it is going to always need a Developer provisioning profile, and never a Distribution profile?
The "iPhone Developer" profile always comes up in the Code Signing Identity section of Build Settings as "(currently matches 'iPhone Developer: Bill Norman(4GR2 etc) in 'iOS team". But any other profile doesn't say anything like that, and so none of the other profiles work. If they don't work, why are they there? And do I need to delete them?
And yes, there are lots of profiles listed that are the result of many trials and errors. Only one appears in the Profiles section of the iPhone's Settings, and that's the iOS Team Provisioning Profile.
If it does need a "Distribution" profile, how do I make it work?
Next question: Will my Enterprise users need to download and re-install the app to get the new provisioning profile? Or will it do it by itself, seamlessly? Or will it inform my users that the profile has expired, and they need to do such-and-such to get their app to work?
More: The Developer profile only lasts for a year, while the Distribution profile lasts three years. Obviously it would be helpful to make it last three years, but can we do that with an Enterprise app?
My apologies for my continued inability to fathom the inner workings of this stuff. And many thanks to anyone who can help.
First thing that you want to do is delete all of those extra provisioning profiles that you created through trial and error. Just totally remove them from the organizer. The difference between developer provisioning profiles and distribution provisioning profiles is that developer profiles will only work on devices that are registered with that developer profile, meaning test devices. You would not be able to sign an app with a developer profile and then put it on any device, only devices that you have registered to work with that profile. In the distribution zone you will have app store distribution and Ad Hoc distribution. App store refers to the Apple App Store which you must submit your app to apple for that. Ad Hoc distribution allows developers who have enterprise accounts to distribute to any device via the internet or other methods.
I would need more information when you say that compile fails with distribution but generally speaking, you would click the product tab and then click on archive. When the archiving is complete and the archive window pops up, you would click on the button that says Distribution in the bottom right corner. You would then click on the Save for Enterprise or Ad-Hoc deployment option. You choose your distribution code signing identity when asked which identity to use and hit next. Here comes the tricky part: On the next section where you are choosing where to save the app, you click on the option, save for Enterprise distribution. There are two fields that need to be filled in here, the first is an application url, this is the exact url where you will be hosting the ipa file, for example http://www.somewebsiteyouown.com/myApplication.ipa
The second is the ApplicationTitle which will just be your app title: myApplication.
This process will generate for you a plist and an ipa file, you put thos both on the server and link to the plist from a button or link on a webpage. The plist is like the instructions on where the ipa file is and what to do with it.
Background: I have some existing apps in the App Store and I have just renewed my Apple Developer Program membership.
Appreciate if someone can help with these questions:
Is it necessary to release an update for each of my apps, compiled with a new distribution profile and signed with a new distribution certificate?
If I don't do the above (1), will my apps expire and disappear from the App Store?
Will a user who has previously downloaded my app, but have yet to install the update, be able to use my app even after its distribution profile has expired?
I found a related question, but it doesn't specifically address the above questions:
How can I update my App in the App Store if the Distribution Provisioning Profile expired?
1. No, your apps are there to stay on the app store. Distribution profiles do not expire until you force them to. Even then, the expiration only keeps you from submitting new apps with that certificate. It does not effect pre-existing applications.
2. Nope! Jeez, that'd suck...
3. Yes. Apple actually applies their own certificate to your app once it is submitted. Your distribution certificate only goes as far as Apple's verification process.
You're good friend. No need to freak out. The provisioning/signing/profile process is a pain in the a**, but fortunately for us we don't have to worry about things like this.
If you have renewed it then there is no need to Do all these stuffs :)
1) You cannot Update a new Version with Different Certificate... you have to use that only.
2) if you do not Renew your Certificate, i think so they are removed from Sale only. :(
But as Peter Said May be he hi Right :)
You can find a lots of links having Queries like this... Hope you will find and get the solutions. :)
All the Best :)
Ive only previously been developing the Apps for our company by myself and Provision management has been quite simple. We have now added another developer to the project and i am having trouble setting up the provisioning for both of us to deploy and test to out iphone.
Does anybody know if there is a step by step or any tips on how to set up provisioning for a multi developer scenario project?
Thanks
Probably you are having trouble sending the iphone developer certificate, if you want to share it, you have to share the private key of the certificate. Not only the public part which can be downloaded from the member center. For that, you have to get into the KeyChain, look for the developer certificate, expand it and right click over the key, then export the key and send it to the new developer.
Hope this helps
We use a team provisioning profile that was created and managed by xcode. If we get a new developer they just login to the dev portal in organiser and then they can deploy. Unfortunately I can't remember how I did it because it was like two small things and it just worked.
You will need to:
Export your Developer Cert from your
KeyChain and send it to your second
developer
Export your Distribution Cert from
your key chain and send it (if you want him to be able to submit to the app store or send out ad-hoc builds to beta testers)
Go to your Provisioning Portal and
add his device to your portal
Then go hit edit on all your
provisioning profiles, adding his
device to each of them
You will both need to download the
new versions of your provisioning
profiles
(Adding his device to the portal & downloading new profiles can be done through the xcode organiser, its usually faster that way)
I'm part of the design (I've had experience with python, php, jquery, and java, but never ObjC) team for our application and was handed off some of the developer responsibilities with our iPhone developer went on his vacation. From the developer, I have the project source, his p12 private key, and the mobileprovision file.
Already, I've encountered this error when attempting to build the application on a device:
Code Sign error:
The identity 'iPhone Developer: xxxxxx xxxxx (xxxxxxxxxx)' doesn't match any valid
certificate/private key pair in the default keychain
despite XCode apparently recognising the distro and keychain (I used security import xx.p12 -k ~/Library/Keychains/login.keychain to import the p12 file; and there are both the private key and the iPhone Distribution: xxxx xxxxxxx certificate in the keychain GUI.
This I am pretty sure I can solve, but my main concern is whether I can add new UDIDs for the beta tests, which are occurring next week. The methods I've seen all involve adding devices via Apple's dev centre, and then downloading; i.e. no way to add UDIDs locally. Our developer is running it off of his personal Apple Dev license ($99 one), which we don't have the password for.
So main question: is there any way to add UDIDs to our distro WITHOUT using the Apple dev centre (i.e. locally), or worse case, can I register my account as an apple developer and then add the UDIDs to that new account to distribute?
Without being able to access his Developer account there is no way for you to create new provisioning files (for extra UUID's) for his account. To add more UUID's you will have to create your own account and setup the project with those certificates and provisioning files.
Of course you could ask the developer to add the UUID's to his account and create a new provisioning file for you. It just depends how many of his 100 UUID's per year he has used up.
If you sign up for your own account, read up on ad hoc distribution. Apple has plenty of documentation. The following chapters will be of use:
Managing Devices and Digital Identities
Distributing Applications
......but sometimes guides are easier to follow.
Nope. The only way to add new UDIDs is via iTunes connect.
You'll have to contact your developer and either ask him for the password, or tell him the UDIDs so he can regenerate the profiles.
If you have the full source code, and an apple developer account, you could create a private beta test.
You will need to build and code sign your app with a Ad-Hoc Distribution Profile.
The limit is 100 devices, but you can produce multiple Ad-Hoc Distribution Profiles.
Each Ad-Hoc Profile can be attached to a select number of devices.
When Devices are added - you will need to get a new Ad-Hoc Provisioning Profile to distribute, but that should get you through a limited beta test.
If you need more information - send me a quick message. (You may have some issues helping your beta - testers install on VISTA and Windows-7) so learn about IPA files.
"So main question: is there any way to add UDIDs to our distro WITHOUT using the Apple dev centre (i.e. locally), or worse case, can I register my account as an apple developer and then add the UDIDs to that new account to distribute?"
I think I'm just cloudy on how debugging works on a real device - is that how to go about it? I've been reading through Apple's docs on creating provisioning profiles for distribution, but I'm not finding any information for simply debugging my app, which is running on my device, through Xcode. Can someone point me in the right direction?
Edit (2/19/09):
I'm getting conflicting answers on whether or not I need to create an ad-hoc provisioning profile to debug my app. If I don't need to create an ad-hoc provisioning profile, what else do I have to do to debug my app, other than having my development provisioning profile and certificate for myself?
Edit (2/20/09):
This link, iPhone Development Guide: Preparing Devices for Development, seems to say that you do need a development provisioning profile for debugging on a device. In my last edit, I mentioned that I was getting conflicting answers on whether or not I need to create an ad-hoc provisioning profile. The answers are not conflicting, I just didn't understand the difference between an ad-hoc provisioning profile and a development provisioning profile.
Any time you're writing software to be installed on an iPhone, you need two things: a key and a provisioning profile. The key identifies the person who developed the application; it stays on your computer and is used to sign the apps you build. The profile identifies which devices are allowed to run applications signed by a given key; it needs to be installed onto the device.
Distribution keys are basically one per company, and are only meant to be used when you are building a version of an app that's intended to be distributed outside your development team. (App Store builds must be signed with a distribution key.) Development keys are intended to be one per developer, but are only meant to be used when actively developing an app.
(If you are an individual developer, of course, you have only one developer key and one distribution key. On my machine, I've set up Keychain to require a password for the distribution key, so even if somebody steals my laptop they can't release an update to one of my apps that compromises user security. The developer key, which can only install software onto my personal phone, is not passworded.)
When you're testing on your own personal device and installing through Xcode, you need a development provisioning profile and a development key. This development profile should be installed into Xcode, which will then install it onto your phone.
When you're distributing to a small number of others (for example, for beta testing, or if you wrote an app that's specialized for a specific customer), you need an ad-hoc profile and a distribution key. You'll need to send the ad-hoc profile to the user along with the app. The user can then drop both the profile and app into iTunes and sync their phone to install.
When you're distributing through the App Store, you need an App Store profile and a distribution key. Builds made in this way cannot be run on any device you control, but Apple's submission tools require them to be built using this profile.
So to answer your question: You need to provision your device, but it has to be a development provisioning profile, not an ad-hoc profile.
No, you don't need an Ad Hoc provisioning profile to debug an app, you only need a development provisioning profile and certificate for yourself on your device.
You need to provision the device, yes. IIRC you need to use Apple's online tool, and then provision it using Xcode, after which you will be able to debug it on the device.
See the first post on this blog for more.