Programowanie międzyplatformowe
Problemy klienta
Z czym przychodzą do nas klienci
Firmy często zwracają się do firm zajmujących się tworzeniem aplikacji międzyplatformowych, gdy muszą ograniczyć duplikację między platformami mobilnymi, zsynchronizować wydania lub określić, jaki zakres funkcjonalności powinien być współdzielony między systemami iOS i Android.
Funkcja może zostać zdefiniowana raz, ale wdrożona, sprawdzona i przetestowana osobno dla systemów iOS i Android. Nawet stosunkowo niewielkie zmiany w produkcie mogą zatem wymagać równoległej pracy w dwóch backlogach, dwóch procesach dostaw i dwóch implementacjach specyficznych dla danej platformy.
Funkcjonalności dostępne na jednej platformie mogą być niedostępne lub zachowywać się inaczej na innej. Odpowiedzi wsparcia są zależne od platformy, planowanie wydań staje się trudniejsze, a decyzje dotyczące produktu mogą zależeć od wersji zainstalowanej przez klienta.
Gdy dwa zespoły pracujące nad platformami pracują w różnym tempie, koordynacja wydania jednego produktu staje się bardziej złożona. Funkcje mogą wymagać odczekania na ukończenie i przetestowanie obu wdrożeń, zanim będą mogły być spójnie udostępniane na różnych platformach.
Zatrudnienie i utrzymanie oddzielnych zespołów iOS i Android może zwiększyć zapotrzebowanie na pracowników i stwarzać ryzyko przepustowości, szczególnie w mniejszych organizacjach inżynierskich. Podejście oparte na wspólnej bazie kodu może zmniejszyć liczbę pracowników wymaganych dla konkretnych platform w przypadku produktów, w których rozwój międzyplatformowy jest technicznie uzasadniony.
Zespoły mogą mieć wątpliwości, czy dostęp do sprzętu, przepływy pracy offline, przetwarzanie w tle, złożone animacje lub zestawy SDK innych firm mogą być skutecznie obsługiwane w ramach współdzielonej architektury. Wymagania te należy przeanalizować przed wyborem struktury i strategii współdzielenia kodu.
Przegląd usług
Pełny cykl rozwoju aplikacji wieloplatformowych – od architektury po długoterminowe wsparcie
Nasze usługi w zakresie tworzenia aplikacji wieloplatformowych mogą obejmować pełen zakres tworzenie aplikacji mobilnych Cykl życia, obejmujący architekturę, wdrożenie, testowanie, wydania sklepowe, migrację i ciągły rozwój funkcji. Zakres jest definiowany dla każdego projektu i może obejmować od nowego produktu mobilnego po konsolidację istniejących aplikacji na iOS i Androida.
Projektujemy i tworzymy aplikacje na iOS i Androida w oparciu o wspólną bazę kodu, z modułami specyficznymi dla danej platformy dodawanymi w razie potrzeby. Zakres prac może obejmować architekturę aplikacji, obsługę danych, funkcjonalność offline, interfejsy użytkownika oraz integrację z istniejącymi usługami zaplecza.
Możemy dokonać przeglądu istniejących repozytoriów iOS i Android, ocenić zależności i funkcjonalność specyficzną dla danej platformy oraz zdefiniować strategię migracji przyrostowej. Wybrane funkcjonalności można przenieść do współdzielonej implementacji, a istniejące aplikacje będą nadal obsługiwane w trakcie okresu przejściowego.
Definiujemy, która logika biznesowa, przetwarzanie danych, komponenty interfejsu użytkownika i inne funkcje mogą być współdzielone, a które powinny pozostać specyficzne dla danej platformy. Decyzja podejmowana jest na podstawie wymagań dotyczących urządzenia, oczekiwań dotyczących wydajności, istniejących umiejętności inżynierskich, integracji oraz konwencji platformy.
W przypadku gdy współdzielona infrastruktura nie zapewnia bezpośredniego dostępu do wymaganej funkcjonalności, można opracować moduły natywne lub specyficzne dla platformy, zapewniające dostęp do sprzętu, wykonywanie zadań w tle, dane biometryczne, zastrzeżone zestawy SDK i inne funkcje na poziomie urządzenia.
Możemy przygotowywać kompilacje, wspierać zgłoszenia do App Store i Google Play oraz zapewniać ciągłą pracę inżynieryjną w miarę rozwoju wersji systemu operacyjnego, struktur, zależności i wymagań produktu.
Problem i rozwiązanie
Problem
Utrzymywanie oddzielnych aplikacji natywnych może dublować logikę biznesową, nakłady testowania, koordynację wydań i prace konserwacyjne na platformach iOS i Android. Wraz z rozwojem produktów, funkcjonalność może się różnić między platformami, co utrudnia utrzymanie synchronizacji wydań i spójnych doświadczeń użytkowników.
Podejście Solbega
Definiujemy, które części produktu powinny być współdzielone, a które powinny pozostać specyficzne dla danej platformy. Logika biznesowa, przetwarzanie danych, komponenty interfejsu użytkownika, nawigacja i inne funkcje mogą być współdzielone, jeśli jest to technicznie uzasadnione, podczas gdy dostęp do sprzętu i specyficzne dla danej platformy zachowania pozostają w modułach natywnych. Testowanie obejmuje obie platformy w całym procesie rozwoju, co pozwala na identyfikację różnic przed wydaniem. Nasze usługi rozwoju wieloplatformowego mogą również obejmować skoordynowane tworzenie, wydanie i wsparcie po uruchomieniu dla obu platform.
Przypadków użycia
Kiedy wybrać tworzenie aplikacji mobilnych na wiele platform
Firmy zamawiają usługi tworzenia wieloplatformowych aplikacji mobilnych w różnych sytuacjach.
Utrzymywanie oddzielnych zespołów ds. konkretnych platform może być trudne do uzasadnienia, gdy produkt mobilny ma ograniczony zakres funkcji lub częstotliwość wydań. Podejście oparte na wspólnej bazie kodu może ograniczyć powielanie prac inżynieryjnych i konserwacyjnych tam, gdzie wymagania produktu to uzasadniają.
Umowa, kampania, partnerstwo lub premiera produktu mogą wymagać, aby wersje na iOS i Androida były dostępne w tym samym oknie wydania. Rozwój międzyplatformowy może uprościć koordynację, gdy większość funkcjonalności jest współdzielona.
Funkcje mogą pojawiać się na jednej platformie znacznie wcześniej niż na drugiej, co powoduje różnice w doświadczeniu użytkownika i wsparciu. Konsolidacja większej liczby funkcji w ramach wspólnej implementacji może pomóc w zapewnieniu parytetu funkcji.
Usługi terenowe, logistyka, magazynowanie, sprzedaż detaliczna i inne wewnętrzne aplikacje mogą być dobrymi kandydatami, gdy większość złożoności wynika ze współdzielonych przepływów pracy, a logika biznesowa i funkcjonalność specyficzna dla platformy są stosunkowo ograniczone.
Firma może potrzebować działających aplikacji na obu platformach mobilnych, aby przetestować popyt przed zainwestowaniem w głębszą optymalizację pod kątem konkretnej platformy. Rozwój międzyplatformowy może zapewnić praktyczny sposób weryfikacji produktu z udziałem rzeczywistej grupy odbiorców.
Wewnętrzny zespół może nie mieć już możliwości utrzymywania dwóch niezależnych natywnych stosów, podczas gdy produkt wciąż wymaga stałego wsparcia i rozwoju.
Aplikacje do zarządzania treścią, rezerwacjami, zarządzaniem kontami, transakcjami i podobne często w dużym stopniu opierają się na danych po stronie serwera i współdzielonych przepływach pracy. Produkty te mogą być dobrymi kandydatami do współdzielonej implementacji mobilnej, gdy wymagania specyficzne dla danej platformy są ograniczone.
Szczegółowy zakres prac
Co obejmuje tworzenie aplikacji wieloplatformowych
Projekt rozwoju aplikacji wieloplatformowej może obejmować poniższe strumienie prac. Dokładny skład zależy od produktu, istniejących systemów, wybranej struktury i uzgodnionego zakresu dostaw.
Inżynieria warstwy współdzielonej
Warstwa współdzielona może obejmować architekturę, nawigację, zarządzanie stanem, logikę biznesową, działanie w trybie offline i synchronizację, obsługę błędów i pamięć lokalną. Elementy te można ponownie wykorzystać w systemach iOS i Android.
Rozwój modułów per-systemowych
Można tworzyć moduły specyficzne dla platformy lub natywne dla funkcjonalności wymagających bezpośredniego dostępu do czujników, danych biometrycznych, zadań wykonywanych w tle, powiadomień push, zastrzeżonych zestawów SDK lub innych możliwości na poziomie systemu operacyjnego.
Implementacja interfejsu
Ekrany można wdrożyć, korzystając z ustalonego systemu projektowania, i dostosować do konwencji nawigacji, rozmiarów ekranu, typografii, ustawień dostępności i wzorców interakcji danej platformy.
Integracja API i warstwy danych
Praca może obejmować nawiązywanie połączeń z usługami zaplecza, przegląd umów API, uwierzytelnianie, buforowanie, obsługę błędów, synchronizację i zarządzanie żądaniami w przypadku niestabilnych lub niestabilnych warunków sieciowych.
QA
Testowanie może obejmować funkcjonalność, integracje, scenariusze regresji, obsługiwane wersje systemów operacyjnych oraz odpowiednie konfiguracje urządzeń. Urządzenia fizyczne, symulatory, emulatory oraz pokrycie urządzeń chmurą mogą być wykorzystywane zgodnie ze strategią testowania projektu.
Inżynieria wydania
Praca nad wydaniem może obejmować tworzenie potoków kompilacji, podpisywanie kodu, kompilacje dystrybucyjne dla testerów i recenzentów, przesyłanie do App Store i Google Play oraz konfigurację monitorowania awarii lub wydajności.
Konserwacja
Po wprowadzeniu produktu na rynek prace mogą obejmować aktualizacje zapewniające zgodność z nowymi wersjami systemu operacyjnego i infrastruktury, uaktualnienia zależności, rozwiązywanie usterek, poprawę wydajności i stopniowy rozwój funkcji.
Dlaczego Solbeg
Dlaczego warto współpracować z Solbeg w zakresie rozwoju wieloplatformowego
Solbeg łączy doświadczenie w zakresie rozwiązań wieloplatformowych i natywnych rozwiązań mobilnych, aby dostarczać aplikacje, które łączą wydajność programowania z wymaganiami specyficznymi dla danej platformy. Nasze zespoły zajmują się doborem frameworków, projektowaniem UI/UX, inżynierią, kontrolą jakości, integracją i ciągłym rozwojem w ramach jednego zakresu dostaw.
Wybór ram nie jest ustalany na podstawie tego, co nam się przytrafia
Solbeg współpracuje zarówno z Flutter, jak i React Native. Dzięki temu wybór frameworka może być oparty na wymaganiach interfejsu, istniejących umiejętnościach inżynierskich, architekturze produktu, oczekiwaniach dotyczących wydajności oraz zestawach SDK innych firm lub możliwościach platformy, których potrzebuje produkt, a nie na pojedynczej dostępnej technologii.
Umiejętności rodzime pozostają w firmie
Swift, Objective-C i Kotlin również stanowią część możliwości Solbeg w zakresie inżynierii mobilnej. Gdy wymagana jest funkcjonalność specyficzna dla danej platformy lub natywna integracja, prace te można wykonać w ramach tego samego partnerstwa technologicznego, bez konieczności angażowania oddzielnego dostawcy.
Zapewnienie jakości jest oddzielnym etapem realizacji
Za zapewnienie jakości odpowiadają dedykowani specjaliści ds. jakości, którzy mogą być prowadzeni równolegle z pracami rozwojowymi, a nie w całości wpleceni w prace wdrożeniowe. Testowanie na różnych urządzeniach, wersjach systemów operacyjnych, integracjach i przepływach użytkowników pomaga zidentyfikować problemy specyficzne dla platformy i parzystości przed udostępnieniem produktu w wersji produkcyjnej.
Projektowanie i inżynieria w jednym zakresie
Analiza wymagań, prototypowanie, projektowanie UI/UX, inżynieria i testowanie mogą być koordynowane w ramach jednego projektu. Pozwala to na weryfikację decyzji dotyczących interfejsu pod kątem ograniczeń technicznych, zanim ich późniejsza modyfikacja stanie się bardziej kosztowna.
Ugruntowany rekord dostaw
Solbeg zrealizował ponad 50 projektów mobilnych i zarządza zespołami wdrożeniowymi w Polsce, Indiach, Urugwaju i Stanach Zjednoczonych. To doświadczenie zapewnia praktyczny kontekst dla produktów mobilnych, które wymagają wieloplatformowej inżynierii, integracji, testowania, wsparcia wydań i ciągłego rozwoju.
Porównanie
Podejścia do rozwoju międzyplatformowego
Solbeg dysponuje zasobami inżynierskimi zarówno w zakresie Flutter, jak i React Native, dzięki czemu rekomendacje mogą opierać się na produkcie, a nie na pojedynczym dostępnym frameworku. Przy porównywaniu opcji szczególnie przydatne są trzy czynniki: wymagania dotyczące interfejsu, istniejący stos inżynieryjny klienta oraz zestawy SDK lub możliwości platformy, których potrzebuje produkt.
Flutter
Flutter doskonale sprawdzi się w przypadku produktów wymagających wysoce spójnego, dostosowanego interfejsu na różnych platformach, złożonych układów wizualnych lub wspólnego podejścia do renderowania dla systemów iOS i Android.
React Native
React Native może być dobrym wyborem dla organizacji specjalizujących się w językach JavaScript, TypeScript lub React oraz dla produktów, których aplikacje mobilne wykorzystują wspólne koncepcje, reguły walidacji, modele API lub praktyki inżynieryjne z istniejącym produktem internetowym.
Wspólne reguły, oddzielne interfejsy
To podejście może być odpowiednie dla produktów, które wymagają odrębnych natywnych interfejsów dla systemów iOS i Android, a jednocześnie współdzielą logikę domeny, sieć, pamięć masową, reguły synchronizacji lub kontrolę dostępu.
Flutter
Zespoły mogą potrzebować specjalistycznej wiedzy z zakresu języka Dart, podczas gdy nieobsługiwane możliwości platformy, zastrzeżone zestawy SDK lub specjalistyczne integracje sprzętowe mogą nadal wymagać natywnego programowania.
React Native
Wysoce spersonalizowane interfejsy, zestawy SDK specyficzne dla platformy i specjalistyczne funkcje urządzeń mogą wymagać dodatkowych prac natywnych. Podczas planowania architektury należy również uwzględnić jakość pakietów innych firm i długoterminową konserwację.
Wspólne reguły, oddzielne interfejsy
Nadal trzeba opracować, przetestować i utrzymać dwie warstwy interfejsu specyficzne dla danej platformy, a zespołowi potrzebna jest wiedza inżynieryjna w zakresie obu ekosystemów.
Flutter
Dużą część interfejsu użytkownika i logiki biznesowej można współdzielić między platformami, a aktualizacje struktury, zależności i kompatybilności systemu operacyjnego pozostają częścią bieżącej konserwacji.
React Native
Posiadanie wiedzy na temat React lub JavaScript może ograniczyć nakład pracy związany z wdrażaniem, a znaczną część logiki aplikacji i implementacji interfejsu użytkownika można współdzieli na różnych platformach.
Wspólne reguły, oddzielne interfejsy
Model ten pozwala ograniczyć powielanie współdzielonej logiki biznesowej, przy jednoczesnym zachowaniu w pełni natywnych interfejsów i wzorców interakcji charakterystycznych dla danej platformy.
Przetwarzanie
Jak Solbeg dostarcza aplikacje wieloplatformowe
Typowa współpraca z firmą zajmującą się tworzeniem aplikacji wieloplatformowych może przebiegać w pięciu etapach, których szczegółowość i kolejność dostosowują się do projektu, istniejącego produktu i modelu dostarczania.
-
odkrycie
Gromadzimy wymagania funkcjonalne, punkty integracji, obsługiwane urządzenia, ograniczenia platformy i istotne wymagania biznesowe. Jeśli problem dotyczy istniejącego produktu, możemy również przeanalizować repozytoria, zależności, analizy i znane defekty.
-
Definicja architektury i zakresu
Określamy, co powinno pozostać współdzielone, a co powinno być specyficzne dla danej platformy, ustalamy początkowy zakres wydania, wybieramy podejście techniczne i przygotowujemy wycenę na podstawie tego zakresu.
-
Konfiguracja i wdrażanie zespołu
Inżynierowie otrzymują dostęp do repozytoriów, środowisk, plików projektowych, dokumentacji zaplecza oraz narzędzi do współpracy. Procesy rozwoju, kompilacji, testowania i komunikacji są przygotowywane przed rozpoczęciem wdrożenia.
-
Iteracyjne dostarczanie i zapewnianie jakości
Rozwój może przebiegać stopniowo, a instalowalne kompilacje na systemy iOS i Android są udostępniane do wglądu w miarę rozwoju produktu. Testowanie może odbywać się przez cały okres dystrybucji, co pozwala na identyfikację problemów związanych z parzystością, integracją i specyfiką platformy przed wydaniem.
-
Wydanie i kontynuacja pracy
Możemy przygotować zgłoszenia do sklepu, wesprzeć proces recenzji, monitorować stabilność po wprowadzeniu produktu na rynek i kontynuować prace rozwojowe w oparciu o analizę produktu, ustalenia techniczne i plan działania klienta.
FAQ
Często zadawane pytania dotyczące rozwoju międzyplatformowego
Bierzemy pod uwagę wymagania dotyczące interfejsu, technologie inżynieryjne już wykorzystywane przez zespół klienta, oczekiwania dotyczące wydajności, funkcjonalność specyficzną dla danej platformy oraz pakiety SDK innych firm, które muszą zostać zintegrowane. Rekomendacja może zostać udokumentowana na etapie definiowania zakresu, aby klient mógł przeanalizować techniczne kompromisy przed rozpoczęciem implementacji.
Wydajność zależy od obciążenia aplikacji, złożoności interfejsu użytkownika, frameworka, integracji i wymagań specyficznych dla danej platformy. Wiele aplikacji biznesowych może osiągnąć odpowiednią wydajność dzięki architekturze wieloplatformowej, natomiast funkcje wymagające dużej mocy obliczeniowej, wrażliwe na opóźnienia, wymagające dużego obciążenia sprzętowego lub ściśle zależne od platformy mogą skorzystać z implementacji natywnej.
Tak. W zależności od istniejącej architektury, konsolidację można zaplanować stopniowo, zamiast wymagać jednorazowego, całkowitego przepisania. Możemy zidentyfikować, które komponenty są silnie zależne od interfejsów API platformy, a które funkcjonalności biznesowe lub warstwy danych można przenieść do wspólnej implementacji. Podejście do migracji można zaprojektować tak, aby zapewnić ciągłe wsparcie produktu podczas przejścia.
Możliwości te mogą być obsługiwane za pośrednictwem bibliotek frameworka lub implementowane za pomocą modułów natywnych, w przypadku których wymagany jest bezpośredni dostęp do platformy. Własne pakiety SDK, specjalistyczny sprzęt lub funkcjonalności nieobjęte wybranym frameworkiem można oszacować osobno podczas definiowania architektury i zakresu.
Tak, jeśli jest to częścią wymagań projektowych. Wzory nawigacji, elementy sterujące, typografia, gesty i inne konwencje różnią się między systemami iOS i Android i można je odpowiednio dostosować. Jeśli produkt wymaga celowo identycznego wyglądu na obu platformach, można to również zdefiniować na etapie projektowania produktu i interfejsu.
Trwałość frameworka i stabilność ekosystemu to czynniki brane pod uwagę podczas planowania architektury. Solbeg może zmniejszyć ryzyko zależności poprzez oddzielenie współdzielonej logiki biznesowej, integracji specyficznych dla platformy oraz komponentów zależnych od frameworka, o ile wybrana architektura obsługuje taką separację. Utrzymanie frameworka i zależności powinno być również uwzględnione w długoterminowym planie technicznym produktu.
Porównaj, jak każdy dostawca definiuje granicę między kodem współdzielonym a kodem specyficznym dla platformy, jak obsługiwane są aktualizacje frameworka i systemu operacyjnego po premierze, co obejmuje testowanie pokrycia urządzeń i systemów operacyjnych, jak dostarczane są natywne integracje oraz kto zarządza zgłoszeniami do sklepów. Warto również zrozumieć uzasadnienie wcześniejszych decyzji dotyczących architektury, zamiast porównywać wyłącznie listy frameworków. Obowiązki związane ze wsparciem, własnością i konserwacją powinny zostać wyjaśnione przed rozpoczęciem współpracy.