Flutter⇄SwiftUI

@State private var count = 0 allocates a private, view-owned mutable cell — this is the direct analog of a field inside a StatefulWidget's State class. The private keyword isn't cosmetic: SwiftUI expects @State to be exclusively owned by the view that declares it, same as you'd never read another widget's private State fields.

The key difference from Flutter is in the button closures: count += 1 and isPremiumUser.toggle() mutate the value directly — there's no setState(() { ... }) wrapper. SwiftUI's property-wrapper machinery detects the write to a @State var automatically and schedules a re-render of exactly the parts of body that read it, so you get fine-grained rebuilds without ever calling something equivalent to notifyListeners().

This is the classic "controlled child" pattern. ParentView owns the real value with @State private var isLightOn = false — same as any StatefulWidget holding a boolean. When it hands that value to the child, it doesn't pass isLightOn directly; it passes $isLightOn. The $ prefix on any @State property produces a Binding<Bool> — a live, two-way reference, not a copy.

LightSwitchComponent declares @Binding var isOn: Bool, meaning "I don't own this value, but I can read and write it." When the child does isOn.toggle(), that mutation is written straight back into the parent's isLightOn, and the parent's Circle re-renders. In Flutter terms this is exactly passing a value down alongside an onChanged: (val) { setState(() => isLightOn = val); } callback — except @Binding collapses "the value" and "the callback that writes it" into a single object.

The comment at the top says it all: @MainActor is Swift's compiler-enforced guarantee that every property mutation on this class happens back on the UI thread, even after an await has hopped onto a background worker. Dart doesn't need this — its single-threaded event loop makes this a non-issue — but Swift's structured concurrency genuinely can run await continuations off the main thread, so ViewModels that touch UI state are annotated @MainActor as standard practice.

@Observable class TodoViewModel is your Cubit: var tasks: [TodoItem] is the state, and loadRemoteTasks() is a Cubit method. Notice there's no emit() call and no separate TodoState class — the macro instruments every stored property so that any SwiftUI view reading viewModel.tasks automatically subscribes to just that property, and self.tasks = fetchedData is the entire "emit new state" step.

This is the standard "who creates it, who edits it" split. ParentDashboardView declares @State private var globalCubit = ProfileViewModel() — the @State wrapper here is doing the same job as BlocProvider(create: (_) => ProfileCubit()): it constructs the instance and owns its lifetime, keeping it alive across re-renders of this view.

That instance is then passed down as a plain constructor argument: SettingsScreen(viewModel: globalCubit). Inside the child, @Bindable var viewModel: ProfileViewModel unlocks the ability to write $viewModel.username — a live two-way binding straight into the parent-owned object's property, which is what lets TextField("Change username", text: $viewModel.username) mutate the shared instance directly. The Flutter equivalent is handing an existing Cubit reference into a child widget's constructor so a controller/field inside it can call methods on that same Cubit instance.

Same @Bindable mechanism as the previous card, but this is the shape you'll actually reach for most often: a settings-style screen with several fields bound straight to one @Observable model, no intermediate local @State copies to keep in sync.

ProfileViewModel is a plain reactive class (your Cubit) with two properties. SettingsScreen receives it as @Bindable var viewModel, which is what makes $viewModel.username and $viewModel.notificationsEnabled legal inside the Form. Without @Bindable, the compiler rejects the $ prefix entirely — this is a compile-time guardrail, not a runtime warning, so a missing @Bindable shows up immediately rather than as a silent "my toggle doesn't update the model" bug the way a missed notifyListeners() call might in Flutter.

This is the simplest navigation shape: NavigationLink(destination: ProductDetailView(product: product)) builds the destination screen eagerly, inline, right where the link is declared — the direct equivalent of Navigator.push(context, MaterialPageRoute(builder: (_) => ProductDetailView(product: product))) called from inside a list item's onTap.

NavigationStack { ... } wraps the whole screen and gives it a navigation context, similar to how MaterialApp/Navigator gives every screen access to push/pop. This style is fine for a handful of destinations, but because the destination view is constructed immediately for every row (not lazily), it doesn't scale the same way as the typed-routes pattern shown in the next card once a list gets pushed to hundreds of items.

This is the scalable alternative to inline destinations. Instead of building a view per row, NavigationLink(product.name, value: product) pushes a plain value (the Product struct itself) onto the navigation stack — nothing is built yet.

