@ObservedObject: qué es, observación de objetos y actualización de Views

Qué es @ObservedObject en SwiftUI

@ObservedObject es un property wrapper que suscribe una View a los cambios de ObservableObject. Cuando un objeto marcado con @ObservedObject cambia alguna de sus propiedades declaradas con @Published, SwiftUI redibuja automáticamente la View. @ObservedObject no crea el objeto — solo establece una conexión entre una instancia existente de ObservableObject y la View que debe reaccionar a sus cambios.

La diferencia clave entre @ObservedObject y @StateObject es la propiedad. @ObservedObject asume que el objeto se crea y almacena en algún lugar más arriba en la jerarquía de Views. La View hija recibe una referencia a este objeto a través del inicializador y simplemente lo observa. Si la View hija se recrea, recibe la misma referencia del padre — los datos no se pierden.

Según Apple Developer Documentation — SwiftUI (2025), @ObservedObject está disponible desde iOS 13, lo que lo convierte en la única opción para observar ObservableObject en proyectos que admiten versiones antiguas de iOS. En iOS 14+ se prefiere @StateObject para crear objetos, pero @ObservedObject sigue siendo relevante para pasar objetos existentes.

Cómo funciona @ObservedObject

El mecanismo de @ObservedObject se basa en el protocolo ObservableObject del framework Combine. Cada clase que conforma ObservableObject obtiene automáticamente un publisher objectWillChange que envía una señal antes de que cualquier propiedad @Published cambie. SwiftUI se suscribe a este publisher a través de @ObservedObject y al recibir la señal marca la View como necesitada de redibujado.

class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var isLoading = false
    
    func loadTasks() async {
        isLoading = true
        // fetch data
        isLoading = false
    }
}

struct TaskListView: View {
    @ObservedObject var viewModel: TaskViewModel
    
    var body: some View {
        List(viewModel.tasks) { task in
            Text(task.title)
        }
        .task { await viewModel.loadTasks() }
    }
}

Cuando la View padre pasa viewModel a TaskListView a través del inicializador, SwiftUI crea una conexión entre el objeto y la View. Cuando el array tasks o el flag isLoading cambian, SwiftUI redibuja TaskListView. El objeto en sí permanece sin cambios — se almacena en la View padre a través de @StateObject.

@ObservedObject vs @StateObject: cuándo usar cada uno

La diferencia entre @ObservedObject y @StateObject es la diferencia entre un observador y un propietario. @StateObject crea el objeto y gestiona su ciclo de vida. @ObservedObject solo observa un objeto que fue creado y almacenado en otro lugar. La elección entre ellos está determinada por la responsabilidad de la View sobre los datos.

La regla principal: si la View crea el objeto — @StateObject. Si la View recibe el objeto — @ObservedObject. Violar esta regla usando @ObservedObject para crear un objeto provoca pérdida de datos cuando la View se reconstruye. Violarla usando @StateObject para recibir un objeto crea una instancia duplicada independiente del padre.

Ejemplos de uso de @ObservedObject

Un escenario típico de uso de @ObservedObject es una lista de tareas donde la View raíz crea un view model y cada celda de la lista lo recibe a través de @ObservedObject. Cada celda puede llamar a métodos del view model, y los cambios se reflejan automáticamente en toda la lista ya que todas las celdas observan el mismo objeto.

struct TaskRow: View {
    @ObservedObject var viewModel: TaskViewModel
    let task: Task
    
    var body: some View {
        HStack {
            Text(task.title)
            Spacer()
            Button("Done") {
                viewModel.completeTask(task)
            }
        }
    }
}

struct TaskListContainer: View {
    @StateObject var viewModel = TaskViewModel()
    
    var body: some View {
        List(viewModel.tasks) { task in
            TaskRow(viewModel: viewModel, task: task)
        }
    }
}

En este ejemplo, TaskListContainer crea viewModel a través de @StateObject, y cada TaskRow lo recibe a través de @ObservedObject. Cuando el usuario presiona “Done” en cualquier fila, viewModel.completeTask cambia una propiedad publicada, y todas las Views que observan este objeto se actualizan automáticamente.

Errores comunes con @ObservedObject

El error más común es usar @ObservedObject para crear un objeto dentro de una View. Cuando la View se reconstruye (por ejemplo, al cambiar el estado), SwiftUI crea una nueva instancia de ObservableObject, lo que provoca la pérdida de todos los datos acumulados. Este error es especialmente doloroso en NavigationStack, donde un usuario podría rellenar un formulario y perder los datos al navegar hacia atrás.

Error: @ObservedObject en lugar de @StateObject

// ❌ Pérdida de datos: @ObservedObject no retiene el objeto
struct FormView: View {
    @ObservedObject var formVM = FormViewModel()
    // ¡Nuevo formVM creado en cada reconstrucción de View!
}

// ✅ Correcto: @StateObject retiene el objeto
struct FormView: View {
    @StateObject var formVM = FormViewModel()
    // Objeto creado una vez por ciclo de vida de la View
}

Error: pasar @StateObject donde se necesita @ObservedObject

Si una View hija declara el mismo ObservableObject a través de @StateObject, crea una copia independiente. Los cambios en el objeto padre no serán visibles en la hija, y viceversa. Usa siempre @ObservedObject para Views hijas que reciben el objeto externamente.

Alternativas a @ObservedObject en SwiftUI

En SwiftUI moderno existen varias alternativas a @ObservedObject, cada una con sus ventajas. La elección depende de la arquitectura de la aplicación, la versión de iOS y el caso de uso específico.

• @EnvironmentObject — permite obtener un objeto del entorno SwiftUI sin pasarlo explícitamente a través del inicializador. Conveniente para objetos necesarios en muchas pantallas, pero requiere inyección explícita mediante .environmentObject().
• @State + @Binding — para tipos de valor simples no se necesita ObservableObject. Usa @State para almacenar y @Binding para pasar a Views hijas.
• @AppStorage — para valores de UserDefaults que deben sincronizarse automáticamente con la View.
• @SceneStorage — para preservar el estado temporal entre reinicios de escena (por ejemplo, posición de desplazamiento en una lista).

La elección entre @ObservedObject y @EnvironmentObject es una cuestión de estilo y arquitectura. @ObservedObject muestra explícitamente las dependencias de la View a través del inicializador, haciendo el código más predecible. @EnvironmentObject es conveniente para jerarquías profundas pero oculta las dependencias, lo que puede dificultar la depuración.