We are developing an iOS application for a customer who manages his apps under his own name in iTunes Connect.
I was wondering if there was a feasible way to validate an ipa when you are not the final instance which will actually upload the bundle to the App Store. A common scenario is that you deploy an application bundle to a customer so that he will be the one who manages the app in iTunes Connect, but you still want to make sure that everything checks out once the app is in your customers hands.
To be clear: we don't have access to our customers iTunes Connect but we archive the application with their distribution profile.
The idea which came to mind is to create a mock application in our own iTunes Connect without the intention to actually release the application. One could expand on this and actually do a pre-review of the app to make sure the app will not cause unpleasant surprises after we sent the archive to or customer. Will Apple throw any rocks in this path? I could imagine that they won't be happy that developers will let review the same app version twice...
You ask about whether the final Xcode archive could be tested. Yes, it can be tested. You should ask your customer to send you a copy of the submitted application, as it appears in the Xcode organizer). They would have to resign the bundle with THEIR AdHoc profile that should contain YOUR device, and send the IPA to you. You would then be able to check the final submitted app.
For the second part of your question, which is most interesting: It would be great to release the app in your account and then let the customer release it again. There are two problems: if the reviewer is the same, then your customer's app may be rejected. And: if the reviewer is not the same, it could pass validation with the first reviewer and fail with the second one.
Related
I'm developing an iOS app in Xcode 12.2 for a client.
The client does not have an Apple Developer account yet, so I'm using the Testflight of my own account to test the app with the designer.
The app uses AppGroups, let's say I have a group named "group.com.myorg.appname".
I'm also using CoreData, and will implement NSCloudKitContainer very soon.
My question is:
Once the client has purchased a developer account, can I easily delete my version from my Testflight, and then add it to the client's Testflight, without issues?
For example, do I have to change the AppGroup identifier? And is this a problem for iCloud?
I have read this answer which contains lots of good information, but didn't allow me to be sure about iCloud or the AppGroup identifier. This was also very useful but incomplete. I've also read information about app transfert, but in my case the app is not published, it's just in Testflight, there's no publishing before moving to the client's account.
If you do not want to lose the IDs, the safest option is the transfer the app to the new account rather than deleting it. If you have push notification certificates, these would need to be regenerated on the new account. However the same goes for the App Groups. You will need to delete it from your old account to release the ID and make it available for the new one. There shouldn’t be issues doing this since it is not launched yet. https://developer.apple.com/forums/thread/70297
I have an app uploaded on Testflight which has been expired from my developer account. I want to upload the same app to Test flight from another company developer account. Will it create a conflict?
There is no transfer option in Testflight mode.
If you haven't already read the documentation, you can find it here:
https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/TransferringAndDeletingApps.html
Key points to highlight in your case would be:
Make sure your accounts aren’t in a pending or changing state.
The App must have had at least one version that has been released to
the App Store
The last point is the most troublesome but it happens -_-
I'm working on an app on iOS, but I'm not the one who publish it on the app store. So each time I have to send the build to the third party who try to upload it and come back to me with upload errors. This way, we are both wasting time and the release is delayed.
Is there any tool that would allow me to see if there is any "TRC" error on the build before sending to the third party?
You can try to use the "Validate..." feature in the Xcode Organizer (Window -> Organizer) to identify any issues with your binary ahead of you sending it to the third party.
Note: This will require some level of access to the third party's iTunes Connect account. Additionally, it will require that the application is actually created in iTunes Connect with a matching bundle identifier.
I'm guessing, without actually trying it, that this permission will align with "Upload Builds" in this screenshot, so you would need Developer, App Manager, Admin, or Legal:
Here's one way to "preflight" the entire submission procedure:
In your own personal Developer account on iTunes Connect, create a dummy app with a dummy bundle ID. Temporarily change the bundle ID and owner of your client's app to this dummy ID, build, and upload to your own Developer account (not the client's). After the Validation and upload succeeds 100%, delete this build from your iTC app version (so you can re-use the dummy bundle ID as many times as needed). Throw away the dummy app archive, and send the identical (except for bundle ID) app to your client.
You can even copy all the client's My App : App Information and Version Details to your dummy app entry to see if that causes any problems when hitting "Save" in iTunes Connect. Even if you hit "Submit" by accident, you can always reject this submitted build to reuse your dummy app ID.
We have developed an app for a client which we deliver to them as an ipa signed with our dev credentials and bundle identifier etc.
When they receive it they strip off the existing credentials and re-sign it and submit it themselves to the app store.
Now there is to going to be a new version of the app that will include in-app purchase. In order to develop and test it I'm going to have to set up an entry for our in-house version of app in iTunes connect in order to create some products.
I've never done in-app purchase or set up an iTunes connect account before so was wondering if there are any potential issues I need to be aware of bearing in mind what I've said about how the app is delivered to the client and submitted to the app store.
For example:
- can I easily set up an iTunes connect account for an app that will never be released, for example I see there's a paid applications contract to agree to? (I say the app will never be released - what I mean is the exact version we deliver to the client will never be released in that form, its bundle identifier will be altered and thus will be different).
the product identifiers used during the development phase will be different than the eventual product identifiers. I already have a .plist config file in use, are there any potential issue with adding the product identifier names in there, and when the client re-signs the app they edit it to contain the actual product identifier names?
I thought I remember reading somewhere (but not can't find it) that after creating an entry for an app on iTunes connect there's a time window within which the app must be submitted. If this is correct then would the iTunes connect account disappear? If this happened before finishing the app I'd have to go through the hassle of creating a new bundle id and associated profiles and create a new iTunes connect entry to compete it?
If you have any issues I need to be aware of I'd be keen to hear.
TIA
Your plan seems to be fine, however be careful when shifting things to the product, as there are so many parts to this operation(bundle identifiers, etc...). A small mistake could set you back weeks if not months.
We have apps with IAP that we develop for other clients and they submit with their own credentials. We also have our own app on the app store with IAP. We just have to make sure that our clients set up their IAP with the same ids as we set them up with. Other than that we have not had any problems with it. Also, we fully do IAP fulfillment (downloads and IAP store display) from our servers and not from the clients.
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.