Resolution happens once, centrally, via .navigationDestination(for: Product.self) { product in ProductDetailView(product: product) } — a single closure that knows how to turn any Product pushed anywhere in this stack into a screen. Stack multiple .navigationDestination(for:) modifiers for different types on one NavigationStack and you get something close to GoRouter's centralized routes: [...] table — one registration point per "route type" instead of one MaterialPageRoute built at every call site.

NavigationPath is what you reach for when you need to manipulate the back-stack from outside the view that's currently on top — the same job a GlobalKey<NavigatorState> does in Flutter so you can call Navigator.of(key.currentContext!).push(...) from anywhere.

@State private var path = NavigationPath() on the root view owns the entire stack, and it's bound into NavigationStack(path: $path). From anywhere holding a Binding<NavigationPath>, path.append(CartStep.shipping) pushes a new screen programmatically (no NavigationLink tap required) — like calling navigatorKey.currentState!.push(route). Resetting it with path = NavigationPath() pops everything back to root in one line, equivalent to Navigator.popUntil((route) => route.isFirst). Popping just one screen from inside a pushed view uses @Environment(\.dismiss) then dismiss() — SwiftUI's version of Navigator.pop(context).

.sheet(isPresented: $showingFilters) { ... } is driven purely by a boolean @State flag — set it true and SwiftUI animates the sheet in; when the user dismisses it (or you flip the flag back), it animates out and resets automatically. This is directly analogous to Flutter's showModalBottomSheet(), except here presentation is declarative and tied to state rather than an imperative call that returns a Future.

.presentationDetents([.medium, .large]) is the part with no one-line Flutter equivalent — it makes the sheet draggable between a half-height and full-height snap point, similar to hand-rolling a DraggableScrollableSheet with fixed size fractions, but built into the modal itself with zero extra widget nesting.

struct User: Codable, Identifiable — conforming to Codable (which is really Decodable + Encodable combined) is all it takes to get JSON parsing for free, as long as every stored property is itself a Codable type (here: two Strings and an Int, all of which qualify automatically). The compiler synthesizes the parsing/serialization code at build time.

This replaces two separate things you'd normally reach for in Flutter: hand-writing User.fromJson(Map) / toJson() methods yourself, or running json_serializable + build_runner to generate a user.g.dart file. Here there's no generated file and no build step — Identifiable additionally gives the struct the id requirement that List/ForEach need to diff rows efficiently, similar to supplying a key: in a Flutter ListView.builder.

enum NetworkError: Error is a lightweight custom error type — think of it like a small sealed class of failure reasons you'd throw from a Dart repository method. NetworkService is a plain struct with one static async function; there's no DI container or service locator involved, it's called directly as NetworkService.fetchUser(id:), similar to a static utility method or a top-level function in Dart.

try await URLSession.shared.data(from: url) is the built-in HTTP client — no http or dio package needed, and it's the direct equivalent of await http.get(uri). The guard let http = response as? HTTPURLResponse, (200...299).contains(http.statusCode) else { throw ... } block is a range-check on the status code (matching if (res.statusCode == 200), but tolerating the whole 2xx family) that throws instead of falling into an else branch. JSONDecoder().decode(User.self, from: data) is the jsonDecode() + User.fromJson() combo collapsed into one call, thanks to Codable.

This ViewModel is exactly your Cubit calling a repository method. var user: User? and var loadingState: FetchState together are the state — there's no separate immutable state class to construct and emit(); you assign these properties directly and @Observable notifies any view reading them.

loadingState = .loading then a do/catch around the network call mirrors emitting a loading state before an async call and a success/failure state after — the same three-phase dance you'd write with a Cubit's emit(state.copyWith(status: Loading)) pattern, just without the copyWith boilerplate since these are plain mutable vars on a reference-typed class.

import SwiftData plus the @Model macro on an otherwise ordinary class is what turns Note into a persisted, queryable database entity — this is the direct sibling of annotating a class for Hive (@HiveType) or Isar (@collection). No manual adapter registration or generated .g.dart file is required; the macro does the work at compile time.

The init is a completely normal Swift initializer — nothing SwiftData-specific about it. SwiftData is the framework recommended for iOS 17+ targets; on older deployment targets you'd reach for Core Data instead, which needs considerably more setup (an .xcdatamodeld file, generated NSManagedObject subclasses).

