ViewController Lifecycle in iOS: concetti chiave, fasi e metodi

Cos’è il ViewController Lifecycle

ViewController Lifecycle è un insieme di metodi che UIViewController riceve da UIKit durante la sua esistenza. Ogni schermo in un’app iOS passa sequenzialmente attraverso le fasi di creazione, caricamento della View, comparsa sullo schermo, scomparsa e rilascio della memoria. UIKit chiama automaticamente i metodi corrispondenti in ogni fase e lo sviluppatore li sovrascrive per aggiungere la propria logica.

L’architettura di UIViewController è fondamentale per UIKit e rimane rilevante anche nell’era di SwiftUI — molti progetti utilizzano ancora l’approccio classico o un’architettura ibrida. Comprendere il Lifecycle permette di prevedere quando le subviews sono disponibili, quando è sicuro modificare il layout e quali operazioni eseguire alla comparsa o scomparsa dello schermo.

Ogni metodo del ciclo di vita ha uno scopo specifico: alcuni vengono chiamati una sola volta durante l’intera vita del controllore, altri — a ogni comparsa o scomparsa. Mescolare la logica tra i metodi porta a bug difficili da trovare: perdite di memoria, aggiornamenti errati dei dati e richieste di rete non necessarie.

Ciclo completo dei metodi di UIViewController

Sei metodi formano il ciclo di vita completo di UIViewController. L’ordine di chiamata è fisso e non dipende dal metodo di navigazione — push, present o unwind segue seguono tutti lo stesso programma.

loadView — creazione della View radice

loadView è il primo metodo del ciclo, chiamato quando la View del controllore non esiste ancora. Se si utilizza Storyboard, UIKit carica automaticamente la View dal file xib. Quando si crea l’interfaccia programmaticamente, si sovrascrive questo metodo assegnando la View radice manualmente. Nella maggior parte dei progetti, loadView non viene toccato — il lavoro viene svolto in viewDidLoad.

Sovrascrivere loadView è necessario solo in casi specifici: quando l’intera interfaccia viene creata in codice senza Storyboard, o quando la View radice deve essere di una classe non standard. Apple raccomanda di non chiamare super.loadView durante la sovrascrittura — si assume la piena responsabilità della creazione della View.

override func loadView() {
    view = UIView()
    view.backgroundColor = .white
}

viewDidLoad — inizializzazione una tantum

viewDidLoad è il metodo più utilizzato del ciclo. Viene chiamato una volta dopo che la View è stata caricata in memoria ma non è ancora visualizzata sullo schermo. Qui si configurano le subviews, si riempiono le tabelle con i dati, si registrano le celle e ci si abbona alle notifiche che durano per tutta la vita del controllore.

Una caratteristica importante: viewDidLoad non viene chiamato di nuovo quando lo schermo viene visualizzato nuovamente. Se è necessario aggiornare i dati ogni volta che lo schermo appare — utilizzare viewWillAppear. In viewDidLoad inserire solo operazioni una tantum necessarie per la configurazione di base.

viewWillAppear — preparazione prima della visualizzazione

viewWillAppear viene chiamato ogni volta immediatamente prima che la View diventi visibile all’utente. Questo metodo riceve un parametro animated che indica se la comparsa è animata. Qui si aggiornano i dati, si ricaricano le tabelle, si configura la NavigationBar e si nascondono o mostrano gli elementi in base allo stato dell’applicazione.

Utilizzare viewWillAppear per la sincronizzazione dello stato tra schermate: se l’utente potrebbe aver modificato i dati nella schermata precedente, questo metodo è il luogo appropriato per aggiornare l’interfaccia. Ogni chiamata a viewWillAppear precede la comparsa dello schermo, anche quando si ritorna da un controllore figlio.

viewDidAppear — schermo completamente visibile

viewDidAppear notifica che la View è apparsa completamente sullo schermo e tutte le animazioni di transizione sono completate. A questo punto, lo schermo è pronto per l’interazione — l’utente vede l’interfaccia completa e può interagire con essa. Questo metodo è adatto per avviare animazioni che devono iniziare dopo la comparsa, avviare timer e tracciare le impressioni di analisi.

A differenza di viewWillAppear, viewDidAppear garantisce che lo schermo non solo sia visibile ma anche completamente renderizzato. Se si avvia un’animazione in viewWillAppear, alcuni fotogrammi potrebbero essere saltati perché UIKit non ha ancora completato la transizione. Per animazioni fluide, utilizzare viewDidAppear.

viewWillDisappear — preparazione alla scomparsa

viewWillDisappear viene chiamato prima che la View scompaia dallo schermo — quando si passa a un altro controllore, si chiude una finestra modale o si sospende l’app. Questo è il luogo appropriato per salvare lo stato, annullare l’iscrizione alle notifiche, fermare i processi attivi e rilasciare le risorse che non servono quando lo schermo non è visibile.

È importante ricordare: viewWillDisappear non garantisce che la View scomparirà effettivamente — il gesto potrebbe essere annullato. Pertanto, salvare i dati critici anche in viewDidDisappear, che viene chiamato solo dopo la scomparsa effettiva.

viewDidDisappear — schermo nascosto

viewDidDisappear completa il ciclo di comparsa e scomparsa. Viene chiamato dopo che la View è già nascosta dallo schermo. In questo metodo, le animazioni vengono finalmente fermate, gli oggetti temporanei vengono rimossi e il salvataggio dei dati iniziato in viewWillDisappear viene confermato.

Questo metodo precede anche il deinit del controllore — se il UIViewController viene distrutto, viewDidDisappear sarà l’ultimo metodo del Lifecycle prima che venga chiamato deinit. Utilizzarlo per la pulizia finale che deve avvenire prima della distruzione dell’oggetto.

