Fruta: Building a feature-rich app with SwiftUI

At a glance

Project structure

Source bundle/
├── Shared/
│   ├── FrutaApp.swift
│   ├── Orders/
│   │   ├── OrderPlacedView.swift
│   │   └── RewardsView.swift
│   ├── Components/
│   │   ├── FlipView.swift
│   │   ├── StepperView.swift
│   │   └── BubbleView.swift
│   ├── Recipe/
│   │   └── RecipeView.swift
│   ├── Navigation/
│   │   ├── AppSidebarNavigation.swift
│   │   └── ContentView.swift
│   └── NutritionFacts/
│       └── NutritionFactView.swift
├── iOS/
│   └── FrutaAppClip.swift
└── Widgets/
    └── FrutaWidgets.swift

Structure observations

• Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
• Primary languages: Swift.
• The verified tree contains 15 project/configuration file(s) and 78 source declaration(s).

Overall architecture

flowchart LR
    Bundle["Sample bundle"]
    V1["Shared"]
    V2["Widgets"]
    V3["iOS"]
    Boundary["SwiftUI / StoreKit APIs"]
    Bundle --> V1
    V1 --> Boundary
    Bundle --> V2
    V2 --> Boundary
    Bundle --> V3
    V3 --> Boundary

Reference code

Shared/FrutaApp.swift:10 — architecture anchor

@main
struct FrutaApp: App {
    @StateObject private var model = Model()

    var body: some Scene {
        WindowGroup {
            ContentView()
                .environmentObject(model)
        }
        .commands {
            SidebarCommands()
            SmoothieCommands(model: model)
        }
    }
}

Interpretation

The branches represent separate entry-bearing project variants in the downloaded bundle, not runtime calls between those variants. Each branch is intentionally collapsed at the documented framework boundary; the detailed target-local flow remains in the cited files. Ownership is claimed only where the next section cites a stored property or assignment.

Ownership and state

classDiagram
    FrutaApp *-- Model : model
    FlipView o-- FlipViewSide : visibleSide
    FlipView o-- Front : front
    FlipView o-- Back : back

Ownership evidence

Shared/FrutaApp.swift:12 — stored dependency or nearest verified ownership anchor

@main
struct FrutaApp: App {
    @StateObject private var model = Model()
    // ...
}

Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.

Concurrency, scheduling, and thread safety

Evidence limit: actor isolation, async/await, or Task creation does not by itself prove background-thread execution; Sendable conformance alone does not prove thread-safe mutation.

@MainActor/MainActor.run, DispatchQueue.main, and RunLoop.main are reported as distinct isolation, queue, and event-loop mechanisms. A plain Task is kept separate from Task.detached; neither is labeled as a background thread.

Reference code

Shared/Model/Model.swift:48 — representative execution boundary

        updatesHandler = Task {
            await listenForStoreUpdates()
        }

State propagation, frameworks, and dependencies

Evidence limit: an import proves a source-level compilation dependency at the cited line; it does not prove runtime use, architectural adoption, or whether a Swift package is a direct application dependency.

receive(on:) describes downstream delivery scheduling, while subscribe(on:) describes upstream subscription/request/cancel scheduling. An import Combine alone establishes neither behavior nor a Store, reducer, Redux, or other application architecture.

Class and protocol design

Shared/NutritionFacts/UnitIcons.swift:22 — representative type boundary

private protocol UnitIconProvider {
    var customUnitIcon: Image { get }
}

The source explicitly defines local protocol relationships: Measurement → DisplayableMeasurement, UnitMass → UnitIconProvider, UnitVolume → UnitIconProvider.

Access control

Reference code

Shared/Components/BubbleView.swift:16 — representative boundary

struct BubbleView: View {
    // ...
    @State private var shimmer: Bool = .random()
    // ...
}

Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.

Logic ownership and placement

Design patterns

Naming conventions

• Types: App: FrutaApp; Builder: SmoothieArrayBuilder, SmoothieBuilder; Coordinator: Coordinator; Model: Model; Provider: Provider, UnitIconProvider; View: BubbleView, ContentView, FeaturedSmoothieEntryView, FlipView, MeasurementView.
• Protocols: UnitIconProvider, DisplayableMeasurement.
• Methods: handleUserActivity, toggle, body, increment, decrement.
• Files: Shared/FrutaApp.swift, iOS/FrutaAppClip.swift, Shared/Orders/OrderPlacedView.swift, Widgets/FrutaWidgets.swift, Shared/Components/FlipView.swift, Shared/Components/StepperView.swift.

Architecture takeaways

• FrutaApp is the main source-visible entry or composition anchor for this sample.
• Framework work reaches SwiftUI, StoreKit, AuthenticationServices, WidgetKit through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
• Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
• Access-control conclusions separate verified language visibility from the likely design rationale.
• Local protocol relationships provide an explicit substitution boundary.

Source map

• Official Apple documentation