Publikowanie aplikacji Flutter w Play Store i App Store: przewodnik krok po kroku

applicationId (Android) i Bundle ID (iOS) to trwała tożsamość Twojej aplikacji w każdym sklepie; żadnego z nich nie da się zmienić po pierwszym przesłaniu. Ustal oba przed rozpoczęciem publikacji — zmiana ich później oznacza otwarcie zupełnie nowego wpisu od zera, z utratą dotychczasowych recenzji i liczby instalacji.

W Flutterze numer wersji znajduje się w polu version: x.y.z+N pliku pubspec.yaml; x.y.z to wersja widoczna dla użytkownika, a N to numer builda, który odpowiada jednocześnie Android versionCode i iOS build number. Przesłanie bez zwiększenia N przy każdym nowym zgłoszeniu do sklepu kończy się odrzuceniem.

Wymagania dotyczące ikon różnią się między sklepami: Play chce ikony w wysokiej rozdzielczości 512x512 pikseli z kanałem alfa (przezroczystość), natomiast App Store oczekuje pliku PNG 1024x1024 pikseli BEZ kanału alfa. Za pomocą pakietu flutter_launcher_icons możesz wygenerować obie z jednego obrazu źródłowego jednym poleceniem.

Polecenie flutter build appbundle --release tworzy gotowy do publikacji pakiet w build/app/outputs/bundle/release/app-release.aab. Play Store akceptuje teraz przy nowych przesyłaniach wyłącznie format .aab; nie musisz tworzyć osobnego pliku .apk.

Osobiste (indywidualne) konta Play Console założone po 13 listopada 2023 r. muszą przed uzyskaniem dostępu produkcyjnego ukończyć nieprzerwany 14-dniowy test zamknięty z udziałem co najmniej 12 aktywnych testerów. Ten wymóg nie dotyczy kont organizacji ani kont osobistych założonych wcześniej; przed złożeniem wniosku sprawdź aktualny wymóg w Play Console, ponieważ zasada bywa zmieniana.

Zawsze PIERWSZY plik .aab przesłany do Play Console dla danej aplikacji musi zostać przesłany ręcznie — bez CLI czy automatycznego zgłoszenia; kolejne wydania mogą już korzystać z CLI lub własnej integracji. Przy przechodzeniu na produkcję rozpoczęcie od stopniowego wdrożenia (np. najpierw 5-20%, ze stopniowym zwiększaniem przy obserwacji Android vitals), zamiast wydania dla wszystkich naraz, zmniejsza ryzyko.

Polecenie flutter build ipa --release tworzy gotowy do wydania plik .ipa w katalogu build/ios/ipa/. Archiwizacja tego builda i wysłanie go do App Store Connect wymaga Maca (fizycznego lub w chmurze); Xcode nie działa w Windows ani Linuksie. Jeśli nie masz Maca, opcją są chmurowe usługi CI, takie jak Codemagic, macOS runnery GitHub Actions czy MacStadium.

Wynikowy plik .ipa możesz przesłać do App Store Connect zarówno poprzez przepływ Xcode Organizer (Window > Organizer > Archives > Distribute App), jak i samodzielną aplikację Transporter; oba dają ten sam efekt. Version (widoczna dla użytkownika) i build number (musi być unikalny i rosnący przy każdym przesłaniu, nie może być ponownie użyty w obrębie tej samej wersji) to dwa oddzielne pola.

TestFlight oferuje dwa poziomy testów: test wewnętrzny (do 100 osób w Twoim zespole App Store Connect) NIE wymaga weryfikacji Apple i jest dostępny, gdy tylko build zakończy przetwarzanie. Test zewnętrzny obejmuje testerów dołączających przez e-mail lub publiczny link (do 10 000 na grupę); PIERWSZY build dodany do aplikacji musi przejść weryfikację Apple „beta review" (zwykle kończy się w ciągu jednego dnia), natomiast kolejne buildy mogą nie wymagać już pełnej weryfikacji.

W Play limity znaków są ścisłe: nazwa aplikacji do 30, krótki opis do 80, pełny opis do 4000 znaków. W App Store Connect nazwa aplikacji musi być unikalna w całym sklepie, a dodatkowo trzeba wypełnić podtytuł i pole słów kluczowych. Rozmiary zrzutów ekranu (1080x1920 dla zrzutów telefonu w Play, dokładne dopasowanie pikseli dla klasy iPhone 6,9 cala w App Store) podlegają różnym zasadom w każdym sklepie.

Oba sklepy wymagają zadeklarowania sposobu zbierania danych: formularz Data safety w Play oraz etykiety App Privacy w App Store (czasem nazywane „etykietą wartości odżywczych"). Jeśli używasz SDK reklamowego, analityki lub raportowania awarii, musisz to dokładnie zaznaczyć w obu miejscach; żaden z paneli nie pozwoli opublikować aplikacji bez naprawdę dostępnego, aktualnego adresu URL polityki prywatności.

Oba panele wymagają też pola wsparcia/kontaktu: w Play jest to e-mail wsparcia na poziomie konta i opcjonalne pole strony internetowej; w App Store Connect obowiązkowy Support URL i opcjonalny Marketing URL. Jeśli nie masz strony internetowej na te pola, praktyczne opcje omawiamy w osobnym wpisie.

Najczęstsze odrzucenia przez Apple to: Wytyczna 2.1(a) (awarie, puste ekrany, uszkodzone linki, niezadeklarowane brakujące funkcje lub brak działającego konta demonstracyjnego w Review Notes dla funkcji wymagającej logowania), Wytyczna 5.1.1 (puste lub niejasne opisy użycia uprawnień) oraz Wytyczna 4.3 (aplikacje-szablony ponownie zgłaszane z drobnymi zmianami). Przetestowanie całego przepływu na czystym urządzeniu przed zgłoszeniem zapobiega większości tych trzech przypadków.

W Play najczęstszym problemem jest formularz Data safety niezgodny z faktycznym zachowaniem SDK albo pusty/niedostępny adres URL polityki prywatności; oba ryzykują odrzuceniem lub późniejszym zawieszeniem. Korzystanie z AdMob bez weryfikacji app-ads.txt nie powoduje bezpośredniego odrzucenia, ale może ograniczyć wyświetlanie reklam i kosztować Cię przychody.

W projektach korzystających z Expo (EAS) przebieg jest w dużej mierze zautomatyzowany: npx eas-cli build --platform all --profile production buduje w chmurze dla obu sklepów, a npx eas-cli submit automatyzuje zgłoszenie (poza wyjątkiem pierwszego przesłania w Play). Numery wersji znajdują się w trzech osobnych polach w app.json — expo.version, expo.ios.buildNumber i expo.android.versionCode — zamiast jednego pola pubspec.yaml jak we Flutterze, i trzeba je ręcznie synchronizować.