Aplikacje na telefon, zbudowane tak, aby logikę dało się zweryfikować bez telefonu.

Nie. Żadna z naszych aplikacji nie jest w App Store ani Google Play, i słusznie pytasz o to na początku. Co możemy pokazać: pięć celów aplikacji zdefiniowanych w tym samym projekcie, z czego cztery dla iPhone'a i jeden dla macOS, które kompilują się i instalują na symulatorze, plus pakiet logiki 160 weryfikacji, uruchamiany na żądanie na twoich oczach. Blokadą publikacji jest puste `DEVELOPMENT_TEAM` w konfiguracji projektu, czyli brak identyfikatora z Apple Developer Program. Na Macu istnieje poprawna tożsamość podpisywania, typu deweloperskiego — wystarcza do instalacji na własnym urządzeniu, nie do sklepu.

Z niczego, jeśli prosisz o dowód publikacji — nie mamy go i nie wymyślamy go. To, co możesz zweryfikować, to reszta łańcucha: kod, który się kompiluje, testy, które przechodzą, obecne pliki poufności, zadeklarowane uprawnienia, skonfigurowane ikony i wersje. Brakuje kroku: płatnego zapisania do programu Apple, dokonanego na firmę, która posiada aplikację. W projekcie klienta to konto należy do klienta i jest otwierane na początku, dokładnie po to, żeby to nie ono było krokiem, który zaskoczy kogoś na końcu.

To zależy od czujników. Jeśli aplikacja odczytuje ruch, zdrowie, Bluetooth albo kamerę w czasie rzeczywistym, to natywnie — te interfejsy należą do platformy i każda warstwa pośrednia dodaje opóźnienie oraz nowe sposoby awarii. Jeśli aplikacja to w zasadzie formularze, obliczenia i ekrany wyników, jeden kod obejmuje iOS, Android oraz przeglądarkę z jednego repozytorium. Mamy obie wersje w portfolio i wybieramy je z pisemnym uzasadnieniem, nie domyślnie.

Przez wspólny kod, tak: ten sam projekt Expo generuje build dla Androida, z ikoną adaptacyjną i monochromatyczną wersją wymaganą przez system, już skonfigurowanymi. Natywnego Androida, w Kotlinie, nie mamy w portfolio — jeśli projekt tego wymaga, mówimy to przed podpisaniem, nie po.

Przez to, że rdzeń nie zależy od ekranu. Pliki analizy kompilują się osobno, kompilatorem Swift, i uruchamiają się jako program na Macu. Obecny zestaw ma 160 sprawdzeń w 16 etapach i wykonuje się w kilka sekund. To, czego nie da się tak sprawdzić — jak czuje się wibracja, jak wygląda ekran na konkretnym telefonie, jak zachowują się słuchawki, gdy wypadają z jednego ucha — testuje się na urządzeniu i mówi się, co jest czym.

Tylko jeśli wyrazisz zgodę, typ po typie, na ekranie Apple, i tylko te zadeklarowane. W kodzie polityka jest jawna dla każdego rodzaju danych: niektóre zostają tylko na telefonie, inne są odczytywane z HealthKit, inne można zapisać z powrotem jako trening albo sesję relaksacyjną. Nie stawia się diagnozy, a dane nie trafiają do nas.

Zostają na telefonie. W referencyjnej aplikacji iOS z naszego portfolio nie ma żadnego wywołania sieciowego — wyszukiwanie `URLSession` w źródłach tego targetu zwraca zero wyników. Historia jest zapisywana w pliku lokalnym i można ją usunąć z aplikacji. Gdy projekt potrzebuje serwera, budujemy go, ale nie dodajemy go odruchowo.

Zaczyna się od sprawdzenia zgodności, nie od oferty: jaką wersję platformy targetuje, jakie ma zależności i które z nich są jeszcze utrzymywane, czy build odtwarza się na czystej maszynie, kto posiada konto deweloperskie i klucze. Są projekty, w których uczciwa odpowiedź brzmi, że przepisanie rdzenia kosztuje mniej niż jego utrzymanie.

Na macOS, tak, i z tego samego rdzenia: w naszym głównym repozytorium target macOS ponownie wykorzystuje piętnaście plików logiki z aplikacji na iPhone’a jako współdzielone źródła. Windows nie jest w portfolio.