Zero to iOS Hero, post series

Zero to iOS Hero teaches the layers that turn Swift source into an Apple platform product. The path begins with the language and toolchain, builds the same Field Notes product through SwiftUI and UIKit, separates product rules from framework code, and carries the result through testing and release work.

Each post names its evidence boundary. Standard-library exercises can run in the browser’s Swift 6.3.3 Linux environment. Apple SDK, Simulator, signing, entitlement, account, and physical-device claims require their matching Apple development surface.

Reading order

Orientation and development workflow

1. The Apple development map, place Swift, Xcode, SDKs, frameworks, targets, schemes, runtimes, and devices into separate layers.
2. Xcode, simulators, devices, and Git, follow a project through building, running, signing, and its first source-control checkpoint.
3. Learn by building and debugging, use predictions, assertions, compiler diagnostics, LLDB, logs, documentation, and small experiments to shorten the feedback loop.

Swift from first principles

4. Values, variables, types, and inference, use constants, mutation, annotations, and inference to model Field Notes data precisely.
5. Operators, conversion, and overflow, combine typed values, make numeric conversions explicit, and choose checked or wrapping arithmetic deliberately.
6. Control flow, ranges, and patterns, select branches, classify tuples, filter sequences, and repeat work with the construct that matches the rule.
7. Functions and API shape, name behavior, design readable argument labels, and make results and mutation visible at the call site.
8. Optionals and absence, model missing input and results with binding, guard, chaining, coalescing, and explicit propagation.
9. Collections, sequences, and cost, choose order, keyed lookup, uniqueness, and eager or lazy evaluation with their operation costs visible.
10. Strings, Unicode, and formatting, handle grapheme clusters, indexes, search keys, dates, measurements, and localized display boundaries.
11. Structures and value semantics, replace temporary tuples with a Field Note value and prove edits do not leak across copies.
12. Enumerations, associated values, and pattern matching, replace contradictory loading flags with one exhaustive state whose cases carry only relevant data.
13. Classes, identity, inheritance, and type casting, model a shared editing session, separate reference identity from equality, and keep subclassing and casts deliberate.
14. Properties, methods, subscripts, initialization, and deinitialization, build a validated Tag whose construction and mutation paths preserve its invariants.
15. Closures, function types, capture, and higher-order operations, pass ranking and filtering rules as typed values and make live and snapshot capture policies explicit.
16. Protocols, extensions, and protocol-oriented design, isolate wall time behind a small Clock capability and compare existential, generic, opaque, and composed uses.
17. Errors, Result, throwing APIs, and recovery, decode a typed import, translate provider failures at the boundary, preserve outcomes, and choose recovery without erasing the cause.
18. Generics, associated types, existentials, and opaque types, page typed values and compare caller-selected generics, conformer-selected associated types, runtime boxes, and hidden concrete returns.
19. ARC, ownership, capture lists, and memory safety, trace a strong editor and callback cycle, remove its owning edge, and choose weak or unowned captures from lifetime rules.
20. Async and await, tasks, groups, cancellation, and continuations, load note assets with structured child tasks, observe cancellation, and bridge one callback exactly once.
21. Actors, global actors, Sendable, and data isolation, protect revision bookkeeping inside an actor and keep UI-observed status on the main actor.
22. Property wrappers, result builders, and macros, inspect generated behavior through a clamped property, a validation builder, and the macro expansion boundary.
23. Modules, packages, access control, interoperability, and API design, shape the real FieldNotesCore package around a small public contract and keep interop details at adapters.

Product and interface design

24. From app idea to user problem, define the Field Notes user, situation, smallest useful release, research risks, and measurable outcome before choosing screens.
25. User journeys, tasks, states, and edge cases, model capture, offline work, permission denial, interruption, deletion, and recovery as complete behavior.
26. Information architecture and navigation, map notes, places, search, detail, editing, and settings across compact and regular presentations.
27. Interaction design and feedback, specify save, autosave, focus, deletion, undo, progress, failure, and gesture alternatives as observable transitions.
28. Visual systems, HIG, typography, color, symbols, and materials, define semantic visual roles and audit their appearance, contrast, content-size, and motion behavior.
29. Adaptive design for iPhone, iPad, and windows, transform one route model across stack and split presentations, resizing, multiple scenes, touch, pointer, and keyboard input.
30. Accessibility, localization, and inclusive product design, audit the editor across assistive technologies, text sizes, contrast, motion, input methods, languages, and right-to-left layout.