@Query(sort: \Note.createdAt, order: .reverse) private var notes: [Note] is the standout line here: it's a property wrapper that both fetches and subscribes to the persisted store. Any insert, update, or delete to Note anywhere in the app causes this array — and therefore this view — to refresh automatically.

Think of it as a Hive box change-listener that's already wired up for you: normally you'd pair a box listener with a ValueListenableBuilder to get the UI to redraw on changes; @Query collapses both steps into one declaration. @Environment(\.modelContext) private var context is the handle used to write — context.insert(Note(...)) is the "add a record" call, comparable to box.add(note), and because the view is already subscribed via @Query, the list updates without any extra code on the write side.

This is SwiftUI's implicit animation style — you don't choose an animation widget, you animate a value change. .frame(width: isActive ? 60 : 40, ...) computes a different value depending on state, and the single line .animation(.easeInOut(duration: 0.3), value: isActive) tells SwiftUI: "whenever isActive changes, animate every property upstream of this modifier that depends on it" — here, both the fill color and the frame size animate together automatically.

The nearest Flutter equivalent is wrapping the same subtree in an AnimatedContainer and letting it interpolate size/color changes for you — except in SwiftUI this works with any value-driven modifier (color, size, offset, corner radius, opacity...), not just the specific properties one particular animated widget exposes.

This is the explicit counterpart to the implicit example above — used when you want to animate one specific state mutation without touching a persistent modifier on the view. withAnimation(.spring(response: 0.4, dampingFraction: 0.7)) { cart.items.append(product) } wraps just the mutation; only the UI changes that result from cart.items.append(product) get animated, nothing else on screen is affected.

The Flutter analog is manually driving an AnimationController (.forward()) tied to a Tween — except here there's no controller object to create, dispose, or wire to a TickerProvider; withAnimation is a scoped, one-shot block, and the .spring(response:dampingFraction:) curve gives you physics-based motion (bounce and settle time) without hand-configuring a SpringSimulation.

DragGesture() is a composable gesture recognizer, attached via .gesture(...) — this maps to GestureDetector(onPanUpdate:, onPanEnd:) in Flutter. .onChanged { value in offset = value.translation } fires continuously as the finger moves and writes straight into @State private var offset: CGSize, which is read back by .offset(offset) on the same view — a live feedback loop, similar to updating an offset inside setState() on every pan-update callback.

.onEnded { _ in withAnimation(.spring) { offset = .zero } } snaps the card back to its origin with spring physics once the drag ends — the explicit-animation pattern from the card above, applied here to a single reset. .onTapGesture and .onLongPressGesture chain onto the same view for the equivalent of onTap/onLongPress — SwiftUI lets you stack multiple gesture recognizers on one view without an explicit GestureDetector wrapper widget.

Form { Section { ... } } is a built-in, pre-styled grouped list container — no separate package, unlike reaching for a custom ListView layout to mimic native settings-screen styling in Flutter. enum Field { case email, password } paired with @FocusState private var focusedField: Field? tracks which field currently has keyboard focus, the direct equivalent of a FocusNode per field plus a FocusScope to coordinate them.

.focused($focusedField, equals: .email) binds a specific field to that focus state, and .onSubmit { focusedField = .password } chains focus forward on the return key — like calling FocusScope.of(context).requestFocus(passwordNode) from a field's onFieldSubmitted. Crucially there's no validator: callback on TextField: validation is manual, done here inside submit() with plain guard statements that set errorMessage — the same logic a TextFormField(validator:) would run per-field automatically, just written by hand and checked at submit time instead.

@Environment(\.colorScheme) private var scheme reads the current system appearance — this is the property-wrapper equivalent of calling MediaQuery.platformBrightnessOf(context), but resolved automatically and kept live without you subscribing to anything.

The more important line, though, is .background(Color("BrandSurface")): that color is defined once in the Asset Catalog with separate "Any Appearance" and "Dark" values, so this single call already adapts to dark mode with zero branching — closer to referencing Theme.of(context).colorScheme.surface than to hardcoding a color. scheme == .dark ? .white : .black shows the escape hatch for the rarer case where you genuinely need to branch on the mode explicitly rather than letting an asset-catalog color do it for you.

ViewModifier is SwiftUI's mechanism for packaging a chain of modifiers (padding, background, clip shape, shadow) into one reusable, named unit — CardStyle here bundles exactly that "card" look. The extension View { func cardStyle() -> some View { modifier(CardStyle()) } } block is what makes Text("Total balance").cardStyle() read like a first-class modifier at the call site.

