DEV Community: Matt Senter

Introducing Despacer: Copy. Paste. In One Piece.

Matt Senter — Fri, 23 Oct 2026 16:43:03 +0000

I got tired of copying a command from Claude Code or Codex, pasting it into my terminal, and watching it fall apart. Those line breaks aren’t just visual wrapping. They come along for the ride.

So I built Despacer: a tiny Mac menu bar app that puts wrapped commands back together. Copy and paste the way you already do. It repairs the breaks and can recover the original text from your local agent session history.

It’s free and open source under the MIT license. No network access, no analytics, no data collected. And if a repair misses the mark, Undo Last Fix brings your original copy back.

Despacer runs on macOS 14 Sonoma or later. For now, you install it by building from source; the README has the steps.

Get Despacer on GitHub

CommandH ist da: Auch die letzte App ausblenden

Matt Senter — Thu, 22 Oct 2026 14:18:20 +0000

Ich nutze Cmd+H, um meinen Bildschirm freizuräumen. Aber unter macOS lässt sich die letzte sichtbare App nicht ausblenden. Ein Fenster übrig, noch ein Tastendruck und… nichts.

Also habe ich CommandH gebaut. Die kleine Menüleisten-App sorgt dafür, dass Cmd+H auch bei der letzten App funktioniert. Du kannst sie vollständig ausblenden oder Show Desktop wählen: Die Fenster gleiten an den Bildschirmrand und kommen mit einem weiteren Cmd+H zurück.

Die App ist kostenlos und unter der MIT-Lizenz quelloffen. Keine Berechtigungen für Bedienungshilfen oder Bildschirmaufnahme, keine Netzwerkanfragen, keine Datensammlung. Nur eine kleine Korrektur, damit ich meinen Schreibtisch erreiche.

CommandH läuft ab macOS 14 Sonoma. Vorerst wird die App aus dem Quellcode gebaut; die README auf GitHub erklärt das Installationsskript.

CommandH kennenlernen · Quellcode und Installationsanleitung

Apresentando CommandH: oculte aquele último app

Matt Senter — Thu, 22 Oct 2026 14:17:43 +0000

Uso Cmd+H para limpar a tela. Mas, no macOS, o último app visível se recusa a se ocultar. Uma janela restante, mais um toque e… nada.

Então criei o CommandH. É um pequeno app da barra de menus que faz Cmd+H funcionar também naquele último app. Você pode ocultá-lo completamente ou escolher Show Desktop, que afasta as janelas e as traz de volta com outro Cmd+H.

É gratuito e de código aberto, sob a licença MIT. Sem permissões de Acessibilidade ou Gravação de Tela, sem requisições de rede e sem coletar dados. Só uma pequena correção para chegar à mesa.

O CommandH funciona no macOS 14 Sonoma ou posterior. Por enquanto, a instalação exige compilar o código-fonte; o README no GitHub explica como usar o script.

Conheça o CommandH · Código e instruções de instalação

CommandH の紹介：最後のアプリも隠せるように

Matt Senter — Thu, 22 Oct 2026 14:17:05 +0000

私は Cmd+H で画面を片づけています。でも macOS では、最後に表示されているアプリだけは隠せません。残り一つのウィンドウでもう一度押しても……何も起きません。

そこで CommandH をつくりました。最後のアプリでも Cmd+H が効くようにする、小さなメニューバーアプリです。アプリを完全に隠すか、Show Desktop を選んでウィンドウを画面の端へ移動できます。後者では、もう一度 Cmd+H を押すと元に戻ります。

MIT ライセンスで公開している、無料のオープンソースです。アクセシビリティや画面収録の権限は不要。ネットワーク通信もデータ収集もありません。デスクトップに戻るための、小さな修正です。

CommandH は macOS 14 Sonoma 以降に対応しています。現在はソースからビルドしてインストールします。スクリプトの使い方は GitHub の README にあります。

CommandH について · ソースコードとインストール手順

Voici CommandH : masquez cette dernière app

Matt Senter — Thu, 22 Oct 2026 14:16:30 +0000

J’utilise Cmd+H pour dégager mon écran. Mais sur macOS, la dernière app visible refuse de se masquer. Une fenêtre restante, une pression de plus et… rien.

J’ai donc créé CommandH. Cette petite app de la barre des menus permet à Cmd+H de fonctionner aussi sur cette dernière app. Vous pouvez la masquer complètement ou choisir Show Desktop, qui écarte les fenêtres et les ramène avec un autre Cmd+H.

Elle est gratuite et open source, sous licence MIT. Aucune autorisation d’accessibilité ou d’enregistrement de l’écran, aucune requête réseau, aucune donnée collectée. Juste un petit correctif pour retrouver mon bureau.

CommandH fonctionne sur macOS 14 Sonoma ou version ultérieure. Pour le moment, l’installation passe par une compilation du code source ; le README sur GitHub explique comment utiliser le script.

Découvrir CommandH · Code et instructions d’installation

介绍 CommandH：把最后一个应用也隐藏起来

Matt Senter — Thu, 22 Oct 2026 14:15:54 +0000

我习惯用 Cmd+H 清空屏幕。但在 macOS 上，最后一个可见应用就是不肯隐藏。只剩一个窗口，再按一次……毫无反应。

所以我做了 CommandH。这款小巧的菜单栏应用让 Cmd+H 对最后一个应用也有效。你可以彻底隐藏应用，也可以选择 Show Desktop，将窗口滑到屏幕边缘，再按 Cmd+H 就能恢复。

它免费开源，采用 MIT 许可证。不需要辅助功能或屏幕录制权限，不发出网络请求，也不收集数据。只是一个让我顺利回到桌面的小修复。

CommandH 支持 macOS 14 Sonoma 及更新版本。目前需要从源码构建安装；GitHub README 提供了脚本使用说明。

了解 CommandH · 获取源码和安装说明

Presento CommandH: oculta esa última app

Matt Senter — Thu, 22 Oct 2026 14:15:17 +0000

Uso Cmd+H para despejar la pantalla. Pero en macOS, la última app visible se niega a ocultarse. Queda una ventana, pulso una vez más y… nada.

Así que creé CommandH. Es una pequeña app de la barra de menús que hace que Cmd+H funcione también con esa última app. Puedes ocultarla por completo o elegir Show Desktop, que aparta las ventanas y las devuelve con otro Cmd+H.

Es gratuita y de código abierto, con licencia MIT. Sin permisos de Accesibilidad ni de Grabación de pantalla, sin conexiones de red y sin recopilar datos. Solo una pequeña solución para llegar al escritorio.

CommandH funciona en macOS 14 Sonoma o posterior. Por ahora se instala compilando el código fuente; el README de GitHub explica cómo ejecutar el script.

Conoce CommandH · Código e instrucciones de instalación

Introducing CommandH: Hide That Last App

Matt Senter — Wed, 21 Oct 2026 19:12:45 +0000

I use Cmd+H to clear my screen. But on macOS, the last visible app refuses to hide. One window left, one more keystroke, and… nothing.

So I built CommandH. It’s a tiny menu bar app that makes Cmd+H work on that last app, too. You can hide the app completely or choose Show Desktop, which slides the windows aside and brings them back with another Cmd+H.

It’s free and open source under the MIT license. No Accessibility or Screen Recording permissions, no network requests, no data collected. Just a small fix that lets me get to my desktop.

CommandH runs on macOS 14 Sonoma or later. For now, installation means building from source; the GitHub README walks you through the script.

Meet CommandH · Get the code and installation instructions

App Store 4.3: Hilft es Apps, zuerst da zu sein?

Matt Senter — Mon, 19 Oct 2026 14:18:53 +0000

Mein Freund und Mitentwickler Alan Seales hat vor Kurzem erlebt, dass seine App Dumpling nach Apples App Review Guideline 4.3 (Spam) abgelehnt wurde. Ich habe sie benutzt. Das Design ist durchdacht, die Umsetzung solide, und die App versteht die Menschen, für die sie gebaut wurde. Ich kann mir kaum vorstellen, dass das ein austauschbarer Klon sein soll.

Dumpling ist eine App für Sprachnotizen auf dem iPhone und der Apple Watch. Sie soll die Hürde zwischen dem Festhalten eines Gedankens und dem Ordnen verkleinern, auch für Menschen mit ADHS. Sie transkribiert Aufnahmen, vergibt Titel und legt Notizen ab, zieht Aufgaben und Fälligkeitsdaten heraus und stellt eine tägliche Zusammenfassung zusammen. Du kannst einen Gedanken festhalten, ohne vorher entscheiden zu müssen, wohin er gehört.

