Requesting an In App Purchase in iOS 13 fails - in-app-purchase

I use SwiftyStoreKit to request In App Purchases and get only this error with iOS 13:
Error: Optional(Error Domain=ASDErrorDomain Code=507 "Error decoding object" UserInfo={NSLocalizedDescription=Error decoding object, NSLocalizedFailureReason=Attempted to decode store response})
I cannot request information about the products, nor make purchases with a sand box account. However, it works fine in iOS 12.1 on my device. It does not work with the iPhone 11 simulator or an actual device with iOS 13.
I have found a lot, that the Xcode 11 GM seed 1 beta simulator had this problem, but have not found a solution yet. I also tested it with the new released Xcode 11 GM seed 2 version, but there was no fix for me.
Does anyone have a solution on how I can request and purchase In App Purchases again with iOS 13 installed?

Restarting Xcode and simulator did the trick: now my in-app purchases load properly in iOS 13 simulator.
EDIT: This happens in release Xcode 11 too. And happens once in a while, but restarting Xcode and simulators still helps.
EDIT 2: In Xcode 12 beta this bug is also present. But the solution is to create new StoreKit Configuration file (in File -> New menu)
Then add all your products there. Use the same product id's as in AppStore Connect.
Then add this file to Run Scheme configuration.

I had the same issue, iOS13 Simulators produced the same error, iOS12 Simulators were working well.
I then tried out on the iPhone with iOS13 installed, there the calls were working flawlessly too.
Hoping that it'll be fixed soon in Xcode Simulators, I guess until then we are stuck with the error.
Edit:
Now it seems to work also in iOS 13 Simulator Devices.

Note: I've updated the answer, read the Edit part.
To share my experience, it seems that this problem does not exist any more in Xcode 11.1 GM Seed. There's no need to restart Simulators or Xcode to make in-app purchases work anymore.
I had submitted an app for review and it was rejected because of that particular error. As it turns out, it was rejected for a stupid reason as it wasn't my app's bug, however I spent hours trying to get around it.
So, just update to Xcode 11.1 GM Seed and run again. Everything will be okay.
EDIT
The issue still exists in Xcode 11.1 and apparently I was just lucky that it didn't happen to me again. However, I had a second rejection for the exact same reason. What eventually worked and made my app get approved was this:
I had to update my IAP record on App Store by editing and saving it again.
So, I recommend you to try the same; change something temporarily in your IAPs, save and then revert your changes (and save again) so records on the App Store to be refreshed.
FYI, after the second rejection Apple invalidated my IAP and therefore showed me the way. It looks like to be a known issue to them at the end.
For details read this discussion I wrote on Reddit.

For those that has this issue in iOS 14.0, you still need to create the storekit configuration file as per #silvansky answer. Rather than adding it to the target, we can actully start an SKTestSession before making any product request in order to avoid the error.
if #available(iOS 14.0, *) {
do {
let session = try SKTestSession(configurationFileNamed: "Your_StoreKit_Configuration_File_Name")
session.disableDialogs = true
} catch {
// catch error here
}
// Start your product request here
let productIdentifiers = Set(["product_identifier_1", "product_identifier_2"])
let productsRequest = SKProductsRequest(productIdentifiers: productIdentifiers)
productsRequest.delegate = self
// Run the request
productsRequest.start()
}
You can refer to Apple's documentation for SKTestSession for more info: https://developer.apple.com/documentation/storekittest/sktestsession

Related

iOS 13 - FileManager url(forPublishingUbiquitousItemAt:expiration:) not working anymore

I've developed an iOS app that uses the url(forPublishingUbiquitousItemAt:expiration:) method of Apple's FileManager class. Starting with the first Beta of iOS 13 this function stopped working and now it throws an error, stating "This code has been removed. You should switch off of this SPI". But I can't find anything related to this function neither in the release notes of iOS nor in the documentation for this function, and it even states there that it would be supported on Mac Catalyst 13.0+.
This also has nothing to do with Xcode 10 and 11, as it occurs when the app is built using either one of those versions.
Does anyone of you know more about that? It would be great to get new information on that.
Thanks,
Fabian.
This is fixed in iOS 13 beta 6. Updated today and this error magically disappeared!
Had my mind blown when I saw this error message.

