SwiftUI @Observable vs @State: Коли Що Використовувати у 2026
Опануйте відмінності між @Observable та @State у SwiftUI, щоб обрати правильний інструмент керування станом для застосунків iOS.

Керування станом є наріжним каменем будь-якого продуктивного застосунку SwiftUI. Починаючи з iOS 17, макрос @Observable революціонізував створення реактивних моделей, тоді як @State залишається необхідним для локального стану view. Розуміння того, коли використовувати кожен інструмент, дозволяє уникнути зайвих повторних рендерів і створювати плавні, чутливі застосунки.
Стаття досліджує внутрішні механізми @Observable та @State, їхні фундаментальні відмінності та надає чіткі вказівки для вибору правильного інструмента залежно від контексту. Включає зміни макроса @State з iOS 27 (бекпортовані до iOS 17).
Основи @State
@State представляє найпростішу форму керування станом у SwiftUI. Цей property wrapper створює постійне сховище для значення, що належить виключно view, який його декларує.
struct CounterView: View {
// @State creates storage managed by SwiftUI
@State private var count = 0
var body: some View {
VStack(spacing: 20) {
// The view updates when count changes
Text("Counter: \(count)")
.font(.largeTitle)
HStack(spacing: 16) {
Button("- 1") {
count -= 1
}
Button("+ 1") {
count += 1
}
}
.buttonStyle(.borderedProminent)
}
}
}Кожна модифікація count запускає повторний рендер view. SwiftUI автоматично керує життєвим циклом цього значення, зберігаючи його між реконструкціями body.
Ключові характеристики @State
@State має кілька унікальних властивостей, що визначають його оптимальне використання:
struct FormView: View {
// Simple local state with value types
@State private var username = ""
@State private var isEnabled = true
@State private var selectedIndex = 0
// Complex value types supported
@State private var configuration = FormConfiguration()
var body: some View {
Form {
TextField("Username", text: $username)
Toggle("Enabled", isOn: $isEnabled)
Picker("Option", selection: $selectedIndex) {
Text("Option A").tag(0)
Text("Option B").tag(1)
Text("Option C").tag(2)
}
}
}
}
// Structs work perfectly with @State
struct FormConfiguration: Equatable {
var theme: Theme = .light
var fontSize: CGFloat = 16
var showNotifications: Bool = true
}
enum Theme {
case light, dark, system
}Ключовий момент: @State працює з value-типами (struct, enum, примітивні типи). Для reference-типів (класів) потрібні інші інструменти.
Макрос @Observable пояснений
Представлений з iOS 17, @Observable перетворює будь-який клас на реактивне джерело даних. На відміну від старого протоколу ObservableObject, цей макрос пропонує тонкозернисте спостереження: лише властивості, які реально читаються view, запускають його повторний рендер. Документація Observation framework надає повну довідку API.
import Observation
// @Observable transforms the class into a reactive source
@Observable
class UserModel {
var name: String = ""
var email: String = ""
var avatarURL: URL?
var preferences = UserPreferences()
// Computed properties work too
var isValid: Bool {
!name.isEmpty && email.contains("@")
}
}
struct UserPreferences {
var newsletter: Bool = false
var notifications: Bool = true
var theme: Theme = .system
}Магія відбувається на етапі компіляції: макрос автоматично генерує необхідний код відстеження для кожної властивості.
Гранулярне спостереження в дії
Головна відмінність від старого ObservableObject полягає у гранулярності відстеження:
@Observable
class ProfileModel {
var name: String = ""
var bio: String = ""
var followerCount: Int = 0
var posts: [Post] = []
}
struct ProfileHeaderView: View {
let model: ProfileModel
var body: some View {
VStack {
// This view only re-renders if name or bio change
Text(model.name)
.font(.title)
Text(model.bio)
.foregroundStyle(.secondary)
}
}
}
struct FollowerCountView: View {
let model: ProfileModel
var body: some View {
// This view only re-renders if followerCount changes
HStack {
Image(systemName: "person.2")
Text("\(model.followerCount) followers")
}
}
}
struct ProfileScreen: View {
@State private var model = ProfileModel()
var body: some View {
VStack {
// Each subview tracks only its dependencies
ProfileHeaderView(model: model)
FollowerCountView(model: model)
Button("Simulate new follower") {
// Only re-renders FollowerCountView
model.followerCount += 1
}
}
}
}SwiftUI аналізує body кожного view, щоб визначити, які властивості зчитуються. Лише ці властивості запускають повторний рендер при модифікації.
Пряме порівняння: @Observable vs @State
Вибір між цими інструментами залежить від кількох факторів. Структуроване порівняння:
// Scenario 1: Temporary UI state -> @State
struct ToggleExample: View {
@State private var isExpanded = false // @State appropriate
var body: some View {
VStack {
Button(isExpanded ? "Collapse" : "Expand") {
withAnimation {
isExpanded.toggle()
}
}
if isExpanded {
Text("Detailed content...")
}
}
}
}
// Scenario 2: Shared business data -> @Observable
@Observable
class CartModel { // @Observable appropriate
var items: [CartItem] = []
var promoCode: String?
var total: Decimal {
items.reduce(0) { $0 + $1.price * Decimal($1.quantity) }
}
var itemCount: Int {
items.reduce(0) { $0 + $1.quantity }
}
func addItem(_ item: CartItem) {
if let index = items.firstIndex(where: { $0.id == item.id }) {
items[index].quantity += 1
} else {
items.append(item)
}
}
func removeItem(_ item: CartItem) {
items.removeAll { $0.id == item.id }
}
}
struct CartItem: Identifiable, Equatable {
let id: UUID
let name: String
let price: Decimal
var quantity: Int
}Зведена таблиця сценаріїв використання
| Критерій | @State | @Observable |
|---|---|---|
| Тип даних | Value-типи (struct, enum) | Класи |
| Область | Локальна для view | Спільна між view |
| Складність | Простий стан | Складна бізнес-логіка |
| Життєвий цикл | Керується SwiftUI | Керується явно |
| Повторний рендер | Весь view | Гранулярний за властивістю |
Готовий до співбесід з iOS?
Практикуйся з нашими інтерактивними симуляторами, flashcards та технічними тестами.
Оновлення iOS 27: @State як макрос з лінивою ініціалізацією
WWDC 2026 представив значну зміну в @State: тепер він реалізований як макрос, а не property wrapper. Ця зміна безпосередньо вирішує поширену проблему при використанні @State з класами @Observable.
Проблема до iOS 27
Раніше класи @Observable, що зберігалися в @State, ініціалізувалися негайно (eagerly). Це могло спричинити багаторазове створення одного й того ж екземпляра ще до появи view:
// Before iOS 27: potential multiple initializations
struct StickerStoreView: View {
// The StickerStore instance could be created eagerly
// and recreated during parent view updates
@State private var store = StickerStore()
var body: some View {
// ...
}
}
@Observable
class StickerStore {
init() {
print("StickerStore initialized")
// This could print multiple times before the view appeared
}
}Рішення: лінива ініціалізація
З iOS 27 (та бекпортом до iOS 17) класи @Observable, що зберігаються в @State, тепер ініціалізуються ліниво, рівно один раз протягом життєвого циклу view:
// iOS 27+: guaranteed single initialization
struct StickerStoreView: View {
@State private var store = StickerStore()
var body: some View {
// store is created exactly once, when the view first needs it
StoreContentView(store: store)
}
}
@Observable
class StickerStore {
var stickers: [Sticker] = []
init() {
print("StickerStore initialized")
// Now prints exactly once per view lifetime
}
}При присвоєнні @State в ініціалізаторі слід видалити значення за замовчуванням, щоб уникнути помилок компілятора:
// Correct pattern when using custom initializer
struct StickerPageView: View {
@State private var page: StickerPage // No default value
let title: String
init(title: String) {
self.page = StickerPage(title: title)
self.title = title
}
var body: some View {
// ...
}
}Це виправлення усуває марнотратні алокації об'єктів і забезпечує правильне збереження екземплярів @Observable протягом усього життєвого циклу view. Для розробників, які готуються до питань на співбесіді iOS, розуміння цієї зміни демонструє знання поточних внутрішніх механізмів SwiftUI.
Просунуті патерни використання
Поєднання @State і @Observable
У реальних застосунках ці інструменти співіснують гармонійно. @State керує локальним станом UI, тоді як @Observable інкапсулює бізнес-дані.
@Observable
class TodoListModel {
var todos: [Todo] = []
var filter: TodoFilter = .all
var filteredTodos: [Todo] {
switch filter {
case .all:
return todos
case .active:
return todos.filter { !$0.isCompleted }
case .completed:
return todos.filter { $0.isCompleted }
}
}
func addTodo(title: String) {
let todo = Todo(id: UUID(), title: title, isCompleted: false)
todos.append(todo)
}
func toggleTodo(_ todo: Todo) {
guard let index = todos.firstIndex(where: { $0.id == todo.id }) else { return }
todos[index].isCompleted.toggle()
}
}
struct Todo: Identifiable, Equatable {
let id: UUID
var title: String
var isCompleted: Bool
}
enum TodoFilter: CaseIterable {
case all, active, completed
}
struct TodoListView: View {
// Business data via @Observable (lazy init since iOS 27)
@State private var model = TodoListModel()
// Local UI state via @State
@State private var newTodoTitle = ""
@State private var isAddingTodo = false
@State private var selectedTodo: Todo?
var body: some View {
NavigationStack {
VStack {
// Filter with Picker
Picker("Filter", selection: $model.filter) {
ForEach(TodoFilter.allCases, id: \.self) { filter in
Text(filter.label).tag(filter)
}
}
.pickerStyle(.segmented)
.padding()
// Todo list
List(model.filteredTodos, selection: $selectedTodo) { todo in
TodoRowView(todo: todo) {
model.toggleTodo(todo)
}
}
}
.navigationTitle("Tasks")
.toolbar {
Button {
isAddingTodo = true
} label: {
Image(systemName: "plus")
}
}
.sheet(isPresented: $isAddingTodo) {
AddTodoSheet(model: model)
}
}
}
}
struct TodoRowView: View {
let todo: Todo
let onToggle: () -> Void
var body: some View {
HStack {
Image(systemName: todo.isCompleted ? "checkmark.circle.fill" : "circle")
.foregroundStyle(todo.isCompleted ? .green : .secondary)
.onTapGesture(perform: onToggle)
Text(todo.title)
.strikethrough(todo.isCompleted)
}
}
}
extension TodoFilter {
var label: String {
switch self {
case .all: return "All"
case .active: return "Active"
case .completed: return "Completed"
}
}
}@Observable з ін'єкцією залежностей
Для складніших застосунків ін'єкція через environment SwiftUI забезпечує ефективне розв'язання залежностей:
@Observable
class AuthenticationService {
var currentUser: User?
var isAuthenticated: Bool { currentUser != nil }
func login(email: String, password: String) async throws {
// Authentication logic
currentUser = User(id: UUID(), email: email, name: "User")
}
func logout() {
currentUser = nil
}
}
struct User: Identifiable, Equatable {
let id: UUID
let email: String
let name: String
}
// Extension to create an environment key
extension EnvironmentValues {
@Entry var authService: AuthenticationService = AuthenticationService()
}
// Configuration in the App
@main
struct MyApp: App {
@State private var authService = AuthenticationService()
var body: some Scene {
WindowGroup {
ContentView()
.environment(\.authService, authService)
}
}
}
// Usage in views
struct ProfileView: View {
@Environment(\.authService) private var authService
var body: some View {
if let user = authService.currentUser {
VStack {
Text("Hello, \(user.name)")
Button("Sign Out") {
authService.logout()
}
}
} else {
Text("Not signed in")
}
}
}Продуктивність та оптимізація
Уникнення зайвих повторних рендерів
Навіть з гранулярністю @Observable деякі патерни можуть знижувати продуктивність:
// Bad pattern: reading the entire object
struct BadPatternView: View {
let model: ProfileModel
var body: some View {
// Reads model.name AND model.posts even if only name is displayed
let _ = model.posts.count // Creates unnecessary dependency
Text(model.name)
}
}
// Good pattern: targeted reading
struct GoodPatternView: View {
let model: ProfileModel
var body: some View {
// Tracks only name
Text(model.name)
}
}
// Extract into subviews to isolate dependencies
struct OptimizedProfileView: View {
let model: ProfileModel
var body: some View {
VStack {
// Each subview has its own dependencies
ProfileNameView(model: model)
ProfilePostsView(model: model)
ProfileStatsView(model: model)
}
}
}
struct ProfileNameView: View {
let model: ProfileModel
var body: some View {
Text(model.name)
.font(.title)
}
}
struct ProfilePostsView: View {
let model: ProfileModel
var body: some View {
ForEach(model.posts) { post in
PostRow(post: post)
}
}
}
struct ProfileStatsView: View {
let model: ProfileModel
var body: some View {
HStack {
StatBadge(value: model.followerCount, label: "Followers")
StatBadge(value: model.posts.count, label: "Posts")
}
}
}Computed-властивості на @Observable переобчислюються при кожному доступі. Для складних обчислень варто кешувати результат у stored-властивості.
Розширене спостереження в Swift 6.4
Swift 6.4 представив SE-0506, додавши API для детальних і безперервних сповіщень про зміни в Observation framework. Ці розширені інструменти призначені для розробників middleware та реалізацій систем віджетів, а не для типової розробки застосунків. Більшість застосунків продовжують використовувати стандартний патерн макроса @Observable. Примітки до випуску Swift 6.4 деталізують ці доповнення.
Міграція з ObservableObject
Для існуючих проєктів, що використовують ObservableObject, міграція на @Observable спрощує код:
// Old pattern with ObservableObject
class OldSettingsModel: ObservableObject {
@Published var darkMode: Bool = false
@Published var fontSize: CGFloat = 16
@Published var notifications: Bool = true
}
struct OldSettingsView: View {
@StateObject private var settings = OldSettingsModel()
// or @ObservedObject if injected
var body: some View {
Form {
Toggle("Dark Mode", isOn: $settings.darkMode)
Slider(value: $settings.fontSize, in: 12...24)
Toggle("Notifications", isOn: $settings.notifications)
}
}
}
// New pattern with @Observable
@Observable
class NewSettingsModel {
var darkMode: Bool = false
var fontSize: CGFloat = 16
var notifications: Bool = true
}
struct NewSettingsView: View {
@State private var settings = NewSettingsModel()
var body: some View {
Form {
Toggle("Dark Mode", isOn: $settings.darkMode)
Slider(value: $settings.fontSize, in: 12...24)
Toggle("Notifications", isOn: $settings.notifications)
}
}
}Переваги міграції:
- Не потрібно
@Publishedна кожній властивості @Stateзамінює@StateObjectдля створення (з гарантованою лінивою ініціалізацією)- Автоматичне гранулярне спостереження
- Більш читабельний і зручний у підтримці код
Для застосунків, що цілять на iOS 17+, міграція на @Observable рекомендована. Посібник з міграції Combine vs async/await охоплює пов'язані патерни модернізації.
Практичні правила прийняття рішень
Провідник для вибору правильного інструмента:
/*
RULE 1: Ephemeral UI state -> @State
- Animations, transitions
- Local form states
- Temporary selections
- Section expand/collapse
*/
struct AnimatedCard: View {
@State private var isFlipped = false // Local UI state
// ...
}
/*
RULE 2: Shared data across views -> @Observable
- Business data models
- Authentication state
- Shopping cart
- User preferences
*/
@Observable
class UserSession { // Shared across app
var user: User?
var preferences: Preferences
// ...
}
/*
RULE 3: Simple struct with binding -> @State
- Local configuration
- Isolated forms
*/
struct FormData {
var name: String = ""
var email: String = ""
}
struct FormView: View {
@State private var formData = FormData() // Struct with @State
// ...
}
/*
RULE 4: Complex business logic -> @Observable
- Validations
- Network calls
- Data transformations
*/
@Observable
class OrderProcessor { // Complex logic
var items: [OrderItem] = []
var status: OrderStatus = .draft
func validate() -> [ValidationError] { /* ... */ }
func submit() async throws { /* ... */ }
}Джерела
- Документація Observation framework - офіційна довідка API від Apple
- Примітки до випуску Swift 6.4 - розширене відстеження спостереження SE-0506
- Посібник SwiftUI WWDC 2026 - зміни макроса @State та лінива ініціалізація
Вибір між @Observable та @State у SwiftUI
Вибір між @Observable та @State зводиться до двох фундаментальних питань: тип даних (значення чи посилання) та область стану (локальна чи спільна). @State блискуче працює для простого, локального стану UI, тоді як @Observable сяє для складних моделей даних, що вимагають гранулярного спостереження.
Контрольний список рішення
- Використовувати
@Stateдля value-типів та ефемерного стану UI - Використовувати
@Observableдля класів з бізнес-даними - Віддавати перевагу
@Observable, коли стан охоплює кілька view - Виносити в підпредставлення для оптимізації повторних рендерів
- Уникати читання непотрібних властивостей у body
- Поступово мігрувати з
ObservableObject - Використовувати environment для ін'єкції залежностей
- Тестувати продуктивність з Instruments для складних випадків
Завдяки покращенням макроса @State в iOS 27 (бекпортованим до iOS 17), поєднання цих інструментів є надійнішим, ніж будь-коли. Виправлення лінивої ініціалізації усуває поширене джерело помилок при зберіганні класів @Observable у @State.
Починай практикувати!
Перевір свої знання з нашими симуляторами співбесід та технічними тестами.
Чи знайдеш ти помилку в iOS?
Справжній фрагмент коду, прихована помилка, одна спроба на день. Щоб спробувати, акаунт не потрібен.

Автор:
Anthony Fillion-MailletЗасновник SharpSkill
Fullstack-розробник понад 10 років. Керує SharpSkill і відповідає за все, що тут публікується.
Оновлено 5 жовтня 2026 р.
Теги
Поділитися
Пов'язані статті

Продуктивність SwiftUI: Оптимізація LazyVStack та Складних Списків
Техніки оптимізації для LazyVStack та списків SwiftUI. Зменшення споживання пам'яті, покращення продуктивності прокручування та уникнення поширених помилок.

Користувацькі ViewModifier у SwiftUI: патерни багаторазового використання для design system
Створюйте користувацькі ViewModifier у SwiftUI для узгодженого design system. Патерни, кращі практики та практичні приклади ефективного стилізування iOS view.

CloudKit зі SwiftUI у 2026: патерни синхронізації між пристроями
Повний посібник із впровадження синхронізації CloudKit зі SwiftUI: CKSyncEngine, інтеграція зі SwiftData, розв'язання конфліктів і найкращі практики для iOS 2026.