Ich weiß nicht, welche Apps Apple für Dumpling als zu ähnlich angesehen hat oder welche Ähnlichkeiten zur Ablehnung geführt haben. Deshalb lässt sich die Entscheidung schwer beurteilen und noch schwerer darauf reagieren. Auf einer groben Ebene ist fast jede App etwas, das es schon gibt: ein Sprachrekorder, ein Aufgabenmanager, eine Wetter-App. Die Unterschiede zeigen sich oft erst bei der Nutzung.

Diese Unklarheit wirft eine größere Frage auf: Wird es zu einem wertvolleren Wettbewerbsvorteil, zuerst im App Store zu sein, wenn Software immer leichter zu bauen ist? Eine Regel, die Spam fernhalten soll, könnte unbeabsichtigt einen Burggraben um die Produkte ziehen, die bereits zugelassen sind.

Was bedeutet Apples App Store Guideline 4.3?

Apples Spam-Richtlinie deckt zwei verwandte Probleme ab. Abschnitt 4.3(a) betrifft das Einreichen derselben App unter mehreren Bundle IDs, etwa eine eigene Karten-App für jede Stadt. Abschnitt 4.3(b) betrifft Apps, die sich von bestehenden Angeboten praktisch nicht unterscheiden. In etablierten Kategorien verlangt Apple eine „deutlich andere oder bessere Erfahrung“. Als Beispiele nennt Apple Dating-Apps, Wallpaper-Apps und einfache Timer.

Ich verstehe den Zweck. Wenn jemand das Produkt eines anderen nimmt, die Farben ändert und es unter anderem Namen einreicht, macht das den Prüfern Arbeit und füllt den Store mit Ballast. Hundert Varianten zu produzieren macht ein Produkt nicht nützlicher. Apple selbst warnt, dass nahezu identische Einreichungen Kapazität bei App Review binden.

Der Umfang ist beträchtlich. In seinem App-Store-Update vom Mai 2026 sagte Apple, dass es 2025 mehr als 9,1 Millionen Einreichungen geprüft und mehr als 371.000 davon abgelehnt habe, weil sie andere Apps kopierten, Spam waren oder Nutzer in die Irre führten. Diese zusammengefasste Kategorie zählt Einreichungen, nicht einzelne Apps, die speziell nach 4.3 abgelehnt wurden. Sie sagt uns auch nicht, wie oft legitime Apps fälschlich abgelehnt wurden.

KI macht die Sache komplizierter, weil man kein Template mehr kaufen muss, um ein bekanntes Produkt nachzubauen. Du kannst eine unabhängige Implementierung von im Kern derselben Erfahrung schreiben. Dass einem der Code gehört, macht das Ergebnis nicht automatisch deutlich anders.

Ich nutze KI, um Software zu bauen. Sie kann Entwicklern helfen, schwierige technische Probleme zu lösen und übersehene Kundengruppen zu bedienen. Sie kann es aber auch billiger machen, einen Marktplatz mit kaum unterscheidbaren Apps zu fluten. Die Werkzeuge ermöglichen beides; die Qualität des Ergebnisses zählt trotzdem.

Warum widersprechen Entwickler 4.3-Spam-Ablehnungen?

Einen Ähnlichkeitsbefund zu beantworten kann schwer sein, wenn der Entwickler nicht sieht, womit Apple vergleicht. Aktuelle öffentliche Berichte zeigen, wie schwierig es sein kann, nachzuweisen, was eine App unterscheidet, besonders wenn ihr Wert von einem spezialisierten Workflow abhängt.

Sebastian Röhl, Entwickler von FocusKit, berichtete von zwei Ablehnungen nach 4.3(a), bevor er seinen Fokus-Timer im November 2025 startete. Mehrere Tage Schriftwechsel, in denen er die Unterschiede erklärte, führten zur Freigabe. Das ist ein ermutigender Ausgang, aber der Nachweis, dass eine App eine Zulassung verdient, kostete zusätzliche Arbeit, bevor Kunden sie ausprobieren konnten.

Im September 2026 berichtete der Entwickler von YanPian von einer Ablehnung nach 4.3(a) für eine Kletter-Video-App. Zu ihren Funktionen gehörten das Zuordnen von Herzfrequenzdaten der Apple Watch zu Kletteraufnahmen, das Verfolgen eines Kletterers in einer Totalen und eine optionale Gimbal-Steuerung. Der Entwickler räumte ein, dass der Startbildschirm ohne Kletteraufnahmen zum Importieren wie eine gewöhnliche Kamera-App wirken könnte. Der öffentliche Thread dokumentiert einen Einspruch ohne veröffentlichtes Ergebnis.

Diese Berichte belegen nicht, dass Apple jede App abgelehnt hat, weil ihre Kategorie voll war. Wir kennen auch nicht Apples vollständige Prüfunterlagen. Sie zeigen aber, wie schwer es sein kann zu verstehen, was ein Entwickler eigentlich belegen soll.

YanPians Situation erinnert mich an Dumpling. Eine spezialisierte App kann dieselben Grundzutaten haben wie eine Allzweck-App und trotzdem andere Entscheidungen darüber treffen, wie sie zusammenspielen. Diese Entscheidungen zu erkennen, kann voraussetzen, einem bestimmten Workflow zu folgen oder das Problem zu verstehen, das die App löst. Das ist ein schwierigeres Urteil als die Frage, ob eine App abstürzt.

Verschaffen App-Store-Spam-Regeln Vorreitern einen Vorteil?

Ich glaube, das können sie. Eine App, die in eine relativ offene Kategorie eintritt, hat weniger etablierte Produkte, an denen sich ihre Eigenständigkeit messen lassen muss. Ein späterer Einsteiger muss unter Umständen erklären, warum sich sein Ansatz genug von einer wachsenden Zahl vorhandener Apps unterscheidet.

Der frühere Entwickler kann diese Zeit nutzen, um Kunden zu gewinnen, das Produkt zu verbessern und aus der Nutzung zu lernen. Der spätere Entwickler verbringt sie vielleicht damit zu erklären, warum sein Produkt diese Kunden überhaupt erreichen darf. Selbst wenn die Freigabe irgendwann kommt, kosten die Unsicherheit und die Verzögerung etwas.

Eine Freigabe ist kein dauerhafter Schutz. Apples Richtlinien lassen sinnvolle Abgrenzung oder Verbesserung zu und sehen vor, Apps zu entfernen, die nicht gepflegt, verbessert oder von Kunden genutzt werden. Auch bestehende Entwickler können auf Reibung bei der Prüfung stoßen.

Im September 2026 berichtete Josh Dance von einer Ablehnung eines Updates für Pushup Hero nach 4.3(a). Er sagte, die App sei seit 2018 im Store. Er reichte Fehlerbehebungen und einen Dark Mode ein, als Apple eine Ähnlichkeit mit einer App markierte, die mit einem gesperrten Account in Verbindung stand. Sein Bericht beschreibt einen Einspruch, ohne das endgültige Ergebnis zu nennen.

Mich beschäftigt die zusätzliche Last, wenn man erst ankommt, nachdem eine Kategorie voll geworden ist. Diese Last könnte beeinflussen, was Entwickler bauen und wie schnell sie es einreichen.

Das schafft einen unangenehmen Anreiz: sich zu beeilen. Zeit, die man in die Verfeinerung eines Produkts steckt, ist Zeit, in der jemand anderes den Vergleichsmaßstab setzen könnte. Ein Verfahren, das die Qualität verbessern soll, könnte so ungewollt den Druck erhöhen, einzureichen, bevor die Arbeit fertig ist.

Macht KI App Review langsamer oder strenger?

Apple hat das Wachstum bei den Einreichungen eingeräumt. Das Statement vom Mai 2026 sagt, KI-Entwicklungswerkzeuge sorgten für einen Anstieg der Einreichungen, hält aber fest, App Review sei „nahtlos skaliert“, um damit umzugehen. Apple sagt außerdem, es nutze KI, um die Ähnlichkeit von Apps zu analysieren und möglicherweise problematische Änderungen für menschliche Prüfer zu markieren. Das belegt nicht, dass Automatisierung bei einer bestimmten Ablehnung die endgültige Entscheidung getroffen hat.

