Przeniesienie aplikacji na inne konto Google Play i App Store — jak zrobić to bez utraty użytkowników

Jak przenieść aplikację mobilną na konto firmy w Google Play i App Store, zachowując użytkowników, oceny i recenzje. Co przechodzi razem z aplikacją, a co nie, oraz pułapki po transferze: push, keychain, Firebase i Sign in with Apple.

Zespół Mobilesoft· Engineering team· 19 października 2026· 7 min czytania

Aplikacja jest w sklepie od lat, ma tysiące ocen i aktywnych użytkowników — tylko że wisi na koncie poprzedniego software house’u, freelancera albo spółki, której już nie ma w strukturze. Prędzej czy później trzeba ją przenieść na konto, które należy do Ciebie.

Dobra wiadomość: zarówno Google Play, jak i App Store pozwalają przenieść aplikację razem z użytkownikami, ocenami i recenzjami. Nikt nie musi niczego instalować od nowa. Zła wiadomość: sam transfer w konsoli to kilka kliknięć, ale wszystko, co dzieje się wokół niego — powiadomienia push, logowanie, linki, Firebase — potrafi po cichu przestać działać. Ten tekst opisuje, jak przeprowadzić przeniesienie aplikacji tak, żeby użytkownicy niczego nie zauważyli.

Najpierw: czy w ogóle da się przenieść aplikację?

Jedna zasada obowiązuje w obu sklepach: transfer inicjuje właściciel konta źródłowego. Ani Google, ani Apple nie przeniosą aplikacji na Twoją prośbę, jeśli nie masz dostępu do konta, na którym jest opublikowana. Dlatego pierwsze pytanie brzmi nie „jak”, tylko „kto kliknie”.

  • Masz dostęp administratora lub właściciela do konta źródłowego — możesz działać od razu.
  • Konto należy do poprzedniego wykonawcy, który współpracuje — potrzebujesz od niego jednej, konkretnej czynności: rozpoczęcia transferu na wskazane konto. Najlepiej poprosić o to pisemnie, z gotowymi danymi konta docelowego.
  • Konto należy do kogoś, z kim nie ma kontaktu — to inny scenariusz, opisany w tekście programista zniknął — co zrobić z aplikacją. Bez właściciela konta transferu nie będzie.

Przy okazji sprawdź umowę: przeniesienie aplikacji w sklepie nie przenosi praw autorskich do kodu. To osobna sprawa, którą warto uporządkować w tym samym kroku — pisaliśmy o niej w checkliście przekazania projektu po innym software housie.

Przygotuj konto docelowe

Zanim cokolwiek się wydarzy, konto docelowe musi być gotowe — i musi być firmowe, nie prywatne.

Google Play. Załóż konto organizacji w Play Console i przejdź weryfikację tożsamości oraz danych firmy. Konto musi być aktywne i w dobrej kondycji, a jeśli aplikacja ma płatności, skonfiguruj profil płatności, na który będą trafiać wypłaty. Konta organizacji nie mają wymogu zamkniętych testów przed pierwszą publikacją, który dotyczy nowych kont prywatnych.

App Store. Konto organizacji w Apple Developer Program wymaga numeru D-U-N-S dla firmy — jego uzyskanie potrafi zająć kilka dni, więc zacznij wcześnie. Osoba, która będzie Account Holderem, musi zaakceptować aktualne umowy w App Store Connect, a jeśli aplikacja jest płatna lub ma zakupy w aplikacji — także umowę Paid Apps z uzupełnionymi danymi bankowymi i podatkowymi. Niezaakceptowana umowa to najczęstszy powód, dla którego przycisk transferu jest nieaktywny.

Co przechodzi razem z aplikacją, a co nie

To najważniejsza tabela w tym tekście. Sklep przenosi „wizytówkę” aplikacji, ale nie przenosi usług, które są z nią powiązane poza sklepem.

