Who Is the Slower App Review Process Actually Stopping? -- Fatbobman's Swift Weekly #149
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A weekly SwiftUI/iOS newsletter opens with commentary on the App Store review system: suspicious apps with fake ratings and AI-generated screenshots slip through while legitimate developers like Marco Arment wait 12 days for review. The author argues Apple should shift from reviewing isolated submissions to evaluating patterns of developer behavior, incorporating history and submission frequency into risk assessment. The rest of the issue rounds up SwiftUI and iOS development links: a deep dive into the new ContentBuilder compiler speedup, a headless Xcode MCP workflow for AI coding agents, iOS 26's new DataDetector API, using ContinuousClock for timing, turning XCUITest into promo video generation, essays on software engineering fundamentals and soft skills in the AI era, and a GlyphKit library for precise glyph layout.
Questions this post answers
What does Xcode's new xcrun mcp-server do in Xcode 27 beta 5?
It exposes Xcode's MCP capabilities as a background service to external coding agents without launching the Xcode UI. This enables a full headless development loop where an agent like Claude Code can create a project, generate SwiftUI code, build and preview it, launch the Simulator, read the accessibility hierarchy, perform interactions, and verify state via screenshots and OSLog. Developers wiring AI agents into their build pipeline can track Xcode MCP tooling changes on daily.dev.
What is SwiftUI's new ContentBuilder introduced at WWDC 2026?
ContentBuilder is a unified result builder that replaces the need for separate builders like ViewBuilder, ToolbarContentBuilder, and CommandsBuilder, letting APIs that previously required each of those share a single builder instead. Apple states it also brings a significant improvement in type-checking performance for SwiftUI code. Teams optimizing SwiftUI build times can follow compiler-level changes like this via daily.dev.
Why should I use ContinuousClock instead of Date() to measure elapsed time in Swift?
Date() records a point in time but is unreliable for measuring durations, since it can be affected by clock adjustments. ContinuousClock, introduced with the Clock system in Swift 5.7, increases monotonically and keeps counting while the device sleeps, making it better suited for real-world elapsed time, while SuspendingClock pauses during sleep and better measures actual execution time. Developers refactoring timing logic can check Swift API guidance like this through daily.dev.