The news
Joe Fabisevich submitted version 6.0.4 of his app Plinky for App Store review last week. The macOS version received approval in four hours. The iOS version remained in review at the time of his report. Similar accounts appear across developer discussions, indicating the pattern is widespread rather than isolated.
Context
Plinky functions as a link-bookmarking tool that syncs data between iOS and macOS devices. It provides multiple low-friction methods for saving bookmarks. Fabisevich has described the project as a labor of love built around his own needs as the primary user. The App Store distribution model remains the required channel for many developers targeting Apple platforms, leaving them dependent on review queue performance.
The single source available frames these delays against an influx of submissions tied to AI assistance in app creation. No official Apple statements on current review volumes or staffing appear in the available account. The single data point of a four-hour macOS approval versus an open iOS case illustrates the variability developers encounter.
Details
Fabisevich posted the timeline on Mastodon, noting the split outcome between the two platforms for the same update. He observed that comparable experiences surface regularly from other App Store developers. The Daring Fireball summary of the post frames the delays against an influx of submissions tied to AI assistance in app creation. No official Apple statements on current review volumes or staffing appear in the available account. The single data point of a four-hour macOS approval versus an open iOS case illustrates the variability developers encounter.
Plinky itself receives specific attention in the coverage. The summary describes it as an intriguing link-bookmarking app that syncs across iOS and macOS. It offers a bunch of convenient ways to stash new bookmarks with low friction. The coverage notes that the nature of the author’s work creates unusual bookmarking needs, and that Plinky meets them directly. It is presented as a labor of love where Fabisevich is the number one user, a trait the summary says is almost always true of the very best apps.
The post itself carries a short closing remark from Fabisevich: “Sure do love to distribute software this way.” That line captures the frustration without additional elaboration in the source. The observation that he is not an outlier rests on the claim that comments like his appear from App Store developers everywhere the author looks.
Why it matters
When review times fluctuate sharply for the same app across platforms, independent developers absorb direct costs in delayed releases and lost iteration cycles. The reported rise in submissions, attributed to AI tools lowering the barrier to producing new apps, places pressure on a review system that has not scaled visibly to match. Developers who treat the App Store as their primary distribution path now face longer uncertainty windows for iOS releases even when macOS clears rapidly. This asymmetry affects small teams and solo creators most, as they lack resources to maintain parallel distribution methods or absorb extended waits. The pattern suggests the current review process is absorbing volume without corresponding speed gains, leaving the practical experience of shipping updates more unpredictable than before.
The source provides no counter-evidence that review staffing or processes have adjusted to the claimed increase in submissions. It also supplies no data on average review times or queue lengths beyond the single case described. In the absence of those figures, the concrete example of one app receiving platform-specific treatment stands as the clearest available signal. For developers whose income depends on timely updates, that signal translates into concrete planning difficulties rather than abstract inconvenience.
The emphasis on Plinky as a labor of love further sharpens the point. When the primary user of an app is its own creator, extended review waits directly interrupt the feedback loop that improves the product. AI-assisted submissions may increase the total number of apps entering the queue, yet the source gives no indication that the review process distinguishes between those apps and ones built through conventional effort. The result is a shared queue where speed of creation on one side meets unchanged processing capacity on the other.
---
Sources:
{"word_count": 712, "sources_used": 1}
No comments yet