Flaem: aplikacja iOS
Klient panelu z kanałem powiadomień i widżetami na ekranie głównym.
W Swifcie piszemy natywne aplikacje iOS dla naszych platform i biblioteki z czystym rdzeniem: interfejs w SwiftUI, widżety w WidgetKit i powiadomienia przez APNs.
Projekty z tej strony na ekranach z portfolio i case studies, każdy z krótkim opisem i drogą do pełnego.
Klient panelu z kanałem powiadomień i widżetami na ekranie głównym.
Natywny klient w SwiftUI: sesja w pęku kluczy, wiadomości na żywo przez WebSocket i ta sama warstwa logiki co na Androidzie.
Technologia ma pasować do miejsca, w którym kod będzie działał, i do zespołu, który go przejmie. Ostateczny wybór zapada przy wycenie, razem z Tobą.
Flaem i Plazer mają na iOS aplikacje w SwiftUI, które wyglądają i zachowują się jak reszta systemu. Aplikacja Flaem obsługuje panel z kanałem powiadomień, a Plazer rozmowy na żywo przez WebSocket.
Natywna aplikacja dostaje powiadomienia przez APNs także wtedy, gdy jest zamknięta, a dotknięcie otwiera właściwy ekran. Administrator trafia od razu do serwera, który ma problem.
Widżety na ekranie głównym iPhone'a powstają tylko w WidgetKit, czyli w Swifcie. Aplikacja Flaem pokazuje w nich najważniejsze informacje bez otwierania aplikacji.
Plazer trzyma sesję w pęku kluczy iOS, a nie w zwykłym pliku aplikacji. Dostępu do danych logowania pilnuje system.
Plazer na iOS korzysta z tej samej warstwy logiki co na Androidzie, a SwiftUI rysuje tylko interfejs. Zmiana w logice trafia na oba telefony.
Interpreter kite trzyma cały język Scheme w bibliotece KiteCore, a REPL jest osobnym, cienkim programem w tym samym pakiecie Swift. Każdą warstwę sprawdza XCTest. Projekty Xcode generujemy z pliku przez XcodeGen, więc kilka osób nie kłóci się o plik projektu.
Na Androidzie widżety, powiadomienia FCM i Jetpack Compose obsługuje kod w Kotlinie. Flaem i Plazer mają tam osobne aplikacje w Kotlinie.
Gdy iOS jest jedną z kilku platform o tych samych funkcjach, jeden kod w React Native z TypeScriptem albo we Flutterze kosztuje mniej. Swift wybieramy, gdy aplikacja potrzebuje tego, co ma tylko iOS.
Aplikacja webowa w TypeScripcie trafia do ludzi od razu po wdrożeniu, bez przeglądu w App Store. Do sprawdzenia pomysłu zwykle to wystarcza.
Rdzeń szyfrowania Plazera jest w Ruście i ma jedną implementację dla wszystkich aplikacji. Druga kopia w Swifcie oznaczałaby drugi protokół do sprawdzenia.
Swift działa też na serwerze, ale usługi, z którymi rozmawiają nasze aplikacje, są w Go albo w Ruście. Centralka Plazera jest w Go, a rdzeń Flaem w Ruście.
Program na komputer, który ma działać też na Windows i Linuksie, piszemy w C# z Avalonią. Tak powstały aplikacje desktopowe Flaem i Plazera.
Każda potrzeba w jednym wierszu, a obok siebie to, co w tej sprawie daje każda z dwóch kolumn.
Ile linii napisaliśmy w Swift i jaką część wszystkiego, co napisaliśmy, to stanowi. Liczymy linie dodane w commitach naszych repozytoriów, osobno dla każdego języka.
Z plików zależności naszych repozytoriów. Przy każdej jedno zdanie o tym, do czego jej używamy.
Interfejs aplikacji.
Widżety na ekranie głównym.
Projekt Xcode generowany z pliku.
Testy logiki.
Odpowiedzi o Swift, naszych projektach i liczbach na tej stronie.
Opisy projektów z tej strony i przegląd wszystkich technologii.
Opisz, co chcesz zbudować. Odpiszemy w godzinę i powiemy wprost, czy ta technologia jest dobrym wyborem.