Quando viene chiamato ogni metodo

La sequenza delle chiamate dipende da come appare lo schermo: per la prima volta, quando si torna indietro o quando viene presentato modalmente. Consideriamo tre scenari principali dal punto di vista di UIKit.

Ordine alla prima apertura

Quando uno schermo appare per la prima volta, UIKit attraversa il ciclo completo di creazione: viene chiamato loadView, poi viewDidLoad, dopodiché inizia l’animazione di comparsa. Durante l’animazione, viene chiamato viewWillAppear, e dopo il completamento — viewDidAppear. Questo è l’unico scenario in cui tutti i metodi da loadView a viewDidAppear si attivano sequenzialmente.

override func viewDidLoad() {
    super.viewDidLoad()
    print("viewDidLoad — View caricata in memoria")
}

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    print("viewWillAppear — Sta per apparire")
}

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    print("viewDidAppear — Schermo completamente visibile")
}

Ordine quando si torna indietro

Quando l’utente torna a uno schermo precedente, UIKit non chiama di nuovo viewDidLoad — la View è già caricata in memoria. Invece, vengono chiamati solo viewWillAppear e viewDidAppear sullo schermo di ritorno, e su quello corrente — viewWillDisappear e viewDidDisappear. loadView e viewDidLoad vengono saltati poiché lo schermo esiste già nello stack di navigazione.

Casi particolari con present e dismiss

La presentazione modale segue le stesse regole: il nuovo controllore attraversa il ciclo completo alla prima comparsa, mentre quello corrente riceve viewWillDisappear e viewDidDisappear. Al dismiss, l’ordine si inverte: il controllore di ritorno ottiene di nuovo viewWillAppear e viewDidAppear, mentre quello respinto riceve i metodi finali. Questo comportamento è uniforme per tutti i tipi di transizione in UIKit.

Scenari pratici di utilizzo

Esaminiamo quattro scenari chiave in cui la comprensione del Lifecycle influisce direttamente sulla qualità del codice e sull’esperienza utente. Per ogni scenario, forniamo un esempio con raccomandazioni.

Inizializzazione dei dati in viewDidLoad

viewDidLoad è il luogo per la configurazione iniziale che non dipende dalla visibilità dello schermo. Qui si configura il collectionView, si registrano i file nib per le celle, si creano le fonti dati e i layout. Se si stanno caricando dati dalla rete, in viewDidLoad è meglio solo avviare la richiesta e aggiornare l’UI in viewWillAppear quando lo schermo è pronto per la visualizzazione.

override func viewDidLoad() {
    super.viewDidLoad()
    tableView.register(
        MyCell.self,
        forCellReuseIdentifier: MyCell.identifier
    )
    viewModel.loadInitialData()
}

Aggiornamento del contenuto in viewWillAppear

Utilizzare viewWillAppear per la sincronizzazione dei dati ogni volta che lo schermo appare. Ad esempio, se l’utente potrebbe aver modificato le impostazioni nello schermo precedente, qui si aggiornano i valori visualizzati, si ricarica la tabella e si regola lo stato della NavigationBar. Questo garantisce che lo schermo mostri sempre dati aggiornati in qualsiasi scenario di navigazione.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    navigationController?.setNavigationBarHidden(false, animated: animated)
}

Analisi e animazioni in viewDidAppear

viewDidAppear è ideale per avviare animazioni che devono iniziare dopo che l’utente ha visto lo schermo. Qui si inviano anche eventi di analisi: visualizzazione dello schermo, avvio dell’onboarding o riproduzione video. Avviare le animazioni prima del completamento della transizione porta a un’interfaccia a scatti — UIKit non ha abbastanza tempo per preparare un numero sufficiente di fotogrammi.

Salvataggio dello stato in viewWillDisappear

In viewWillDisappear, si salvano le bozze, si fermano i timer e si annulla l’iscrizione a NotificationCenter. Questo è l’ultimo momento in cui lo schermo è ancora visibile e accessibile per operazioni che richiedono il contesto dell’utente. Per i dati critici, utilizzare anche viewDidDisappear come protezione contro i gesti annullati.

Errori comuni nel lavoro con Lifecycle

L’uso errato dei metodi del ciclo di vita è una delle fonti più frequenti di bug nelle app iOS. Esaminiamo i principali errori che gli sviluppatori commettono in diverse fasi del lavoro con UIViewController.

Il primo errore — creare subviews in init o loadView quando si utilizza Storyboard. Se si sta usando Interface Builder, non sovrascrivere loadView inutilmente. Creare una View in loadView quando esiste uno storyboard porta all’ignorare il file xib e a uno schermo vuoto.

Il secondo errore — abbonarsi alle notifiche della tastiera in viewDidLoad senza annullare l’iscrizione. Se ci si è abbonati a UIResponder.keyboardWillShowNotification ma non si è annullata l’iscrizione quando lo schermo viene nascosto, il blocco continuerà a essere chiamato anche dopo il deinit del controllore — questa è una perdita di memoria con potenziale crash dell’app.

Il terzo errore — timer e richieste di rete avviati prima che lo schermo appaia. Caricare immagini o eseguire animazioni quando la View non è ancora visibile è uno spreco di risorse. Spostare gli aggiornamenti visivi in viewWillAppear o viewDidAppear.

Il quarto errore — salvare i dati solo in viewWillDisappear. Con un gesto di pop interattivo, l’utente può iniziare uno swipe e annullarlo — il metodo è stato chiamato ma lo schermo non è scomparso. Duplicare il salvataggio critico in viewDidDisappear o nel gestore applicationDidEnterBackground.