In einem Bericht von Business Insider vom März 2026 räumte Apple einige längere Prüfzeiten ein. Es habe in den vorangegangenen 12 Wochen mehr als 200.000 Einreichungen pro Woche bearbeitet, mit einer durchschnittlichen Prüfdauer von 1,5 Tagen. Laut den Hinweisen für Entwickler werden 90 % der Einreichungen in der Regel in weniger als 48 Stunden geprüft.

Eine Prüfentscheidung und eine erfolgreiche Veröffentlichung sind zwei verschiedene Meilensteine. Ein Entwickler kann schnell eine Ablehnung bekommen und trotzdem Wochen mit Schriftwechsel, erneuten Einreichungen und Einsprüchen verbringen. Schnelle Prüfstatistiken und ein frustrierender Prozess für Entwickler, deren Apps eine umstrittene Einstufung auslösen, schließen sich nicht aus.

Apple hat auch öffentlich auf einzelne Beschwerden reagiert. In einem Thread zu ByGate vom Mai 2026, dem eigenen Client für einen VPN-Dienst, sagte ein Account, der als App-Review-Mitarbeiter von Apple ausgewiesen war, dass Ähnlichkeiten bei Binaries, Metadaten und Gesamtkonzepten zu einem Spam-Befund beitragen können. Er empfahl einen Termin bei App Review, ohne einen konkreten Vergleichsfall zu nennen oder zu erklären, welche Merkmale nicht ausreichend unterscheidbar waren.

Wie können Entwickler auf eine 4.3-Ablehnung reagieren?

Apple bietet Schriftwechsel mit App Review, Termine und Einsprüche beim App Review Board. Diese Wege funktionieren besser, wenn der Entwickler das Anliegen versteht.

Ähnlicher Code, ähnliche Screenshots, ähnliche Funktionen und ein vermuteter Zusammenhang mit einem anderen Entwickler sind verschiedene Probleme. Ohne zu wissen, welches zutrifft, kann ein Entwickler nicht sinnvoll reagieren. Eine hilfreiche Ablehnung würde den betreffenden Bildschirm oder Workflow benennen, erklären, welche behaupteten Unterschiede berücksichtigt wurden, oder klären, ob es um Urheberschaft, wiederholte Einreichungen oder die Kundenerfahrung geht.

Nichts davon erfordert, private Kontoinformationen eines anderen Entwicklers offenzulegen.

Auch Entwickler tragen hier Verantwortung. Monate an Arbeit beweisen nicht, dass eine App etwas bietet, das Kunden nicht schon anderswo bekommen. Wir müssen ihren Wert für jemanden sichtbar machen, der ihr zum ersten Mal begegnet. Wenn dafür Kletteraufnahmen, repräsentative Daten oder eine bestimmte Abfolge von Aktionen nötig sind, sollte man eine funktionierende Demo und klare Prüfhinweise mitliefern.

Ich habe Verständnis für Prüfer, die einen Klon von einer vertrauten, gut umgesetzten Idee unterscheiden müssen. Ein besserer Austausch von Belegen würde beiden Seiten helfen, Missverständnisse zu klären, bevor ein Entwickler anfängt, eine App auf Basis von Vermutungen umzubauen.

Können Entwickler Apps außerhalb des App Store vertreiben?

Für Mac-Entwickler ist der Direktvertrieb eine etablierte Option. Manche Apps brauchen Berechtigungen oder die Interaktion mit anderen Anwendungen, die nicht in die Sandbox des Mac App Store passen. Apples Sandbox-Dokumentation nennt bestimmte Nutzungen der Accessibility-APIs und die Interaktion mit anderen Apps als unvereinbar mit diesen Einschränkungen.

Zwei Mac-Apps vertreibe ich schon auf diesem Weg: Burly, mein Router für Links zu Browser-Profilen, und Comoji, meine App für Emoji-Kürzel. Burly leitet Links an bestimmte Browser-Profile weiter und nutzt den Accessibility-Zugriff, um die Profilmenüs von Safari zu steuern. Comoji bringt Emoji-Kürzel in Textfelder auf dem ganzen Mac, erkennt die Kürzel per Input Monitoring und fügt das Ergebnis per Accessibility-Zugriff ein. Diese Fähigkeiten sind für die Produkte zentral.

Developer-ID-Signierung und Notarisierung erlauben es Entwicklern, Mac-Software direkt zu vertreiben und dabei Apples Prüfungen auf Schadsoftware und Signaturprobleme beizubehalten. Für Apps, die außerhalb der Einschränkungen des Stores arbeiten müssen, ist das ein etablierter Weg, Kunden zu erreichen.

Ich erwarte, dass die Unsicherheit rund um Spam-Ablehnungen mehr Entwicklern einen Grund gibt, in diese Unabhängigkeit zu investieren. Eine Website, ein Checkout, eine Mailingliste und eine direkte Kundenbeziehung geben mehr Kontrolle. Sie bieten auch Raum, ein spezialisiertes Produkt jenseits einer Store-Seite zu erklären.

Aber eine Website ersetzt nicht die Reichweite des App Store. Kunden müssen sie erst finden, dem Entwickler vertrauen und einen anderen Kauf- und Installationsprozess durchlaufen. Auch Entwickler, die unabhängig vertreiben, wollen vielleicht einen Store-Eintrag. Diese Gelegenheit zu verlieren hat ihren Preis.

Für iPhone und iPad sieht die Antwort restriktiver aus. Apple unterstützt derzeit alternative Marktplätze und den autorisierten Vertrieb über Websites in der Europäischen Union, wobei iPhone-Marktplätze auch in Japan und Brasilien verfügbar sind. Diese Optionen haben regionale Voraussetzungen und unterliegen weiterhin der Notarisierung. Ein Entwickler, der normale iPhone-Kunden in den USA erreichen will, kann einen abgelehnten Eintrag nicht einfach durch einen Download-Button auf einer Website ersetzen.

Eine Web-Version kann für manche Produkte funktionieren, kann aber erhebliche Produktänderungen erfordern. Unabhängiger Vertrieb ist für einen Mac-Entwickler eine deutlich vollständigere Antwort als für einen iPhone-Entwickler.

Schrecken strengere App-Store-Prüfungen Wegwerf-Klone ab?

Ich hoffe, dass manche der Leute, die Klone am Fließband produzieren, zu dem Schluss kommen, dass unabhängiger Verkauf mehr Mühe ist, als er wert ist. Wenn die Strategie lautet, hundert Varianten einzureichen und zu schauen, was Geld bringt, könnte eine Ablehnung für manche Projekte das Ende sein.

Eine App zu generieren ist nur ein Teil davon, ein Softwaregeschäft zu führen. Selbst wenn du die Website genauso schnell generieren kannst, musst du trotzdem Kunden gewinnen, Vertrauen aufbauen, Zahlungen und Updates abwickeln und den Leuten einen Grund geben, dich zu wählen. Wer darauf hofft, sich an eine bestehende App dranzuhängen, hat daran womöglich wenig Interesse.

Wer braucht noch einen Pomodoro-Timer mit anderem Icon? Eine vertraute Kategorie kann von einer besseren Erfahrung profitieren oder von einem Ansatz, der für ein übersehenes Publikum gebaut ist. Dasselbe Produkt mit anderem Branding nachzubauen, trägt kaum etwas bei.

Ich hoffe, dass unabhängiger Vertrieb manches dieser Verhalten bremst. Ich hoffe auch, dass Apple besser darin wird, es von einem Entwickler zu unterscheiden, der etwas Nutzbares gebaut hat. Einen Wegwerf-Klon zu stoppen kann dem Marktplatz nützen; eine undurchsichtige Ablehnung eines durchdachten Produkts kann Kunden eine nützliche Wahl nehmen.

Ich möchte, dass Dumpling nach der Erfahrung beurteilt wird, die es den Menschen bietet, für die Alan es gebaut hat. Wenn Apple glaubt, diese Erfahrung sei nicht ausreichend anders, sollte es erklären, warum. Der erste Entwickler in einer Kategorie verdient einen Vorsprung bei den Kunden. Der nächste sollte trotzdem eine faire Chance bekommen, ihnen etwas Besseres anzubieten.

Rejeições 4.3 na App Store: ser o primeiro dá vantagem?

Matt Senter — Mon, 19 Oct 2026 14:18:17 +0000

Meu amigo e colega desenvolvedor independente Alan Seales teve recentemente o app Dumpling rejeitado pela Diretriz 4.3 da App Review da Apple: Spam. Eu já usei o app. O design é cuidadoso, a implementação é sólida e ele entende as pessoas para quem foi feito. Tenho dificuldade em enxergar um clone descartável.

O Dumpling é um app de anotações por voz para iPhone e Apple Watch, criado para reduzir o atrito entre capturar um pensamento e organizá-lo, inclusive para pessoas com TDAH. Ele transcreve as gravações, dá título e arquiva as notas, extrai tarefas e prazos e monta um resumo diário. Você pode registrar um pensamento sem decidir antes onde ele se encaixa.

Não sei com quais apps a Apple considerou o Dumpling parecido demais, nem quais semelhanças motivaram a rejeição. Isso torna a decisão difícil de avaliar e ainda mais difícil de contestar. Num nível amplo o bastante, quase todo app é algo que já existe: um gravador de voz, um gerenciador de tarefas, um app de clima. As diferenças muitas vezes aparecem quando você usa.

Essa incerteza levanta uma pergunta maior: à medida que ficou mais fácil criar software, entrar primeiro na App Store passa a ser uma vantagem competitiva mais valiosa? Uma regra feita para barrar spam pode criar, sem querer, uma barreira de proteção em torno dos produtos que já foram admitidos.

O que significa a Diretriz 4.3 da App Store da Apple?

A diretriz de spam da Apple cobre dois problemas relacionados. A seção 4.3(a) trata do envio do mesmo app com vários Bundle IDs, como criar um app de mapas separado para cada cidade. A seção 4.3(b) trata de apps que são, na prática, indistinguíveis de ofertas já existentes. Em categorias consolidadas, a Apple exige uma “experiência significativamente diferente ou melhor”. Entre os exemplos estão apps de relacionamento, apps de papel de parede e timers simples.

Entendo o propósito. Pegar o produto de outra pessoa, trocar as cores e enviá-lo com outro nome cria trabalho para os revisores e bagunça para os clientes. Produzir cem variações não o torna mais útil. A própria Apple alerta que envios essencialmente idênticos consomem a capacidade da App Review.

A escala é grande. Na atualização da App Store de maio de 2026, a Apple disse que revisou mais de 9,1 milhões de envios em 2025 e rejeitou mais de 371 mil por copiar outros apps, ser spam ou enganar os usuários. Essa categoria combinada conta envios, não apps únicos rejeitados especificamente pela 4.3. Ela também não nos diz com que frequência apps legítimos foram rejeitados por engano.

A IA complica as coisas, porque já não é preciso comprar um template para reproduzir um produto conhecido. Dá para escrever uma implementação independente de essencialmente a mesma experiência. Ser dono do código não torna o resultado automaticamente significativamente diferente.

Eu uso IA para criar software. Ela pode ajudar desenvolvedores a resolver problemas técnicos difíceis e a atender clientes negligenciados. Também pode baratear a inundação do mercado com apps pouco diferenciados. As ferramentas tornam as duas coisas possíveis; a qualidade do resultado continua importando.

Por que desenvolvedores contestam rejeições por spam da 4.3?

Um parecer de similaridade pode ser difícil de contestar quando o desenvolvedor não consegue ver com o que a Apple está comparando. Relatos públicos recentes mostram como pode ser difícil demonstrar o que torna um app diferente, principalmente quando o valor dele depende de um fluxo de trabalho especializado.

O desenvolvedor do FocusKit, Sebastian Röhl, relatou duas rejeições pela 4.3(a) antes de lançar seu timer de foco em novembro de 2025. Vários dias de troca de mensagens explicando as diferenças levaram à aprovação. É um desfecho animador, mas demonstrar que um app merece ser admitido exigiu trabalho adicional antes que os clientes pudessem experimentá-lo.

Em setembro de 2026, o desenvolvedor do YanPian relatou uma rejeição pela 4.3(a) de um app de vídeo para escalada. Entre os recursos estavam combinar os dados de frequência cardíaca do Apple Watch com as imagens da escalada, acompanhar o escalador dentro de um plano aberto e controle opcional de gimbal. O desenvolvedor reconheceu que, sem imagens de escalada para importar, a tela inicial poderia parecer um app de câmera genérico. A discussão pública registra um recurso sem resolução publicada.

Esses relatos não estabelecem que a Apple rejeitou cada app porque a categoria estava cheia. Também não temos os registros completos de revisão da Apple. O que eles mostram é como pode ser difícil entender o que se pede que o desenvolvedor prove.

A situação do YanPian me faz pensar no Dumpling. Um app especializado pode compartilhar seus ingredientes básicos com um app de uso geral e, ainda assim, tomar decisões diferentes sobre como eles trabalham juntos. Reconhecer essas decisões pode exigir seguir um fluxo de trabalho específico ou entender o problema que ele resolve. É um julgamento mais difícil do que verificar se um app trava.

As regras de spam da App Store dão vantagem a quem chega primeiro?

Acho que podem dar. Um app que entra numa categoria relativamente aberta tem menos produtos estabelecidos contra os quais sua distinção possa ser julgada. Quem chega depois pode ter de explicar por que sua abordagem é diferente o suficiente de uma coleção crescente de apps disponíveis.

O desenvolvedor que chegou antes pode usar esse tempo para atrair clientes, melhorar o produto e aprender com o uso. O que chegou depois pode gastá-lo explicando por que o produto deveria poder chegar a esses clientes. Mesmo que a aprovação venha no fim, a incerteza e o atraso têm um custo.

A aprovação não é uma proteção permanente. As diretrizes da Apple admitem diferenciação ou melhoria significativa e preveem a remoção de apps que não são mantidos, melhorados ou não atraem clientes. Desenvolvedores já estabelecidos também podem enfrentar atrito na revisão.

Em setembro de 2026, Josh Dance relatou uma rejeição pela 4.3(a) de uma atualização do Pushup Hero. Ele disse que o app estava na loja desde 2018. Estava enviando correções de bugs e o modo escuro quando a Apple apontou semelhança com um app associado a uma conta encerrada. O relato dele descreve um recurso sem informar o desfecho final.

Minha preocupação é com o peso adicional de chegar depois que uma categoria fica lotada. Esse peso pode influenciar tanto o que os desenvolvedores criam quanto a rapidez com que enviam.

Isso cria um incentivo desconfortável: correr. O tempo gasto refinando um produto vira tempo em que outra pessoa pode estabelecer o ponto de comparação. Um processo desenhado para melhorar a qualidade pode, sem querer, aumentar a pressão para enviar antes de o trabalho estar pronto.

A IA está deixando a App Review mais lenta ou mais rígida?

A Apple reconheceu o crescimento dos envios. Sua declaração de maio de 2026 diz que ferramentas de desenvolvimento com IA estão provocando um aumento nos envios, ao mesmo tempo em que sustenta que a App Review “escalou sem atritos” para lidar com isso. A Apple também diz que usa IA para analisar a similaridade entre apps e sinalizar mudanças potencialmente problemáticas para revisores humanos. Isso não estabelece que a automação tomou a decisão final em qualquer rejeição específica.

Numa reportagem da Business Insider de março de 2026, a Apple reconheceu algumas revisões mais longas. Disse ter processado mais de 200 mil envios por semana nas 12 semanas anteriores, com tempo médio de revisão de 1,5 dia. Seu guia para desenvolvedores diz que 90% dos envios costumam ser revisados em menos de 48 horas.

Uma decisão de revisão e um lançamento bem-sucedido são marcos diferentes. Um desenvolvedor pode receber uma rejeição rápida e ainda assim passar semanas com troca de mensagens, reenvios e recursos. Estatísticas de revisão rápida podem coexistir com um processo frustrante para desenvolvedores cujos apps caem numa classificação contestada.

A Apple também respondeu publicamente a reclamações individuais. Numa discussão de maio de 2026 sobre o ByGate, o cliente dedicado de um serviço de VPN, uma conta identificada como da equipe da App Review da Apple disse que semelhanças em binários, metadados e conceitos gerais podem contribuir para um parecer de spam. Recomendou agendar uma consulta com a App Review, sem identificar um app específico de comparação nem explicar quais características não eram distintas o bastante.

Como os desenvolvedores podem reagir a uma rejeição pela 4.3?

A Apple oferece troca de mensagens com a App Review, consultas e recursos ao App Review Board. Esses mecanismos funcionam melhor quando o desenvolvedor entende qual é a preocupação.

Código parecido, capturas de tela parecidas, funcionalidade parecida e uma suspeita de ligação com outro desenvolvedor são problemas diferentes. Um desenvolvedor não consegue responder com inteligência sem saber qual deles se aplica. Uma rejeição útil identificaria a tela ou o fluxo de trabalho em questão, explicaria quais diferenças alegadas foram consideradas ou esclareceria se a preocupação envolve autoria, envios repetidos ou a experiência do cliente.

Nada disso exige revelar informações privadas da conta de outro desenvolvedor.

Os desenvolvedores também têm responsabilidades aqui. Meses de trabalho não provam que um app oferece algo que os clientes ainda não conseguem obter. Precisamos tornar o valor dele visível para quem o encontra pela primeira vez. Se isso exigir imagens de escalada, dados representativos ou uma sequência específica de ações, forneça uma demonstração funcional e instruções de revisão claras.

Tenho simpatia pelos revisores que tentam distinguir um clone de uma ideia conhecida bem executada. Uma troca de evidências melhor ajudaria os dois lados a resolver mal-entendidos antes que um desenvolvedor comece a redesenhar um app com base em palpites.

Dá para distribuir apps fora da App Store?

Para desenvolvedores de Mac, a distribuição direta é uma opção consolidada. Alguns apps precisam de permissões ou de interação com outros aplicativos que não cabem no sandbox da Mac App Store. A documentação de sandbox da Apple identifica certos usos das APIs de Acessibilidade e a interação com outros apps como incompatíveis com essas restrições.

Eu já distribuo dois apps de Mac assim: o Burly, meu roteador de links para perfis de navegador, e o Comoji, meu app de atalhos de emoji. O Burly encaminha links para perfis específicos do navegador e usa o acesso de Acessibilidade para controlar os menus de perfil do Safari. O Comoji leva atalhos de emoji para campos de texto em todo o Mac, usando o Monitoramento de Entrada para reconhecer os atalhos e o acesso de Acessibilidade para inserir o resultado. Essas capacidades são centrais para os produtos.

A assinatura Developer ID e a notarização permitem que desenvolvedores distribuam software para Mac diretamente, mantendo as verificações da Apple contra software malicioso e problemas de assinatura. Para apps que precisam operar fora das restrições da loja, essa é uma forma consolidada de atender os clientes.

Espero que a incerteza em torno das rejeições por spam dê a mais desenvolvedores um motivo para investir nessa independência. Um site, um checkout, uma lista de e-mails e um relacionamento direto com o cliente dão mais controle. Também dão espaço para explicar um produto especializado além da página na loja.

Mas um site não recria o alcance da App Store. Os clientes ainda precisam descobri-lo, confiar no desenvolvedor e passar por um processo diferente de compra e instalação. Mesmo quem distribui por conta própria pode querer uma página na loja. Perder essa oportunidade tem um custo.

A resposta é mais restritiva para iPhone e iPad. Hoje a Apple oferece suporte a lojas alternativas e à distribuição autorizada por site na União Europeia, com lojas para iPhone também disponíveis no Japão e no Brasil. Essas opções têm requisitos regionais e continuam sujeitas à notarização. Um desenvolvedor que atende clientes comuns de iPhone nos Estados Unidos não pode simplesmente trocar uma página rejeitada por um botão de download num site.

Uma versão web pode funcionar para alguns produtos, mas pode exigir mudanças substanciais no produto. A distribuição independente é uma resposta bem mais completa para um desenvolvedor de Mac do que para um de iPhone.

Revisões mais rígidas da App Store vão desestimular clones descartáveis?

Espero que parte das pessoas que fabricam clones conclua que vender de forma independente dá mais trabalho do que vale. Se a estratégia é enviar cem variações e ver o que rende dinheiro, uma rejeição pode ser o ponto final de alguns projetos.

Gerar um app é só uma parte de tocar um negócio de software. Mesmo que você consiga gerar o site com a mesma rapidez, ainda precisa atrair clientes, conquistar confiança, cuidar de pagamentos e atualizações e dar às pessoas um motivo para escolher você. Quem espera pegar carona num app existente pode ter pouco interesse nesse trabalho.

Quem precisa de mais um timer Pomodoro com outro ícone? Uma categoria conhecida pode se beneficiar de uma experiência melhor ou de uma abordagem feita para um público negligenciado. Reproduzir o mesmo produto com outra marca contribui muito pouco.

Espero que a distribuição independente desestimule parte desse comportamento. Também espero que a Apple melhore em distingui-lo de um desenvolvedor que criou algo que vale a pena usar. Barrar um clone descartável pode beneficiar o mercado; uma rejeição opaca de um produto cuidadoso pode privar os clientes de uma escolha útil.

Quero que o Dumpling seja julgado pela experiência que oferece às pessoas para quem o Alan o criou. Se a Apple acredita que essa experiência não é diferente o bastante, deveria explicar por quê. O primeiro desenvolvedor a entrar numa categoria merece sair na frente com os clientes. O próximo ainda deveria ter uma chance justa de oferecer algo melhor a eles.

App Store 4.3 のリジェクトと先行者の優位性

Matt Senter — Mon, 19 Oct 2026 14:17:41 +0000

インディー開発者仲間で友人のAlan SealesさんのアプリDumplingが、Apple の App Review Guideline 4.3: Spam を理由にリジェクトされました。私は実際に使ったことがあります。デザインは丁寧で、実装もしっかりしていて、対象のユーザーのことをよく理解しています。使い捨てのクローンとはとても思えません。

Dumpling は iPhone と Apple Watch 向けの音声メモアプリで、ADHD のある人を含め、思いついたことを記録してから整理するまでの手間を減らすために作られています。録音を文字起こしし、メモにタイトルを付けて整理し、タスクと期限を抽出して、1日のまとめを作成します。どこに置くかを先に決めなくても、思いつきを記録できます。

Apple が Dumpling をどのアプリと似すぎていると判断したのか、どんな類似点がリジェクトの理由になったのかは、私にはわかりません。そのため、判断を評価するのも、対処するのもさらに難しくなります。十分に大きな視点で見れば、ほとんどどのアプリも既存のものです。ボイスレコーダー、タスク管理、天気アプリのように。違いは、実際に使ってみて初めて見えてくることが多いのです。

この不透明さは、より大きな問いにつながります。ソフトウェアが作りやすくなるほど、App Store に先に入ることは競争上の価値を増すのでしょうか。スパムを排除するためのルールが、すでに承認されたプロダクトを守る思わぬ堀になる可能性があります。

Apple の App Store Guideline 4.3 とは何か

Apple のスパムに関するガイドラインは、関連する2つの問題を扱っています。4.3(a) は、同じアプリを複数の Bundle ID で提出すること(たとえば都市ごとに別々の地図アプリを作ること)を対象にしています。4.3(b) は、既存のものと実質的に区別がつかないアプリを対象にしています。確立されたカテゴリでは、Apple は「意味のある違いや改善のある体験」を求めています。例として挙げられているのは、デートアプリ、壁紙アプリ、シンプルなタイマーなどです。

目的は理解できます。他人のプロダクトの色を変えて別の名前で提出すれば、審査する側の作業は増え、ユーザーの目に入るものも散らかります。100通りのバリエーションを作っても、便利になるわけではありません。Apple 自身も、ほぼ同一の提出が App Review の処理能力を消費すると警告しています。

その規模は相当なものです。Apple は2026年5月の App Store に関する発表で、2025年に910万件を超える提出を審査し、他のアプリの模倣、スパム、ユーザーを欺く行為を理由に37万1,000件以上をリジェクトしたと述べました。この合算されたカテゴリは提出件数を数えたもので、4.3 を理由にリジェクトされた固有のアプリ数ではありません。正当なアプリが誤ってリジェクトされた頻度についても、この数字からはわかりません。

AI によって、話はさらに複雑になります。見慣れたプロダクトを再現するためにテンプレートを買う必要はもうありません。ほぼ同じ体験を、独自の実装で書くことができます。コードを自分で所有しているからといって、結果が自動的に意味のある違いを持つわけではありません。

私は AI を使ってソフトウェアを作っています。AI は、開発者が難しい技術的課題を解決したり、見過ごされてきたユーザーに応えたりするのに役立ちます。一方で、ほとんど差別化されていないアプリで市場をあふれさせることも安くできてしまいます。ツールはどちらも可能にしますが、結果の質は依然として大切です。

開発者はなぜ 4.3 スパムのリジェクトに異議を唱えているのか

Apple が何と比較しているのか開発者に見えない場合、類似しているという判断には答えにくくなります。最近公開された事例は、特に専門的なワークフローに価値があるアプリの場合、何が違うのかを示すことがいかに難しいかを物語っています。

FocusKit の開発者 Sebastian Röhl さんは、フォーカスタイマーを2025年11月にリリースする前に、4.3(a) のリジェクトを2回受けたと報告しています。数日にわたるやり取りで違いを説明し、承認に至りました。心強い結果ですが、アプリが承認に値することを示すために、ユーザーが試せるようになる前に追加の作業が必要でした。

2026年9月には、YanPian の開発者が、クライミング動画アプリについて4.3(a) のリジェクトを報告しました。機能には、Apple Watch の心拍データとクライミングの映像の照合、広角の映像内でクライマーを追従する機能、オプションのジンバル制御がありました。開発者は、取り込むクライミング映像がなければ、最初の画面が一般的なカメラアプリのように見えうることを認めています。公開されているスレッドには、異議申し立てが記録されていますが、解決したという投稿はありません。

これらの事例から、Apple がカテゴリがいっぱいだったという理由であらゆるアプリをリジェクトしたとは言えません。Apple の審査記録の全体も私たちにはわかりません。ただ、開発者が何を証明するよう求められているのかを理解するのがどれほど難しいかは、よく示しています。

YanPian の状況を見ると、私は Dumpling を思い出します。専門的なアプリは、汎用的なアプリと基本的な要素を共有しながら、それらをどう組み合わせて動かすかについて別の判断をしていることがあります。その判断に気づくには、特定のワークフローをたどったり、そのアプリが解決する問題を理解したりする必要があるかもしれません。それは、アプリがクラッシュしないかを確認するよりずっと難しい判断です。

App Store のスパム規則は先行者に有利に働くのか

働きうると私は考えています。比較的開かれたカテゴリに入るアプリには、独自性を判断するための既存プロダクトがまだ少ししかありません。後から入るアプリは、増え続ける既存アプリの集まりに対して、自分のアプローチがなぜ十分に違うのかを説明しなければならないかもしれません。

先に入った開発者は、その時間をユーザーの獲得、プロダクトの改善、利用から学ぶことに使えます。後から入る開発者は、そのプロダクトがユーザーに届くことを認めてもらうための説明に時間を使うかもしれません。最終的に承認されたとしても、不確実さと遅れにはコストがあります。

承認は永続的な保護ではありません。Apple のガイドラインは意味のある差別化や改善を認めており、メンテナンスされていない、改善されていない、ユーザーを集めていないアプリの削除も想定しています。すでにあるアプリの開発者も、審査での摩擦に遭うことがあります。

2026年9月、Josh Dance さんはPushup Hero のアップデートが 4.3(a) でリジェクトされたと報告しました。アプリは2018年から App Store にあり、バグ修正とダークモードを提出したところ、Apple が、停止されたアカウントに関連するアプリとの類似を指摘したとのことです。彼の記事には異議申し立てのことが書かれていますが、最終的な結果は報告されていません。

私が懸念しているのは、カテゴリが混み合ってから参入する際の追加の負担です。その負担は、開発者が何を作るか、そしてどれだけ早く提出するかに影響しうるものです。

そこには、急ぐという居心地の悪いインセンティブが生まれます。プロダクトを磨くのに使った時間は、他の誰かが比較の基準を先に作れる時間になります。品質を高めるための仕組みが、準備ができる前に提出しようという圧力をかえって高めてしまうかもしれません。

AI は App Review を遅くしているのか、厳しくしているのか

Apple は提出数の増加を認めています。2026年5月の発表では、AI 開発ツールが提出の急増を招いていると述べつつ、App Review はそれに対応して「シームレスに拡大してきた」としています。また、Apple はアプリの類似性の分析や、問題になりうる変更を人間の審査担当者に知らせるために AI を使っているとも述べています。ただし、個々のリジェクトの最終判断を自動化が下したとは、これだけでは言えません。

2026年3月のBusiness Insider の記事で、Apple は審査が長引くケースがあることを認めました。直近12週間は週に20万件を超える提出を処理し、平均の審査時間は1.5日だったと説明しています。Apple の開発者向けガイダンスには、提出の90%は通常48時間以内に審査されると書かれています。

審査の判定が出ることと、リリースが成功することは別の到達点です。すぐにリジェクトの連絡が来ても、そのあと数週間をやり取りや再提出、異議申し立てに費やすことがあります。審査が速いという統計と、判断が争われる分類に当たった開発者のもどかしい経験は、両立しえます。

Apple は個別の苦情にも公に応じています。2026年5月の、VPN サービス専用クライアントであるByGate のスレッドでは、App Review のスタッフと名乗るアカウントが、バイナリ、メタデータ、全体のコンセプトの類似がスパム判定の一因になりうると述べました。App Review のアポイントメントを勧めていますが、比較対象を特定することも、どの特徴が十分に区別されていなかったのかを説明することもしていません。

4.3 のリジェクトに開発者はどう対応できるか

Apple はApp Review とのやり取り、アポイントメント、App Review Board への異議申し立てを用意しています。これらの手段は、開発者が懸念点を理解しているほど効果的に働きます。

コードが似ている、スクリーンショットが似ている、機能が似ている、他の開発者との関連が疑われる、というのはそれぞれ別の問題です。どれに当たるのかがわからなければ、開発者は適切に答えられません。役に立つリジェクトとは、問題となる画面やワークフローを示すか、どの主張された違いを検討したのかを説明するか、懸念が作者性、繰り返しの提出、ユーザー体験のどれに関わるのかを明らかにするものです。

そのどれも、他の開発者の非公開のアカウント情報を明かす必要はありません。

開発者にも責任があります。何か月もかけて作ったからといって、ユーザーがまだ手に入れられないものを提供していることの証明にはなりません。初めてそのアプリに出会う人に、価値が見えるようにする必要があります。そのためにクライミングの映像や代表的なデータ、特定の操作手順が必要なら、動作するデモと明確な審査用の説明を用意するべきです。

クローンと、見慣れたアイデアをうまく形にしたものとを見分けようとする審査担当者には、同情します。証拠をもう少しよくやり取りできれば、開発者が推測でアプリを作り直し始める前に、双方が誤解を解く助けになるでしょう。

App Store の外でアプリを配布できるか

Mac の開発者にとって、直接配布は確立された選択肢です。アプリによっては、Mac App Store のサンドボックスに収まらない権限や、他のアプリとのやり取りが必要になります。Apple のサンドボックスに関するドキュメントは、アクセシビリティ API の一部の用途や他のアプリとのやり取りは、その制限と両立しないと説明しています。

私はすでに2つの Mac アプリをこの方法で配布しています。ブラウザのプロファイル用リンクルーターの Burlyと、絵文字ショートカットアプリの Comojiです。Burly はリンクを特定のブラウザプロファイルに振り分け、Safari のプロファイルメニューを操作するためにアクセシビリティのアクセスを使います。Comoji は Mac 上のあらゆるテキストフィールドで絵文字ショートカットを使えるようにするアプリで、ショートカットの認識に入力監視を、結果の挿入にアクセシビリティのアクセスを使います。これらの機能はプロダクトの中核です。

Developer ID による署名と公証を使えば、悪意のあるソフトウェアや署名の問題に対する Apple のチェックを受けたまま、Mac ソフトウェアを直接配布できます。ストアの制限の外で動く必要があるアプリにとって、これはユーザーに届けるための確立された方法です。

スパムを理由にしたリジェクトをめぐる不確実さは、より多くの開発者にこうした独立性への投資をする理由を与えると、私は予想しています。ウェブサイト、決済、メーリングリスト、ユーザーとの直接の関係があれば、コントロールできる範囲が広がります。ストアの掲載ページを超えて、専門的なプロダクトを説明する余地も得られます。

ただし、ウェブサイトは App Store のリーチを再現してはくれません。ユーザーには、見つけてもらい、開発者を信頼してもらい、異なる購入とインストールの手順を完了してもらう必要があります。独立して配布する開発者でも、ストアへの掲載を望むことがあるでしょう。その機会を失うことにはコストがあります。

iPhone と iPad では、状況はもっと厳しくなります。Apple は現在、欧州連合で代替マーケットプレイスと承認されたウェブサイト配布に対応しており、iPhone のマーケットプレイスは日本とブラジルでも利用できます。これらの選択肢には地域ごとの要件があり、公証の対象であることに変わりはありません。米国で一般的な iPhone ユーザー向けに提供している開発者は、リジェクトされた掲載の代わりに、ウェブサイトのダウンロードボタンを置くことはできません。

