Expertise · Desktop-Anwendungen

Anwendungen, die auf dem Computer installiert werden. Für macOS haben wir zwei gebaut; für Windows und Linux ist diese Seite ein Angebot, keine Historie.

Wir bauen native Anwendungen für macOS, mit vom Bildschirm getrenntem Logikkern, damit dieselbe Logik auch auf dem Telefon läuft. Für Windows und Linux/Ubuntu haben wir noch nichts ausgeliefert und schreiben das auch so, mit den Bedingungen, unter denen wir den Auftrag annehmen würden. Die erste Frage bleibt, ob Sie wirklich eine installierte Anwendung brauchen.

Ein Projekt besprechen

Angebot, mit BedingungenDie Regel ist mechanisch, und ich wende sie mechanisch an. Auf macOS haben wir zwei eigene, erstellte und ausführbare Implementierungen: eine Menüleisten-App mit 25 Swift-Dateien, die 15 Dateien aus dem Kern eines iPhone-Projekts wiederverwendet, und eine zweite, einfachere App, die eine WebKit-Hülle über einer Webanwendung ist. Beide haben ein auf diesem Rechner kompiliertes Binary. Aber der Dienst, wie er genannt wird, deckt drei Systemfamilien ab, und für zwei davon — Windows und Linux/Ubuntu — haben wir ernsthaft gesucht und null gefunden: kein eigenes .NET- oder Qt-Projekt, kein `tauri.conf.json`, kein von uns geschriebenes Electron, kein `.desktop`, keine deb-, rpm- oder AppImage-Paketierung. Außerdem wurde keine der beiden macOS-Apps jemals in ein verteilbares Installationsprogramm gepackt. Mit nur einer von drei Plattformen abgedeckt und null Distributionen wird die Seite als Angebot unter Bedingungen geschrieben. Wenn wir die erste Windows- oder Linux-App ausliefern, ändert sich der Wert, nicht der Text.

Die erste Frage, die wir Ihnen stellen, ist nicht für welches System, sondern ob Sie wirklich eine installierte Anwendung brauchen. Sie lohnt sich, wenn sie etwas braucht, das der Browser ihr nicht gibt: direkten Zugriff auf Sensoren oder Peripheriegeräte, dauerhafte Präsenz in der Systemleiste, Arbeit ohne Internet, Zugriff auf Dateien auf der Festplatte, ohne dass die Person sie jedes Mal hochladen muss, oder Ausführung im Hintergrund, wenn das Fenster geschlossen ist. Wenn nichts davon gefordert ist, ist eine Website, die sich über einen Link öffnet, billiger zu bauen, zu aktualisieren und zu warten — und das sagen wir Ihnen, auch wenn die Arbeit kleiner ausfällt.

Auf macOS haben wir zwei Anwendungen gebaut. Die erste ist eine Menüleisten-Anwendung: 25 eigene Swift-Dateien plus 15 Kerndateien, die direkt aus dem iPhone-Projekt desselben Produkts stammen — dieselben Dateien, keine Kopie. Sie wird mit einem Skript gebaut, das den Swift-Compiler direkt aufruft, Ziel `arm64-apple-macosx14`, und elf System-Frameworks verknüpft, darunter SwiftUI, AppKit, CoreMotion, Vision und UserNotifications. Das resultierende Binärprogramm hat 6.516.128 Bytes. Die zweite ist viel einfacher und es ist fair, die Zahl zu nennen: drei Swift-Dateien, eine WebKit-Hülle über eine Webanwendung, mit aktiviertem Sandbox und gehärteter Laufzeit, universal kompiliert für Intel- und Apple-Prozessoren. Das sind zwei verschiedene Dinge, und wir nennen sie auch unterschiedlich.

Was wir nicht haben, klar gesagt. Windows: null. Wir haben nach .NET-, WPF-, WinForms-, WinUI-Projekten, `.xaml`-, `.appxmanifest`-, `.msi`-, `.wxs`-Dateien gesucht — alles, was wir auf der Festplatte gefunden haben, gehört zu einer C-Bibliothek eines Dritten, vendored in einem anderen Projekt, die wir nicht geschrieben haben. Linux-Desktop: null — keine `.desktop`-Datei, kein hier gebautes deb- oder AppImage-Paket. Von uns geschriebene Electron oder Tauri: null. Und ebenso wichtig: Keine der beiden macOS-Anwendungen wurde jemals in einen Installer gepackt. Sie existieren als lokal gebaute, ad-hoc signierte `.app`-Pakete ohne Team-Identifier.

