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.
Related
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.
The company I work for has outsourced development of an iPhone app to another company. They want the binary to be signed with our certificate for distribution, but they've asked me to pass the private key (certificates.p12) used to create our certificate on to the other company. I am extremely concerned about handing the ability to sign applications as us over to another company.
How can I convince my boss this is a really bad idea? What alternative solutions can I suggest to him? I have already asked him to get the source from them so we can sign and submit it ourselves, but without the ability to conclusively state that giving them the certificate is a bad idea, I'm kinda stuck in the "just look into it for me" limbo.
You don't need the source. You just need the compiled binary (make sure it's ARM, not x86) to sign with codesign.
The outsource company can just build and sign the app with their own certificate. You can then resign the app with your company's certificate before submission (use codesign).
There's not too much a consultant can do with the private key to just an App store Distribution certificate but without the team agent's iTunes Connect login credentials, as Apple's review team are the only ones who can run an app signed with your Distribution certificate, and you can't submit an app to iTunes Connect without the login matching the certificate (AFAIK).
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.
I am finishing an app for my client.
He wants to submit it to Apple himself.
What must I do ?
Should I give him the app unsigned ?
Should I ask him a provisioning profile ?
Should I be added to his team and to his Distribution Profile ?
Thanks a lot for your help ?
Thierry
Have your client sign up for the iPhone Developer Program so that way when your client submits the app to the App Store it will be under the client's company name. You can still manage all the code signing and provisioning for your client if they do not know how to do this stuff. The client can simply give u access to their developer account to handle all that stuff.
I would just give him the source code, unless you specifically don't want to do that for some reason. That way, he can just compile it himself.
What I've done for clients who want to submit to Apple themselves:
The client must create (or you can create for them if they give you their login info) the app store distribution profile for the app and send it to you. Requires some communication between you and client to make sure they use the right app id, etc.
(I think you may need the client's developer certificate as well in order for them to "own" the app -- not 100% sure about this)
Don't forget to also get the private key file as the certificate signing won't work without it
I set the client cert / app store dist profile into the app and build the app for app store.
Deliver the binary to the client.
Client uploads to itunes connect.