Facebook’s SDK is once again causing numerous iOS apps to crash on launch.

The current Facebook Developer Policy requires that developers use the official Facebook SDK when implementing Facebook Login in their native app. Given that Facebook cannot ensure the stability of their SDK (resulting in the crashing of client apps), developers should have a policy-compliant option for implementing the login API themselves to avoid Facebook’s QA practices rendering their apps unusable.

Must be nice for Facebook to have the apparent blame fall on other developers and Apple because no user is going to think “Spotify crashed on my iPhone because of Facebook”. Also, notice that this doesn’t happen to Facebook’s own apps.

In Swift 5.3, however, using self in the above kind of situation is no longer required, and we can simply access properties and methods belonging to value types (such as SwiftUI views, or any other type of struct) without any additional prefixes — regardless if that’s done within an escaping closure or not[…]

That’s really neat, and further makes SwiftUI’s DSL feel even more lightweight. However, it’s important to remember that the same kind of capturing still occurs — meaning that the above ListView value (and the ListViewModel instance that it contains) will still be captured by our closures. Within the context of SwiftUI, though, that’s not likely to become a problem — since SwiftUI views are just lightweight structs that don’t hold any strong references to their subviews.

Whenever self is declared explicitly in an escaping closure’s capture list, or its type is a value type, any code inside that closure can use names which resolve to members of the enclosing type, without specifying self. explicitly.

[…]

While this proposal opens up implicit self in situations where we can be reasonably sure that we will not cause a reference cycle, there are other cases where implicit self is currently allowed that we may want to disallow in the future. One of these is allowing bound method references to be passed into escaping contexts without making it clear that such a reference captures self.

It would be nice to concisely say that a closure should be discarded when a weakly-captured param goes away. I imagined what that could look like and now I want @ClosureWrapper.