A Mac developer’s attempt to improve one of Apple’s most neglected features has run straight into the company’s gatekeeping apparatus. The result is a story that crystallizes the tension between Apple’s control over its platforms and the independent developers who try to fill gaps Apple won’t.
The app is called LaunchCade. It does something simple: replace Apple’s Launchpad — the grid of application icons that most Mac power users ignore entirely — with something more functional. Customizable layouts, better search, visual tweaks. The kind of quality-of-life improvement that Apple itself hasn’t bothered to ship in years.
But Apple has blocked updates to LaunchCade in the App Store, and the reason cuts to the heart of a long-running grievance among developers who build for Apple’s platforms.
A Familiar Pattern: Apple’s Guidelines as a Moving Target
According to Mashable, Apple rejected LaunchCade’s latest update citing App Store Review Guidelines — specifically provisions related to duplicating built-in functionality. The developer, who goes by the handle Sindre Sorhus and is well known in the Mac development community for a string of popular utilities, shared the rejection publicly on social media, sparking a wave of frustration from fellow developers.
The irony is thick. Apple’s own Launchpad has barely been touched since its introduction in macOS Lion back in 2011. It’s widely considered one of the weakest built-in features on the Mac. No meaningful customization. No real integration with modern macOS workflows. Just a static grid that mimics the iOS home screen, designed for an era when Apple thought Mac users wanted their computers to behave like iPads.
Sorhus isn’t some fly-by-night developer pushing low-quality clones. He maintains dozens of well-regarded open-source projects and Mac utilities. His apps are the kind of small, focused tools that fill specific needs Apple has left unaddressed. And that’s precisely the problem: Apple’s guidelines give reviewers broad discretion to reject apps that “duplicate” built-in features, even when those built-in features are, by any reasonable standard, inadequate.
This isn’t a new complaint. Developers have been raising alarms about this particular guideline for years. The rule, as written, could theoretically be used to block any third-party calculator, email client, or web browser — though in practice Apple applies it selectively. That selectivity is part of what makes it so maddening.
Sometimes Apple blocks a small utility. Sometimes it doesn’t. The inconsistency creates an environment where developers can’t predict whether their work will be approved, and where months of effort can be nullified by a single reviewer’s interpretation.
The Broader Tension Between Platform Control and Developer Innovation
What makes the LaunchCade situation particularly instructive is its timing. Apple is under regulatory pressure on multiple fronts — from the European Union’s Digital Markets Act to ongoing antitrust scrutiny in the United States — to open up its platforms and treat third-party developers more fairly. The company has made some concessions, particularly on iOS, where it now allows alternative app marketplaces in the EU. But on the Mac, where the App Store has always been optional (developers can still distribute apps directly), Apple’s review process still acts as a chokepoint for anyone who wants the visibility and trust that comes with an App Store listing.
And that trust matters. Many users, especially less technical ones, default to the App Store for software. Being excluded from it isn’t just an inconvenience — it can be a death sentence for discoverability.
The developer community’s reaction on X (formerly Twitter) and Mastodon has been pointed. Several prominent Mac developers shared their own rejection stories, painting a picture of a review process that feels arbitrary. One developer noted that Apple had approved previous versions of LaunchCade without issue, making the sudden rejection of an update feel capricious rather than principled.
Apple, for its part, hasn’t commented publicly on the LaunchCade situation. The company rarely does in individual cases. Its standard posture is to point developers toward the appeals process, which exists but is widely regarded as opaque and slow.
There’s a deeper philosophical question here. Apple argues that its review process protects users from malware, privacy violations, and low-quality software. Those are legitimate concerns. But the “duplicating functionality” rule isn’t about safety or privacy. It’s about control — specifically, Apple’s desire to maintain the primacy of its own software, even when that software is neglected.
Consider the history. Apple once rejected third-party podcast apps before eventually allowing them. It restricted third-party keyboard apps on iOS for years. It blocked alternative mapping applications from accessing certain system features. In each case, Apple eventually relented, usually under competitive or regulatory pressure. But the pattern persists: restrict first, open up later, and only when forced.
For developers like Sorhus, the calculation becomes whether it’s worth investing time in apps that could be blocked at any moment. Some have moved to direct distribution outside the App Store entirely, accepting the loss of discoverability in exchange for independence. Others have simply stopped building Mac utilities altogether.
That’s the real cost. Not just one blocked app, but the chilling effect on an entire category of software development. The Mac has historically thrived because of its vibrant third-party developer community — people who built the tools that made the platform indispensable for creative professionals, developers, and power users. Every arbitrary rejection chips away at that.
Apple’s Worldwide Developers Conference is approaching, and the company is expected to announce updates to macOS, iOS, and its developer tools. Whether any changes to App Store review policies will be among them remains to be seen. But the LaunchCade episode is a reminder that for all the talk of developer relations and platform openness, the fundamental power dynamic hasn’t shifted. Apple controls the gate. And it can close it whenever it wants.
The question isn’t whether Apple has the right to enforce its guidelines. It clearly does. The question is whether those guidelines, as currently written and enforced, serve users — or just serve Apple. For a company that frequently touts the quality and creativity of its developer community, blocking a well-made app that improves a feature Apple has ignored for over a decade sends a contradictory message.
Developers notice. And increasingly, so do regulators.
WebProNews is an iEntry Publication