跪拜 Guibai
← Back to the summary

App Review Is Slowing to a Crawl While Scam Apps Sail Through

issue149.webp

App Review is Getting Slower — Who Is It Blocking?

App Store review is slowing down, and more and more developers are feeling the change. In the era of Vibe Coding, the cost of developing and iterating on apps has dropped dramatically, so it's not hard to understand why review pressure has increased. The problem is that the slower review process seems merely overwhelmed by the growing number of submissions, without a corresponding rise in the barrier for scam apps to enter the store.

Recently, Jeff Johnson discovered a suspicious Safari extension on the Mac App Store: the screenshots appeared to be AI-generated, showing a non-existent "4.9" rating, and some five-star reviews were dated before the app's release. Digging further, he found that the developer behind this extension had 41 apps in the App Store, with at least 368 approved review submissions in the past year — averaging nearly one per day. Meanwhile, well-known developer Marco Arment's new app had been sitting in the review queue for 12 days.

This creates an awkward situation: on one hand, suspicious or even fraudulent apps can pass review and climb the charts; on the other, AI has made rapid development and frequent iteration easier than ever, flooding the same review mechanism with both legitimate and high-risk submissions, continuously draining limited review resources.

A pressing question now stands before us: should App Review continue to treat each submission in isolation?

Johnson suggests introducing a credit-like system, where developers with a long history of compliance and good review records get faster reviews, freeing up more resources to scrutinize high-frequency, bulk, and anomalous accounts. Opponents worry this could eventually turn into preferential treatment for well-known or paying developers, further raising the barrier for newcomers entering the App Store.

After AI has drastically lowered the cost of app production, a model that treats every submission as an isolated object is becoming increasingly unsustainable. I see nothing wrong with incorporating developer history, submission frequency, similarity between apps, and metadata anomalies into risk assessment. Good credit doesn't mean exemption from review — it means fewer redundant, low-value checks. Anomalous accounts aren't banned from submitting — they just face deeper scrutiny.

Perhaps what App Review truly needs to upgrade isn't just review efficiency, but a shift from single-point "review" to "behavioral judgment."

This Issue | Previous Issue | All Issues

Original

ContentBuilder Explained: The Secret to SwiftUI Type-Checking Performance Gains

In the WWDC 2026 session on new SwiftUI features, Apple engineers introduced a new SwiftUI feature — ContentBuilder. From a usage perspective, it seems like just a broader version of ViewBuilder: APIs that previously accepted ViewBuilder, ToolbarContentBuilder, and CommandsBuilder separately can now share a single builder. Apple also claims this adjustment significantly improves type-checking performance. This article will analyze the essence of ContentBuilder and explore the secrets behind the performance boost.

Recent Recommendations

Headless Xcode: From Prompt to Simulator with MCP

Xcode 27 beta 5 added xcrun mcp-server, allowing Xcode's MCP capabilities to be provided to external Coding Agents as a background service without launching the Xcode UI. Artem Novichkov demonstrated a complete Headless Xcode workflow using Claude Code: from creating an Xcode project, generating SwiftUI code, building the project and rendering Previews, to launching the Simulator, reading the accessibility hierarchy, performing interactions, and finally verifying the app state using screenshots and OSLog. This means a complete development loop — from prompt to code, to execution and verification — that doesn't depend on the Xcode UI is beginning to take shape.

iOS 26: Data Detector

iOS 26 introduces a new DataDetector, providing a more modern Swift-style alternative to the long-serving NSDataDetector. Anton Gubarenko introduces the new API with numerous examples: developers can directly obtain an AsyncSequence via StringProtocol.dataDetectorMatches, and use native Swift Ranges and strongly-typed semantic results to identify emails, phone numbers, dates, addresses, monetary amounts, measurements, flight numbers, tracking numbers, and more within text. The new API is not only more natural to use but also recognizes 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 is not the ideal tool for answering "how long did this operation take?" Kyle Browning focuses on the Clock system introduced in Swift 5.7 and presents two more reliable ways to measure time: ContinuousClock and SuspendingClock.

ContinuousClock is monotonic and includes time elapsed while the device is asleep, making it suitable for measuring real-world elapsed time; SuspendingClock pauses when the device sleeps, making it better for measuring actual running time. Kyle offers a simple rule of thumb: if Date() in your code is used for "timing" rather than "recording a point in time," you should generally consider switching to ContinuousClock.

From XCUITest to Promo Video

Every time an app's interface changes, it can mean App Store screenshots, promo videos, and localized assets need to be remade. Noam Efergan proposes an interesting solution: treat marketing assets as reproducible build artifacts. Using launch arguments and fixed test data, the real app can be brought into a deterministic UI state at any time, then XCUITest automatically captures screenshots in different locales, and the results are handed off to Remotion to generate promo videos. The entire process never creates a separate mock UI for marketing purposes; it always uses the actual running SwiftUI interface as the source material. This also demonstrates the value of testability beyond testing: when an application can stably and accurately reproduce a given state, that same capability can serve debugging, demos, localization, and automated marketing content production.

Software Engineering fundamentals matter more than ever

When Coding Agents can quickly generate code, complete tests, and even independently implement fairly complex features, "can we build it?" is gradually becoming the easier problem in software development. Joseph Heck argues that the truly difficult parts haven't gone away: how to design clear boundaries and abstractions, how to make software debuggable, maintainable, and composable, and how to make reasonable trade-offs among various constraints. AI can significantly lower implementation costs, but it cannot replace these software engineering capabilities built on experience, judgment, and a long-term perspective. In a sense, when "writing working code" becomes easier and easier, Software Engineering fundamentals become even more important.

Why Soft Skills Matter More Than Technical Skills in the Age of AI

If the previous piece discussed "how to build software well" in the AI era, Mohammad Azam pushes the question one step further: we first need to determine "what should be built." As AI continues to lower the cost of code implementation, the importance of understanding the business, clarifying requirements, asking the right questions, communication, collaboration, and evaluating trade-offs becomes even more prominent. AI can produce ten implementation options in seconds, but it doesn't know why a particular business rule exists at a company, nor can it bear the ultimate responsibility for delivery on behalf of the developer. Technical skills haven't lost their value — they remain the foundation for judging whether AI-generated results are reasonable; it's just that what will be scarcer in the future may no longer be "how much code you can write," but the ability to understand problems, make judgments, and ultimately solve the right problems.

Tools

GlyphKit: Precise Glyph Layout Control in SwiftUI Using Vector Outlines

Displaying a character in SwiftUI is simple, but making a glyph precisely occupy a specified area is not. Text's primary purpose is text layout, and baselines, font metrics, and Dynamic Type can all influence the final layout.

GlyphKit treats glyphs as graphics: it extracts the vector outline (CGPath) of individual characters via Core Text, then draws them using SwiftUI Canvas, achieving more direct control over size and position. GlyphKit is not a replacement for Text. It is better suited for single, decorative glyphs; complex graphemes, ligatures, and content requiring text accessibility features should still be handled by a full text layout system.

Previous Issues

💝 Support & Feedback

If this issue helped you, please:

🚀 Expand Your Swift Horizons

  • 📮 Email Subscription | weekly.fatbobman.com for exclusive technical insights
  • 👥 Developer Community | Discord for real-time dev discussions
  • 📚 Original Tutorials | fatbobman.com to learn Swift/SwiftUI best practices
Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

iOSleep 1 likes

Review is definitely slow. Submitted last Friday and it's still not reviewed [crying]