Element Google Play App Store Użytkownicy, instalacje, możliwość aktualizacji przechodzą przechodzą Oceny i recenzje przechodzą przechodzą Identyfikator aplikacji (package name / bundle ID) bez zmian bez zmian Produkty w aplikacji i aktywne subskrypcje przechodzą przechodzą Klucz podpisujący aplikację przechodzi, jeśli aplikacja używa Play App Signing nie dotyczy — certyfikaty generuje nowe konto Historia sprzedaży i wypłaty sprzed transferu zostają na starym koncie zostają na starym koncie Projekt Firebase / Google Cloud, klucze API nie przechodzą nie przechodzą Klucz do powiadomień push (APNs) nie dotyczy nie przechodzi — jest przypisany do zespołu Buildy i testerzy TestFlight nie dotyczy nie przechodzą

Dokładne listy warunków i wyjątków obie firmy publikują w swojej dokumentacji i co jakiś czas je zmieniają — przed transferem przeczytaj aktualną wersję. Ale ogólny obraz jest stały: sklep przenosi aplikację, nie przenosi infrastruktury.

Pułapki po stronie iOS

Na iOS transfer zmienia zespół (Team ID), do którego należy aplikacja. Kilka mechanizmów jest do niego przywiązanych:

  • Powiadomienia push. Klucz APNs (plik .p8) należy do zespołu. Po transferze trzeba wygenerować nowy klucz na koncie docelowym i podmienić go na backendzie albo w Firebase Cloud Messaging. Najbezpieczniej przygotować to wcześniej, tak żeby w dniu transferu zmiana była jedną operacją.
  • Dane w pęku kluczy (keychain). Grupy dostępu do keychain są powiązane z prefiksem identyfikatora zespołu. Jeśli aplikacja trzyma tam tokeny logowania, po zmianie zespołu może ich nie odczytać — a użytkownik zobaczy ekran logowania. Nie zawsze tak się dzieje, ale trzeba to sprawdzić w kodzie i przetestować, zanim dowiedzą się o tym użytkownicy.
  • Universal Links. Plik apple-app-site-association na Twojej domenie zawiera identyfikator w formacie TEAMID.bundle.id. Dodaj wpis z nowym Team ID — najlepiej obok starego, na czas przejściowy.
  • Sign in with Apple. Identyfikatory użytkowników są przypisane do zespołu. Apple udostępnia proces migracji (tzw. transfer identifiers), który trzeba przeprowadzić w ograniczonym czasie po transferze — Apple podaje 60 dni. Jeśli go pominiesz, użytkownicy logujący się przez Apple trafią do backendu jako nowe konta.
  • App Groups, iCloud, rozszerzenia. Jeśli aplikacja dzieli dane z widgetem albo rozszerzeniem lub korzysta z kontenerów iCloud, sprawdź w dokumentacji Apple, jak te zasoby zachowują się przy transferze. To najczęstsze źródło niespodzianek w bardziej rozbudowanych aplikacjach.

Pułapki po stronie Androida

Na Androidzie transfer jest zwykle łagodniejszy, bo identyfikator aplikacji i klucz podpisujący (przy Play App Signing) zostają bez zmian. Problemy biorą się z usług wokół:

  • Firebase. Projekt Firebase nie jest częścią aplikacji w sklepie. Nie zakładaj nowego projektu — przenieś istniejący, dodając nowego właściciela w uprawnieniach projektu Google Cloud, a potem usuwając starego. Nowy projekt oznacza nowe tokeny powiadomień, utratę historii analityki i raportów awarii, a push do użytkowników, którzy nie zaktualizowali aplikacji, przestaje dochodzić.
  • Klucz przesyłania (upload key). Jeśli poprzedni wykonawca nie przekaże klucza przesyłania, nowy właściciel może poprosić w Play Console o jego reset. Klucz podpisujący aplikację zostaje u Google, więc użytkownicy niczego nie zauważą.
  • Klucze API ograniczone odciskiem certyfikatu. Mapy Google, logowanie przez Google i inne usługi często mają klucze ograniczone do nazwy pakietu i odcisku SHA-1. Odcisk klucza aplikacji się nie zmienia, ale klucze żyją w projekcie Google Cloud — który, jak wyżej, trzeba przenieść osobno.
  • Starsze aplikacje bez Play App Signing. Jeśli aplikacja nigdy nie przeszła na Play App Signing, klucz podpisujący jest plikiem na czyimś dysku. Bez niego żadnej aktualizacji nie wydasz, niezależnie od tego, na czyim koncie jest aplikacja. Upewnij się, że go masz, zanim zakończysz współpracę z poprzednim wykonawcą.

