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?
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
A previous developer created and uploaded our app with our dev team. They then transferred it to our client's account and released it. However it kept our Team ID. When uploading to the App store, I get the following:
"Potential Loss of Keychain Access - The previous version of software
has an application-identifier value of ['XXXXXX.XXXXXXX'] and the new
version of software being submitted has an application-identifier of
['YYYYYY.XXXXXXX']. This will result in a loss of keychain access."
I can accept losing Keychain Access as I understand that there is little that can be done here and it may not affect this app.
However, my question is, could current users be affected? There are no passwords in the app or any user details stored, it is mostly an informative app. I assume it won't stop them updating the app or block them from using their current build? These users have paid for the app, so if they stop getting access all of a sudden, they might be upset!
i.e. I'm not sure about the following technologies from Apple:
Important: The only apps that can ignore this warning without
consequences are those that do not use technologies that rely on the
App ID prefix, like keychain access, Handoff, and UIPasteboard
sharing.
I think you need to check with the developers to see if they are using anything related to the app ID prefix.
As stated by Apple, the app Prefix is critical to using a couple of their capabilities.
Basically, most of the technologies listed are all about inter-app communication. If you only offer one iOS / Mac app, you aren't doing any special interactions with other apps with the same app prefix, and you don't have anything to worry about. Pasteboard is basically a shared clipboard used to share information between apps by the same developer. Handoff is about syncing state between apps on different platforms (e.g. Sharing Safari tabs between your Mac and your iPhone).
The other thing to worry about would be the first error you show. That error means that if your app is storing any information in the keychain, the new version of the app would lose access to anything that was stored in the keychain by the old version of the app. If, like you say, your app really isn't using the keychain to store information (it doesn't have to just be passwords, FYI), you don't need to worry about that either.
I would definitely have the developers check for anything related to the keychain to confirm, as well as anything related to the PasteBoard or Handoff.
EDIT
As to the affect on current app users, they should not be affected if you are not using any of the above technologies. Existing users will get the update and should not notice any difference. More on that in this answer.
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 -_-
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.
Big headache! I cannot get IAP to work on my iPad device.
I have created a developer account on iTunes.
I created some app information, SKU etc., without uploading a binary.
I have set up Unibill to use the bundle identifiers and Ids as shown in the iTunes dashboard.
I logged out of existing users on the iPad.
I created a test user with a new email.
I fooled around with Xcode settings, trying a million different settings, but mainly following the documentation best I could: specifically, linking the Storekit library.
Unibill initialization keeps returning a 'CRITICAL_ERROR'. Maybe it's a Unibill problem, but what could I have forgotten?
Does testing In-App Purchases require a special contract type?
It is probably not the fault of Unibill. There are too many reason for the failure of IAP test. Basically, you can have a look at this check list first. Follow the questions could solve for most situation.
But there is something not correct in that checklist, the most important one is you do not need to upload the binary.
For your situation, I suggest you check the following things:
If you can create the IAP product, so it seems your contract is OK. IAP need a valid paid contract and correct bank information. So you can check if your bank information is correct or not.
Did you try to uninstall the app in your device and install it again? The old one would not be luck.
Did you generate and use new provision file for the build? Maybe old one does not contain the IAP feature.
Check your app id, version and build version. They should be all set properly or the IAP won't work.
Hope it can help.