# TestFlight: jak przetestować aplikację na iPhone'a

> Testerzy wewnętrzni i zewnętrzni, beta review, publiczny link, buildy ważne 90 dni: TestFlight w prostych słowach, z listą do sprawdzenia przed wysyłką.

Oryginalna strona: [TestFlight: jak przetestować aplikację na iPhone'a](https://devoria.fr/pl/blog/testflight-testowanie-aplikacji-iphone)
Autor: [Mehdi Azizi](https://devoria.fr/pl/mehdi-azizi)
Publikacja: 2026-09-23
Ostatnia aktualizacja treści: 2026-10-09


## Czym jest TestFlight i do czego służy?

TestFlight to usługa Apple, która pozwala zainstalować twoją aplikację na prawdziwych iPhone'ach przed jej premierą w App Store. Wysyłasz build do App Store Connect, zapraszasz testerów, a oni instalują go przez aplikację TestFlight, darmową w App Store. Są dwa rodzaje testerów: wewnętrzni, do 100 członków twojego zespołu, bez przeglądu przez Apple, oraz zewnętrzni, do 10 000 osób, zapraszani mailem lub publicznym linkiem, po beta review twojego pierwszego buildu. Każdy build można testować przez 90 dni.

| Kryterium               | Testerzy wewnętrzni          | Testerzy zewnętrzni          |
| ----------------------- | ---------------------------- | ---------------------------- |
| Maksymalna liczba       | 100                          | 10 000                       |
| Dostęp do twojego konta | Tak, z przypisaną rolą       | Nie                          |
| Zaproszenie             | Dodanie do grupy wewnętrznej | Mail lub publiczny link      |
| Beta review Apple       | Brak                         | Przy pierwszym buildzie      |
| Dla kogo                | Ty, wspólnik, ktoś bliski    | Znajomi, pierwsi użytkownicy |

Żeby korzystać z TestFlight, potrzebujesz [płatnego konta Apple Developer](https://devoria.fr/pl/blog/konto-deweloperskie-apple-cena): [usługa nie jest dostępna na darmowym koncie](https://developer.apple.com/support/compare-memberships/). Cały ten poradnik zakłada, że masz takie konto w ramach standardowego programu: program Enterprise Apple nie daje dostępu do TestFlight.

W moich aplikacjach każdy build wysłany przez EAS Submit przechodzi przez TestFlight i mojego iPhone'a, zanim trafi do review. To tam znajduję problemy, których nie widać podczas developmentu.

## Wysyłanie buildu do TestFlight

Build to skompilowana i podpisana wersja twojej aplikacji: jeśli jest źle podpisana, Apple odrzuci ją przy wysyłce z błędem ITMS-90034. Żeby pojawiła się w TestFlight, musisz wysłać ją do App Store Connect. W Expo robisz to przez `eas build --platform ios`, a potem `eas submit --platform ios`, z wystarczająco świeżym obrazem buildu, żeby uniknąć ITMS-90725. [Według dokumentacji Expo](https://docs.expo.dev/submit/ios/) build pojawia się w TestFlight po przetworzeniu przez Apple, zwykle po 10-15 minutach. Wszystko to zrobisz z PC: poradnik [publikacja aplikacji iOS bez Maca](https://devoria.fr/pl/blog/publikacja-aplikacji-ios-bez-maca-expo-eas) opisuje cały proces.

Dwie rzeczy często blokują za pierwszym razem:

- **Numer buildu musi się zmieniać przy każdej wysyłce.** Apple odrzuca dwa buildy z tym samym numerem dla tej samej wersji. W EAS włącz automatyczną inkrementację i masz to z głowy.
- **Pytanie o szyfrowanie.** Dopóki nie odpowiesz na pytanie o użycie szyfrowania, build pozostaje zablokowany ze statusem brakującej zgodności. Możesz odpowiadać za każdym razem w App Store Connect albo zadeklarować to raz na zawsze w konfiguracji aplikacji.

## Testerzy wewnętrzni: twój zespół, bez czekania

Testerzy wewnętrzni to użytkownicy twojego konta App Store Connect z przypisaną rolą. [Apple pozwala na maksymalnie 100 takich osób](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview), a każda może [zainstalować aplikację na kilku urządzeniach](https://developer.apple.com/testflight/), maksymalnie 30.

Ich duża zaleta: brak beta review. Gdy tylko build skończy się przetwarzać, bez automatycznego błędu typu ITMS-90717, dodajesz go do grupy wewnętrznej i jest dostępny. To dobra grupa dla ciebie, wspólnika albo bliskiej osoby, której dajesz dostęp do konta.

Ich ograniczenie: trzeba ich dodać jako użytkowników twojego konta App Store Connect. To nie nadaje się dla obcych osób.

## Testerzy zewnętrzni i beta review

Testerzy zewnętrzni nie potrzebują żadnego dostępu do twojego konta. [Możesz zaprosić ich do 10 000](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview), mailem lub publicznym linkiem. To dobra grupa dla znajomych, pierwszych użytkowników, społeczności.

W zamian Apple sprawdza build, zanim im go udostępni. [Gdy dodajesz pierwszy build danej wersji do grupy zewnętrznej](https://developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers), trafia on do beta review. Kolejne buildy tej samej wersji nie zawsze wymagają pełnego przeglądu.

Przed wysyłką App Store Connect poprosi cię o informacje do testów:

- **opis bety**, który mówi testerom, na co mają zwrócić uwagę;
- **adres e-mail do feedbacku**;
- **twoje dane kontaktowe**, żeby Apple mogło się z tobą skontaktować.

> Beta review to nie review App Store. Build zaakceptowany w TestFlight wciąż może zostać odrzucony przy publikacji.

Beta review sprawdza, czy build przestrzega zasad, ale finalne review patrzy też na twoją stronę w sklepie, subskrypcje, teksty prawne i całe doświadczenie. Miej w głowie typowe powody odrzucenia, opisane w artykule [dlaczego Apple odrzuca aplikację](https://devoria.fr/pl/blog/odrzucenie-aplikacji-apple-prawdziwe-przypadki).

## Zapraszanie testerów publicznym linkiem

Publiczny link to najprostszy sposób, żeby dać aplikację do testów ludziom, których jeszcze nie znasz. Oto [instrukcja Apple](https://developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers), z nazwami z angielskiego interfejsu:

1. W App Store Connect otwórz swoją aplikację, a potem zakładkę **TestFlight**.
2. W sekcji **External Testing** wybierz grupę zewnętrzną.
3. Kliknij **Create Public Link**.
4. Wybierz **Open to Anyone**, żeby otworzyć link dla wszystkich, albo **Filter by Criteria**, żeby ograniczyć go do określonych urządzeń i wersji iOS.
5. Jeśli chcesz, ustaw limit testerów przez **Set Limit**.

Potem udostępniasz link, gdzie chcesz: wiadomość, social media, mail. Osoba instaluje aplikację TestFlight, otwiera link i akceptuje zaproszenie.

Dwie rzeczy, które warto wiedzieć, zanim rozpuścisz go szeroko:

- **Ustaw limit.** Jeśli link rozejdzie się bardziej, niż planowałeś, zachowasz kontrolę nad liczbą testerów.
- **Testerzy z publicznego linku są anonimowi.** App Store Connect pokazuje dla nich tylko datę instalacji, sesje i crashe. Jeśli chcesz wiedzieć, kto co testował, zapraszaj raczej mailem.

## Jak długo działa build w TestFlight?

[Build jest dostępny dla testerów przez 90 dni](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview). Potem wygasa i testerzy nie mogą go już otworzyć. Jeśli twoja beta trwa dłużej, po prostu wyślij nowy build przed terminem.

W praktyce będziesz wysyłać nowe buildy dużo częściej: przy każdej ważnej poprawce. Każdy nowy build dodany do grupy jest proponowany testerom, którzy pobierają go w aplikacji TestFlight.

## Zbieranie feedbacku od testerów

TestFlight ma wbudowany system feedbacku: [tester robi zrzut ekranu w twojej aplikacji, może go opisać i wysyła go do ciebie](https://developer.apple.com/testflight/). Jeśli aplikacja się wysypie, dostajesz raport crasha, a tester może dodać kontekst. Wszystko znajdziesz w App Store Connect.

To przydatne, ale nie wystarcza, żeby zrozumieć konkretny crash. W moich aplikacjach dodaję Sentry, który zgłasza błąd razem z winną linijką kodu, i PostHog, który pokazuje, gdzie użytkownicy rezygnują. Oba działają w buildzie TestFlight tak samo jak na produkcji.

## Testowanie subskrypcji w TestFlight

Jeśli twoja aplikacja sprzedaje subskrypcję, TestFlight to miejsce, gdzie sprawdzasz, czy naprawdę działa. [Zakupy zrobione w buildzie TestFlight przechodzą przez środowisko testowe Apple](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testing-subscriptions-and-in-app-purchases-in-testflight/): twoi testerzy nie płacą. Odnowienia są przyspieszone: każda subskrypcja odnawia się raz dziennie, maksymalnie sześć razy w tygodniu, niezależnie od jej faktycznego okresu.

Sprawdź przynajmniej, czy wyświetlane ceny są poprawne, czy zakup faktycznie odblokowuje aplikację i czy przycisk przywracania odnajduje subskrypcję po ponownej instalacji. Do zarządzania subskrypcjami w moich aplikacjach używam RevenueCat; cała konfiguracja, od produktów w App Store Connect po paywall, jest opisana na stronie [subskrypcje in-app iOS](https://devoria.fr/pl/expertise/subskrypcja-w-aplikacji-ios).

## Co musisz przetestować przed wysyłką do Apple

To lista, którą stosuję przed każdą wysyłką do review. Każdy punkt odpowiada jakiemuś powodowi odrzucenia albo crashowi, którego da się uniknąć.

### Pierwsze uruchomienie

- Usuń aplikację, zainstaluj ją ponownie z TestFlight, otwórz. Tak zrobi reviewer.
- Przejdź cały onboarding, niczego nie pomijając.
- Odmów każdego uprawnienia (powiadomienia, aparat, lokalizacja) i sprawdź, czy aplikacja dalej działa.

### Pieniądze

- Paywall pokazuje ceny, okres i linki do warunków korzystania oraz polityki prywatności.
- Zakup działa, przywracanie też.
- Wszystkie skonfigurowane produkty są widoczne dla reviewera: [guideline 2.1](https://developer.apple.com/app-store/review/guidelines/) wymaga, żeby zakupy w aplikacji były kompletne, widoczne i działające.

### Trudne warunki

- Tryb samolotowy i wolna sieć: jasny komunikat, a nie biały ekran.
- Najmniejszy i największy iPhone, który obsługujesz: nic uciętego, nic zasłoniętego przez klawiaturę. To ucięty ekran na małym iPhonie kosztował mnie odrzucenie Solys.
- Długie teksty, jeśli twoja aplikacja jest przetłumaczona.

### Materiały dla reviewera

- Jeśli aplikacja wymaga logowania, konto demo w notatkach do review, z włączonym backendem. Guideline 2.1 wprost tego wymaga.
- Notatki do review, które w dwóch zdaniach wyjaśniają, co robi aplikacja i gdzie znaleźć główną funkcję.

Jeśli mimo wszystko twoja aplikacja zostanie odrzucona, strona [aplikacja odrzucona przez Apple](https://devoria.fr/pl/expertise/aplikacja-odrzucona-przez-apple) wyjaśnia, jak odpowiedzieć bez tracenia tygodnia. A żeby zobaczyć całą publikację, od strony w sklepie po premierę, przeczytaj [publikacja aplikacji w App Store](https://devoria.fr/pl/expertise/publikacja-aplikacji-w-app-store).

## Arkusz testów do wypełnienia na twoim buildzie

[Pobierz arkusz z 16 scenariuszami w formacie CSV](https://devoria.fr/ressources/recette-premiere-app-ios.csv). Rozdziela przygotowanie, czynność do wykonania, oczekiwany wynik i zaobserwowany dowód. Zaimportuj go do Numbers, Excela albo Google Sheets, a potem uzupełnij wersję, urządzenie i wynik każdej próby.

W przypadku fikcyjnego dziennika czytania „zapisz stronę” nie wystarczy: zanotuj stronę 24, całkowicie zamknij aplikację, uruchom ją ponownie i sprawdź, czy wartość jest na miejscu. Test, który nie został wykonany, zostaje jako „Do przetestowania”. Jeśli twoja aplikacja nie ma żadnej subskrypcji, wpisz „Nie dotyczy” przy scenariuszach zakupu, podając ten powód.

Arkusz to punkt wyjścia do dopasowania, a nie certyfikat. Znajdziesz też [notatki App Review i inne darmowe szablony](https://devoria.fr/pl/resources), żeby wyjaśnić reviewerowi ścieżkę, którą faktycznie sprawdziłeś.

## Z TestFlight do App Store

TestFlight to etap, na którym twoja aplikacja staje się prawdziwa: działa na prawdziwym iPhonie, w rękach prawdziwych ludzi. W ścieżce [iOS Kit](https://devoria.fr/pl/kits/ios) to drugi etap: zbudować serce aplikacji i przetestować ją na swoim iPhonie przez TestFlight, zanim podłączysz subskrypcje i przygotujesz publikację.

Po TestFlight przychodzi review Apple: [Apple Review Kit](https://devoria.fr/pl/kits/review-apple) zawiera moją checklistę przed wysyłką i notatki dla testera. Strona główna pokazuje cztery etapy, żeby [stworzyć aplikację mobilną](https://devoria.fr/pl) z Claude Code.

Nikt nie zagwarantuje ci, że Apple zaakceptuje twoją aplikację: decyzja należy do Apple.

## Najczęściej zadawane pytania

### Jak przetestować aplikację na iPhone'a przez TestFlight?

Wyślij build do App Store Connect, a potem dodaj go do grupy testerów. W Expo kompilujesz go przez EAS Build i wysyłasz przez [EAS Submit](https://devoria.fr/pl/blog/eas-submit-ios-publikacja-aplikacji-expo-app-store): pojawia się w TestFlight po przetworzeniu przez Apple, według Expo zwykle po 10-15 minutach. Testerzy instalują go przez aplikację TestFlight, darmową w App Store. Potrzebujesz płatnego konta Apple Developer.

### Jak wygenerować link TestFlight, żeby zaprosić testerów?

W App Store Connect otwórz zakładkę TestFlight swojej aplikacji, wybierz grupę w sekcji External Testing i kliknij Create Public Link. Wybierz Open to Anyone albo Filter by Criteria, a potem ustaw limit przez Set Limit. Testerzy z publicznego linku pozostają anonimowi: jeśli chcesz wiedzieć, kto co testował, zapraszaj ich raczej mailem.

### Czy beta review w TestFlight zastępuje review App Store?

Nie. Beta review sprawdza, czy build przestrzega zasad, ale finalne review patrzy też na twoją stronę w sklepie, age rating, subskrypcje, teksty prawne i całe doświadczenie. Build zaakceptowany w TestFlight wciąż może więc zostać odrzucony przy publikacji. Beta review uruchamiają tylko testerzy zewnętrzni, przy pierwszym buildzie danej wersji: testerzy wewnętrzni nie przechodzą żadnego.

### Ilu testerów można zaprosić do TestFlight?

Możesz zaprosić do 100 testerów wewnętrznych i do 10 000 testerów zewnętrznych. Wewnętrzni to członkowie twojego konta App Store Connect, bez beta review, a każdy może zainstalować aplikację na maksymalnie 30 urządzeniach. Zewnętrznych zapraszasz mailem lub publicznym linkiem, po beta review pierwszego buildu. Każdy build można testować przez 90 dni.

### Czy można przetestować subskrypcję w TestFlight bez płacenia?

Tak, zakupy zrobione w buildzie TestFlight przechodzą przez środowisko testowe Apple: twoi testerzy nie płacą. Odnowienia są przyspieszone: każda subskrypcja odnawia się raz dziennie, maksymalnie sześć razy w tygodniu, niezależnie od jej faktycznego okresu. Sprawdź przynajmniej wyświetlane ceny, odblokowanie aplikacji i przywracanie po ponownej instalacji. Pełna konfiguracja jest opisana na stronie [subskrypcje in-app iOS](https://devoria.fr/pl/expertise/subskrypcja-w-aplikacji-ios).

### Co sprawdzić w TestFlight przed wysłaniem aplikacji do Apple?

Zainstaluj aplikację ponownie z TestFlight, tak jak zrobi to reviewer, i przejdź cały onboarding. Odmów każdego uprawnienia, przetestuj zakup i przywracanie, a potem sprawdź tryb samolotowy oraz najmniejszy i największy iPhone, który obsługujesz. Jeśli aplikacja wymaga logowania, przygotuj konto demo w notatkach do review, z włączonym backendem.


## Twój projekt

[Apple Review Kit](https://devoria.fr/pl/kits/review-apple): Checklista review App Store, której używam, moje poprawione odrzucenia od Apple, notatki dla recenzenta i dwa skille Claude Code, które sprawdzają twoją aplikację. 29 €.

[iOS Kit](https://devoria.fr/pl/kits/ios): Stwórz aplikację na iPhone'a z Claude Code: Starter Code moich aplikacji, skille sprawdzające jego pracę oraz Apple Review Kit, App Store Screenshots Kit i ASO Kit. 129,99 €.