Kiedy polecamy Swifta, a kiedy go odradzamy
Aplikacja natywna na iOS daje pełny dostęp do funkcji Apple i wygląd zgodny z systemem, ale obejmuje tylko jedną platformę. O wyborze decyduje to, czego aplikacja potrzebuje od iPhone’a.
Polecamy Swifta, gdy:
- aplikacja korzysta z funkcji dostępnych tylko u Apple: HealthKit, ARKit, Apple Watch, widżety, Siri i skróty,
- Twoi klienci to głównie użytkownicy iPhone’ów, a aplikacja ma wyglądać jak aplikacje systemowe,
- aplikacja przetwarza obraz, wideo albo rozszerzoną rzeczywistość w czasie rzeczywistym,
- rozwijasz istniejącą aplikację napisaną w Swifcie.
Odradzamy Swifta, gdy:
- aplikacja musi być jednocześnie na Androidzie i iOS, a budżet nie wystarczy na dwie aplikacje - wtedy proponujemy Fluttera,
- zakres to formularze, listy, zamówienia i płatności bez funkcji specyficznych dla Apple,
- większość użytkowników ma Androida, na przykład pracownicy z firmowymi telefonami.
Natywnie w Swifcie czy Flutter - porównanie dla iOS
Wymagania App Store są takie same dla obu dróg. Różnice dotyczą dostępu do funkcji Apple i kosztu drugiej platformy.
| Kryterium | Swift i SwiftUI (natywnie) | Flutter |
|---|---|---|
| Platformy | iPhone, iPad, Apple Watch, Mac | iOS i Android z jednego kodu |
| Interfejs | komponenty systemowe, zgodne z nowymi wersjami iOS | własny silnik, wygląd iOS odtwarzany |
| HealthKit, ARKit, widżety, zegarek | pełny dostęp od dnia premiery systemu | część przez wtyczki, reszta natywnie |
| Weryfikacja w App Store | te same wytyczne Apple | te same wytyczne Apple |
| Koszt, gdy potrzebny też Android | wyższy - dwie osobne aplikacje natywne | niższy - jeden kod na obie platformy |
| Kiedy wybieramy | funkcje Apple, AR, zdrowie, zegarek | aplikacje biznesowe na obie platformy |
W studiach przypadków publikowanych przez Google zespoły Google Classroom i Reflectly raportują, że jeden kod we Flutterze skrócił czas pracy nad aplikacją na obie platformy o co najmniej 50% - to wyniki wybranych wdrożeń, a nie średnia rynkowa.
Jak przygotowujemy aplikację do weryfikacji w App Store i ile kosztuje aplikacja na iOS, opisujemy na stronie aplikacje mobilne na iOS.
Jak pracujemy w Swifcie
Wersje
Nowe ekrany budujemy w SwiftUI, a UIKit stosujemy tam, gdzie SwiftUI wciąż nie wystarcza, na przykład przy nietypowych widokach kamery. Minimalną wersję iOS ustalamy na podstawie urządzeń Twoich użytkowników. Apple wymaga budowania aplikacji w aktualnym Xcode, więc pilnujemy tych terminów za Ciebie.
Architektura
Kod dzielimy na moduły Swift Package Manager, operacje asynchroniczne piszemy z async/await, a dane lokalne przechowujemy w SwiftData albo Core Data. Logikę oddzielamy od widoków, żeby dało się ją testować bez uruchamiania interfejsu.
CI/CD i wydania
Każda zmiana uruchamia automatyczną budowę i testy, a wersje testowe dostajesz przez TestFlight. Certyfikaty i profile podpisywania są na Twoim koncie Apple Developer, nie na naszym, więc aplikacja jest publikowana w App Store na Twoim koncie.
Testy
Logikę testujemy w XCTest, ścieżki krytyczne testami interfejsu, a przed wysłaniem do App Review sprawdzamy aplikację na fizycznych urządzeniach Apple - także w trybie ciemnym i z powiększoną czcionką.
Aplikacje na iOS, które zbudowaliśmy
Na iOS budujemy natywnie w Swifcie (IT-Renhold) albo we Flutterze, gdy aplikacja powstaje równolegle na Androida (aplikacja dla hotelu, Germania Mint).
IT-Renhold: natywne aplikacje na iOS i Androida dla klientów i pracowników firmy sprzątającej w Norwegii. Aplikacja dla hotelu: rezerwacje, room service, zdalny check-in i check-out, czat z obsługą. Germania Mint: weryfikacja produktów przez NFC przy odbiorze przez kuriera.
Dlaczego możesz nam zlecić aplikację na iOS
Od 2010 roku na rynku, ponad 300 zrealizowanych projektów
Aplikacje na iOS w Swifcie i we Flutterze - od projektu po publikację w App Store
Backend w Laravelu, w którym powstała większość naszych realizacji
Konto Apple Developer, certyfikaty i kod zostają u Ciebie
Najczęściej zadawane pytania o aplikacje w Swifcie
Zaktualizowano: