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.

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.

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.

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.

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.

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.

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.

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.

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.

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.