ウェブ版が機能するプロダクトもありますが、プロダクトの大きな変更が必要になることもあります。独立した配布は、iPhone の開発者より Mac の開発者にとって、はるかに完全な答えになります。

App Store の審査が厳しくなれば使い捨てのクローンは減るのか

クローンを量産している人の一部が、独立して売るのは割に合わないと考えるようになることを願っています。100通りのバリエーションを提出して何が稼げるかを見る戦略なら、リジェクトがそのプロジェクトの終わりになることもあるでしょう。

アプリを生成することは、ソフトウェアビジネスを運営することの一部にすぎません。ウェブサイトを同じ速さで生成できたとしても、ユーザーを集め、信頼を得て、決済やアップデートに対応し、自分を選ぶ理由を人々に与える必要があります。既存のアプリの人気に便乗したい人は、その作業にほとんど関心がないかもしれません。

アイコンだけ違うもう1つのポモドーロタイマーを、誰が必要とするでしょうか。見慣れたカテゴリでも、より良い体験や、見過ごされてきた層に向けたアプローチがあれば、価値を生みます。ブランドだけ変えて同じプロダクトを再現しても、得られるものはごくわずかです。

独立した配布が、そうした行為の一部を思いとどまらせることを願っています。同時に、Apple がそれを、使う価値のあるものを作った開発者と、もっとうまく区別できるようになることも願っています。使い捨てのクローンを止めることは市場の利益になりえますが、よく考えて作られたプロダクトを理由もわからずリジェクトすれば、ユーザーから有益な選択肢を奪うことになりかねません。

私は、Dumpling が、Alan さんが想定したユーザーに提供する体験で評価されてほしいと思っています。Apple がその体験の違いが十分でないと考えるなら、理由を説明するべきです。カテゴリに最初に入った開発者には、ユーザーの獲得で先行する権利があります。次に来る開発者にも、より良いものを提供する公平な機会があるべきです。

Rejets 4.3 de l’App Store : être premier donne-t-il un avantage ?

Matt Senter — Mon, 19 Oct 2026 14:17:04 +0000

Mon ami et collègue développeur indépendant Alan Seales a récemment vu son app, Dumpling, rejetée au titre de la règle 4.3 des App Review Guidelines d’Apple : Spam. Je l’ai utilisée. Le design est réfléchi, l’implémentation est solide, et l’app comprend bien les gens pour qui elle a été conçue. J’ai du mal à y voir un clone jetable.

Dumpling est une app de notes vocales pour iPhone et Apple Watch, conçue pour réduire la friction entre le moment où l’on capte une idée et celui où on l’organise, y compris pour les personnes avec un TDAH. Elle transcrit les enregistrements, titre et classe les notes, extrait les tâches et les échéances, et prépare un résumé quotidien. Vous pouvez noter une idée sans avoir d’abord à décider où elle va.

Je ne sais pas à quelles apps Apple a jugé Dumpling trop semblable, ni quelles similitudes ont motivé le rejet. Cela rend la décision difficile à évaluer et encore plus difficile à contester. À un niveau assez général, presque toute app est quelque chose qui existe déjà : un enregistreur vocal, un gestionnaire de tâches, une app météo. Les différences apparaissent souvent à l’usage.

Cette incertitude soulève une question plus large : maintenant que les logiciels sont plus faciles à créer, entrer le premier dans l’App Store devient-il un avantage concurrentiel plus précieux ? Une règle destinée à écarter le spam pourrait créer, sans le vouloir, un fossé protecteur autour des produits déjà admis.

Que signifie la règle 4.3 de l’App Store d’Apple ?

La règle d’Apple sur le spam couvre deux problèmes liés. La section 4.3(a) vise le fait de soumettre la même app sous plusieurs Bundle ID, par exemple en créant une app de plan distincte pour chaque ville. La section 4.3(b) vise les apps pratiquement impossibles à distinguer des offres existantes. Dans les catégories établies, Apple exige une « expérience sensiblement différente ou améliorée ». Ses exemples comprennent les apps de rencontre, les apps de fonds d’écran et les minuteurs simples.

Je comprends l’objectif. Prendre le produit de quelqu’un d’autre, changer les couleurs et le soumettre sous un autre nom crée du travail pour les examinateurs et du désordre pour les clients. En produire cent variantes ne le rend pas plus utile. Apple prévient lui-même que des soumissions essentiellement identiques consomment la capacité de l’App Review.

L’échelle est considérable. Dans sa mise à jour de mai 2026 sur l’App Store, Apple a indiqué avoir examiné plus de 9,1 millions de soumissions en 2025 et en avoir rejeté plus de 371 000 pour copie d’autres apps, spam ou tromperie des utilisateurs. Cette catégorie combinée compte des soumissions, pas des apps uniques rejetées spécifiquement au titre de la règle 4.3. Elle ne nous dit pas à quelle fréquence des apps légitimes ont été rejetées par erreur.

L’IA complique les choses, car il n’est plus nécessaire d’acheter un modèle pour reproduire un produit familier. On peut écrire une implémentation indépendante d’essentiellement la même expérience. Posséder le code ne rend pas automatiquement le résultat sensiblement différent.

J’utilise l’IA pour créer des logiciels. Elle peut aider les développeurs à résoudre des problèmes techniques difficiles et à servir des clients négligés. Elle peut aussi rendre moins cher d’inonder une place de marché d’apps à peine différenciées. Les outils rendent les deux possibles ; la qualité du résultat compte toujours.

Pourquoi des développeurs contestent-ils les rejets pour spam au titre de la 4.3 ?

Un constat de similarité peut être difficile à contester quand le développeur ne voit pas ce qu’Apple compare. Des témoignages publics récents montrent combien il peut être difficile de démontrer ce qui différencie une app, surtout quand sa valeur repose sur un flux de travail spécialisé.

Sebastian Röhl, développeur de FocusKit, a signalé deux rejets au titre de la 4.3(a) avant le lancement de son minuteur de concentration en novembre 2025. Plusieurs jours d’échanges pour expliquer ses différences ont mené à l’approbation. C’est une issue encourageante, mais démontrer qu’une app mérite d’être admise a demandé du travail supplémentaire avant que les clients puissent l’essayer.

En septembre 2026, le développeur de YanPian a signalé un rejet au titre de la 4.3(a) pour une app de vidéo d’escalade. Parmi ses fonctions figuraient la synchronisation des données de fréquence cardiaque de l’Apple Watch avec les images d’escalade, le suivi d’un grimpeur dans un plan large et un contrôle optionnel de stabilisateur. Le développeur a reconnu que, sans images d’escalade à importer, l’écran d’accueil pouvait ressembler à une app photo générique. Le fil public rapporte un appel sans résolution publiée.

Ces témoignages n’établissent pas qu’Apple a rejeté chaque app parce que sa catégorie était pleine. Nous n’avons pas non plus les dossiers de révision complets d’Apple. Ils montrent en revanche combien il peut être difficile de comprendre ce qu’on demande à un développeur de prouver.

La situation de YanPian me fait penser à Dumpling. Une app spécialisée peut partager ses ingrédients de base avec une app généraliste tout en faisant des choix différents sur la façon dont ils fonctionnent ensemble. Reconnaître ces choix peut exiger de suivre un flux de travail précis ou de comprendre le problème qu’elle résout. C’est un jugement plus difficile que de vérifier si une app plante.

Les règles anti-spam de l’App Store avantagent-elles les premiers arrivés ?

Je pense que oui, potentiellement. Une app qui arrive dans une catégorie relativement ouverte a moins de produits établis par rapport auxquels juger sa singularité. Un arrivant plus tardif peut devoir expliquer en quoi son approche diffère assez d’un ensemble croissant d’apps disponibles.

Le développeur arrivé plus tôt peut consacrer ce temps à attirer des clients, à améliorer le produit et à apprendre de l’usage. Le développeur arrivé plus tard peut le passer à expliquer pourquoi son produit devrait avoir le droit d’atteindre ces clients. Même si l’approbation finit par venir, l’incertitude et le retard ont un coût.

L’approbation n’est pas une protection permanente. Les règles d’Apple autorisent une différenciation ou une amélioration significative et prévoient le retrait des apps qui ne sont pas maintenues, améliorées ou qui n’attirent pas de clients. Les développeurs déjà en place peuvent eux aussi rencontrer des frictions lors de la révision.