SwiftUI in depth

31. SwiftUI’s value-view mental model, separate ephemeral view values from framework-owned storage and trace how identity and dependency reads drive updates.
32. SwiftUI composition, modifiers, styles, and components, extract rows, chips, modifiers, and button styles around clear visual and interaction contracts.
33. SwiftUI layout, safe areas, stacks, grids, and custom layout, follow proposal, measurement, and placement from standard containers to a wrapping tag layout.
34. SwiftUI controls, forms, validation, focus, and keyboards, build a draft-based editor with native inputs, validation recovery, focus, and honest cancellation.
35. SwiftUI state, bindings, source of truth, and identity, give each mutable fact one owner, derive secondary values, and pass narrow mutation access.
36. SwiftUI Observation, environment, and dependency flow, connect observable presentation models to explicit application contracts and scoped context.
37. SwiftUI lists, grids, scrolling, search, selection, and refresh, derive one visible collection with stable identity and preserve useful content through refresh.
38. SwiftUI navigation, presentation, alerts, and deep links, model routes and focused presentations as validated, restorable data.
39. SwiftUI async work, loading states, networking, and images, tie cancellable requests to identity and render first load, refresh, failure, retry, and cached resources honestly.
40. SwiftUI with SwiftData, queries, migration, and test stores, separate persistent models from domain rules and test fresh, disk, relationship, and migration behavior explicitly.
41. SwiftUI animation, gestures, drag and drop, and drawing, explain state changes with motion while preserving alternate input and reduced-motion paths.
42. SwiftUI scenes, windows, navigation, and commands, give each window coherent state and adapt shared route intent to system-managed presentations.
43. SwiftUI previews, tests, accessibility, and performance, place fixtures, behavior tests, UI journeys, audits, and measurements at the distance that proves each risk.
44. SwiftUI Field Notes capstone, assemble the local-first release loop, architecture, product states, acceptance checks, and honest evidence ledger.

UIKit in depth

45. UIKit’s event-driven mental model and app lifecycle, trace application, scene, window, controller, responder, and run-loop ownership.
46. UIKit views, controls, target-action, and delegation, configure reusable views and controls that report intent without owning domain decisions.
47. UIKit Auto Layout, stack views, guides, and priorities, express adaptive relationships and debug conflicts from product rules.
48. UIKit view-controller lifecycle and containment, compose loading, empty, list, and error regions with complete ownership transitions.
49. UIKit navigation, tabs, split views, and coordinators, translate shared routes into container-controller behavior across compact and regular presentations.
50. UIKit sheets, popovers, alerts, activities, and pickers, choose presentation from task scope and keep system-owned work in system controllers.
51. UIKit responder chain, gestures, menus, and input, route touch, pointer, keyboard, menu, gesture, and drag input to one intentional action path.
52. UIKit text, forms, keyboards, focus, and validation, edit a temporary draft with deliberate focus, keyboard layout, validation, and failure recovery.
53. UIKit table views, reuse, prefetching, and diffable data, drive rows from stable IDs, reusable configuration, deterministic snapshots, and cancellable prefetching.
54. UIKit collection views and compositional layout, separate snapshot identity, adaptive section geometry, and reusable cell presentation.
55. UIKit scrolling, drawing, layers, animation, and haptics, choose the rendering layer from measured interaction and performance needs.
56. UIKit observation, concurrency, networking, and persistence, render observable state on the main actor and keep effects behind cancellable adapters.
57. UIKit traits, accessibility, localization, and restoration, respond to changing environments and restore route intent by stable identity.
58. UIKit Field Notes capstone, assemble feature parity through UIKit’s lifecycle, containers, collections, input, and evidence model.

iOS app architecture and design

