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.
Related
Since my latest update of Xcode, I get repeatedly the following log in my Coredata based app:
[logging] flag(s) 0x00000020 are reserved for VFS use and do not affect behaviour when passed to sqlite3_open_v2
Is this simply log noise or is it in any way relevant to me?
Update:
This happens under Xcode 13.2.1 on an iPhone with iOS 15.4. It does not happen on a Simulator with iOS 15.2.
I'm pretty sure this is something you can ignore, that will probably be fixed when iOS 15.4 is out of beta.
According to the SQLite file-open flag documentation,
Flag value 0x00000020 is SQLITE_OPEN_AUTOPROXY, for what that's worth
This flag is one of several flags that "...have historically been ignored by sqlite3_open_v2()", however...
"...future versions of SQLite might change so that an error is raised if any of the disallowed bits are passed into sqlite3_open_v2()"
What this seems to say is that the flag has no effect and hasn't had one for a while, so it doesn't matter if Core Data is using it internally. The message probably means that iOS 15.4 has a newer version of SQLite which has started to print warnings about it but hasn't started causing errors yet.
I'd expect this to be fixed when 15.4 is released, and in the meantime I encourage you to file a bug with Apple just in case.
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
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.
Has anyone else encountered this? Specifically with an iPhone 6 running iOS 10.0 I'm getting consistent reports of the following crashing:
if #available(iOS 10.0, *) {
UISelectionFeedbackGenerator()
}
Where it's not even being used, just created and it causes an EXC_BAD_ACCESS crash. The docs say it just fails silently if the device doesn't support it. Oddly enough if I change the check to iOS 10.0.1 it works fine.
Am I doing something wrong?
I saw a few seemingly random crashes in production when calling this function as well. When reviewing some old logs, I found that this was only occurring on iOS 10.0.0. As users updated past that, I stopped seeing the crash. I imagine it was some sort of internal UIKit bug that was fixed in iOS 10.0.1.
In my app, I would like to know if the user has setup a passcode or fingerprint (touchID). There's a pretty easy method just for that: [LAContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthentication error:error].
However, Apple's docs say LAPolicyDeviceOwnerAuthentication is only available on iOS9 and above. I would rather not crash iOS 8 users without explanation, even if it is getting older. The thing is, I've tried it on an iOS8.4 simulator, and it seems to compile and just work.
What ill effects can happen if I use LAPolicyDeviceOwnerAuthentication on iOS 8?
I use code similar to this:
LAPolicy localAuthPolicy = LAPolicyDeviceOwnerAuthenticationWithBiometrics;
if (![[UIDevice currentDevice].systemVersion hasPrefix:#"8."]) {
localAuthPolicy = LAPolicyDeviceOwnerAuthentication;
}
This ensures I only use LAPolicyDeviceOwnerAuthentication on iOS 9 and later.
It's undocumented what actually happens on an iOS 8 device when you attempt to use LAPolicyDeviceOwnerAuthentication. It's very unlikely anything will crash but the authentication may return NO due to an unknown value or it may succeed because iOS 8 only had one valid value and it may not do any checking.
Unfortunately Objective-C doesn't provide any runtime checks for valid enum values like you can do with constants, methods, and classes.
If you use LAPolicyDeviceOwnerAuthentication on anything below iOS 9, the app will crash. That is what happened to my app when I didn't realize that this was not available on anything below iOS 9, but my app supported iOS 8.x as its minimum supported OS version.