En septembre 2026, Josh Dance a signalé le rejet au titre de la 4.3(a) d’une mise à jour de Pushup Hero. Il a dit que l’app était dans le store depuis 2018. Il soumettait des corrections de bugs et le mode sombre quand Apple a signalé une similarité avec une app associée à un compte résilié. Son récit décrit un appel sans indiquer son issue finale.

Ce qui me préoccupe, c’est la charge supplémentaire de celui qui arrive après qu’une catégorie s’est remplie. Cette charge pourrait influencer à la fois ce que les développeurs créent et la rapidité avec laquelle ils le soumettent.

Cela crée une incitation inconfortable : se précipiter. Le temps passé à affiner un produit devient du temps pendant lequel quelqu’un d’autre pourrait établir le point de comparaison. Un processus conçu pour améliorer la qualité pourrait augmenter, sans le vouloir, la pression de soumettre avant que le travail soit prêt.

L’IA rend-elle l’App Review plus lente ou plus stricte ?

Apple a reconnu la hausse des soumissions. Sa déclaration de mai 2026 dit que les outils de développement basés sur l’IA provoquent une vague de soumissions, tout en affirmant que l’App Review a « évolué sans accroc » pour y faire face. Apple dit aussi utiliser l’IA pour analyser la similarité entre apps et signaler aux examinateurs humains les changements potentiellement problématiques. Cela n’établit pas qu’une automatisation a pris la décision finale dans un rejet en particulier.

Dans un article de Business Insider de mars 2026, Apple a reconnu que certaines révisions étaient plus longues. Elle a indiqué avoir traité plus de 200 000 soumissions par semaine au cours des 12 semaines précédentes, avec un délai moyen de révision de 1,5 jour. Ses consignes aux développeurs précisent que 90 % des soumissions sont généralement examinées en moins de 48 heures.

Une décision de révision et une sortie réussie sont deux étapes différentes. Un développeur peut recevoir un rejet rapide et passer pourtant des semaines en échanges, en nouvelles soumissions et en appels. De bonnes statistiques de rapidité peuvent coexister avec un processus frustrant pour les développeurs dont l’app déclenche une classification contestée.

Apple a aussi répondu publiquement à des plaintes individuelles. Dans un fil de mai 2026 à propos de ByGate, le client dédié d’un service VPN, un compte identifié comme appartenant au personnel de l’App Review d’Apple a dit que des similitudes dans les binaires, les métadonnées et les concepts généraux peuvent contribuer à un constat de spam. Il a recommandé de prendre un rendez-vous avec l’App Review, sans identifier d’app de comparaison précise ni expliquer quelles caractéristiques n’étaient pas assez distinctes.

Comment les développeurs peuvent-ils répondre à un rejet au titre de la 4.3 ?

Apple propose des échanges avec l’App Review, des rendez-vous et des appels auprès de l’App Review Board. Ces mécanismes fonctionnent mieux quand le développeur comprend le grief.

Un code semblable, des captures d’écran semblables, des fonctionnalités semblables et un lien présumé avec un autre développeur sont des problèmes différents. Un développeur ne peut pas répondre intelligemment sans savoir lequel s’applique. Un rejet utile identifierait l’écran ou le flux de travail concerné, expliquerait quelles différences revendiquées ont été prises en compte, ou préciserait si le grief porte sur la paternité, sur des soumissions répétées ou sur l’expérience client.

Rien de tout cela n’exige de révéler les informations privées du compte d’un autre développeur.

Les développeurs ont aussi des responsabilités ici. Des mois de travail ne prouvent pas qu’une app offre quelque chose que les clients ne peuvent pas déjà obtenir. Nous devons rendre sa valeur visible à quelqu’un qui la découvre pour la première fois. Si cela exige des images d’escalade, des données représentatives ou une séquence d’actions précise, fournissez une démonstration fonctionnelle et des instructions de révision claires.

J’ai de la sympathie pour les examinateurs qui essaient de distinguer un clone d’une idée familière bien exécutée. Un meilleur échange de preuves aiderait les deux parties à dissiper les malentendus avant qu’un développeur ne commence à redessiner une app à partir de suppositions.

Peut-on distribuer des apps en dehors de l’App Store ?

Pour les développeurs Mac, la distribution directe est une option établie. Certaines apps ont besoin d’autorisations ou d’interactions avec d’autres applications qui ne rentrent pas dans le sandbox du Mac App Store. La documentation d’Apple sur le sandbox indique que certains usages des API d’accessibilité et l’interaction avec d’autres apps sont incompatibles avec ces restrictions.

Je distribue déjà deux apps Mac de cette façon : Burly, mon routeur de liens vers des profils de navigateur, et Comoji, mon app de raccourcis emoji. Burly envoie les liens vers des profils de navigateur précis et utilise l’accès Accessibilité pour contrôler les menus de profil de Safari. Comoji apporte des raccourcis emoji aux champs de texte de tout le Mac, en utilisant la Surveillance de l’entrée pour reconnaître les raccourcis et l’accès Accessibilité pour insérer le résultat. Ces capacités sont au cœur des produits.

La signature Developer ID et la notarisation permettent aux développeurs de distribuer directement des logiciels Mac tout en conservant les contrôles d’Apple contre les logiciels malveillants et les problèmes de signature. Pour les apps qui doivent fonctionner en dehors des restrictions du store, c’est une façon établie de servir les clients.

Je m’attends à ce que l’incertitude autour des rejets pour spam donne à davantage de développeurs une raison d’investir dans cette indépendance. Un site web, un paiement, une liste de diffusion et une relation directe avec les clients offrent plus de contrôle. Ils laissent aussi la place d’expliquer un produit spécialisé au-delà d’une fiche de store.

Mais un site web ne recrée pas la portée de l’App Store. Les clients doivent encore le découvrir, faire confiance au développeur et suivre un processus d’achat et d’installation différent. Même les développeurs qui distribuent de façon indépendante peuvent vouloir une fiche dans le store. Perdre cette possibilité a un coût.

La réponse est plus restrictive pour l’iPhone et l’iPad. Apple prend actuellement en charge les places de marché alternatives et la distribution autorisée par site web dans l’Union européenne, avec des places de marché iPhone également disponibles au Japon et au Brésil. Ces options ont des exigences régionales et restent soumises à la notarisation. Un développeur qui sert des clients iPhone ordinaires aux États-Unis ne peut pas simplement remplacer une fiche rejetée par un bouton de téléchargement sur un site web.

Une version web peut convenir à certains produits, mais elle peut exiger des changements importants du produit. La distribution indépendante est une réponse bien plus complète pour un développeur Mac que pour un développeur iPhone.

Des révisions plus strictes de l’App Store décourageront-elles les clones jetables ?

J’espère que certaines des personnes qui produisent des clones à la chaîne décideront que vendre de façon indépendante demande plus d’efforts que ça ne vaut. Si la stratégie consiste à soumettre cent variantes pour voir ce qui rapporte, un rejet pourrait être le point final de certains projets.

Générer une app n’est qu’une partie de la gestion d’une entreprise de logiciels. Même si vous pouvez générer le site web tout aussi vite, il faut encore attirer des clients, gagner leur confiance, gérer les paiements et les mises à jour, et leur donner une raison de vous choisir. Quelqu’un qui espère profiter du sillage d’une app existante aura peut-être peu d’intérêt pour ce travail.

Qui a besoin d’un énième minuteur Pomodoro avec une autre icône ? Une catégorie familière peut bénéficier d’une meilleure expérience ou d’une approche conçue pour un public négligé. Reproduire le même produit sous une autre marque n’apporte presque rien.

J’espère que la distribution indépendante décourage une partie de ces comportements. J’espère aussi qu’Apple deviendra meilleure pour les distinguer d’un développeur qui a créé quelque chose qui vaut la peine d’être utilisé. Arrêter un clone jetable peut profiter à la place de marché ; le rejet opaque d’un produit réfléchi peut priver les clients d’un choix utile.

Je veux que Dumpling soit jugée sur l’expérience qu’elle offre aux personnes pour qui Alan l’a conçue. Si Apple estime que cette expérience n’est pas assez différente, elle devrait expliquer pourquoi. Le premier développeur dans une catégorie mérite une longueur d’avance auprès des clients. Le suivant devrait quand même avoir une chance équitable de leur offrir quelque chose de mieux.