59. iOS architecture starts with pressure, score boundaries by change, test, integration, lifetime, criticality, and team pressure before choosing a pattern.
60. MVC and controller boundaries, keep UIKit controllers focused on lifecycle, events, navigation, and rendering while ordinary Swift types own formatting and validation.
61. MVVM and presentation models, share semantic editor state, derived values, and commands across SwiftUI and UIKit without importing either framework.
62. Unidirectional data flow, reducers, and state machines, express synchronization as explicit states, events, transitions, and controlled effects.
63. Domain models, value objects, invariants, and use cases, protect product meaning with validated values and framework-independent application actions.
64. Dependency injection and the composition root, select clocks, IDs, stores, APIs, and analytics once at startup instead of hiding them in global state.
65. Coordinators, routers, deep links, and restoration, parse one stable route model and adapt it to SwiftUI and UIKit navigation.
66. Repositories, gateways, clients, and ports and adapters, define purpose-named application contracts only where substitution, tests, transactions, or volatile integrations justify them.
67. Modularization with Swift Package Manager, enforce an inward dependency graph when reuse, ownership, safety, or measured build pressure earns a module.
68. Data architecture, source of truth, caching, offline sync, and conflict, keep durable local work visible while an outbox and explicit conflict policy reconcile server state.
69. Concurrency architecture, isolation, cancellation, and lifecycle, assign mutable state to owners and connect every task to a lifetime with a real cancellation path.
70. Architecture tests, refactoring seams, decisions, and tradeoffs, prove boundaries with behavior at several distances and evolve them through small recorded decisions.

Testing as a development discipline

71. Testing strategy, seams, and confidence, place each risk at the lowest testing distance that can produce trustworthy environment-specific evidence.
72. Swift Testing fundamentals and parameterized tests, express focused behavior with suites, expectations, requirements, traits, arguments, and async tests.
73. XCTest, XCUITest, test plans, and framework coexistence, retain XCTest for UI automation, performance, established suites, and configurable Xcode matrices.
74. Deterministic dependencies and concurrency tests, control time, identity, events, cancellation, and ordering instead of sleeping or relying on scheduler luck.
75. SwiftUI, UIKit, navigation, accessibility, and UI behavior tests, run one product acceptance contract through framework-specific drivers and retain separate accessibility evidence.
76. Persistence, migration, networking, and contract tests, exercise adapters against shared behavior, historical fixtures, corrupt inputs, retries, and transactional failure.
77. Performance, memory, energy, launch, and device matrices, set journey budgets and retain distinct Simulator, device, thermal, and release evidence.
78. CI, flake control, test data, release qualification, and evidence, layer gates, preserve first-failure artifacts, govern quarantine, and qualify releases claim by claim.

Production engineering and shipping

79. Networking, authentication, real-time events, and resilience, build typed transport, single-flight authentication refresh, bounded retries, explicit pagination, and recoverable streams without exposing credentials.
80. Persistence, Core Data, files, caches, migrations, and secure storage, choose storage by durability, query, size, secrecy, migration, and recovery requirements.
81. Security, privacy, permissions, and platform policy, request least privilege in context and preserve useful denial paths.
82. Background work, notifications, deep links, and app extensions, treat system re-entry as bounded adapters around shared routes and use cases.
83. Logging, analytics, crashes, privacy, and feature flags, collect typed minimized evidence and govern operational flags explicitly.
84. Instruments, responsiveness, energy, launch, and networking, reproduce a budget failure, trace its dominant cost, and verify one focused fix.
85. Build settings, signing, entitlements, CI, dependencies, and release configuration, produce auditable environment-specific archives without putting secrets in source.
86. TestFlight, App Store review, launch, observability, and evolution, carry an archive through beta evidence, truthful review material, controlled rollout, support, and rollback.

Apple ecosystem and capability atlas