Was die bisherige Erfahrung dennoch überträgt, und das ist der Teil, der für ein neues Projekt zählt: die Disziplin, den Kern der Logik von der Oberfläche getrennt zu halten. Im macOS-Projekt importieren die Berechnungs- und Policy-Dateien die Oberfläche nicht, also werden sie auf dem Mac als gewöhnliches Programm kompiliert und ausgeführt, ohne Simulator; ihre Logik-Suite läuft in wenigen Sekunden. Dieselbe Trennung macht das Portieren auf ein anderes System zu einer Frage der Hülle, nicht der Neuschreibung. Darauf stützen wir uns, wenn wir sagen, dass wir Windows oder Linux machen könnten — nicht auf eine Erfahrung, die wir nicht haben.

Was dazugehört

Die Arbeit, nach Bestandteilen

Zuerst entscheiden wir, ob Sie eine installierte Anwendung brauchen

Fünf Kriterien, nacheinander geprüft: Zugriff auf Sensoren oder Peripheriegeräte, Präsenz in der Systemleiste, Arbeit ohne Internet, direkter Zugriff auf Dateien auf der Festplatte, Ausführung im Hintergrund bei geschlossenem Fenster. Wenn keines zutrifft, ist die Empfehlung eine Webanwendung, und der Grund ist praktisch: Eine installierte Anwendung muss auf jedem Computer signiert, verteilt und aktualisiert werden, und jeder dieser drei Schritte kostet fortlaufend, nicht nur einmal.

Der Kern wird einmal geschrieben und weiß nicht, worauf er läuft

In unserer macOS-Anwendung listet das Desktop-Ziel 15 Dateien aus dem Kern des iPhone-Projekts als eigene Quellen auf — Berechnung, Kalibrierung, Verlauf, Benachrichtigungs- und Gesundheitsdatenrichtlinien. Sie sind nicht kopiert, es sind dieselben Dateien. Die Folge: Eine Algorithmuskorrektur wird an einem Ort vorgenommen und erscheint in beiden. Die zweite Folge, wichtiger für Sie: Der Kern kann getestet werden, ohne die Anwendung zu starten.

Die Plattform-Hülle bleibt dünn, und wir sagen Ihnen, wie dünn

Die Menüleisten-Anwendung verwendet `MenuBarExtra` über einen AppKit-Anwendungsdelegierten — nativer Code, aber wenig, weil der Rest der gemeinsame Kern ist. Unsere andere macOS-Anwendung ist das Gegenteil: drei Dateien, ein für SwiftUI verpacktes `WKWebView`, also ein Fenster über einer Webanwendung. Beide sind legitime macOS-Anwendungen, aber sie bedeuten Unterschiedliches in Aufwand, Geschwindigkeit und Systemzugriff. Welche Sie brauchen, wird am Anfang entschieden, nicht bei der Lieferung entdeckt.

Wir bauen mit einem Skript, nicht mit einem Knopfdruck

Die Menüleisten-App wird aus einem Skript mit weniger als hundert Zeilen gebaut, das den Swift-Compiler direkt aufruft, mit Ziel und Framework-Liste ausdrücklich geschrieben, dann das `.app`-Paket ablegt und signiert. Ein Build, der in ein Skript passt, läuft auf einem anderen Rechner genauso und kann in eine automatisierte Pipeline eingebunden werden; ein Build, der nur in der Oberfläche eines Entwicklungsprogramms existiert, kann das nicht.

Sandbox und gehärtete Runtime, wenn die App ins Netz geht

