@Published properties in iOS Swift - Deep Dive

Overview - @Published properties

What is it?

@Published is a special marker in Swift used with properties inside classes that conform to ObservableObject. It automatically announces when the property's value changes, so the user interface can update itself without extra code. This helps keep the app's data and UI in sync smoothly. It is mainly used in SwiftUI apps to make reactive and dynamic interfaces.

Why it matters

Without @Published, developers would have to manually tell the UI when data changes, which is error-prone and tedious. This could lead to outdated screens or bugs where the app shows wrong information. @Published solves this by automating change notifications, making apps more reliable and easier to build. It improves user experience by keeping the app responsive and up-to-date.

Where it fits

Before learning @Published, you should understand Swift classes, properties, and basic SwiftUI views. After mastering @Published, you can learn about ObservableObject, Combine framework basics, and advanced state management in SwiftUI apps.

Mental Model

Core Idea

@Published properties automatically broadcast changes so the UI can react and update instantly without manual intervention.

Think of it like...

Imagine a classroom where a student raises their hand every time they have a new idea. The teacher (UI) notices immediately and writes it on the board. @Published is like the student raising their hand to signal a change.

ObservableObject Class
  ├─ @Published property 1 ──> Notifies UI on change
  ├─ @Published property 2 ──> Notifies UI on change
  └─ Other properties (no notification)

UI View listens to ObservableObject
  └─ Updates automatically when notified

Build-Up - 7 Steps

1

Foundation

Understanding Swift Properties

Concept: Learn what properties are in Swift and how they store data inside classes.

In Swift, properties are variables or constants inside classes or structs that hold data. For example, a class Person can have a property name to store the person's name. Properties can be changed or read to keep track of information.

Result

You can create and use properties to store and access data inside your Swift classes.

Knowing how properties work is essential because @Published modifies how properties behave by adding automatic notifications.

2

Foundation

Introduction to ObservableObject

Concept: Discover the ObservableObject protocol that allows classes to broadcast changes to their data.

ObservableObject is a protocol in SwiftUI that classes can adopt to let views watch for changes. When data inside an ObservableObject changes, it can notify any views that depend on it to refresh automatically.

Result

Classes conforming to ObservableObject can be observed by SwiftUI views for changes.

Understanding ObservableObject sets the stage for using @Published, which works inside these classes to mark which properties send updates.

3

Intermediate

Using @Published to Mark Properties

🤔Before reading on: do you think @Published properties notify changes automatically or require manual calls? Commit to your answer.

Concept: @Published is a property wrapper that marks properties to automatically announce changes to observers.

By adding @Published before a property, SwiftUI knows to watch it. When the property's value changes, it sends a signal to update any views using that data. For example: class Counter: ObservableObject { @Published var count = 0 } Changing count triggers UI updates.

Result

Any SwiftUI view observing this class will refresh when count changes.

Knowing that @Published automates change announcements removes the need for manual update code, simplifying reactive UI design.

4

Intermediate

Connecting @Published with SwiftUI Views

🤔Before reading on: do you think SwiftUI views update automatically when @Published properties change, or do you need extra code? Commit to your answer.

Concept: SwiftUI views can observe ObservableObject classes and update automatically when @Published properties change.

To connect, use @StateObject or @ObservedObject in your view to watch the ObservableObject. For example: struct ContentView: View { @StateObject var counter = Counter() var body: some View { Text("Count: \(counter.count)") } } When counter.count changes, the Text updates automatically.

Result

The UI stays in sync with data changes without manual refresh calls.

Understanding this connection is key to building dynamic interfaces that react to data changes smoothly.

5

Intermediate

Limitations of @Published Properties

Concept: @Published works well for simple properties but has limits with complex data types or nested changes.

@Published only notifies when the property itself changes. If the property is a class or struct with internal data, changing internal parts may not trigger updates. For example, changing an element inside an array marked @Published won't notify automatically unless the whole array is replaced.

Result

Developers must manage complex data carefully to ensure UI updates correctly.

Knowing these limits helps avoid bugs where UI does not update as expected due to subtle data changes.

6

Advanced

Custom Publishers and Manual Notifications

🤔Before reading on: can you manually trigger change notifications without @Published? Commit to your answer.

Concept: You can create custom publishers or manually send change notifications for more control beyond @Published.

ObservableObject requires a publisher called objectWillChange. @Published automatically sends signals to it. But you can also send signals yourself: import Combine class CustomModel: ObservableObject { let objectWillChange = PassthroughSubject() var value: Int = 0 { willSet { objectWillChange.send() } } } This approach allows fine control over when views update.

Result

You can optimize or customize UI updates beyond what @Published offers.

Understanding manual notifications reveals how @Published works under the hood and when to use custom solutions.

7

Expert

Performance Implications and Best Practices

🤔Before reading on: do you think marking many properties @Published always improves performance? Commit to your answer.

Concept: Using @Published on many properties or large data can cause unnecessary UI updates and performance issues.

