Ein macOS-Clipboard-Manager, in dem sich Kopiertes Stück für Stück ansammelt und später gezielt auswählen und verwenden lässt.
Ich habe ihn mit Blick auf Monetarisierung entwickelt. Schon am ersten Tag kam das Thema Preis auf, und drei Tage später stand fest, mit welchem Modell ich ihn verkaufen würde – es ist also nicht zufällig ein Hobbyprojekt geworden, das ich einfach hochgeladen habe. Am Ende nutze ich ihn aber selbst am meisten. Das ist der Punkt, mit dem ich am zufriedensten bin.
Am besten war er bei der Arbeit mit AI. Wenn man mehrere Prompts parallel laufen lässt oder Ergebnisse ins Clipboard ausgeben lässt, sammelt sich alles sauber an, und selbst wenn man zwischendurch andere Dinge macht, verpasst man nichts.
Gesammelte Inhalte lassen sich bearbeiten. Die meisten Clipboard-Manager sind ein schreibgeschütztes Protokoll, hier kann man einen Eintrag öffnen, direkt ändern und mit ⌘S speichern. Es gibt Zeilennummern, außerdem ⌘F zum Suchen und ⌘R zum Ersetzen. Dass man Kopiertes nicht mehr erst in einen Editor verschieben, dort ändern und dann erneut kopieren muss, ist ein größerer Vorteil, als man denkt.
Beim Entwickeln habe ich auch kleine nützliche Dinge eingebaut. JSON-, SQL- und Mongo-Formatierung, XML↔YAML, JWT-Dekodierung, Base64-/URL-Encoding, Unix-Timestamps, SHA-256, AES sowie ein zeilenweises Diff zweier Karten per ⌘D. Alles Dinge, die ich gebaut habe, weil ich keine Browser-Tabs dafür öffnen wollte.
Im Standardzustand fragt die App keinerlei Systemberechtigungen an. Alle Daten werden verschlüsselt und nur lokal gespeichert, es gibt keine Analyse, kein Tracking und keinen Server.
Aufzeichnung über 24 Tage
Ich habe es mit Claude Code gebaut. Weil der Gesprächsverlauf erhalten blieb, habe ich später nachgesehen: In 24 Tagen waren es 310 Einträge, davon 28 Fehlermeldungen und 15 Fälle, in denen ich Vorschläge abgelehnt oder zurückgenommen habe. Chronologisch sah das so aus.
5.7. (30 Einträge) — Die erste Anweisung war: "Frag mich nach den Anforderungen und konkretisiere sie mit mir." Noch am selben Tag wurden Name und Bundle-ID festgelegt, Base64 und Beautify hinzugefügt und die Detailansicht per ⌘⏎ eingebaut. Auch die Bemerkung "Ist das nicht eine 4,99-Dollar-App für den App Store?" kam an diesem Tag. Außerdem habe ich die Auto-Paste-Funktion entfernt. "Lassen wir sie weg, das wirkt wie eine Quelle für unbeabsichtigtes Einfügen."
6.7.–7.7. — Die Frage "Wo wird der Inhalt des Clipboards gespeichert?" führte zur Einführung lokaler Verschlüsselung. Ich habe einen Bug behoben, durch den Inhalte aus Excel nach dem Kopieren als Bild erkannt wurden, und zwei Tage lang verfolgt, warum der Shortcut ⌘⇧V nicht funktionierte. Dabei habe ich direkt log show ausgeführt und die Logs weitergereicht.
8.7. — Das Verkaufsmodell wurde endgültig festgelegt. Zur Debatte stand, ob von Anfang an bezahlt werden soll oder ob die App kostenlos verteilt und intern abgerechnet wird: "Sollen wir sie einfach direkt nur kostenpflichtig anbieten? Vielleicht nur 30 Tage gratis?" → entschieden wurde sich für eine 30-Tage-Testphase. Und die drei Tage zuvor entfernte Auto-Paste-Funktion kam zurück. Als ich die App selbst benutzte, merkte ich: "Es ist unpraktisch, wenn nach der Auswahl nicht sofort eingefügt wird."
11.7. — Ich habe eine Snippet-Funktion gebaut und wieder getötet. "Die Usability ist Mist" → "Schlag eine Verbesserung vor, und wenn sie schlecht ist, entfernen wir die Funktion" → "Nein, weg damit." Am schwierigsten war die Entscheidung, etwas Wegzuwerfen, das bereits gebaut war.
12.7.–16.7. — Für den Lizenzvertrieb habe ich bis hin zu Lemon Squeezy und PayPal alles geprüft und es dann doch auf den App Store reduziert. Danach folgte eine endlose Reihe aus fehlgeschlagener Adressprüfung, Bankcode, W-8BEN und Überlegungen zur Gewerbeanmeldung. Das hat mehr Zeit gekostet als das eigentliche Coden.
19.7. — Obwohl die App schon zur Prüfung eingereicht war, fiel mir beim Blick auf die Launcher-Screenshots auf, dass sie als DevClip-AppStore installiert wurde. Ich habe die Einreichung abgebrochen und neu gebaut.
25.7. — Ablehnung. Guideline 2.4.5 (Performance: Hardware Compatibility).
Ablehnung – und eine Entscheidung, die nach 24 Tagen abgeschlossen war
Ausgerechnet diese Funktion war der Grund für die Ablehnung. Das "Sofort-Einfügen", das ich am 5. Juli selbst als riskant entfernt hatte und drei Tage später wegen der Unbequemlichkeit wieder eingebaut hatte. Es nutzt die Bedienungshilfen-Berechtigung (Accessibility), und Apple wertete das als "Nutzung nicht zu Accessibility-Zwecken".
Die Funktion zu entfernen wäre einfach gewesen, aber ich hatte sie schon einmal entfernt und dann aus gutem Grund zurückgebracht – diesmal wollte ich sie behalten. Stattdessen habe ich die Art der Anfrage geändert.
Sie war ohnehin standardmäßig deaktiviert und wurde nur angefragt, wenn Nutzer sie selbst einschalteten. Das Problem war, dass Reviewer nirgends auf dem Bildschirm erkennen konnten, dass das so ist. Deshalb führt das Aktivieren des Toggles nun nicht mehr direkt zum Systemdialog für Berechtigungen, sondern zeigt zuerst ein Erklärfenster in der App. Darin steht unter anderem, dass sie "nur dafür verwendet wird, direkt nach der Auswahl einmal ⌘V zu senden, und keine Inhalte anderer Apps liest". Erst nach einem Klick auf "Weiter" erscheint der Systemdialog.
Ich habe sie mit einem Hinweis in den Review-Notizen erneut eingereicht – "Sie können es direkt unter Einstellungen > Allgemein nachvollziehen" – und sie wurde freigegeben.
"Es funktioniert bereits so" und "Nutzer können das auch selbst überprüfen" sind offenbar zwei verschiedene Dinge.
Wie ich mit AI gearbeitet habe
Den Code habe ich fast nicht selbst geschrieben. Ich saß eher an der Stelle, an der ich per Prompt erzeugte Implementierungen gelesen und beurteilt habe; ich bin zwar Engineer, habe mich diesmal aber faktisch auf Planung und QA konzentriert.
Es lief nicht immer gut. Dass sich Bilder nicht ziehen ließen, wurde dreimal nur per Vermutung "behoben", und jedes Mal musste ich selbst prüfen. Erst nachdem ich sagte: "Teste das bitte ordentlich, damit ich nicht alles einzeln verifizieren muss", änderte sich die Vorgehensweise dahin, erst mit echten Daten zu prüfen und dann zu korrigieren. Danach habe ich Bugs, die ich manuell gefunden hatte, jeweils sofort als Tests festgeschrieben, und ein großer Teil der inzwischen 270 Tests ist so entstanden.
Am Ende standen 87 Commits, rund 10.000 Zeilen Swift und 3.700 Zeilen Tests.
30 Tage lang sind alle Funktionen kostenlos. Danach bleiben die Grundfunktionen weiterhin gratis, und Pro ist kein Abo, sondern ein Einmalkauf.
2 Kommentare
Es scheint, als würde fast alles unterstützt, was es auch in Raycast gibt — worin genau liegen denn die Unterschiede?
Stimmt, wenn man nur die Clipboard-History betrachtet, gibt es viele Überschneidungen. Aber Raycast hat neben dem Clipboard noch viele andere Funktionen, sodass es sich für mich etwas überladen angefühlt hat.
Worauf ich geachtet habe, sind diese Punkte:
Zunächst soll es leichtgewichtig sein und nur die Clipboard-History verwalten. Aktuell sind es etwa 2 MB.
Außerdem kann man gespeicherte Inhalte in der Detailansicht bearbeiten. Das war praktisch, wenn ich mehrere Prompts geprüft und vorab ein wenig angepasst habe.
Auch Suche und Foldering waren mir wichtig. Ich habe versucht, die Fälle abzudecken, in denen man bei der Arbeit Informationen nur einmal braucht oder sie später ungern wieder suchen möchte.
Die Suche funktioniert über Inhalt, Tags, Titel usw.
Später möchte ich ermöglichen, Funktionen oder Layouts direkt über Plugins hinzuzufügen, aber das ist noch nicht konkret ausgearbeitet.
Ich halte Raycast ebenfalls für eine gute App und möchte daran arbeiten, dass es eine Auswahl je nach persönlichem Geschmack sein kann.
Vielen Dank für das Feedback.