Die zweite macOS-Anwendung startet mit aktivierter Sandbox und mit einer einzigen Netzwerkberechtigung, der als Client — kein Server, kein Zugriff auf die Dateien des Benutzers, keine Kamera, kein Mikrofon. Die gehärtete Runtime ist in der Projektkonfiguration eingeschaltet. Die Berechtigungen werden von Anfang an als kurze, lesbare Liste deklariert, sie werden nicht unterwegs hinzugefügt, wenn etwas nicht funktioniert.

Die Signierung ist eine Frage des Kontos, nicht des Codes, und wir legen sie von Anfang an auf den Tisch

Unsere macOS-Apps werden ad hoc signiert: Die Prüfung besteht lokal, aber es gibt keine Team-ID, und in der Projektkonfiguration ist das Feld für das Entwicklungsteam leer. Für die Verteilung außerhalb des Stores braucht ein macOS-Paket eine Signierung mit einem identifizierbaren Entwicklerzertifikat und den Durchlauf durch die Apple-Notarisierung, andernfalls blockiert das Betriebssystem des Empfängers es. Es ist eine Frage von Konto und Prozess, nicht von Funktionalität — aber es ist eine echte Frage, und wir verschweigen sie nicht erst im letzten Meeting.

Windows und Linux: was wir vor der Annahme verlangen

Eine kostenpflichtige Kompatibilitätsprüfung als erste Phase, die mit einem Gerüst endet, das auf Ihrem Rechner startet, nicht mit einem Dokument. Dabei werden drei Dinge entschieden: welche Laufzeitumgebung wir verwenden und warum, wer das Signaturzertifikat und das Vertriebskonto besitzt und wie ein Update auf die Rechner der Menschen gelangt. Wenn eines der drei keine Antwort hat, beginnt die Arbeit nicht. Wir übernehmen keine Plattform, die wir nicht geliefert haben, und tun nicht so, als wäre das eine Formalität.

Linux-Server ist nicht Linux-Desktop, und wir verwechseln die beiden nicht

Unsere Systeme laufen Tag für Tag auf Linux: Systemdienste mit Neustart bei Fehlern, Webserver davor, Protokolle und deren Rotation. Das ist echte Linux-Erfahrung, aber Server-Erfahrung. Eine Fensteranwendung für Ubuntu ist eine andere Disziplin — Verpackung, Integration in die grafische Umgebung, Verteilung über ein Repository oder als eigenständige Datei — und dort haben wir nichts geliefert. Den Unterschied erkennt ein Ingenieur in drei Sekunden; besser, wir sagen ihn selbst vorher.

Was wir nicht machen

Wir versprechen kein Installationsprogramm, das wir nie produziert haben, ohne zu sagen, dass es das erste Mal ist. Wir wählen keine Laufzeitumgebung nur, weil sie gerade in Mode ist, ohne zuerst zu prüfen, was die Anwendung vom System verlangt. Und wir übernehmen keine bestehende Desktop-Anwendung, bevor wir sie von Grund auf auf unserem Rechner aus den erhaltenen Quellen bauen können — wenn sich der Build nicht reproduzieren lässt, ist jede Schätzung danach ein Ratespiel.

Wie es aussieht

Der Weg, Schritt für Schritt.

Wir entscheiden zwischen installiert und Web, nach fünf Kriterien

Sensoren und Peripheriegeräte, Systemleiste, Arbeit ohne Internet, Dateizugriff, Ausführung im Hintergrund. Wir liefern die schriftliche Entscheidung mit der Begründung, auch wenn die Begründung lautet: „Sie brauchen keine installierte App“. Diese Phase ist kurz und kann hier ohne Verlust enden.

Wir bauen den Kern und testen ihn ohne Plattform

Logik, Zustände, Persistenz, Richtlinien — so geschrieben, dass die Oberfläche keine Rolle spielt und sie als Kommandozeilenprogramm kompiliert und ausgeführt werden können. Wir liefern die Testsuite und den Befehl, mit dem Sie sie ausführen. Wenn später eine zweite Plattform dazukommt, sieht man hier, ob die Arbeit von Anfang an richtig gemacht wurde.

Wir setzen die Plattformhülle auf

Auf macOS: Fenster oder Menüleiste, Benachrichtigungen, Berechtigungen, das `.app`-Paket, das Build-Skript. Auf Windows oder Linux: nach der Kompatibilitätsprüfung aus der ersten Phase, mit der dort gewählten Laufzeitumgebung. Am Ende der Phase startet die Anwendung auf Ihrem Rechner, nicht auf unserem.

