Profil nie jest zgodny z wartością pliku uprawnień dla uprawnienia z identyfikatorem aplikacji
92
Próbuję przesłać aplikację do sklepu z aplikacjami i pojawia się ten błąd na stronie z certyfikatami. O ile wiem, zmieniłem pole, więc są zgodne, ale czegoś mi brakuje.
Może dlatego, że nigdy wcześniej tego nie szukałem, ale jedyne listy, które widzę, mówią info, ale tutaj jest to, że jest to drugi obraz.
Paul Raymond
ona mówi, że nie można już dodawać linki, mam zamiar dostać się na samolot do Chicago, jeśli ktoś przychodzi z niczego
Paul Raymond
Odpowiedzi:
208
Nie jestem pewien, dlaczego to naprawiło, ale wszedłem do karty Możliwości mojego celu, włączyłem iCloud, próbowałem wykonać kompilację archiwum, nie udało się, ponownie wyłączyłem iCloud, próbowałem wykonać kompilację archiwum i udało się, i po tym czasie był w stanie ponownie automatycznie rozwiązać certyfikaty.
Nie wiem, dlaczego to zadziałało, ale zadziałało, wsparcie Apple było mniej pomocne.
Paul Raymond,
13
Dzięki za to - po włączeniu / wyłączeniu utworzył pusty plist .entitlements obok xcodeproj. Wygląda na to, że właśnie tego szuka proces przesyłania. Prawdopodobnie tylko problem w Xcode 9 dla istniejących aplikacji, które nie wymagają żadnych uprawnień / możliwości.
Andrew Wood
3
To samo tutaj. Starożytny projekt. Wielkie dzięki za sugestię zmiany możliwości, teraz jest pusty plik .entitlements, który jest akceptowany. Zgłaszanie błędu w Apple.
RickJansen
6
Dostałem lanie przez cały wieczór na tym bs. Musiałem włączać i wyłączać, co spowodowało utworzenie pustego pliku uprawnień, a następnie musiałem wskazać ustawienie kompilacji „Uprawnienia do podpisywania kodu” na ten pusty plik.
Adam Waite
2
W Xcode 10.0beta5 nadal tak się dzieje. U mnie było to spowodowane zmianą nazwy projektu po utworzeniu uprawnień. Włączenie i wyłączenie iCloud zmieniło nazwę pliku uprawnień i zaktualizowało jego nazwę w ustawieniach kompilacji. Zawartość pliku była identyczna. Wygląda na to, że przesyłający dba o nazwę pliku uprawnień niezależnie od nazwy pliku ustawień kompilacji.
Troy
42
Kliknij prawym przyciskiem myszy Finder -> Idź do folderu ...
~/Library/MobileDevice/Provisioning
Dla Xcode 11
~/Library/MobileDevice/Provisioning Profiles/
Usuń wszystkie profile obsługi administracyjnej, gotowe.
w moim przypadku folder to „~ / Library / MobileDevice / Provisioning Profiles”
LightMan
Zgadzam się, to poprawna odpowiedź, tylko z Xcode 11 ścieżka jest~/Library/MobileDevice/Provisioning Profiles/
Marius Kažemėkaitis
Dlaczego to rozwiązuje problem? Co właśnie usunęliśmy? Czy ma to jakieś skutki uboczne?
markdon
Usuwasz profile obsługi administracyjnej dodane automatycznie przez Xcode lub ręcznie, otwierając profil z developer.apple.com. Jeśli nie chcesz stracić innych profili, możesz użyć czegoś takiego jak ... grep -ir IDENTYFIKATOR_TWOJEJ_APLIKACJI ~ / Library / MobileDevice / Provisioning \ Profiles; Aby pokazać, które profile pasują. Po prostu je usuń, a wykona to samo zadanie.
Chris Douglass
To rozwiązuje problem, ale musisz najpierw przejść do Xcode i odznaczyć Automatycznie zarządzaj podpisywaniem, a następnie wykonaj powyższe czynności, a następnie ponownie sprawdź Automatyczne podpisywanie i wszystko jest w porządku. Naprawiłem to dla mnie. Zobacz pełny opis tutaj: ottorinobruni.com/…
c0d3p03t
33
Utworzona aplikacja ma niepoprawną application-identifierwartość, której oczekuje profil informacyjny. Certyfikat dla appID com.example.foo dla zespołu 2ABCDEFG będzie oczekiwał identyfikatora aplikacji: 2ABCDEFG.com.example.foo, Twoja aplikacja zadeklarowała, że jej appID to com.example.foo, ale identyfikator aplikacji nie pasuje , albo używasz niewłaściwego prefiksu zespołu, albo masz błędnie skonfigurowany identyfikator pakietu.
W moim przypadku używam schematów kompilacji, aby umożliwić mi zbudowanie aplikacji prod i aplikacji QA. com.example.foo w przypadku prod i com.example.foo.qa w przypadku kontroli jakości. Ustawiłem identyfikator bundleIdentifier w Info.plist na $ (PRODUCT_BUNDLE_IDENTIFIER) $ (BUNDLE_SUFFIX), który działa świetnie w symulatorze i na urządzeniu do posiadania różnych aplikacji, jednak gdy aplikacja generuje swój identyfikator aplikacji podczas fazy archiwizacji, nie może czytać bundleIdentifier wygenerowanego przez Info.plist.
Aby zaradzić tej sytuacji, zmodyfikowałem FooProject.xcodeproj / project.pbxproj (za pomocą edytora tekstu), aby zmienić ustawienia QA buildSettings PRODUCT_BUNDLE_IDENTIFIER na com.example.foo.qa
Możesz zapoznać się z technicznymi pytaniami i odpowiedziami firmy Apple, aby zobaczyć szczegółowe informacje na temat rozwiązania tego problemu. Po uruchomieniu uprawnień do kodu w wyeksportowanej aplikacji i sprawdzeniu, z jakim identyfikatorem aplikacji została właśnie zbudowana aplikacja, szybko zorientujesz się, co robisz źle.
https://developer.apple.com/library/content/qa/qa1879/_index.html
Nie znalazłem tej strony podczas wyszukiwania w Google, ponieważ w rzeczywistości nie używają oni frazy z komunikatu o błędzie ani nie wywołują aplikacji -identifier według pełnej nazwy, ale zamiast tego powiedz identyfikator aplikacji.
Ponadto rozwiązaniem tego problemu nie jest wygenerowanie nowego profilu aprowizacji, który ma uprawnienie do identyfikatora aplikacji, ale ma to uprawnienie, jednak wartość w profilu aprowizacji i aplikacja muszą być zgodne.
Dziękuję Ci! Udało mi się to naprawić, zmieniając ustawienia kompilacji w pakiecie, aby użyć mojej niestandardowej zmiennej jako sufiksu w identyfikatorze pakietu produktów. np. com.mycompany.myapp $ (BUNDLE_ID_SUFFIX) i to rozwiązało problem. Nie musiałem więc ręcznie edytować pliku projektu i mogłem łatwo zarządzać różnymi identyfikatorami pakietów dla każdego środowiska.
n8tr
Jednym z powodów, dla których może wystąpić niezgodność identyfikatora aplikacji, jest to, że nie masz wszystkich pobranych profili obsługi administracyjnej. Twoje archiwum jest tworzone z profilem wieloznacznym, jeśli brakuje profilu z dokładnym identyfikatorem aplikacji, co prowadzi do niezgodności w fazie eksportu.
diidu
To zadziałało dla mnie. Budowałem aplikację Ionic i zdałem sobie sprawę, że testowałem na innym koncie. Użyłem com.foo.testName i zmieniłem go z powrotem podczas budowania z poprawnym kontem. Wygląda na to, że com.foo.testName nadal znajdował się w pliku pbxproj
Dewald Els
Dziękuję bardzo, właśnie to blokowało moją weryfikację, a wyjaśnienie jest bardzo jasne!
MDH,
@ n8tr Po prawie tygodniu bólu głowy i frustracji Twój komentarz mnie uratował. Dzięki.
Behdad
9
Może brakowało pliku {project} .entitlements. Wykonanie tego, o czym wspomniał @samkass, spowoduje automatyczne wygenerowanie pliku i zadziała. Więc po prostu przejdź do zakładki możliwości, włącz cokolwiek i wyłącz to.
Oczywiście to byłoby rozwiązanie! Dlaczego nie pomyślałem o tej całkowicie nieoczywistej rzeczy, aby spróbować. Dzięki Apple.
Jonathan Plackett
3
W Xcode 11 może się to zdarzyć, gdy w projekcie nie ma pliku .entitlement. Rozwiązaniem byłoby dodanie dowolnej losowej możliwości poprzez kliknięcie „+ Możliwości” pod „Podpisywanie i możliwości” (co prowadzi do utworzenia pliku .entitlement), a następnie usunięcie tej możliwości. Umożliwi to również automatyczne udostępnienie certyfikatu.
W Xcode 10 uruchomiłem to, przenosząc plik uprawnień do odpowiedniego folderu w Nawigatorze projektu. Nie miałem pliku uprawnień, ale udało mi się go zdobyć, przełączając funkcje na karcie Możliwości.
W moim przypadku problem był następujący: profil zaopatrzeniowy używany do kroku kompilacji został utworzony dla innego identyfikatora aplikacji niż profil zaopatrzeniowy używany do kroku eksportu.
Upewnij się więc, że używasz tego samego profilu aprowizacji do etapu kompilacji i eksportu.
Ponieważ chciałem podkreślić, że ten błąd może wystąpić z powodu różnych profili aprowizacji na etapie kompilacji i eksportu. Komunikat o błędzie nie jest pomocny w znalezieniu głównej przyczyny w tym przypadku. Co do tego, dlaczego odpowiedź jest spóźniona - ten błąd nie jest związany z jakimś konkretnym okresem. Tak więc stało się to rok temu i teraz tak samo. Zaakceptowana odpowiedź nie zadziałała w moim przypadku.
Alexey Komov
1
Pomogło mi to, że zrobiłem archiwum w XCode 11 i załadowałem do niego Xcode 12 beta.
To bezpłatna aplikacja, a ja niczego nie włączyłem, a to jest po prostu frustrujące. Instaluje się dobrze na moim urządzeniu, po prostu nie wiem, gdzie szukać.
Paul Raymond,
czy możesz udostępnić zrzuty ekranu obu?
KavyaKavita
czego chcesz zrzut ekranu?
Paul Raymond,
zrzut ekranu sekcji możliwości i konfiguracji identyfikatora aplikacji na koncie programisty
KavyaKavita
0
Wypróbowałem kilka opcji wymienionych w odpowiedziach tutaj, ale żadna nie pomogła, jednak wyłączenie i włączenie pola wyboru „Automatycznie zarządzaj podpisywaniem” rozwiązało problem.
TL; DR: sprawdź swój identyfikator aplikacji i upewnij się, że usługi są zgodne z tym, co jest w celu.
Przydarzyło mi się to, że pozwoliłem Xcode 10.1 pomóc mi w utworzeniu identyfikatora aplikacji, a potem napotykam problem opisany tutaj. (Wybrałem identyfikator aplikacji whildcard podczas tworzenia aplikacji w iTunesConnect, więc nawet nie zdawałem sobie sprawy, że zostało to zrobione). Kiedy otworzyłem portal dla programistów iOS, nowy identyfikator aplikacji ma automatycznie włączone Game Center i In App Purchase.
Ponieważ nie mogłem włączyć Game Center w Twoim Target -> Capabilities, włączyłem zakup w aplikacji, a następnie moja aplikacja mogła zostać podpisana i przesłana.
Kiedy napotkaliśmy ten sam problem, próbowaliśmy wszystkich powyższych rzeczy, ale żadna z nich nie działała.
Udało nam się zmienić identyfikator pakietu tak, aby nie był identyczny z poprzednim, na przykład „com.name.App” na „com.name.App2”; niech xcode spróbuje pobrać / utworzyć profil informacyjny, a następnie zresetować go z powrotem do oryginalnego.
Trafiłem na tę stronę niedawno po próbie utworzenia zduplikowanego celu - żadna z sugestii nie zadziałała. Dalsze dochodzenie i trochę wyrywania włosów ostatecznie doprowadziły mnie do przejrzenia ustawień kompilacji mojej aplikacji, aby spróbować dowiedzieć się, co jest nie tak.
Okazało się, że mój projekt nadal wskazywał na plik uprawnień ORYGINALNEGO celu, zamiast mieć własny. Aby rozwiązać ten problem, przeszedłem do oryginalnego pliku uprawnień w Finderze (np. $ {SRCROOT} /MyProject/Entitlements/TargetName.entitlements ), utworzyłem kopię w tym samym folderze, a następnie zmieniłem jego nazwę (np. NewTargetName.entitlements).
Następnie otworzyłem nowy plik uprawnień i zmieniłem pole identyfikatora aplikacji, aby pasowało do końca identyfikatora pakietu mojego nowego celu (np. ABCDEFGH.US.co.fake-company.superduperapp-newtargetname ).
Na koniec zaktualizowałem pole „Uprawnienia do podpisywania kodu” w ustawieniach kompilacji na ścieżkę do mojego pliku uprawnień (dla mnie było to coś w rodzaju $ {SRCROOT} /MyProject/Entitlements/TargetName.entitlements ).
Wróciłem do zakładki Podpisywanie i możliwości i oto problem został rozwiązany. Mam nadzieję, że ktoś tam uzna to za przydatne.
Przejdź do zakładki Informacje Xcode i zmień pole Identyfikator pakietu - po zmianie nazwy aplikacji nie zmieniło się, mimo że zmieniłem Identyfikator pakietu na karcie Ogólne. Powyższe poprawki nie zadziałały dla mnie, ale ta zadziałała natychmiast.
Xcode miał włączoną opcję „Automatycznie zarządzaj podpisywaniem”. Jednak identyfikator zespołu wyświetlany w „Certyfikacie podpisywania” nie zgadzał się z identyfikatorem zespołu wyświetlanym w witrynie iTunes Connect. To była główna przyczyna uniemożliwiająca przesłanie aplikacji.
Jak to naprawiłem:
Utworzyłem ręcznie profil aprowizacji do dystrybucji w sklepie App Store
W Xcode kliknąłem „Pobierz profile ręczne” w Preferencjach -> Konto
Następnie wyłączyłem „Automatycznie zarządzaj podpisywaniem”.
Po wybraniu profilu obsługi administracyjnej z listy rozwijanej prawidłowy identyfikator zespołu pojawił się w sekcji „Certyfikat podpisywania”
Napotkałem ten sam problem podczas konfigurowania potoku Gitlab, który uruchamia exportArchive cmd i przesyłanie do AppStore. Udało mi się go uruchomić, zmieniając DEVELOPMENT_TEAM w ustawieniach kompilacji na ten sam zespół wybrany w Podpisywanie i certyfikaty.
Ponieważ poprzednio był pusty, który domyślnie używał innego identyfikatora DEV TEAM, który był niepoprawny i nie pasował, i narzekał, że „identyfikator aplikacji” = 12331232.com.bannana.apples.peach nie pasuje. Co doprowadziło mnie do ustawienia właściwego DEV TEAM i zadziałało.
Włączanie i wyłączanie iCloud nie było dla nas opcją. Używamy go już w produkcji i raczej nie zadzieramy z nim ... W pewnym momencie dostałem wiadomość z oryginalnego pytania i tę odmianę:
Profil nie jest zgodny z wartościami pliku uprawnień dla uprawnień dla identyfikatora aplikacji i grup dostępu do pęku kluczy.
Rozwiązanie
Wskazując na inne odpowiedzi tutaj, upewniliśmy się, że wszystkie cele będą miały .entitlementsplik. Gdyby cel nie miał żadnego, stworzyliśmy pusty, taki jak poniżej:
entitlements.plist
plik.Odpowiedzi:
Nie jestem pewien, dlaczego to naprawiło, ale wszedłem do karty Możliwości mojego celu, włączyłem iCloud, próbowałem wykonać kompilację archiwum, nie udało się, ponownie wyłączyłem iCloud, próbowałem wykonać kompilację archiwum i udało się, i po tym czasie był w stanie ponownie automatycznie rozwiązać certyfikaty.
źródło
Kliknij prawym przyciskiem myszy Finder -> Idź do folderu ...
~/Library/MobileDevice/Provisioning
Dla Xcode 11
~/Library/MobileDevice/Provisioning Profiles/
Usuń wszystkie profile obsługi administracyjnej, gotowe.
źródło
~/Library/MobileDevice/Provisioning Profiles/
Utworzona aplikacja ma niepoprawną
application-identifier
wartość, której oczekuje profil informacyjny. Certyfikat dla appID com.example.foo dla zespołu 2ABCDEFG będzie oczekiwał identyfikatora aplikacji: 2ABCDEFG.com.example.foo, Twoja aplikacja zadeklarowała, że jej appID to com.example.foo, ale identyfikator aplikacji nie pasuje , albo używasz niewłaściwego prefiksu zespołu, albo masz błędnie skonfigurowany identyfikator pakietu.W moim przypadku używam schematów kompilacji, aby umożliwić mi zbudowanie aplikacji prod i aplikacji QA. com.example.foo w przypadku prod i com.example.foo.qa w przypadku kontroli jakości. Ustawiłem identyfikator bundleIdentifier w Info.plist na $ (PRODUCT_BUNDLE_IDENTIFIER) $ (BUNDLE_SUFFIX), który działa świetnie w symulatorze i na urządzeniu do posiadania różnych aplikacji, jednak gdy aplikacja generuje swój identyfikator aplikacji podczas fazy archiwizacji, nie może czytać bundleIdentifier wygenerowanego przez Info.plist.
Aby zaradzić tej sytuacji, zmodyfikowałem FooProject.xcodeproj / project.pbxproj (za pomocą edytora tekstu), aby zmienić ustawienia QA buildSettings PRODUCT_BUNDLE_IDENTIFIER na com.example.foo.qa
Możesz zapoznać się z technicznymi pytaniami i odpowiedziami firmy Apple, aby zobaczyć szczegółowe informacje na temat rozwiązania tego problemu. Po uruchomieniu uprawnień do kodu w wyeksportowanej aplikacji i sprawdzeniu, z jakim identyfikatorem aplikacji została właśnie zbudowana aplikacja, szybko zorientujesz się, co robisz źle. https://developer.apple.com/library/content/qa/qa1879/_index.html Nie znalazłem tej strony podczas wyszukiwania w Google, ponieważ w rzeczywistości nie używają oni frazy z komunikatu o błędzie ani nie wywołują aplikacji -identifier według pełnej nazwy, ale zamiast tego powiedz identyfikator aplikacji.
Ponadto rozwiązaniem tego problemu nie jest wygenerowanie nowego profilu aprowizacji, który ma uprawnienie do identyfikatora aplikacji, ale ma to uprawnienie, jednak wartość w profilu aprowizacji i aplikacja muszą być zgodne.
źródło
Może brakowało pliku {project} .entitlements. Wykonanie tego, o czym wspomniał @samkass, spowoduje automatyczne wygenerowanie pliku i zadziała. Więc po prostu przejdź do zakładki możliwości, włącz cokolwiek i wyłącz to.
źródło
Zmiana przełącznika iCloud na włączony, budowanie i wyłączanie iCloud pozwoliło pozbyć się błędu mówiącego, że:
źródło
W Xcode 11 może się to zdarzyć, gdy w projekcie nie ma pliku .entitlement. Rozwiązaniem byłoby dodanie dowolnej losowej możliwości poprzez kliknięcie „+ Możliwości” pod „Podpisywanie i możliwości” (co prowadzi do utworzenia pliku .entitlement), a następnie usunięcie tej możliwości. Umożliwi to również automatyczne udostępnienie certyfikatu.
źródło
Sprawdź funkcje aplikacji, które są wymagane dla Twojej aplikacji, takie jak zakup aplikacji, powiadomienie push, dźwięk z aplikacji, zestaw Siri itp.
To jedyna przyczyna tego typu błędu.
Upewnij się, że w identyfikatorze aplikacji powyższe flagi powinny być włączone.
W większości przypadków dzieje się tak, gdy nie skonfigurowałeś powiadomień push, zakup w aplikacji w Twoim identyfikatorze aplikacji deweloperskiej.
źródło
Wszedłem do zakładki Możliwości celu, włączyłem udostępnianie pęku kluczy i zaczęło działać
źródło
Dla mnie był to trik
źródło
W Xcode 10 uruchomiłem to, przenosząc plik uprawnień do odpowiedniego folderu w Nawigatorze projektu. Nie miałem pliku uprawnień, ale udało mi się go zdobyć, przełączając funkcje na karcie Możliwości.
źródło
Otrzymałem ten sam błąd i żadne z powyższych rozwiązań nie rozwiązało problemu w moim przypadku.
W moim przypadku zadziałała zmiana ustawienia „Można debugować” w pliku „Entitlements.plist” z „NIE” na „TAK”.
źródło
W moim przypadku problem był następujący: profil zaopatrzeniowy używany do kroku kompilacji został utworzony dla innego identyfikatora aplikacji niż profil zaopatrzeniowy używany do kroku eksportu.
Upewnij się więc, że używasz tego samego profilu aprowizacji do etapu kompilacji i eksportu.
źródło
Pomogło mi to, że zrobiłem archiwum w XCode 11 i załadowałem do niego Xcode 12 beta.
źródło
Funkcje sprawdzania krzyżowego w aplikacji z opcjami włączonymi dla identyfikatora aplikacji na koncie programisty.
źródło
Wypróbowałem kilka opcji wymienionych w odpowiedziach tutaj, ale żadna nie pomogła, jednak wyłączenie i włączenie pola wyboru „Automatycznie zarządzaj podpisywaniem” rozwiązało problem.
źródło
TL; DR: sprawdź swój identyfikator aplikacji i upewnij się, że usługi są zgodne z tym, co jest w celu.
Przydarzyło mi się to, że pozwoliłem Xcode 10.1 pomóc mi w utworzeniu identyfikatora aplikacji, a potem napotykam problem opisany tutaj. (Wybrałem identyfikator aplikacji whildcard podczas tworzenia aplikacji w iTunesConnect, więc nawet nie zdawałem sobie sprawy, że zostało to zrobione). Kiedy otworzyłem portal dla programistów iOS, nowy identyfikator aplikacji ma automatycznie włączone Game Center i In App Purchase.
Ponieważ nie mogłem włączyć Game Center w Twoim
Target -> Capabilities
, włączyłem zakup w aplikacji, a następnie moja aplikacja mogła zostać podpisana i przesłana.źródło
Kiedy napotkaliśmy ten sam problem, próbowaliśmy wszystkich powyższych rzeczy, ale żadna z nich nie działała.
Udało nam się zmienić identyfikator pakietu tak, aby nie był identyczny z poprzednim, na przykład „com.name.App” na „com.name.App2”; niech xcode spróbuje pobrać / utworzyć profil informacyjny, a następnie zresetować go z powrotem do oryginalnego.
Pomysł wziąłem z tego wątku na forach programistów Apple - https://forums.developer.apple.com/thread/114539
źródło
Trafiłem na tę stronę niedawno po próbie utworzenia zduplikowanego celu - żadna z sugestii nie zadziałała. Dalsze dochodzenie i trochę wyrywania włosów ostatecznie doprowadziły mnie do przejrzenia ustawień kompilacji mojej aplikacji, aby spróbować dowiedzieć się, co jest nie tak.
Okazało się, że mój projekt nadal wskazywał na plik uprawnień ORYGINALNEGO celu, zamiast mieć własny. Aby rozwiązać ten problem, przeszedłem do oryginalnego pliku uprawnień w Finderze (np. $ {SRCROOT} /MyProject/Entitlements/TargetName.entitlements ), utworzyłem kopię w tym samym folderze, a następnie zmieniłem jego nazwę (np. NewTargetName.entitlements).
Następnie otworzyłem nowy plik uprawnień i zmieniłem pole identyfikatora aplikacji, aby pasowało do końca identyfikatora pakietu mojego nowego celu (np. ABCDEFGH.US.co.fake-company.superduperapp-newtargetname ).
Na koniec zaktualizowałem pole „Uprawnienia do podpisywania kodu” w ustawieniach kompilacji na ścieżkę do mojego pliku uprawnień (dla mnie było to coś w rodzaju $ {SRCROOT} /MyProject/Entitlements/TargetName.entitlements ).
Wróciłem do zakładki Podpisywanie i możliwości i oto problem został rozwiązany. Mam nadzieję, że ktoś tam uzna to za przydatne.
źródło
Przejdź do zakładki Informacje Xcode i zmień pole Identyfikator pakietu - po zmianie nazwy aplikacji nie zmieniło się, mimo że zmieniłem Identyfikator pakietu na karcie Ogólne. Powyższe poprawki nie zadziałały dla mnie, ale ta zadziałała natychmiast.
źródło
Miałem ten problem z zupełnie nową aplikacją, w Xcode 12 beta 3 ( zgłoszenia aplikacji rozpoczęły się dzisiaj ).
Xcode miał włączoną opcję „Automatycznie zarządzaj podpisywaniem”. Jednak identyfikator zespołu wyświetlany w „Certyfikacie podpisywania” nie zgadzał się z identyfikatorem zespołu wyświetlanym w witrynie iTunes Connect. To była główna przyczyna uniemożliwiająca przesłanie aplikacji.
Jak to naprawiłem:
źródło
Napotkałem ten sam problem podczas konfigurowania potoku Gitlab, który uruchamia exportArchive cmd i przesyłanie do AppStore. Udało mi się go uruchomić, zmieniając DEVELOPMENT_TEAM w ustawieniach kompilacji na ten sam zespół wybrany w Podpisywanie i certyfikaty.
Ponieważ poprzednio był pusty, który domyślnie używał innego identyfikatora DEV TEAM, który był niepoprawny i nie pasował, i narzekał, że „identyfikator aplikacji” = 12331232.com.bannana.apples.peach nie pasuje. Co doprowadziło mnie do ustawienia właściwego DEV TEAM i zadziałało.
Xcode ver: wersja 11.3.1
Mam nadzieję, że to komuś pomoże.
źródło
Nasza konfiguracja
Wiele celów:
... i użyj iCloud.
Włączanie i wyłączanie iCloud nie było dla nas opcją. Używamy go już w produkcji i raczej nie zadzieramy z nim ... W pewnym momencie dostałem wiadomość z oryginalnego pytania i tę odmianę:
Rozwiązanie
Wskazując na inne odpowiedzi tutaj, upewniliśmy się, że wszystkie cele będą miały
.entitlements
plik. Gdyby cel nie miał żadnego, stworzyliśmy pusty, taki jak poniżej:<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict/> </plist>
... i wskazał, że to cel
Code Signing Entitlement
wBuild Settings
do pustego.entitlements
pliku.Rozwiązany!
źródło
Usuń wszystkie profile znajdujące się w
~/Library/MobileDevice/Provisioning Profiles/
źródło