87. One product across Apple platforms, share domain behavior while giving each device its own capabilities, navigation, input, and lifecycle.
88. iPadOS, multitasking, pointer, keyboard, Pencil, and documents, build independent adaptive workspaces with alternate input and document boundaries.
89. macOS with SwiftUI, make windows, documents, menus, settings, tables, toolbars, and keyboard access primary surfaces.
90. AppKit, Mac Catalyst, and framework choice, choose a UI stack by interaction quality, control depth, team knowledge, and measured reuse.
91. watchOS app structure and Watch connectivity, divide glanceable capture, independent work, phone coordination, and shared rules.
92. Workouts, complications, Smart Stack, and watch constraints, design sessions and timelines around wrist interaction, privacy, battery, and system scheduling.
93. tvOS focus, remote input, shelves, and navigation, replace direct touch with predictable focus identity and ten-foot hierarchy.
94. AVKit, AVFoundation, playback, streaming, and media sessions, compose system playback, interruptions, remote controls, subtitles, and durable position.
95. visionOS windows, volumes, ornaments, and spatial input, choose the smallest spatial presentation that serves the task and preserves comfort.
96. RealityKit, ARKit, immersive spaces, comfort, and assets, model entities, tracking quality, gestures, assets, performance, and nonspatial fallback.
97. WidgetKit and Live Activities, publish glanceable timelines and bounded live progress without treating extensions as always running.
98. App Intents, Shortcuts, Spotlight, and system actions, expose stable entities and application commands outside the app.
99. CloudKit, iCloud containers, sharing, and sync, keep Apple’s cloud stack behind local-first sync, account, conflict, and sharing policy.
100. MapKit, Core Location, geocoding, and WeatherKit, add optional place and weather context with proportional access, caching, and fallback.
101. Camera, PhotoKit, image pipelines, and Vision, acquire, orient, store, thumbnail, analyze, and delete images with bounded memory and consent.
102. Audio, speech, recording, and interruptions, model recording, routes, interruptions, permissions, transcription, and recovery explicitly.
103. Video capture, editing, playback, and streaming architecture, separate capture, timed assets, composition, export, playback, and delivery.
104. Core Bluetooth, nearby interaction, accessories, and connectivity, treat nearby hardware as a stateful protocol with bounded discovery, framing, and recovery.
105. HealthKit, WorkoutKit, and health-data design, preserve units and provenance while minimizing authorization, retention, and export.
106. Core ML, Vision, Natural Language, and on-device intelligence, place versioned inference behind measured accuracy, confidence, performance, and fallback contracts.
107. StoreKit, subscriptions, offers, and entitlement state, derive durable access from verified transaction history and lifecycle state.
108. Apple Pay, passes, Wallet, and transaction UX, validate eligible physical transactions and durable pass state without storing payment credentials.
109. Games, GameKit, SpriteKit, SceneKit, and Metal choices, choose scene, service, and rendering layers from mechanics and measured needs.
110. Home, Matter, CarPlay, files, collaboration, and specialized extensions, evaluate specialized frameworks, entitlements, targets, and document flows without coupling the core.
111. Atlas Desk discovery and release boundary, define Atlas Desk around capture, connection, retrieval, export, and a measurable first release.
112. Atlas Desk domain and architecture, protect document rules with domain values, application operations, and purpose-named ports.
113. Atlas Desk SwiftUI phone and tablet app, adapt one task model to quick phone capture and keyboard-rich iPad research.
114. Atlas Desk storage, search, files, and sync, coordinate durable local writes, indexing, attachments, migrations, outbox sync, and conflicts.
115. Atlas Desk macOS product design, make the Mac product native through windows, commands, import, settings, and desktop interaction.
116. Atlas Desk quality and release review, gate release on migration, conflict, scale, accessibility, and interrupted-sync evidence.
117. PulseTrail product, safety, and privacy, bound an offline outdoor product with explicit safety limits and health-data minimization.
118. PulseTrail cross-device architecture, assign workout authority and exchange versioned, recoverable phone-watch messages.
119. PulseTrail HealthKit, WorkoutKit, maps, and location, preserve authorization, units, provenance, interruptions, and route gaps in workout records.
120. PulseTrail watch UI, complications, widgets, and Live Activities, project one durable workout into glanceable watch, widget, and lock-screen surfaces.
121. PulseTrail offline, battery, sync, and failure recovery, checkpoint sessions, batch samples, conserve energy, and recover delayed cross-device transfer.
122. PulseTrail testing and release review, combine deterministic replays with device, outdoor, energy, authorization, and privacy evidence.
123. ScreenRoom product and content model, separate catalog, profile, access, playback intent, and progress before styling the television experience.
124. ScreenRoom tvOS architecture and focus, make focus and selection restorable product state across remote-driven catalog navigation.
125. ScreenRoom playback and media lifecycle, give playback, commands, interruptions, subtitles, progress, and events stable lifecycle ownership.
126. ScreenRoom backend, auth, subscriptions, and downloads, separate device authorization, account sessions, verified access, catalog paging, and downloads.
127. ScreenRoom performance, accessibility, and resilience, measure television image and playback costs while exposing buffering, failure, and accessible recovery.
128. ScreenRoom testing and release review, layer media, purchase, focus, account, analytics, and real-device evidence for release.
129. NeighborLink product, trust, and moderation, design listing, identity, chat, location, reporting, blocking, appeal, and moderation as one trust system.
130. NeighborLink architecture, identity, and API contracts, isolate identity, authorization, paging, uploads, DTO mapping, and message streams behind typed contracts.
131. NeighborLink UIKit feed, search, forms, camera, and maps, drive UIKit collection snapshots, drafts, media, search, and maps from coherent presentation state.
132. NeighborLink chat, offline writes, push, and deep links, make chat durable with client IDs, outbox replay, sequence reconciliation, push, and validated routes.
133. NeighborLink payments, privacy, security, and moderation operations, fit physical-goods payment, data minimization, reports, blocks, audit events, and appeals into one operation.
134. NeighborLink quality and release review, attack authorization, moderation, media, services, accessibility, and account transitions before release.
135. SpacePlanner product, comfort, and spatial design, choose windows, volumes, and immersion from planning value, comfort, exit, and recovery needs.
136. SpacePlanner architecture and asset pipeline, keep spatial projects and edits independent of entities, assets, rendering, persistence, and collaboration.
137. SpacePlanner windows, volumes, immersion, and input, combine predictable window, volume, immersive, gaze, pinch, and direct-manipulation behavior.
138. SpacePlanner RealityKit, ARKit, interaction, and rendering, build scalable component and system interaction with domain-owned snapping and undo.
139. SpacePlanner persistence, collaboration, performance, and accessibility, merge intent, stream large assets, measure performance, and provide accessible nonspatial alternatives.
140. SpacePlanner testing and release review, close the series with domain, device, tracking, frame, comfort, collaboration, and accessibility evidence.