Signierung, Verteilung, Aktualisierung

Die Phase, die die meisten Projekte erst spät entdecken und die wir absichtlich zuletzt setzen, damit sie sichtbar ist: Zertifikat, Konto, Notarisierung, wo die Plattform es verlangt, Aktualisierungskanal. Hier liegt auch unser aktueller Blocker auf macOS — die Anwendungen sind ad-hoc signiert, ohne Team-ID. In Ihrem Projekt gehört das Konto Ihnen, und der Blocker verschwindet.

Ein Kern in der Mitte — Berechnung, Kalibrierung, Historie, Richtlinien — der keine Oberfläche importiert und deshalb allein getestet wird. Darum herum vier Hüllen der Plattform: iPhone und macOS, verbunden und gebaut, voll gezeichnet; Windows und Linux Desktop, offen gezeichnet, weil sie nicht existieren. Der fünfte Knoten, die Distribution, ist über eine gestrichelte Linie mit macOS verbunden: Das Paket wird gebaut und ad hoc signiert, geht aber nicht durch die Notarisierung und gelangt daher nicht auf einen anderen Rechner. Die Zeichnung sagt, was gemacht ist und was nicht, im selben Bild.

Die Daten

Was wir anfassen, wo die Daten liegen und wie lange sie bleiben

Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.

Eine installierte App sieht mehr als eine im Browser: Das ist der Grund, warum Sie sie wollen, und zugleich ihr Risiko: Sie hat Zugriff auf die Festplatte, auf das Dateisystem des Benutzers und, wenn ihr Berechtigungen gegeben werden, auf Peripheriegeräte. Deshalb werden Berechtigungen ausdrücklich deklariert und auf ein Minimum begrenzt. Unsere Anwendung mit Sandbox hat genau eine Berechtigung, die als Netzwerk-Client.
Wo liegen die Daten, wenn die Anwendung keinen Server hat: Auf dem Rechner der Person. In der Menüleisten-App wird der Verlauf in eine eigene Datei geschrieben, und die Einstellungen in den System-Einstellungsspeicher, mit app-präfixierten Schlüsseln. Es geht nichts an einen Server aus einem einfachen Grund: Es gibt keinen Netzwerkcode in der Anwendung. Wenn es einen gibt, wird auf der Berechtigungsseite geschrieben, wer was erhält.
Was wir standardmäßig nicht erfassen: Keine Telemetrie, keine Gerätekennung, kein Nutzungsbericht, wenn sie nicht ausdrücklich angefordert und in der Oberfläche deklariert werden. Eine Desktop-Anwendung ist ein Ort, an dem Telemetrie unbemerkt durchgeht; deshalb wird sie, wenn sie hinzugefügt wird, sichtbar hinzugefügt, mit Schalter zum Ausschalten, und es wird geschrieben, welche Felder gesendet werden.
Aktualisierungen sind eine Entscheidung, kein technisches Detail: Wir haben heute keinen gebauten Kanal für automatische Aktualisierungen. In einem neuen Projekt ist das eine der ersten drei Entscheidungen, neben Signierung und Verteilung: Wird manuell aktualisiert, über den Store der Plattform oder über einen eigenen Kanal? Jede Variante hat andere laufende Kosten und eine andere Sicherheitsfläche, und sie wird vor der ersten Codezeile gewählt, nicht danach.
Was bei uns bleibt: Die Quellen, solange wir arbeiten; nach der Übergabe das, was im Vertrag vereinbart wurde. Die Signaturzertifikate bleiben idealerweise auf Ihrem Organisationskonto — wenn sie auf unserem bleiben, sind Sie für jedes Update an uns gebunden, und das muss eine bewusste Entscheidung sein, keine Folge.

Ein Fall

Eine macOS-Anwendung, aus dem Kern einer iPhone-Anwendung herausgelöst, ohne zweite Implementierung

Die Ausgangslage