The closest Flutter idiom is an extension method on BuildContext or a small reusable wrapper widget that applies a consistent decoration — except here it composes directly into the modifier chain (.padding().background().cardStyle()) rather than nesting one more widget around your content. Reach for a ViewModifier any time you catch yourself repeating the same 3–4 modifiers across several views.

Without any accessibility modifiers, VoiceOver would read this HStack's two Text views as two separate stops when swiping through the screen — annoying for anyone navigating by screen reader. .accessibilityElement(children: .combine) merges the whole row into a single stop, the direct equivalent of Flutter's MergeSemantics() wrapping the same row.

.accessibilityLabel(...) and .accessibilityHint(...) then explicitly control what gets announced and what extra context follows — matching Semantics(label: '...', hint: '...') in Flutter. The hint in particular ("Double tap to view order details") tells VoiceOver users the row is interactive, since a merged custom row otherwise gives no indication it's tappable the way a native list cell would.

enum CameraPermission { static func request() async -> Bool { ... } } is a tiny namespaced utility — comparable to how you might wrap permission_handler's Permission.camera calls in a small helper class of your own. There's no unified cross-permission package in SwiftUI/Swift; each system framework (here, AVFoundation) has its own request API.

The switch AVCaptureDevice.authorizationStatus(for: .video) covers every possible state in one exhaustive statement — .authorized returns immediately, .notDetermined triggers the actual system prompt via await AVCaptureDevice.requestAccess(for: .video), and .denied/.restricted both resolve to false without showing anything (iOS won't re-prompt once denied — that matches permission_handler's behavior of only showing a dialog when status is genuinely undetermined). @unknown default future-proofs the switch against Apple adding a new case in a future SDK.

final class PushNotificationManager: NSObject, UNUserNotificationCenterDelegate is a delegate-conforming singleton (static let shared) — the shape you'd use in place of a package like firebase_messaging, since push here talks directly to Apple's frameworks. @MainActor on the whole class keeps every callback safely on the UI thread.

