Should I use [weak self] when calling an API in Swift

I'm not sure if I should use [weak self] when calling an API in Swift.
I'm creating a user with Firebase, and if the user is created successfully, I want to use self to perform a segue.

This is my code:

import UIKit 
import FirebaseAuth

class RegisterViewController: UIViewController {

  @IBOutlet weak var emailTextfield: UITextField!
  @IBOutlet weak var passwordTextfield: UITextField!

  @IBAction func registerPressed(_ sender: UIButton) {
    if let email = emailTextfield.text, let password = passwordTextfield.text {
        Auth.auth().createUser(withEmail: email, password: password) { authResult, error in
            if let e = error {
                print(e)
            } else {
                self.performSegue(withIdentifier: "registerToChat", sender: self)
            }
        }
    }
  }}

The code is working, but I'm not sure what would happen if the Firebase API request doesn't work or is delayed for a long time, and the self pointer of the RegisterViewController doesn't get deallocated.
Therefore, I would also like to discuss the general practice of using APIs that may experience delays, and whether it is advisable to always use [weak self] in such cases.

In your example, you almost certainly would use weak reference to self. It would make no sense to perform the segue if the view controller had been dismissed. And while there is no persistent strong reference cycle risk here, there simply is no reason to keep this view controller in memory longer than is needed. Using weak reference allows the view controller to be deallocated as soon as it is no longer needed, and it will not have to wait for the asynchronous call to complete. Using weak references can be a good defensive programming pattern.

Hopefully that answers the question regarding your specific question, but more generally, there are a number of considerations:

1. It is not a concern here, but we will often use weak references to eliminate the possibility of persistent strong reference cycles (in those cases where the closure might be saved in some property and the API service neglects to release this closure when it was done). This is generally not a concern in mature API, like Firebase, but becomes more of a concern in home-spun API or services, which might not pay attention to these sorts of details. We often will use weak references in a defensive manner when we might not be entirely sure how disciplined the library might be with respect to its memory semantics.

2. When dealing with a caller that is something other than a view controller (view controllers, as a rule, should be released as soon as the associated view is dismissed; the same might not be true for some service class), it raises whether you want to keep a strong reference until the request finishes or not.

   E.g., by design, if you use delegates with URLSession, it keeps a strong reference to its delegate until the session is invalidated. Other services might not do that. Regardless, there are definitely use-cases where, having started some asynchronous request, the caller might want to save the results in some model object or cache, regardless of whether the view was dismissed or not. In edge cases like this, you might consciously want a temporary strong reference to self until the request finishes.

3. While you are focusing on memory semantics, often the broader question is “what should happen when the caller is deallocated”. Specifically, when dealing with cancelable API, rather than worrying about the lifecycle of the caller, we instead focus on the lifecycle of the called API. Specifically, we might explicitly cancel the request as soon as its results are no longer needed. In that scenario, you not only free the resources of self, but also those of the API service, too.

   Now, in your example, the Auth may not support cancelation. If not, this issue is moot. But in cases where the API does support cancelation, rather than dwelling on “should I keep a strong reference until the request is done”, you should focus on “if the caller is dismissed before the asynchronous request finishes, should I just immediately stop/cancel the asynchronous API?”

So, the short answer to “should I always use weak references” is, “often, but it depends.” Generally we gravitate to weak references, but there are lots of use-cases where we might consciously use strong references or pursue proactive cancelation patterns.

There is a final, loosely related question, unrelated to the memory semantics. Namely, what you may want to have happen if the user completely leaves the app while the asynchronous request is in progress? Sometimes (especially with uploads, post requests, etc.), the app may want to ask the OS for a little extra time in case the user leaves the app while the request is underway. E.g., in iOS, we might Continue Foreground Work in the Background.

You should use [weak self] inside a Closures to avoid giving the strong reference and avoid the reference cycle. You can see this documentation to understand whether we should use [weak self] inside closures all the time or not.

See You don’t (always) need [weak self] or Understanding Weak and Unowned References in Swift Closures.

And for API calling it is a good practice to use [weak self] or perform asynchronous operations to prevent strong reference cycles and potential memory leaks.