Article Accelerator tutorial: “Dissecting an app’s architecture” doesn’t explain data flow, and ArticleStore isn’t a realistic network simulation

Here's a sharper version. It's blunt about how badly the app is built, but it avoids swearing and insults, because forum moderators remove posts like that.

Title:
Article Accelerator: an architecture tutorial built on patterns we shouldn't copy

Text:

The tutorial "Dissecting an app's architecture" promises to show how data flows in and through Article Accelerator:
https://developer.apple.com/tutorials/app-dev-training/dissecting-an-apps-architecture

For a tutorial whose whole subject is architecture, the sample app is a poor example of it. The article never actually traces the data flow, and the code it describes uses patterns that most SwiftUI guidance tells you to avoid.

The "simulated network service" isn't one.
The tutorial says ArticleStore simulates a network service. In reality it's a singleton that synchronously loads JSON files from the bundle. It can't be slow, can't fail and can't return partial data, so it simulates none of what makes networking hard. It cannot be turned into an async URLSession call without throwing it away and redesigning the data layer.

Views fetch data directly from a singleton.
DetailView does private let articles = ArticleStore.shared.articles() as a stored property. There's no @Observable model, no loading state, no error state, and no dependency injection. This makes the views impossible to test with fake data and hides the data flow the tutorial claims to explain.

Error handling is print and fatalError.
A broken article file is silently skipped with print. An unreadable folder crashes the app. Failing to delete user data also crashes the app.

SwiftData setup is inconsistent.
The app creates one ModelContainer, then ArticleStateManager creates a separate ModelContext instead of using the container's mainContext. So writes through the manager and @Query reads go through different contexts. On top of that, the environment default for articleStateManager quietly creates a second ModelContainer with try!, so any window that forgets to inject it gets a different container.

The structure isn't structured.
The tutorial's challenge asks you to sort the Models folder into three categories, but the project puts everything in one flat folder, including ArticleStateManager, which isn't a model at all. Article, the main model, isn't even in it.

The key design decision is never explained.
Articles live only in memory while user data lives in SwiftData, and views join them by ID. That's a reasonable split, but the tutorial never says so, never explains why, and never addresses what it means for offline support, caching or paging. A learner who expects "fetch, store in SwiftData, show with @Query" is left confused.

Official Apple tutorials are where many developers learn what good practice looks like. An article called "Dissecting an app's architecture" should either show a sound architecture, or clearly label the shortcuts as shortcuts. Right now it does neither.

My questions:

  1. Is ArticleStore intended as a pattern to follow, or only a placeholder?
  2. What would Apple recommend for this app's data layer with a real async network service, including caching and paging?