DispatchQueue.main.async availability iOS 10 works on prior iOS

After migration to new swift 3we've got a lot of automatic syntax changes among which:
DispatchQueue.main.async(execute: {
// Do something
})
documentation says that it's available in iOS 10 and later.
So I expected to see unrecognized selector error when running on iOS 8 but it still works.
So I'm just wondering if it would affect some users since our deployment target is iOS 8?
I just tested it on an iPod touch running 8.4 and DispatchQueue.main.async{} works just fine.
The docs are misleading (wrong?)
I went to log a documentation problem, but wait, among lots of other stuff that's been removed from the Xcodebuilt-in documentation system, you can't log issues with the docs anymore!
I suggest filing a radar bug, then.

Keychain error -34018, unable to delete current dictionary

I have an app that is written in Swift 2.3. The app uses the KeychainItemWrapper that makes accessing the Keychain simpler.
When I run the app in the iOS 9.3 simulator with Xcode, the app runs as expected and there are no issues reading/writing to the keychain.
The same exact app, without any changes in my code, crashes with the call to:
- (void)resetKeychainItem
With the line:
SecItemDelete((__bridge CFDictionaryRef)tempDictionary);
Thus making this NSAssert give me my error:
NSAssert( junk == noErr || junk == errSecItemNotFound, #"Problem deleting current dictionary." );
Researching this error by the code 34018 pointed me to other posts with users experiencing a bug with the keychain that was actually brought to the attention of the devs at Apple. It was made a high priority bug, and one post suggested iOS 9.3 had a fix for this (my app works on iOS 9.3!).
However, it is my understanding that Xcode 8 handles such things as code signing differently than previous versions. So I wonder if with iOS 10 if this is a possible new bug.
If anyone has any ideas or experience with this error on iOS 10/Xcode 8... please share your suggestions.

CKQueryOperation iOS 9 only work plugged in

I am using CloudKit in my iOS 9 app and I have a CKQueryOperation that work fine and performs as expected when plugged into the Mac. As soon as the query is run when it is not plugged in to the Mac, it does not finish. There is no error message, the activity indicator I added never stops and the results are never displayed.
If I start the operation when unplugged, then plug it in it completes too.
The code was copied and adapted from an app built in Xcode 6.4 and works as expected in that app.
Any ideas why this could be happening? Could it be anything to do with app thinning in iOS 9?
Thank you
ANSWER
Adding this fixed the issue:
queryOperation.qualityOfService = NSQualityOfService.UserInitiated
The default QoS changed in iOS 9. If the query operation is user initiated, then it needs to be marked as such.
See CKOperation.h and the QualityOfService property.

iOS Keychain writing value results in error code -34018

I have an iOS application that stores some sensitive information in the keychain.
While writing values into the keychain, I am getting error code -34018.
I am currently using Apple's iOS KeyChainItemWrapper class.
Both of the following lines of code receive the same error code.
OSStatus res1 = SecItemCopyMatching((__bridge CFDictionaryRef)genericPasswordQuery, (CFTypeRef *)&attributes);
OSStatus res = SecItemUpdate((__bridge CFDictionaryRef)updateItem, (__bridge CFDictionaryRef)tempCheck);
This issue does not occur every time, but intermittently. Once I get this error, I am no longer able to write any values to the keychain.
I have printed the error description like so:
NSError *error = [NSError errorWithDomain:NSOSStatusErrorDomain code:res userInfo:nil];
and this is what the error prints out:
Error: Error Domain=NSOSStatusErrorDomain Code=-34018 "The operation couldn’t be completed. (OSStatus error -34018.)"
Seems like this is a bug in Keychain, which only appears when you launch your app from xcode. See here: https://github.com/soffes/sskeychain/issues/52
We debugged it a lot and it seems an issue accessing the keychain when
the app is launched from the background. This is only happening with
the debugger (i.e. when launched from Xcode). We think the issue
might be related in our case to the debugger keeping alive the app
even if it should be killed by the OS. We tried in fact to run the
app and then put it in background and launch many other app to occupy
RAM. With the debugger the bug came up when resuming the app from the
background, while without the debugger it didn't (we did run at least
10 tests each).
If someone will come here back with this error and XCode8 with iOS10, probably you have to enable KeyChain Share in the tab Capabilities:
As others have mentioned, this is a Keychain bug, one that Apple is aware of and has been aware of since at least mid-2015.
As of March 22, 2016, however, Apple has said:
We believe these problems were resolved in iOS 9.3.
iOS 9.3 was released on March 21, 2016.
See the thread: https://forums.developer.apple.com/thread/4743
To quote the response by an Apple employee:
Mar 22, 2016 3:28 AM
OK, here’s the latest. This is a complex problem with multiple possible causes:
Some instances of the problem are caused by incorrect app signing. You can easily distinguish this case because the problem is 100% reproducible.
Some instances of the problem are caused by a bug in how iOS supports app development (r. 23,991,853). Debugging this was complicated by the fact that another bug in the OS (r. 23,770,418) masked its effect, meaning the problem only cropped up when the device was under memory pressure.
We believe these problems were resolved in iOS 9.3.
We suspect that there may be yet more causes of this problem.
So, if you see this problem on a user device (one that hasn’t been talked to by Xcode) that’s running iOS 9.3 or later, please do file a bug report about it. Try to include the device system log in your bug report (I realise that can be tricky when dealing with customer devices; one option is to ask the customer to install Apple Configurator, which lets them view the system log). And if you do file a bug, please post your bug number, just for the record.
On behalf of Apple I’d like to thank everyone for their efforts in helping to track down this rather horrid issue.
Share and Enjoy
This held me up for 2 hours before I found a quick "fix" - reboot the iOS device
A quote from the discussion at http://forums.developer.apple.com/thread/4743,
From user littledetails
As others have reported, this mysterious keychain error is most easily observable when launching via Xcode with the debugger attached. Once the error starts occurring, the keychain doesn't seem to right itself regardless of memory pressure until one reboots the device.
When I rebooted my device the error went away, allowing me to continue testing. Not sure what else to do. In my situation, moving to NSUserDefaults or some other storage solution was not a possibility.
One way to get around this issue with the keychain is to use dispatch_async to allow the app to launch. This works when the app is opened from the background. Also make sure you have the kSecAttrAccessibleAfterFirstUnlock accessibility setting on the keychain.
dispatch_async(dispatch_get_main_queue(), ^{
// save/write to keychain
})
I am using GenericKeychain classes from apple:
https://developer.apple.com/library/content/samplecode/GenericKeychain/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007797-Intro-DontLinkElementID_2
struct KeychainConfiguration {
static let serviceName = "MyAppService"
/*
Specifying an access group to use with `KeychainPasswordItem` instances will create items shared accross both apps.
For information on App ID prefixes, see:
https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/AppID.html
and:
https://developer.apple.com/library/ios/technotes/tn2311/_index.html
*/
// static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"
/*
Not specifying an access group to use with `KeychainPasswordItem` instances
will create items specific to each app.
*/
static let accessGroup: String? = nil
}
In this file I was specifying my custom accessGroup in this line static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"
After returning to static let accessGroup: String? = nil the problem was gone. :)
Make sure keychain sharing must on under Capabilities in project Target.
In my case the App_Name.entitlements file has different bundle id than of my project bundle id. So, I change bundle id in the App_Name.entitlements file as of my project bundle id.
e.g., Suppose your project bundle id is com.Apple.testApp then got to
App_Name.entitlements file open key Keychain Access Groups key which is of Array type.
Under item0 set value of your project bundle id as eg:- $(AppIdentifierPrefix)com.Apple.testAp.
According to #iCaramba's answer. I've found a workaround:
Stop the task to kill the app (if you are already running the app)
Launch the app on your device manually. DO NOT use Xcode
Use Xcode to re-launch the app

Resources