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 -_-
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'm using now the new Apple service for testing apps.
I know that the process to send an app for test is:
Create an ID
Create the certificates
Create an app in iTunesConnect
Archive, upload and invite internal or external test.
But not all apps that I create in my account (iTunesConnect) go to be public; because a lot of my app finish published in the accounts of my costumers.
In this way in my iTunesConnect I have a lot of: (for example)
App1 Test
App2 Test
App3 test
....
I want to delete these, is there a way?
If what I wrote is wrong, so there is another way more intelligent to follow, tell me please!
Unfortunately, you cannot delete apps from iTunes Connect unless one or more versions of the app have been approved by Apple's review team. According to their documentation:
You can delete your app if there is at least one approved version of the app
Honestly, aside from the annoyance of seeing old unused apps there, there isn't much of a problem with what you're doing. What you could do to reduce the number of "junk" apps in your portal is to re-use app identifiers after the TestFlight testing time of 30 days expires (and, of course, you'll have to clear out those beta testers).
You can Not delete it before atleast one of the versions of your app is approved!
Apparently, other people can't use your undeleted App names. I had an old one on my account that another Developer wanted to use. I got this letter from Apple:
Dear Sir or Madam,
Please include **** in the subject line of any future correspondence on this matter.
On 3/4/2016, we received a notice from **** (“Complainant”) that
Complainant believes your application named "****" infringes
Complainant’s intellectual property rights. In particular,
Complainant believes you are infringing its app name, thereby blocking
Complainant from using it on the App Store.
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.
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.
I have an App in the App Store which uses an In-App-Purchase item to unlock the full feature set. During all versions so far updates have never been a problem. The customers could download the new version from the App Store and the "full version item" which they did purchase before was still active: They could still use the full version after the update.
Today I have released a new version of the app and several customers are reporting problems with the full version: After the update the app only works as limited trial version. The app seems to have "forgotten" the information about the IAP.
I use MKStoreKit to handle the purchase and the information about the IAP is stored within the KeyChain. The users can restore the full version using the "restore previous purchase function" within the app which calls the corresponding StoreKit function.
How can it be that the information in the key chain is lost?
I do not know if all customers are affected by this problem or just some of them. All that I can tell is, that quite many reported the problem.
I have no idea what the problem might be.
This is the first version using iCloud and therefore it is the first time, that a entitlements file is included in the App. Could this be the source of the problem?
The "Keychain Access Groups" property in the entitlements file is set to "xy.mycompany.MyApp" which is the same as the bundle identifier.
I thought that without the entitlements the app used "xy.mycompany.MyApp" within the key chain to store the IAP information and that the information in the entitlements file is just to let different app share the same information in the key chain. Thus I am not sure if this might have to anything with the IAP problem.
What do you think? Any ideas or suggestions?