Slower App Store reviews have become something more and more developers can clearly feel. In the age of vibe coding, the cost of building and iterating on apps has dropped dramatically, so it is not hard to understand why the review system is under greater pressure. The problem is that longer review times seem to be little more than a system overwhelmed by a growing volume of submissions, without a corresponding increase in the barriers that keep scam apps out of the store.
Recently, Jeff Johnson came across a highly suspicious Safari extension in the Mac App Store: its screenshots appeared to be AI-generated, advertised a nonexistent “4.9 out of 5” rating, and some of its five-star reviews were even dated before the app itself was released. Looking further, he found that the developer behind the extension had 41 apps on the App Store and had accumulated at least 368 approved review submissions over the past year—nearly one per day on average. Meanwhile, well-known developer Marco Arment’s new app had already been sitting in the review queue for 12 days.
This creates a rather awkward situation. On one hand, suspicious and potentially fraudulent apps can make it through review and climb the charts. On the other, AI has made rapid development and frequent iteration easier than ever, sending large numbers of both legitimate and high-risk submissions through the same review system and consuming its limited resources.
An urgent question is becoming difficult to avoid: Should App Review continue to treat each submission in isolation?
Johnson suggests introducing something akin to a trust system, allowing developers with a long history of following the rules and maintaining a good review record to receive faster reviews, while directing more resources toward accounts that submit at unusually high volumes, publish apps in bulk, or exhibit other suspicious patterns. Critics worry that such a system could eventually turn into preferential treatment for well-known developers or those willing to pay, further raising the barrier to entry for newcomers to the App Store.
Now that AI has dramatically reduced the cost of producing apps, a review model that treats every submission as an isolated case is becoming increasingly difficult to sustain. I see nothing unreasonable about incorporating factors such as a developer’s history, submission frequency, similarities among their apps, and metadata anomalies into risk assessment. A strong track record should not mean exemption from review, but rather fewer repetitive, low-value checks; suspicious accounts should not be barred from submitting, but should receive greater scrutiny.
Perhaps what App Review truly needs is not simply greater efficiency, but a shift from reviewing individual submissions in isolation toward evaluating patterns of developer behavior.
Original
ContentBuilder Explained: The Secret Behind SwiftUI’s Type-Checking Speedup
In the WWDC 2026 session on what’s new in SwiftUI, Apple engineers introduced a new SwiftUI feature: ContentBuilder. Judging by how you use it, it looks like nothing more than a ViewBuilder with a wider reach — APIs that previously accepted ViewBuilder, ToolbarContentBuilder, or CommandsBuilder separately can now share a single builder. Apple also claims the change delivers a significant improvement in type-checking performance. This article digs into what ContentBuilder actually is, and where that performance comes from.
Recent Recommendations
Headless Xcode: From Prompt to Simulator with MCP
Xcode 27 beta 5 introduces xcrun mcp-server, allowing Xcode’s MCP capabilities to be exposed to external coding agents as a background service without launching the Xcode UI. Artem Novichkov uses Claude Code to demonstrate a complete Headless Xcode workflow: creating an Xcode project, generating SwiftUI code, building the project and rendering previews, launching the Simulator, reading the accessibility hierarchy, performing interactions, and finally verifying app state through screenshots and OSLog. This means a complete development loop—from prompt to code, then execution and verification—is beginning to take shape without relying on the Xcode UI.
iOS 26: Data Detector
iOS 26 introduces the new DataDetector, providing a more modern, Swift-native alternative to the long-standing NSDataDetector. Anton Gubarenko walks through the new API with numerous examples: developers can obtain an AsyncSequence directly through StringProtocol.dataDetectorMatches, then use native Swift ranges and strongly typed semantic results to identify email addresses, phone numbers, dates, addresses, monetary amounts, measurements, flight numbers, shipment tracking numbers, and more. The new API not only feels more natural to use, but can also recognize a richer set of semantic objects.
Measuring Elapsed Time in Swift with ContinuousClock
Many developers still habitually use Date() to record start and end times, but Date isn’t the ideal tool for answering “how long did this operation take?” Kyle Browning explores the Clock system introduced in Swift 5.7 and explains two more reliable ways to measure time: ContinuousClock and SuspendingClock.
ContinuousClock increases monotonically and continues counting while the device is asleep, making it suitable for measuring real-world elapsed time. SuspendingClock, by contrast, pauses while the device is asleep, making it more appropriate for measuring actual execution time. Kyle offers a simple rule of thumb: if Date() in your code is being used to “measure time” rather than “record a point in time,” you should probably consider replacing it with ContinuousClock.
From XCUITest to Promo Video
Every change to an app’s interface can mean recreating App Store screenshots, promotional videos, and assets for different languages. Noam Efergan proposes an interesting solution: treat marketing assets as reproducible build artifacts. Using launch arguments and fixed test data, he makes the real app enter deterministic UI states on demand, then uses XCUITest to automatically capture screenshots across different locales before passing the results to Remotion to generate promotional videos. Rather than maintaining a separate mock UI for marketing, the entire workflow keeps the actual running SwiftUI interface as its source material. It also demonstrates another value of testability beyond testing: when an app can reliably and precisely reproduce a given state, the same capability can support debugging, demos, localization, and automated marketing content production.
Software Engineering fundamentals matter more than ever
As coding agents become capable of rapidly generating code, completing tests, and even independently implementing fairly complex features, “can it be built?” is gradually becoming one of the easier questions in software development. Joseph Heck argues that the genuinely difficult parts have not disappeared: designing clear boundaries and abstractions, making software debuggable, maintainable, and composable, and making sensible tradeoffs among competing constraints. AI can significantly reduce implementation costs, but it cannot replace the software engineering skills built on experience, judgment, and a long-term perspective. In a sense, as “writing code that works” becomes easier, software engineering fundamentals matter more than ever.
Why Soft Skills Matter More Than Technical Skills in the Age of AI
If the previous article discusses “how to build software well” in the age of AI, Mohammad Azam takes the question one step further: first, we need to decide “what should be built.” As AI continues to reduce the cost of implementation, understanding the business, clarifying requirements, asking the right questions, communicating and collaborating, and evaluating tradeoffs become even more important. AI can produce ten implementation approaches in seconds, but it doesn’t know why a particular business rule exists within a company, nor can it take responsibility for the final product on behalf of the developer. Technical skills have not lost their value—they remain the foundation for judging whether AI-generated results are sound. What may become scarcer in the future is not the ability to “write more code,” but the ability to understand the problem, make sound judgments, and ultimately solve the right problem.
Tool
GlyphKit: Precise Glyph Layout in SwiftUI with Vector Outlines
Displaying a character in SwiftUI is easy, but making a glyph precisely occupy a specified region is not. Text is designed primarily for text layout, where baselines, font metrics, and Dynamic Type can all influence the final result.
GlyphKit takes a different approach by treating glyphs as graphics: it extracts the vector outline (CGPath) of an individual character through Core Text and renders it with SwiftUI Canvas, providing more direct control over size and positioning. GlyphKit is not a replacement for Text. It is better suited to individual decorative glyphs, while complex graphemes, ligatures, and content that requires text accessibility should still be handled by a full text layout system.