Swift 6 crash calling requestAutomaticPassPresentationSuppression

I found a similar problem here https://developer.apple.com/forums/thread/764777 and I could solve my problem by wrapping the call to requestAutomaticPassPresentationSuppression in a call to DispatchQueue.global().async.

But my question is if this is really how things should work. Even with strict concurrency warnings in Swift 6 I don't get any warnings. Just a runtime crash.

How are we supposed to find these problems? Couldn't the compiler assist with a warning/error.

Why does the compiler make the assumptions it does about the method that is declared like this:

@available(iOS 9.0, *)
open class func requestAutomaticPassPresentationSuppression(responseHandler: @escaping (PKAutomaticPassPresentationSuppressionResult) -> Void) -> PKSuppressionRequestToken

Now that we have migrated to Swift 6 our code base contains a bunch of unknown places where it will crash as above.

Answered by DTS Engineer in 825626022
Written by Roland4711 in 774718021
But my question is if this is really how things should work.

Well, it kinda depends on your definition of “should” (-:

As things currently stand, if an API is not annotated correctly then the only way you hear about it is via a trap at runtime. This isn’t ideal, as you’ve noted, but it’s better than the Swift 5 behaviour, where your callback ends up running, but on the wrong thread, potentially corrupting things as it goes.

As to the big picture, I think it’s safe to say that there’s significant demand for improvements in this space (-: In fact, Swift Evolution has recently published a “vision” document that’s covers this overall issue.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Written by Roland4711 in 774718021
But my question is if this is really how things should work.

Well, it kinda depends on your definition of “should” (-:

As things currently stand, if an API is not annotated correctly then the only way you hear about it is via a trap at runtime. This isn’t ideal, as you’ve noted, but it’s better than the Swift 5 behaviour, where your callback ends up running, but on the wrong thread, potentially corrupting things as it goes.

As to the big picture, I think it’s safe to say that there’s significant demand for improvements in this space (-: In fact, Swift Evolution has recently published a “vision” document that’s covers this overall issue.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Swift 6 crash calling requestAutomaticPassPresentationSuppression
 
 
Q