Each @Published property change triggers UI refreshes. If many properties change frequently, or if large data structures are marked @Published, the app may slow down. Best practice is to minimize @Published usage to only essential properties and batch updates when possible.

Result

Apps remain smooth and responsive by avoiding excessive change notifications.

Knowing performance trade-offs helps build efficient apps and avoid common pitfalls with reactive programming.

Under the Hood

@Published is a property wrapper that creates a publisher for the property's value. When the property changes, it automatically sends a signal through the Combine framework's publisher to the ObservableObject's objectWillChange publisher. SwiftUI subscribes to this publisher and refreshes views when it receives a signal. This chain allows seamless reactive updates without manual wiring.

Why designed this way?

SwiftUI and Combine were designed to simplify reactive programming by automating change notifications. @Published abstracts away boilerplate code, making it easy for developers to mark properties for observation. This design reduces errors and improves code clarity compared to manual notification methods used before Combine.

┌─────────────────────┐
│ @Published Property  │
│  (wrapped value)     │
└─────────┬───────────┘
          │ change triggers
          ▼
┌─────────────────────┐
│ Publisher sends     │
│ signal to objectWillChange
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ ObservableObject    │
│ objectWillChange    │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ SwiftUI View        │
│ subscribes and      │
│ refreshes UI        │
└─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does @Published notify changes for nested properties inside a class automatically? Commit yes or no.

Common Belief: Many believe @Published tracks all changes inside nested objects automatically.

Reality: @Published only notifies when the property itself changes, not internal changes inside nested objects.

Why it matters: This misconception leads to UI not updating when nested data changes, causing confusing bugs.

Quick: Do you think marking a property @Published slows down your app significantly? Commit yes or no.

Common Belief: Some think @Published has no performance cost and can be used everywhere freely.

Reality: @Published triggers UI updates on every change, so overusing it can degrade performance.

Why it matters: Ignoring this can cause sluggish apps and poor user experience.

Quick: Does @Published work outside ObservableObject classes? Commit yes or no.

Common Belief: People often think @Published can be used in any class or struct to notify changes.

Reality: @Published only works inside classes conforming to ObservableObject.

Why it matters: Using it elsewhere leads to compile errors or no notifications, wasting time.

Quick: Is @Published a replacement for all state management in SwiftUI? Commit yes or no.

Common Belief: Some believe @Published alone handles all app state needs.

Reality: @Published is one tool; complex apps often need other state management patterns.

Why it matters: Relying solely on @Published can cause messy code and scalability issues.

Expert Zone

1

Using @Published with structs requires replacing the whole struct to trigger updates, as internal changes don't notify automatically.

2

Combining @Published with custom Combine operators allows filtering or throttling updates for performance tuning.

3

@Published properties emit changes on the main thread by default, but this can be customized for background processing.

When NOT to use

Avoid @Published when you need fine-grained control over updates or when working with complex nested data. Instead, use manual objectWillChange notifications or custom Combine publishers. For simple UI state, consider @State or @Binding in SwiftUI views.

Production Patterns

In production, @Published is often combined with dependency injection to provide ObservableObjects to views. Developers batch multiple property changes inside a single update to reduce UI refreshes. Also, they use immutable data models with @Published to ensure predictable updates.

Connections

Observer Pattern

Builds-on

Understanding @Published deepens knowledge of the observer pattern, where objects watch for changes and react, a fundamental design pattern in software.

Reactive Programming

Same pattern

@Published is a concrete example of reactive programming, where data flows and changes propagate automatically, improving app responsiveness.

Event-driven Systems (Computer Science)

Builds-on

Knowing how @Published triggers events helps understand event-driven architectures where components communicate via signals and listeners.

Common Pitfalls

#1 UI does not update when nested data changes inside a @Published property.

Wrong approach:

class Model: ObservableObject {
@Published var user = User(name: "Alice")
}

// Changing nested property
model.user.name = "Bob" // UI does not update

Correct approach:

class Model: ObservableObject {
@Published var user = User(name: "Alice")
}

// Replace whole user to trigger update
model.user = User(name: "Bob") // UI updates

Root cause:

Believing @Published tracks internal changes of complex types instead of only property replacements.

#2 Marking too many properties @Published causing performance issues.

Wrong approach:

class DataModel: ObservableObject {
@Published var a = 0
@Published var b = 0
@Published var c = 0
@Published var d = 0
// Many more
}

Correct approach:

class DataModel: ObservableObject {
@Published var combinedData: DataType
// Update combinedData in batches to reduce UI refreshes
}

Root cause:

Not understanding that each @Published change triggers UI updates, leading to excessive refreshes.

#3 Using @Published in structs or non-ObservableObject classes.

Wrong approach:

struct MyStruct {
@Published var value = 0
}

// Compile error or no notifications

Correct approach:

class MyClass: ObservableObject {
@Published var value = 0
}

Root cause:

Misunderstanding that @Published requires ObservableObject conformance and class types.

Key Takeaways

@Published properties automatically notify SwiftUI views when their values change, enabling reactive UI updates.

