Archive for July 13, 2020

Monday, July 13, 2020 [Tweets] [Favorites]

Another Facebook SDK Crash

John Sundell (also: Hacker News):

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

Here are some of the GitHub issues. It seems like another case of a server change causing an unexpected JSON value to be returned.

Jumhyn:

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.

See also: SDKs should not crash apps — learnings from the Facebook outage.

Previously:

Update (2020-07-30): Nick Heer:

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.

Implicit Capturing of Self in Swift 5.3

John Sundell:

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.

This is perhaps confusing, but it doesn’t seem like it will cause unwanted captures because it’s limited to value types.

SE-0269:

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.

I still think closures are an area of Swift that needs work. I wish it were harder to accidentally strongly capture self in reference types and less verbose to use it weakly.

Previously:

Update (2020-07-30): Sami Samhuri:

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.