Ошибка itms-90035

Ответ 1

Я пробовал почти все решения на SO при отладке этого для приложения, которое я отправляю, и понял, что вы можете получить эту ошибку разными способами. Вот краткое изложение того, что обычно неправильно и как его исправить.

1) Вы не выбрали профиль Provisioning для распространения с действительным сертификатом для своих PROJECT и TARGETS. Убедитесь, что вы выбрали действительный профиль подготовки в настройках сборки для опции "Отпуск" и подтвердите на developer.apple.com, что ваш профиль Provisioning Profile по-прежнему действителен. (здесь: https://developer.apple.com/account/ios/profile/profileList.action)

2) Ваша идентификация подписи кода в настройках сборки является допустимой для распространения. Убедитесь, что вы выбрали тот, который действителен, и он выбран для опции "Отпуск".

3) Ваша схема (может быть найдена через Product → Scheme → Edit Scheme) для вашего типа исполнения должна быть "Release" для вашей конфигурации сборки. Если вы архивируете свое приложение для представления в App Store, убедитесь, что в этом окне у вас установлен "Release" для типа сборки архива.

4) У вас есть несколько сертификатов распространения в вашем доступе к цепочке ключей. Попробуйте удалить дубликаты сертификатов из вашей связки ключей, а затем попробуйте отправить еще раз.

5) Один из самых злых... у вас есть строка кода, которая начинается с "#!" в верхней части одного из ваших файлов, обычно ".sh" или ".py". Недавно Apple, похоже, требует, чтобы эти файлы подписывались кодом. Чувствуется как ошибка на их стороне, но для вашего представления просто удалите эту строку! Это также может произойти, если у вас есть файлы ".sh", кроме сборки script в вашем каталоге подкаталогов.

6) У вас есть дубликаты строк CODE_SIGN_IDENTITY в файле project.pbxproj. Они могут выглядеть так...

"CODE_SIGN_IDENTITY [sdk = iphoneos *]" = "Разработчик iPhone"; CODE_SIGN_IDENTITY = "Распределение iPhone";

Удалите одну из этих строк, и ваш файл должен иметь возможность правильно строить.

7) Обновите сертификаты и профили обеспечения в Xcode из своей учетной записи разработчика. Xcode → Настройки... выберите свою учетную запись → Просмотреть сведения → Нажмите кнопку обновления.

8) Подход на кухне: создайте новый проект и загрузите свои настройки с нуля. Восстановите свои сертификаты и профили подготовки. Никогда не весело, но это сработало для меня в нескольких безнадежных ситуациях.

Удачи!

Ответ 2

Кажется, что XCode, начиная с версии 10.0 (10A255), неправильно подписывает приложения с PRODUCT_NAME, содержащие умлауты, такие как ü (и, возможно, другие не-ASCII-символы - но мы не проверяли это). Это на macOS 10.13.6 (17G65) с APFS, что также может быть причиной.

Он действительно работал с той же версией macOS, что и APFS с более ранней версией XCode, но мы подозреваем, что это XCode.

В любом случае, исправление состоит в том, чтобы установить PRODUCT_NAME в строку без умлаутс...

Ответ 3

Проверено и проверено решение:

• Скопируйте как RNGrid.m, так и RNGrid.h в другое место
• Удалите оба RNGrid.m и RNGrid.h и перейдите в корзину
• Очистить и построить
• Добавьте файлы RNGrid.m и RNGrid.h обратно в проект и скопируйте его в папку назначения
• Очистить и построить

Это решение работает для меня, на который также можно ответить здесь: Почему у одного файла .o в моем проекте нет профиля Provisioning?

Ответ 4

У меня была та же проблема:

Мой проект - это клиент, который обращается к API с использованием нестандартного протокола Auth. Я реализовал библиотеку для этого протокола как отдельный проект и импортировал его как подпроект в клиентский. Оба проекта использовали AFNetworking как HTTP Client. Также клиент и библиотека используют другие не общие внешние библиотеки.

Эта схема хорошо работала до Xcode 6.3: все заявки на просмотр были приняты на всех этапах. После обновления до XCode 6.3.1 мои сообщения в iTunes, где были отклонены из-за неподписанных .o файлов AFNetworking lib. После повторения всех ответов без успеха я решил удалить подпроект. Я переместил все файлы библиотеки в проект клиента и удалил избыточные файлы AFNetworking. После этого приложение было одобрено в iTunes Connect:)

Он работал как временное решение. Вероятно, мне нужно будет использовать CocoaPods или Carthage, чтобы снова разделить приложение и lib.

Ответ 5

Проверьте, есть ли у вас файлы RNGridMenu.m или .h в разделе "Ресурсы копирования Bundle" в "Фазы сборки" вашей целевой страницы

Ответ 6

Я пробовал все решения, описанные в Stackoverflow. Я также попробовал все возможности, как сказал thebhanman в первом ответе, но не решил проблему.

Решение работало для меня: - [Загрузить с загрузчиком приложений]

Не делайте .ipa с дополнительным процессом, например с Terminal или Itunes и т.д. make.ipa с xcode в экспорт, и это сработало для меня.

Шаг 1: Перейдите в Продукт Архивное приложение в xcode

Шаг 2: выберите опцию экспорта

Шаг 3: - Выберите 1-й вариант // → Сохранить для развертывания iosappstore

Шаг 4: - Xcode сделает файл .ipa вашего приложения с папкой даты и времени.

Примечание. -. Сначала проверьте свое приложение. Если проверка выполнена успешно, попробуйте сделать это с помощью Application Loader.

Я надеюсь, что это будет полезно для некоторых в будущем. потому что я теряю 2 дня, чтобы решить эту проблему.

Ответ 7

У меня была эта проблема, когда я работал над проектом привязок для Xamarin.

Библиотека не будет связываться, поэтому я создал прокси-фреймворк, который вызывает нужный мне фреймворк.

Это была самодельная структура прокси, которая получала сообщение об ошибке ITMS-90035.

После нескольких часов возни я обнаружил несоответствие между платформой в файле IPA и фактическим содержимым моей прокси-платформы.

После бесчисленного очищения/перестройки проекта мне удалось решить проблему, удалив кэш Xamarin на Mac.

Он находится по адресу ~/Library/Caches/Xamarin.

После того, как я удалил папку Xamarin, я пересобрал свой проект привязок. Затем я смог загрузить свое приложение в TestFlight/AppStore.

Ответ 8

Для меня проблема была в том, что у меня был актив с не-ASCII символом в имени файла.

Ответ 9

У меня была та же проблема, это было связано с активом с не-ASCII символом в имени файла, как в другом ответе.

Я использовал эту команду, чтобы найти файлы, которые вызывали проблему:

LC_ALL=C find . -name '*[! -~]*'

Я нашел это в другом ответе в этом посте.

Надеюсь, это кому-нибудь поможет.