I'm sorting through the various Apple docs, but haven't seen it yet.
Here's the deal: I've created a series of apps that are for a service for NPOs. These are hugely popular (albeit in a very small pond), and I have been asked to make customized versions for some of these organizations.
It's a FOSS app, but these outfits can't get iOS programmers to build and release the apps. They are willing to set up App Store accounts, but don't have the geeks on hand.
Due to the way the organization manages its IP, I am not allowed to release branded apps under my app store account. They need to release under theirs.
I don't want to set up an enterprise account for this. I haven't read up on that, but I'll bet that it would not be practical, anyway.
Is there a reasonable way for folks to take apps built on one account, and apply a new provisioning profile, and release it via another account?
Yes a company can take any developer app, sign it with their own certificates, and submit it using their own iOS enrolled team leader ADC account. They can even hire a contractor or temporary employee and legally authorize them to do this work for them.
If you do this type of subcontracting, you might want to get authorization in writing from the CEO, COO or chief legal consul of the company to do so.
you can use a different provisioning profile and deliver the app to the other guys. You can have multiple profiles in your X-Code and select with which one you want to sign the app when you create the archive.
You can either do this yourself by getting access to your client's app store signing certificates, or you can get your clients to use their codesign tool - details on the latter technique can be found on google - here is one example.
Enterprise accounts don't let you release on the App Store.
A typical way of handling this is for them to set up an account and give you the details for the team agent to log in. You then generate a key pair and a certificate signing request in Keychain Access. You log in as the team agent and use the certificate signing request to get a distribution certificate, which you then download and open - this will install into the keychain. Export the key pair and supply this to them so that they aren't screwed if you get hit by a bus or something.
From that point on, it's all stuff you should be used to. Xcode knows which private key to sign the build with because it matches the provisioning profile. It knows which provisioning profile to use because the app ID in the profile matches the app ID in the Info.plist file. Beta testing with ad hoc builds is the same as normal, except you register the UDIDs after logging into their account, not yours. Archives are not tied to your account.
When you submit the app through Xcode, you'll have to supply the team agent login details again. The submission will show up under their developer account, not yours.
Technically speaking, I think it breaks their developer agreement with Apple for them to supply a third-party (you) with their login details. However I don't believe it's possible to delegate all of the privileges necessary to submit an app to anybody other than the team agent, and the parts that can't be delegated aren't easy to explain to a non-technical person. You can script some of it to make it easier, but it's easy for them to get into a mess, so it's usually best if they let you handle it all.
Related
I am a developer and I am making an app for my client.
I have indie developer account so During testing period I am using client's UDID to build ipa file so they can test on their iOS devices.
Now client will distribute final ipa file into itunes connect.
so What are the different legal solutions for this?
Assume that they have indie developer account too and client is non-technical so they don't want to mess with xcode or source code.
And in future I will do the same for other clients too.
In order to submit an app to iTunesConnect, it has to be signed with a valid distribution certificate and provisioning profile that match the developer account they are submitted to. That means that someone (whether it's you or your client) needs to create an appID, a distribution certificate and a matching app store provisioning profile that you will then use in Xcode to sign the ipa that will be submitted to the store.
Since your client isn't a technical person and you will most likely be able to do that process much quicker and more efficiently than he/she will, the best solution would be for your client to simply give you the credentials to the developer account and for you to perform these steps there. If that's not an option, and your client has a company account (and not a personal account), he/she can give you access to their account by adding you to their development team - that way, you'll still be able to perform the necessary actions on the account, without having the admin's personal credentials.
As for the submission itself, once you have a signed archive, you can either submit it directly via Xcode or you can send the signed ipa to the client, and he/she can submit it via Application Loader from their admin credentials. But, you will still have to sign it with valid certificate/profile from the right developer account.
I hope this makes sense and makes things a bit clearer. Good luck.
I have an apple developer account using which I have developed an application for one of my clients. Now, the client also has a developer account. Is there anyway, I can create an app ID like com.client.* in the clients developer account and then upload an application's release version using an appID like com.mycompany.applicationname which is created in my developer account.
Or else, there is no option like that??
An app ID is a unique application identifier. Even the exact same source code, built with two different app ID's, would be considered two completely different applications.
In order for you to compile your client's application, you will need to get a copy of their profile using com.client.* and compile the application as com.client.appname.
That would be possible, (as far as I know, apple doesn't check the AppIDs if they are used anywhere yet outside of your program) but might get problems when submitting to the appstore and furthermore, you could not submit with his account, what he probably wants. Here's what we usually do:
1. Create a *. Provising profile for yourself for development purposese.
3. For push notifications, you should be able to create a DEV certfiicate with Appid com.client.appname in your developer program
4. Have your customer invite you into his Program and create the matching provising profile for appstore submission and push notification with this Appid.
You can be in multiple development programs (I'm currently in three different ones..)
I am doing some dev work for a client. She has a Dev License should would like to put the app under but since she is non-technical it has been frustrating since she has to be the one to submit the final app.
Is there a way for a Dev License to have multiple Admins? I have it configured so I am a developer but as such I cannot do the Distribution License. Only she can do that. Is there a fix?
If you have a good relationship to your client, you might want to ask her for her login details so you can do it yourself.
There is one other possibility though: For a similar problem I was given the advice to build & archive my app and send the archive to the client. He could then resign the app using his certs, which would eliminate the need for him to do all the building stuff, not to mention it will spare you to surrender your source code. However, this will not eliminate the need for your client to enter all the meta information and so forth while uploading the app.
For the necessary steps to resign an app, see this answer.
To answer your original question: Each developer account has exactly one Team Agent. So you need some kind of workaround anyway.
There is only one administrative or Team leader per developer account. So you really need to plan on the policy for sharing use of that account from the beginning, if the required activities of the agent need to be split up among multiple parties, if you can't have one party capable of doing everything.
A shared account can be created from the beginning (either by the owner or the developer). I recommend an ADC account be created just for this purpose, instead of just using the owner's personal account and email address ( e.g. instead of mary.smith#sample.com, create and use iosdeveloper#sample.com for enrolling as an iOS developer. )
Account credentials can be "loaned" (perhaps with password changes after use).
You can be given remote access (VNC/RDP) into the owners PC or Mac (or more secure yet, a VM session) as or after they log in.
You can talk the owner though the process over the phone (or video chat, etc.).
Or, the owner can learn how to get certificates, and build or resign and submit apps themselves, perhaps using a comprehensive script.
I developed a iPhone application for my client.
I have my own developer account, so I created the Ad Hoc and App Store Distribution profiles by using my account.
Now the thing is, my client want to submit the app by using his account. He has his own account.
I want to know,
Should I build the app using my distribution profile?
OR
Should I need the distribution profile created using client's account?
Thanks in advance.
All the certs involved for the client's app should be the client's certs. You should even create a separate developer's cert for yourself under the client's account.
These certs not only identify the distributed apps to the technology of the App store but are also the apps financial and legal IDs. In other words, the certs control who gets paid and who gets sued.
Neither you or your clients want the other's certs entangled with their own. If you do entangle the certs, your client might find they can't administer or update their own app and you might find yourself responsible for some future action of the client.
You might even want to go so far as to create a separate user account on your development Mac for each client in order to keep all the certs and profiles cleanly separated. It's a pain but these certs and profiles are the very heart of the App Store system. If the certs and profiles get scrambled it's a big, big deal. As in money, guns and lawyers big deal.
You should create a distribution profile using the client's account.
You can have multiple distribution profile & certificates on your machine at once and select the one you want to use when you build the project.
While you're at it, I would also create a iTunes Connect user for yourself in their account, so that you can still administrate the application and get notifications, etc ...
My team and I have been contracted by a company to develop our first iPhone Application.
I am wondering how this contractor relationship is best handled. Does the $99 SDK/Dev connection account need to be established under the contractor's name, so that when the application is approved it isn't listed by our company's name, but by their business name?
Essentially is it best-practice to submit the application under the contractor's name or is there an option to define this when you apply?
You get an account and they get an account.
Accounts serve two functions. Access to the development tools and access to the business interface for the company publishing the app.
You sign up once. Each client signs up for their own account for the most important reason. That's where the bank information is to tell where the money goes. :). And contracts and sales data, etc.
The best way for it to work is for you to do development under Wildcarded developer and distribution (ad hoc) code signing keys (your account). You sign for multiple clients with the same keys. Then at the end, you sign and publish with a specific AppStore key (each client's account).
That will allow you to do control development, testing and beta distribution. When development is finished, you zip up the release version signed with their key and they upload it via iTunes Connect under their account.
Bonus section:
This configuration is easy to set up in XCode (once you get over the 24 hours of strangling yourself getting your head around how xcode and the distribution certificates work).
Go to Project->Edit Project Settings->Configurations. Duplicate two new configurations off of the "Release" configuration. Call one "Ad Hoc", the other "AppStore". Set your signing certificates as follows, iPhone Developer for Debug/Release, iPhone Distribution (Ad Hoc) for Ad Hoc, and their iPhone Distribution (AppStore) for "AppStore". Forget you even have a client until the end, then switch to AppStore distribution, build, zip, email, and done.
In practice, it's more complicated than that as you'll need to set up multiple certs/profiles/keys on your machine, but once you're done, it basically runs like this.
I would create the dev account and publish it under the company that will own the app and the source, regardless of who is developing it.