Wir hatten ein eigenes iPhone-Produkt, das die Kopfneigung relativ zu einer zu Beginn der Sitzung kalibrierten Position misst. Dieselben Regeln — Kalibrierung, Schwellenwerte, Verlauf, Benachrichtigungsrichtlinien — ergaben auch auf dem Mac Sinn, wo die Person ohnehin vor dem Bildschirm sitzt. Die eigentliche Frage war nicht, ob es geht, sondern wie viel Logik neu geschrieben werden müsste.

Was wir gebaut haben

Null, weil der Kern von Anfang an geschrieben wurde, ohne den Bildschirm zu kennen. Das macOS-Ziel listet 15 Dateien aus dem iPhone-Projekt als eigene Quellen auf, zu denen 25 spezifische Swift-Dateien für den Desktop kommen: das Fenster, das Menü in der Systemleiste über einen AppKit-Delegaten, die Benachrichtigungen, der Umgebungsdienst. Der Build läuft nicht über die Xcode-Oberfläche: Ein Skript ruft den Swift-Compiler direkt mit dem Ziel `arm64-apple-macosx14` auf und bindet explizit elf System-Frameworks, legt danach das `.app`-Paket ab und signiert es, und am Ende prüft es die Signatur.

Was dabei herauskam

Ein Binärprogramm von 6.516.128 Bytes für Apple-Prozessoren, das startet und in der Menüleiste bleibt, gebaut mit einem einzigen Befehl. Dieselbe Algorithmuskorrektur landet auf dem Telefon und auf dem Mac, weil es dieselbe Datei ist, keine manuell synchronisierte Kopie.

Was der Fall nicht sagt

Die Anwendung wird nicht verteilt und kann es in dieser Form derzeit nicht sein: Die Signatur ist ad-hoc, ohne Team-ID, und das Team-Feld ist in der Projektkonfiguration leer. Auf einem anderen Rechner wäre sie vom System blockiert. Es ist ein Problem des Kontos und der Notarisierung, nicht der Funktionalität — aber es bleibt ein ungelöstes Problem, und wir schreiben es so, nicht als Detail.

Fragen

Was uns die Leute fragen, bevor sie anrufen

Warum steht auf dieser Seite „Angebot“, wenn Sie sagen, dass Sie zwei Mac-Anwendungen haben?

Weil der Dienst „Desktop-Anwendungen“ heißt und drei Systemfamilien abdeckt, und wir ihn auf einer ausgeliefert haben. Unsere eigene Regel verlangt mindestens zwei eigene, im Code vorzeigbare Implementierungen für jede Aussage vom Typ „wir haben gemacht“. Auf macOS haben wir sie. Auf Windows und auf Linux haben wir null, und keine der beiden Mac-Anwendungen wurde jemals in ein verteilbares Installationspaket gepackt. Eine Seite, die etwas anderes behauptet, würde bei der zweiten Frage eines Ingenieurs scheitern.

Haben Sie eine Mac-Anwendung, die ich jetzt herunterladen kann?

Nein. Beide liegen als `.app`-Pakete vor, die auf unserem Rechner erstellt wurden: eine für Apple-Prozessoren kompiliert, die andere universal, für Intel und Apple. Sie sind ad-hoc signiert, das heißt, sie bestehen die lokale Prüfung, haben aber keine Team-ID, daher würde das System sie auf einem anderen Rechner blockieren. Was wir vor Ihnen tun können, ist, sie zu starten, den Code und das Build-Skript zu öffnen und die Logik-Suite auszuführen.

Was ist bei Ihnen der Unterschied zwischen den beiden Mac-Anwendungen?

Die eine ist nativ, die andere ist ein Fenster über dem Web, und der Unterschied ist groß. Die native hat 25 eigene Swift-Dateien plus 15 gemeinsame Kernel-Dateien mit der iPhone-Version, dockt über einen AppKit-Anwendungsdelegierten in der Menüleiste an und bindet elf System-Frameworks ein, darunter Bewegungssensoren, Benachrichtigungen und Bildverarbeitung. Die zweite hat drei Dateien und zeigt eine Webanwendung in einem `WKWebView` an. Die zweite ist schnell gemacht und eine richtige Wahl, wenn Ihre Anwendung bereits web-basiert ist und Sie nur ein Symbol im Dock wollen. Es ist keine richtige Wahl, wenn Sie ein System brauchen.