Where the path goes

The orientation arc establishes the tools and evidence vocabulary. The later curriculum follows eight connected tracks:

Swift language
    |
    v
Product and interface design
    |
    +-> SwiftUI
    |
    +-> UIKit
    |
    v
Architecture and data boundaries
    |
    v
Testing and production engineering
    |
    v
Shipping and Apple platform capabilities
    |
    v
Complete product case studies

The same Field Notes domain appears across the core path. Keeping one product spine makes framework differences visible without changing every business rule at the same time.

Evidence labels

Examples use the smallest environment that can prove their claim:

• Compiled: The named Swift source or target completed compilation.
• Package tested: Swift package tests passed.
• Linux runner tested: Browser or executor checks passed against Swift 6.3.3 on Linux.
• Simulator tested: A named journey passed on a recorded Simulator runtime.
• Device tested: A named journey passed on recorded physical hardware.
• Account tested: A service integration passed with the named development or sandbox account.
• Not verified: The required tool, destination, hardware, entitlement, account, or service was unavailable.

One label never silently upgrades into another. A successful browser run does not prove SwiftUI. A successful Simulator run does not prove camera behavior or device performance.

Practice surfaces

The course uses several execution shapes because one shape cannot prove everything:

• Editable browser exercises for Swift standard-library work.
• Standalone Swift files for compiler and debugger experiments.
• Swift packages for domain rules and deterministic tests.
• Xcode targets for SwiftUI, UIKit, extensions, and Apple SDK integrations.
• Simulator journeys for supported interface and runtime behavior.
• Physical-device checks for hardware, performance, background execution, and service boundaries.

The current browser editor has an explicit unavailable state when no execution service is configured. Source remains editable and visible in that state.

Product spine

Field Notes is a local-first notebook for short observations, tags, favorites, search, and later synchronization. It begins as a command-line package checkpoint, gains separate SwiftUI and UIKit adapters, and grows only when a lesson introduces a new product pressure.

The shared core does not depend on either interface framework. This lets the series compare framework models without duplicating domain behavior or pretending that an interface type owns persistence and networking rules.

How to read the series

Read in order when Swift or Apple development is new. Experienced Swift developers can use the orientation arc as a vocabulary check, then enter at product design, SwiftUI, UIKit, architecture, testing, production engineering, or the platform capability atlas.

Run the code when the environment is available. When it is not, keep the evidence label honest and continue with lessons whose claims fit the installed tools.

Related topics

• Swift coding problems, runnable standard-library practice across the full coding-problem catalog.
• Testing, the test distances and feedback loops used throughout the course.
• Software design principles, neighboring design guidance for boundaries, composition, and maintainable change.