Plan przeniesienia krok po kroku

  1. Inwentaryzacja. Lista wszystkich usług powiązanych z aplikacją: Firebase, backend, push, logowanie społecznościowe, mapy, płatności, domeny. Przy każdej — na czyim koncie jest i czy przechodzi razem ze sklepem.
  2. Konto docelowe. Założone, zweryfikowane, z zaakceptowanymi umowami i profilem płatności.
  3. Zamrożenie wydań. Na czas transferu nie wysyłaj nowych wersji do recenzji. Wersja oczekująca na recenzję potrafi zablokować transfer.
  4. Przygotowanie zmian technicznych. Nowy klucz APNs gotowy do podmiany, nowy wpis w apple-app-site-association, plan migracji Sign in with Apple, sprawdzony kod korzystający z keychain.
  5. Transfer. Właściciel konta źródłowego inicjuje przeniesienie, podając identyfikator konta docelowego, a konto docelowe je akceptuje. W Google Play transfer jest dodatkowo weryfikowany przez Google i może potrwać kilka dni.
  6. Przeniesienie usług. Firebase, Google Cloud, klucze APNs, uprawnienia użytkowników w konsolach.
  7. Weryfikacja. Na produkcyjnej wersji aplikacji sprawdź: przychodzą powiadomienia? Użytkownik pozostaje zalogowany? Działają linki z maila i strony? Działają zakupy i odnawiają się subskrypcje?
  8. Pierwsze wydanie z nowego konta. Mała wersja techniczna, najlepiej z automatycznym procesem wydań skonfigurowanym od razu na nowe konto. Dopiero to wydanie potwierdza, że cały łańcuch działa.

Ile to trwa

Samo kliknięcie transferu to minuty, akceptacja i weryfikacja po stronie sklepów — zwykle od jednego do kilku dni. Realny czas wyznaczają przygotowania: numer D-U-N-S, weryfikacja konta Google, umowy w App Store Connect i odpowiedź poprzedniego wykonawcy. Przy aplikacji średniej wielkości, z Firebase, pushami i logowaniem, całość warto zaplanować na dwa–trzy tygodnie, z czego sam dzień transferu jest najkrótszą częścią.

Podsumowanie

Przeniesienie aplikacji na inne konto w Google Play i App Store zachowuje użytkowników, oceny i recenzje — pod warunkiem, że zadbasz o wszystko, czego sklep nie przenosi. Na iOS to przede wszystkim push, keychain, Universal Links i Sign in with Apple. Na Androidzie — Firebase, Google Cloud i klucz przesyłania. Najwięcej problemów nie bierze się z samego transferu, tylko z tego, że nikt wcześniej nie spisał, co jest z aplikacją powiązane.

Transfer kont to zwykle pierwszy etap przejęcia aplikacji mobilnej po innym wykonawcy — przeprowadzamy go razem z klientem i sprawdzamy, czy przekazane materiały są kompletne. Jeśli nie wiesz, w jakim stanie jest Twój projekt, zacznij od bezpłatnej analizy aplikacji: sprawdzimy konta, konfigurację i kod i powiemy, co trzeba zrobić przed przeniesieniem.