Machen Sie Anwendungen für Windows?

Wir haben keine einzige ausgeliefert und behaupten nichts anderes. Wir haben auf unseren Datenträgern nach jeder Spur gesucht — .NET-, WPF-, WinForms-, WinUI-Projekte, XAML-Oberflächendateien, Anwendungsmanifeste, MSI- oder WiX-Pakete — und alles, was auftaucht, gehört zu einer Drittanbieter-C-Bibliothek, die wir nur in einem anderen Projekt verwenden. Wenn Sie Windows brauchen, ist die erste Etappe eine Kompatibilitätsprüfung, die mit einem Gerüst endet, das bei Ihnen auf dem Rechner startet, und erst danach besprechen wir den Rest.

Und für Linux oder Ubuntu?

Die gleiche Position, mit einer wichtigen Präzisierung. Fenstergesteuerte Anwendung für Linux: null ausgeliefert, kein von uns gebautes deb- oder AppImage-Paket. Linux-Server: Tag für Tag — Systemdienste, Webserver davor, Protokolle, Neustart bei Fehler. Das sind zwei unterschiedliche Disziplinen, und es wäre unehrlich, die erste als Beweis für die zweite zu verwenden.

Warum nicht Electron, wenn das einfacher ist?

Weil wir keine einzige ausgeliefert haben und nicht behaupten werden, Erfahrung dort zu haben, wo wir keine haben. Auf unseren Datenträgern gibt es zwei funktionierende Electron-Anwendungen, aber es sind von anderen Autoren geklonte Repositorien, mit null Beiträgen von uns — wir haben sie im Commit-Verlauf genau geprüft, damit sie nicht auf dieser Seite als „Beweis“ landen. In einem realen Projekt wird die Wahl zwischen einer verpackten Webumgebung und nativem Code danach getroffen, was die Anwendung vom System verlangt, wie schwer das Paket ist und wer die Wartung bezahlt, nicht nach Mode.

Was blockiert bei Ihnen die Veröffentlichung einer Mac-Anwendung?

Das Konto, nicht der Code. In der Projektkonfiguration ist das Feld für das Entwicklungsteam leer, und die Signatur des gebauten Pakets ist ad-hoc, ohne Team-ID. Für die Verteilung außerhalb des Stores verlangt macOS ein identifizierbares Entwicklerzertifikat und die Notarisierung des Pakets. In einem Projekt von Ihnen gehören Zertifikat und Konto Ihrer Organisation, also tritt dieser Blocker einfach nicht auf — aber er muss von Anfang an eingeplant werden, mit seinen Kosten und seiner Zeit.

Ist es nicht einfacher, eine Website zu machen und fertig?

Oft ja, und das sagen wir Ihnen, bevor Sie es uns sagen. Eine Website braucht keine Signatur, keine Notarisierung, kein Installationspaket, keinen Update-Kanal und auch keine Version für jedes Betriebssystem. Die installierte Anwendung ist im Vorteil, wenn Sie Sensoren, Peripheriegeräte, Arbeit ohne Internet, dauerhafte Präsenz in der Systemleiste oder direkten Zugriff auf die Dateien des Benutzers brauchen. Wenn nichts davon auf der Liste steht, ist das Geld an anderer Stelle besser ausgegeben.

Können Sie eine Desktop-Anwendung übernehmen, die wir bereits haben?

Mit einer Bedingung, die vor jeder Schätzung geprüft wird: Wir müssen sie von Grund auf auf unserem Rechner aus den erhaltenen Quellen bauen können. Wenn der Build nicht reproduzierbar ist — Abhängigkeiten, Zertifikate, nicht dokumentierte Schritte fehlen — dann kann niemand etwas ehrlich schätzen, und die erste Arbeit wird die Reproduktion des Builds sein, nicht neue Funktionalität. Das sagen wir im Voraus, damit es nicht in der Mitte entdeckt wird.

Worauf die obigen Aussagen beruhen (14 Quellen)

14 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.

Wie wir arbeiten Alle Dienstleistungen

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen