Aplikacje, które instaluje się na komputerze. Na macOS zbudowaliśmy dwie; dla Windows i Linux ta strona jest ofertą, nie historią.

Ponieważ usługa nazywa się „aplikacje desktopowe” i obejmuje trzy rodziny systemów, a my mamy dostarczone na jednej. Reguła, którą stosujemy wobec siebie, wymaga minimum dwóch własnych implementacji, możliwych do pokazania w kodzie, dla każdego stwierdzenia typu „zrobiliśmy”. Na macOS je mamy. Na Windows i na Linux mamy zero, i żadna z dwóch aplikacji na Maca nigdy nie została spakowana w dystrybuowalny instalator. Strona, która mówiłaby co innego, upadłaby przy drugim pytaniu inżynierki.

Nie. Obie istnieją jako pakiety `.app` zbudowane na naszym komputerze: jeden skompilowany dla procesorów Apple, drugi uniwersalny, dla Intel i Apple. Są podpisane ad hoc, co oznacza, że przechodzą lokalną weryfikację, ale nie mają identyfikatora zespołu, więc na innym komputerze system by je zablokował. To, co możemy zrobić przed Tobą, to uruchomić je, otworzyć kod i skrypt budowy oraz uruchomić zestaw logiki.

Jedna jest natywna, druga jest oknem nad webem, i różnica jest duża. Ta natywna ma 25 własnych plików Swift plus 15 wspólnych plików rdzenia z wersją na iPhone’a, wpina się w pasek menu przez delegata aplikacji AppKit i łączy jedenaście frameworków systemowych, w tym czujniki ruchu, powiadomienia i przetwarzanie obrazu. Druga ma trzy pliki i wyświetla aplikację webową w `WKWebView`. Druga robi się szybko i jest właściwym wyborem, kiedy twoja aplikacja jest już webowa i chcesz tylko ikony w Docku. Nie jest właściwym wyborem, kiedy potrzebujesz systemu.

Nie dostarczyliśmy żadnej i nie twierdzimy inaczej. Szukaliśmy na naszych dyskach wszelkich śladów — projektów .NET, WPF, WinForms, WinUI, plików interfejsu XAML, manifestów aplikacji, pakietów MSI albo WiX — i wszystko, co się pojawia, należy do zewnętrznej biblioteki C, której tylko używamy w innym projekcie. Jeśli potrzebujesz Windows, pierwszy etap to weryfikacja zgodności, która kończy się szkieletem uruchamiającym się u ciebie na komputerze, i dopiero po niej omawiamy resztę.

To samo stanowisko, z ważnym doprecyzowaniem. Aplikacja okienkowa dla Linux: zero dostarczonych, ani jednego pakietu deb ani AppImage zbudowanego przez nas. Serwery Linux: codziennie — jednostki systemowe, serwer webowy z przodu, logi, ponowne uruchomienie przy awarii. To dwie różne dyscypliny i byłoby nieuczciwe używać pierwszej jako dowodu dla drugiej.

Ponieważ nie dostarczyliśmy żadnej i nie będziemy twierdzić, że mamy doświadczenie tam, gdzie go nie mamy. Na naszych dyskach istnieją dwie działające aplikacje Electron, ale są to repozytoria sklonowane od innych autorów, z zerowym naszym wkładem — sprawdziliśmy je w historii commitów dokładnie po to, żeby nie stały się „dowodem” na tej stronie. W prawdziwym projekcie wybór między opakowanym środowiskiem webowym a kodem natywnym robi się po ustaleniu, czego aplikacja wymaga od systemu, ile waży pakiet i kto płaci za utrzymanie, a nie według mody.

Konto, nie kod. W konfiguracji projektu pole zespołu deweloperskiego jest puste, a podpis pakietu zbudowanego jest ad hoc, bez identyfikatora zespołu. Do dystrybucji poza sklepem macOS wymaga identyfikowalnego certyfikatu deweloperskiego i przejścia pakietu przez notarizację. W twoim projekcie certyfikat i konto należą do twojej organizacji, więc ta blokada po prostu nie występuje — ale trzeba ją przewidzieć od początku, z jej kosztem i czasem.

Często tak, i mówimy ci to my, zanim ty nam to powiesz. Strona nie potrzebuje podpisywania, notarizacji, instalatora, kanału aktualizacji ani wersji dla każdego systemu operacyjnego. Zainstalowana aplikacja wygrywa, kiedy potrzebujesz czujników, peryferiów, pracy bez internetu, stałej obecności w pasku systemowym albo bezpośredniego dostępu do plików człowieka. Jeśli żadna z tych rzeczy nie jest na liście, pieniądze lepiej wydać gdzie indziej.

Z jednym warunkiem sprawdzonym przed jakąkolwiek wyceną: musimy móc zbudować ją od zera, na naszej maszynie, z otrzymanych źródeł. Jeśli build nie daje się odtworzyć — brakuje zależności, certyfikatów, niespisanych kroków — wtedy nikt nie może uczciwie niczego wycenić, a pierwszą pracą staje się odtworzenie builda, nie nowa funkcjonalność. Mówimy to z góry, żeby nie wyszło pośrodku.