My friend and fellow indie developer Alan Seales recently had his app, Dumpling, rejected under Apple’s App Review Guideline 4.3: Spam. I’ve used it. The design is thoughtful, the implementation is solid, and it understands the people it was built for. I have a hard time seeing a disposable clone.
Dumpling is a voice note-taking app for iPhone and Apple Watch, built to reduce the friction between capturing a thought and organizing it, including for people with ADHD. It transcribes recordings, titles and files notes, extracts tasks and due dates, and assembles a daily summary. You can capture a thought without first deciding where it belongs.
I don’t know which apps Apple considered Dumpling too similar to, or which similarities drove the rejection. That makes the decision difficult to evaluate and even harder to address. At a broad enough level, almost any app is something that already exists: a voice recorder, a task manager, a weather app. The differences often emerge when you use it.
That uncertainty raises a bigger question: as software becomes easier to build, does getting into the App Store first become a more valuable competitive advantage? A rule meant to keep out spam could create an accidental moat around the products already admitted.
What does Apple’s App Store Guideline 4.3 mean?
Apple’s spam guideline covers two related problems. Section 4.3(a) addresses submitting the same app through multiple Bundle IDs, such as making a separate map app for every city. Section 4.3(b) addresses apps that are effectively indistinguishable from existing offerings. In established categories, Apple requires a “meaningfully different or improved experience.” Its examples include dating apps, wallpaper apps, and simple timers.
I understand the purpose. Taking somebody else’s product, changing the colors, and submitting it under another name creates work for reviewers and clutter for customers. Producing a hundred variations doesn’t make it more useful. Apple itself warns that essentially identical submissions consume App Review capacity.
The scale is substantial. In its May 2026 App Store update, Apple said it reviewed more than 9.1 million submissions during 2025 and rejected more than 371,000 for copying other apps, spam, or misleading users. That combined category counts submissions, not unique apps rejected specifically under 4.3. It doesn’t tell us how often legitimate apps were mistakenly rejected.
AI makes this more complicated because buying a template is no longer necessary to reproduce a familiar product. You can write an independent implementation of essentially the same experience. Owning the code doesn’t automatically make the result meaningfully different.
I use AI to build software. It can help developers solve difficult technical problems and serve overlooked customers. It can also make it cheaper to flood a marketplace with barely differentiated apps. The tools make both possible; the quality of the result still matters.
Why are developers disputing 4.3 spam rejections?
A similarity finding can be hard to answer when the developer cannot see what Apple is comparing. Recent public accounts show how difficult it can be to demonstrate what makes an app different, especially when its value depends on a specialized workflow.
FocusKit developer Sebastian Röhl reported two 4.3(a) rejections before launching his focus timer in November 2025. Several days of correspondence explaining its differences led to approval. That’s an encouraging outcome, but demonstrating that an app deserves admission took additional work before customers could try it.
In September 2026, the developer of YanPian reported a 4.3(a) rejection of a climbing-video app. Its features included matching Apple Watch heart-rate data to climbing footage, following a climber within a wide shot, and optional gimbal control. The developer acknowledged that without climbing footage to import, the opening screen could resemble a generic camera app. The public thread records an appeal without a posted resolution.
These accounts don’t establish that Apple rejected every app because its category was full. We also don’t have Apple’s complete review records. They do show how difficult it can be to understand what a developer is being asked to prove.
YanPian’s situation makes me think of Dumpling. A specialized app can share its basic ingredients with a general-purpose app while making different decisions about how they work together. Recognizing those decisions may require following a particular workflow or understanding the problem it solves. That’s a harder judgment than checking whether an app crashes.
Do App Store spam rules give early entrants an advantage?
I think they can. An app entering a relatively open category has fewer established products against which its distinctiveness can be judged. A later entrant may have to explain why its approach differs enough from a growing collection of available apps.
The earlier developer can spend that time attracting customers, improving the product, and learning from use. The later developer may spend it explaining why the product should be allowed to reach those customers. Even if approval eventually comes, the uncertainty and delay have a cost.
Approval isn’t permanent protection. Apple’s guidelines allow meaningful differentiation or improvement and contemplate removing apps that aren’t maintained, improved, or attracting customers. Existing developers can encounter review friction, too.
In September 2026, Josh Dance reported a 4.3(a) rejection of a Pushup Hero update. He said the app had been in the store since 2018. He was submitting bug fixes and dark mode when Apple flagged similarity to an app associated with a terminated account. His account describes an appeal without reporting its eventual outcome.
My concern is the additional burden of arriving after a category becomes crowded. That burden could influence both what developers build and how quickly they submit it.
It creates an uncomfortable incentive: rush. Time spent refining a product becomes time in which somebody else could establish the comparison point. A process designed to improve quality could inadvertently increase the pressure to submit before the work is ready.
Is AI making App Review slower or stricter?
Apple has acknowledged the submission growth. Its May 2026 statement says AI development tools are driving a surge in submissions while maintaining that App Review has “seamlessly scaled” to handle it. Apple also says it uses AI to analyze app similarity and flag potentially problematic changes for human reviewers. That doesn’t establish that automation made the final decision in any particular rejection.
In a March 2026 Business Insider report, Apple acknowledged some longer reviews. It said it had processed more than 200,000 submissions per week during the preceding 12 weeks, with an average review time of 1.5 days. Its developer guidance says 90% of submissions are typically reviewed in less than 48 hours.
A review decision and a successful release are different milestones. A developer can receive a prompt rejection and still spend weeks on correspondence, resubmissions, and appeals. Fast review statistics can coexist with a frustrating process for developers whose apps trigger a disputed classification.
Apple has also responded publicly to individual complaints. In a May 2026 thread about ByGate, a VPN service’s dedicated client, an account identified as Apple’s App Review staff said similarity in binaries, metadata, and overall concepts can contribute to a spam finding. It recommended an App Review appointment without identifying a specific comparator or explaining which characteristics were insufficiently distinct.
How can developers respond to a 4.3 rejection?
Apple offers correspondence with App Review, appointments, and appeals to the App Review Board. Those mechanisms work better when the developer understands the concern.
Similar code, similar screenshots, similar functionality, and a suspected connection to another developer are different problems. A developer cannot respond intelligently without knowing which applies. A useful rejection would identify the relevant screen or workflow, explain which claimed differences were considered, or clarify whether the concern involves authorship, repeated submissions, or the customer experience.
None of that requires revealing another developer’s private account information.
Developers have responsibilities here, too. Months of work don’t prove that an app offers something customers cannot already get. We need to make its value visible to someone encountering it for the first time. If that requires climbing footage, representative data, or a particular sequence of actions, provide a working demonstration and clear review instructions.
I have sympathy for reviewers trying to distinguish a clone from a familiar idea executed well. A better exchange of evidence would help both sides resolve misunderstandings before a developer starts redesigning an app around guesses.
Can developers distribute apps outside the App Store?
For Mac developers, direct distribution is an established option. Some apps need permissions or interaction with other applications that don’t fit within the Mac App Store’s sandbox. Apple’s sandbox documentation identifies certain uses of Accessibility APIs and interaction with other apps as incompatible with those restrictions.
I already distribute two Mac apps this way: Burly, my browser profile link router, and Comoji, my emoji shortcut app. Burly routes links to specific browser profiles and uses Accessibility access to control Safari’s profile menus. Comoji brings emoji shortcuts to text fields across the Mac, using Input Monitoring to recognize shortcuts and Accessibility access to insert the result. Those capabilities are central to the products.
Developer ID signing and notarization let developers distribute Mac software directly while retaining Apple’s checks for malicious software and signing problems. For apps that need to operate outside the store’s restrictions, that’s an established way to serve customers.
I expect uncertainty around spam rejections to give more developers a reason to invest in that independence. A website, checkout, mailing list, and direct customer relationship provide more control. They also offer room to explain a specialized product beyond a store listing.
But a website doesn’t recreate the App Store’s reach. Customers still have to discover it, trust the developer, and complete a different purchase and installation process. Even developers who distribute independently may want a store listing. Losing that opportunity has a cost.
The answer is more restrictive for iPhone and iPad. Apple currently supports alternative marketplaces and authorized website distribution in the European Union, with iPhone marketplaces also available in Japan and Brazil. These options have regional requirements and remain subject to notarization. A developer serving ordinary iPhone customers in the United States cannot simply replace a rejected listing with a website download button.
A web version may work for some products, but it can require substantial product changes. Independent distribution is a much more complete answer for a Mac developer than for an iPhone developer.
Will stricter App Store reviews discourage disposable clones?
I hope some of the people churning out clones decide that selling independently is more trouble than it’s worth. If the strategy is to submit a hundred variations and see what earns money, a rejection might be where some projects end.
Generating an app is only part of running a software business. Even if you can generate the website just as quickly, you still need to attract customers, earn trust, handle payments and updates, and give people a reason to choose you. Someone hoping to ride an existing app’s coattails may have little interest in that work.
Who needs another Pomodoro timer with a different icon? A familiar category can benefit from a better experience or an approach built for an overlooked audience. Reproducing the same product with different branding contributes very little.
I hope independent distribution discourages some of that behavior. I also hope Apple gets better at distinguishing it from a developer who has built something worth using. Stopping a disposable clone can benefit the marketplace; an opaque rejection of a thoughtful product can deny customers a useful choice.
I want Dumpling judged on the experience it provides to the people Alan built it for. If Apple believes that experience is insufficiently different, it should explain why. The first developer into a category deserves a head start with customers. The next developer should still get a fair chance to offer them something better.