requestAuthorization() is the permission-request step (FirebaseMessaging.instance.requestPermission()'s equivalent), and once granted it calls UIApplication.shared.registerForRemoteNotifications() to actually register with APNs. didReceiveDeviceToken(_:) is where you'd send the token to your backend, same job as FirebaseMessaging.instance.getToken(). The two delegate methods at the bottom are the part with no free equivalent: willPresent decides how a notification looks while the app is already open (Flutter plugins usually pick sane defaults for you; here you list [.banner, .sound, .badge] explicitly), and didReceive(response:) fires when the user taps it — your hook for routing to the relevant screen, comparable to FirebaseMessaging.onMessageOpenedApp.

SwiftUI's App protocol has no built-in delegate method for "APNs handed you a device token" — that particular callback still only exists on the older UIKit AppDelegate API. @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate is the sanctioned bridge: it lets a small UIKit-style AppDelegate class run alongside your SwiftUI app just for the handful of lifecycle callbacks SwiftUI doesn't expose yet.

Think of this the same way you'd think about writing a small native platform-channel plugin in Flutter when a capability isn't wrapped by the framework layer — you drop one level down to the native API, then bridge the result back up. Here, didRegisterForRemoteNotificationsWithDeviceToken fires on the AppDelegate and forwards straight into PushNotificationManager.shared.didReceiveDeviceToken(deviceToken), keeping the actual push logic in one place. .task { ... requestAuthorization() } on the root scene kicks the whole flow off on launch.

@Environment(\.scenePhase) private var scenePhase is a single environment value that replaces the observer-registration dance of WidgetsBindingObserver + overriding didChangeAppLifecycleState — no subscribe/unsubscribe pair to remember, and nothing to clean up in dispose().

.onChange(of: scenePhase) { oldPhase, newPhase in switch newPhase { ... } } fires on every transition with both the old and new value handed to you. The three cases map cleanly onto Flutter's states: .active ≈ resumed (resume syncing here), .background ≈ paused (pause work and persist a draft, since the process may be suspended or killed at any point after this), and .inactive ≈ the brief transitional state (e.g. Control Center being pulled down) that usually needs no action, hence the empty break.

protocol UserServiceProtocol { func fetchUser(id: Int) async throws -> User } is Swift's interface mechanism — the direct sibling of an abstract Dart class (or a repository interface) that a Cubit depends on rather than a concrete implementation. async throws in the signature means any conforming type's implementation must also be async and can throw.

LiveUserService and MockUserService are two interchangeable concrete conformances: the real one calls NetworkService.fetchUser(id:) from the networking section above, and the fake one returns a canned User instantly with no network call at all — exactly the real-vs-fake repository pair you'd hand into a Cubit's constructor to make it unit-testable without hitting the network.

This ViewModel depends on the UserServiceProtocol abstraction from the card above, not on LiveUserService directly — private let userService: UserServiceProtocol is typed as the protocol. init(userService: UserServiceProtocol = LiveUserService()) is constructor injection with a default argument: production code calls UserViewModel() and silently gets the real service, while a test calls UserViewModel(userService: MockUserService()) to swap it — the same idea as passing a repository into a Cubit's constructor, defaulted to the real implementation.

Notice there's no DI container anywhere in this snippet — no get_it/riverpod/provider equivalent needed for this pattern to work. @Environment exists for genuinely app-wide dependencies (a logged-in session, a theme), but for a single service like this, plain constructor injection is simpler to trace and easier to test.

This is the one tool in the whole document that's identical on both sides — if your AppGenie pipeline already runs Fastlane for the Android/Flutter build, this Fastfile slots in as the iOS half of the same setup, using the same Ruby-ish DSL and step functions (match, build_app, upload_to_testflight, upload_to_app_store) you may already recognize.

lane :beta do ... end and lane :release do ... end are named, runnable pipelines (fastlane beta / fastlane release from the CLI). match(type: "appstore") pulls signing certificates from a shared repo instead of managing provisioning profiles by hand; build_app(scheme:) archives the project; upload_to_testflight/upload_to_app_store ship the resulting build — automatic_release: false on the release lane means the build reaches App Store Connect but a human still flips the switch to actually publish it after review.

The data layer for the full worked reference screen. struct TodoItem: Identifiable mirrors a plain Dart model class, except let id = UUID() auto-generates a unique row identifier at construction time — comparable to assigning a key: yourself for a ListView.builder, except SwiftUI's List/ForEach require Identifiable conformance (or an explicit id: keypath) to diff rows efficiently, so this is done once, here.

enum FetchState is the state-machine enum this whole reference screen branches on — .idle / .loading / .success / .error(message: String) is the direct equivalent of a Dart sealed class (or a Freezed union) representing a Cubit's possible states, with .error carrying an associated message value the same way a sealed class's error variant would carry a field.

This is the complete Cubit-equivalent for the reference screen: @MainActor @Observable class TodoViewModel holds three plain var properties as its entire state — tasks, loadingState, and taskInputBuffer — with no separate immutable state object and no emit() calls anywhere.

loadRemoteTasks() simulates a network round trip with try await Task.sleep(nanoseconds: 1_200_000_000) — Swift's equivalent of await Future.delayed(Duration(milliseconds: 1200)) — then flips loadingState through the same .loading → .success/.error sequence you'd see in a real Cubit method. addNewTask() and deleteItems(at:) mutate tasks directly (array .append / .remove(atOffsets:)) rather than rebuilding a new immutable list via copyWith. Finally, deinit { print(...) } is a destructor that fires the instant ARC drops the last reference to this ViewModel — proof there's no manual bloc.close() step to remember; it just happens.

The root screen tying the whole reference example together. @Bindable var bindableModel = viewModel is a small but important trick: viewModel itself is @State-owned (created once by this view), but to get $-prefixed two-way bindings into its properties for the TextField, it's re-wrapped locally as @Bindable right where it's needed — same instance, just viewed through a different property wrapper for binding purposes.

Group { switch viewModel.loadingState { ... } } is the BlocBuilder-equivalent state machine: each case of FetchState renders different UI — an empty state, a spinner, an error view, or the real list — exactly like a Flutter BlocBuilder's builder callback switching on the current state. Inside .success, ForEach(viewModel.tasks.indices, id: \.self) iterates by index rather than by value, because ForEach loops normally hand you copies of value-type structs — iterating indices is what lets viewModel.tasks[index].isCompleted.toggle() actually write back into the source array. .onDelete { viewModel.deleteItems(at: $0) } wires up native swipe-to-delete, the built-in equivalent of a Dismissible wrapping each row in a ListView.builder. NavigationLink(destination: TodoItemDetailView(...)) at the bottom pushes a detail screen per row using the inline-destination pattern from the navigation section.