They only notify when the property itself changes, not internal changes of nested data, requiring careful data management.

@Published works only inside classes conforming to ObservableObject and is a key part of SwiftUI's reactive data flow.

Overusing @Published can cause performance problems; use it thoughtfully and batch updates when possible.

Understanding @Published reveals the power and limits of reactive programming in building dynamic, responsive apps.

Practice

1. What is the main purpose of marking a property with @Published in SwiftUI?

easy

A. To make the property constant

B. To make the property private

C. To automatically notify views when the property changes

D. To prevent the property from being saved

Solution

1. Step 1: Understand @Published role

   @Published marks a property to send updates when its value changes.

2. Step 2: Connect to UI updates

   This automatic notification helps SwiftUI views update when data changes.

3. Final Answer:

   To automatically notify views when the property changes -> Option C

4. Quick Check:

   @Published = automatic update notification [OK]

Hint: Remember: @Published means auto-update UI on change [OK]

Common Mistakes:

• Thinking @Published makes property private
• Confusing @Published with constant declaration
• Assuming @Published saves data permanently

2. Which of the following is the correct way to declare a @Published property inside an ObservableObject class?

easy

A. struct Model: ObservableObject { @Published var count: Int = 0 }

B. class Model: ObservableObject { @Published var count: Int = 0 }

C. class Model { @Published var count: Int = 0 }

D. class Model: ObservableObject { var count: @Published Int = 0 }

Solution

1. Step 1: Check class and ObservableObject conformance

   @Published must be inside a class conforming to ObservableObject, so class Model: ObservableObject is correct.

2. Step 2: Verify property declaration syntax

   The correct syntax is @Published var count: Int = 0, not var count: @Published Int.

3. Final Answer:

   class Model: ObservableObject { @Published var count: Int = 0 } -> Option B

4. Quick Check:

   Correct syntax = class Model: ObservableObject { @Published var count: Int = 0 } [OK]

Hint: Remember: @Published goes before var inside ObservableObject class [OK]

Common Mistakes:

• Using struct instead of class for ObservableObject
• Placing @Published after the type
• Not conforming class to ObservableObject

3. Given the code below, what will be printed when model.count = 5 is executed?

class Model: ObservableObject {
  @Published var count: Int = 0
}

let model = Model()
model.$count.sink { print("Count changed to \($0)") }

medium

A. Count changed to 5

B. Count changed to 0

C. No output

D. Compile error

Solution

1. Step 1: Understand @Published publisher

   @Published creates a publisher accessible via $property, here $count, which emits new values on change.

2. Step 2: Analyze sink subscription and assignment

   The sink closure prints the new value when count changes. Setting model.count = 5 triggers the print with 5.

3. Final Answer:

   Count changed to 5 -> Option A

4. Quick Check:

   @Published publishes new values = Count changed to 5 [OK]

Hint: Remember: $property publishes changes, sink prints new value [OK]

Common Mistakes:

• Expecting output before assignment
• Confusing $count with count
• Thinking no output without explicit call

4. Identify the error in this code snippet:

class Model: ObservableObject {
  @Published var name: String

  init() {
    name = ""
  }
}

let model = Model()
model.name = "Alice"

medium

A. Missing initial value for @Published property

B. ObservableObject conformance is missing

C. Cannot assign to @Published property outside class

D. No error, code works fine

Solution

1. Step 1: Check @Published property initialization

   The property name is initialized in init(), which is valid for non-optional properties.

2. Step 2: Verify ObservableObject conformance and usage

   Class conforms to ObservableObject and property is assigned outside class, which is allowed.

3. Final Answer:

   No error, code works fine -> Option A

4. Quick Check:

   Proper init and conformance = No error, code works fine [OK]

Hint: Remember: @Published properties can be initialized in init() [OK]

Common Mistakes:

• Assuming @Published needs default value inline
• Thinking ObservableObject conformance is missing
• Believing external assignment is disallowed

5. You want to create a SwiftUI app where a @Published property updates a label text automatically. Which of the following is the best way to connect the @Published property to the UI?

hard

A. Use @EnvironmentObject without passing the object

B. Use @State in the view for the property

C. Manually call setNeedsDisplay() after changing the property

D. Use @ObservedObject in the view to watch the ObservableObject

Solution

1. Step 1: Understand property wrappers for UI updates

   @Published properties notify changes, but the view must observe the object using @ObservedObject to update UI automatically.

2. Step 2: Evaluate other options

   @State is for local view state, not external objects; setNeedsDisplay() is UIKit, not SwiftUI; @EnvironmentObject requires injection.

3. Final Answer:

   Use @ObservedObject in the view to watch the ObservableObject -> Option D

4. Quick Check:

   @Published + @ObservedObject = auto UI update [OK]

Hint: Connect @Published with @ObservedObject in views [OK]

Common Mistakes:

• Using @State instead of @ObservedObject for external data
• Trying manual UI refresh calls in SwiftUI
• Using @EnvironmentObject without proper injection