Подтвердить что ты не робот

Недопустимое двоичное приложение для iPhone

Я пытаюсь загрузить приложение в iPhone App Store, но я получаю это сообщение об ошибке из iTunes Connect:

Выбранный двоичный файл недействителен. Подпись была недействительной или не была подписана с сертификатом подачи Apple.


Примечание. Детали исходного вопроса были удалены, так как эта страница превратилась в репозиторий для всей информации о возможных причинах этого конкретного сообщения об ошибке.

Общие сведения о представлении приложений iPhone в App Store см. в разделе Шаги по загрузке приложения iPhone в AppStore.

4b9b3361

Ответ 1

По моему опыту, Xcode иногда путается о том, какой сертификат подписи использовать. У меня появилась привычка уходить и перезапускать Xcode после любого изменения настроек подписи кода (и создания чистой сборки), чтобы обойти эту проблему.

Ответ 2

Я просто хотел упомянуть, что у меня тоже была проблема с zip из команды . Проблема заключается в том, как по умолчанию она обрабатывает символические ссылки. Использование:

zip -y -r myapp.zip myapp.app

Решена эта проблема.

Ответ 3

У меня была такая же проблема, и я решил ее так:

Сертификаты свойств были установлены на моей машине разработки, а mobileprovision.embedded был включен в архив распространения. По прошествии часа или около того в Google Googling и рытье я нашел источник ошибки. Внутри Xcode я скопировал конфигурацию Release и создал новую конфигурацию дистрибутива, а затем изменил идентификатор подписи на свой сертификат распространения. Однако, хотя он был обновлен в графическом интерфейсе, файл проекта не был правильно обновлен.

Если вы столкнулись с той же ошибкой, загляните в каталог [ProjectName].xcodeproj для файла project.pbxproj и откройте его в своем любимом редакторе. Найдите раздел "Распространение". Мой сломанный выглядит так:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: Edward McCreary";
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = "iPhone Developer: Edward McCreary";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: Edward McCreary";
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = "DB12BCA7-FE72-42CA-9C2B-612F76619788″;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};

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

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: Edward McCreary";
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = "iPhone Distribution: Edward McCreary";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: Edward McCreary";
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = "F00D3778-32B2-4550-9FCE-1A4090344400″;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};

изменено для защиты невинных

Ответ 4

Такая же проблема, другое решение.

В моем случае я сжимал файл, используя zip -r myapp.zip myapp.app Оказывается, команда zip ввернула узел. Сжатие его от искателя заставило его работать.

Ответ 5

У меня была такая же проблема, и после нескольких попыток я удалил права .plist из прав на подписание кода (просто оставил его пустым), и он был создан нормально и загружен НАКОНЕЦ.

Удачи всем:-D

Ответ 6

У меня была такая же проблема, но при создании я заметил, что в сборке не было добавлено обеспечение.

Исправление для меня состояло в том, чтобы установить сборку на iphone-устройство, где я обычно использую симулятор, но тогда он не будет включать профиль подготовки...

Это может быть ошибка noob. Обычно вы не можете подключиться к устройству, но когда вы это сделаете для распространения, вы можете.

Ответ 7

Еще одна точка данных: какое-то время мое приложение прошло. Теперь я добавил поддержку покупок в приложении, и внезапно он завершился с ошибкой "Недопустимая двоичная/недействительная подпись". После тщательного изучения, я узнал, что значение идентификатора приложения в файле plients разрешено.

Это, скорее всего, связано с тем фактом, что я заменил профиль обеспечения с подстановочного на конкретный для приложения (необходимый для покупок в приложении). Неверный идентификатор приложения, присвоенный по старому профилю. Он не соответствовал идентификатору приложения в info.plist, но, по-видимому, iTunes прощал это.

Итак, чтобы повторить:

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*

в порядке, а

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo

вызывает "Недействительный двоичный файл".

Ответ 8

Хорошо, повторив шаги несколько раз, я, наконец, успешно загрузил свое приложение.

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

Ответ 9

Здесь проблема, с которой я столкнулся: я добавил двоичный файл Subversion перед загрузкой. Сравнивая/застегивая двоичный файл, затем включали скрытые каталоги .svn, которые испортили подписание кода.

Ответ 10

Я пробовал разные вещи после прочтения различных сообщений, в том числе выше. Что, наконец, сработало для меня, началось полностью! Я удалил каждый сертификат и профиль профилей, связанные с моим приложением.

Я воссоздал новый сертификат разработки и новый сертификат распространения. Я снова загрузил промежуточный сертификат. Затем я воссоздал как профиль разработки, так и профиль распространения.

После установки трех сертификатов (я заметил, что на этот раз у дистрибутива были как закрытые, так и открытые ключи) и два профиля подготовки (мой профиль распространения не был отмечен как не имеющий действительного сертификата!), все сработало.

Как только я принял решение отозвать все и только начал, для создания нового материала и его повторной установки потребовалось всего 5 минут.

Ответ 11

Посмотрите эту ссылку для решения:

http://greghaygood.com/2010/09/04/invalid-binary-message-from-itunesconnect

Короткий ответ: "В итоге я дважды проверил свой info.plist и обнаружил что-то. Я добавил CFBundleIconFiles в соответствии с новыми рекомендациями, но в списке массивов была пустая запись. Я удалил это и повторно отправил, и это было наконец принято!"

Ответ 12

У меня была аналогичная проблема, но в Monotouch. Я обнаружил, что мой профиль выпуска настроен на использование сертификатов разработчика. Он должен выглядеть так: enter image description here

Ответ 13

Кажется, эта проблема имеет много причин. Здесь мое решение:

Это относится ко всем, кто принадлежит нескольким группам разработчиков (например, вашим собственным приложениям и вашим компаниям).

Если вы создаете сборку с одним набором учетных данных и повторно подписываете ее с другим (например, для распространения adhoc/appstore), вы должны убедиться, что сборка была изначально построена и подписана с учетными данными, принадлежащими та же команда разработчиков iOS, что учетные данные для распространения, которые вы переписываете, принадлежат.

Поэтому не создавайте учетные данные "Indy Dev Inc", затем попробуйте развернуть с учетными данными "Company Inc". Убедитесь, что вы установили оба разработчика "Company Inc", а также учетные данные распространения и используете их.

Я разместил дополнительную информацию об этом в своем блоге: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/

Ответ 14

У меня была та же проблема. Я был готов бросить полотенце на эту проблему, но я понял это, когда я пошел проверять свой код с помощью Murky. Я всегда просматриваю diff на файлах, которые были изменены до того, как я зарегистрировался. В этом случае я заметил, что файл project.pbxproj изменился.... и в разделе "Распространение" запись для "PROVISIONING_PROFILE [sdk = iphoneos *])" было пусто.

Завершение и перезапуск Xcode не помогло мне. Вместо этого я включил оба моих проекта и целевые настройки и изменил подписание кода, чтобы напрямую выбрать профиль распространения, а не полагаться на функцию автоматического выбора. Это привело к тому, что файл project.pbxproj заполнил правильные значения, даже если функция автоматического выбора предположительно выбрала тот же самый профиль, который я выбрал вручную.

Мне нужно пиво...

Ответ 15

После проверки всех остальных исправлений, перечисленных здесь, мы зарегистрировали TSI с Apple. Следуя всем шагам в Техническая нота TN2250, наша проблема возникла из-за отсутствия или отсутствия закрытого ресурса. В нашем случае это было ._.DS_Store.

".." называется файлом Apple Double и является результатом копирования папки проекта Xcode Project, * unzipped *, на и обратно из файловой системы, которая не поддерживает HFS + "вилки ресурсов" (используется для подписи кода). Эти дополнительные файлы ".." приводят к потере подтверждения подписи кода.

Чтобы очистить проблемные файлы Apple Double от папки проекта Xcode, запустите команду dot_clean в папке проекта Xcode, выполните чистую сборку, а затем закрепите ее и повторите попытку.

dot_clean /the/path/to/xcode/project

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

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

Ответ 16

У меня была аналогичная проблема, но я не использую права .plist. Однако после дюжины неудачных загрузок я проверил свой info.plist и обнаружил что-то. Мой массив CFBundleIconFiles имел пустую запись. Я удалил это и повторно представил, и он был наконец принят!

Серьезно, насколько сложно было бы Apple опубликовать такие ошибки проверки?

Изменить: это не сразу apparant, где CFBundleIconFiles - это потому, что они используют другое имя. В представлении информации о проекте нажмите Ctl и выберите "Show Raw Keys/Values", а затем вы увидите ссылки на CFBundleWhatever. В этом случае редактора он пытался использовать несуществующий файл [email protected]

Ответ 17

Устранено это, очистив файл myProject.xcodeproj(щелкните правой кнопкой мыши, откройте пакет), пакет содержит файлы от со-разработчика, после удаления этих проблем была решена

Ответ 19

Я получил недействительный двоичный файл, если приложение не использует удаленное push-уведомление, но я оставил код для регистрации push и делегатов callback для регистрации/получения удаленного уведомления без комментариев, даже если код не используется.

Это последнее. Мое последнее представление на прошлой неделе было прекрасным. На этой неделе он возвращает недействительный двоичный файл. К счастью, есть сообщение, объясняющее ошибку.

Ответ 20

Для чего это стоит, я хочу добавить, что это, что исправил эту проблему для меня. У меня есть? (вопросительный знак) в названии моего приложения, которое вызывало ошибку.

Ответ 21

У нас была эта проблема сегодня, но ответы здесь не помогли. Я, наконец, нашел проблему.

Удостоверьтесь, что используется выпадающее меню: Проект > Изменить Active Target "Имя_проекта" для изменения Подписи кодов к распределению. Я выбрал проект в панели "Группы и файлы" и с помощью кнопки "Информация", которая показывает ПРОЕКТ, а не TARGET - очень запутанная! Только понял, когда я выключил код в проекте и построил его, и он все еще хочет ввести код!

Я думаю, именно поэтому в постели Эдди он должен был изменить его на уровне project.pbxproj

Также на оригинальном посте в 1-м шаге: 1. В Xcode выберите целевое устройство Device | Release Разумеется, это должно быть целевое приложение Device | Distribution? (при условии, что этот скопированный релиз и переименовал его в соответствии с инструкциями Apple в Provisioning Portal)

Ответ 22

Мои два цента:

Загрузите последнюю версию загрузчика приложений. Я только что обновился и теперь получаю другое сообщение об ошибке.

Ответ 23

Я просто пережил эту проблему (снова), но на этот раз я обнаружил, что мой профиль распространения имеет статус "Недействительный". Если вы считаете, что все остальное правильно, дважды проверьте статус на портале и обновите/перезагрузите все, что не находится в активном состоянии.

Ответ 24

Я получил Invalid Binary после загрузки приложения, не отслеживая сообщения по электронной почте о том, почему это не удалось. Я попытался сделать пару вещей сразу, и я не уверен, что из следующего действительно исправил его:

  • Перезагруженный Macbook Pro
  • Переместил исходный код моего проекта с диска NTFS на диск HFS + и перекомпилировал.

Ответ 25

У меня возникла проблема с этим и 4.3 GM SDK. Одно из наших приложений не сделало бы его прошлой загрузкой. Оказалось, что это вопрос профилирования. Я восстановил профиль магазина приложения, и он работал нормально.

Ответ 26

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

Ответ 27

Другое решение:

Для меня просто установка сертификатов "Release" под "подписание кода" исправлена. Первоначально они были установлены на "Не вводить код".

Ответ 28

Для меня проблема была решена путем сохранения изображения PNG с опцией без чередования. В предыдущих версиях разрешалось чередование png, но известно, что это изображение может вызвать недопустимый двоичный файл.

Мое яблочное сообщение: Коррумпированный файл значков. Файл значка[email protected] выглядит искаженным. Ваш значок не должен быть чересстрочным PNG файлом.

Вы можете увидеть, чередуется ли PNG с помощью команды "файл" в терминале: Eva-Madrazos-MacBook-Pro-2: Интерактивные объявления GQ 7 Eva $file *.png Default.png: данные изображения PNG, 320 x 480, 8 бит/цвет RGB, без чередования

Удачи, Eva

Ответ 29

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

Проблема в моем случае состояла в том, что я ранее пробовал другие иконки приложений, и ссылка на старое изображение все еще оставалась в "CFBundleIcons". Я использовал функцию перетаскивания, чтобы установить значок, но я не заметил, что старый контент не был полностью очищен до добавления новой ссылки.

Чтобы увидеть неисправную ссылку, необходимо было развернуть стрелки для просмотра каждого элемента в файле plist. Один из советов - щелкнуть правой кнопкой мыши в файле и выбрать опцию для просмотра исходного содержимого. Таким образом вам не нужно ничего расширять.

Ответ 30

Я попробовал все другие предлагаемые решения, но ничего не помогло.

Я закончил создание нового проекта Xcode и скопировал в него весь мой код и ресурсы. Это сделал трюк, и мое приложение попало в очередь просмотра.

Я также могу рекомендовать Яркие технические примечания о подписании кода для отладки/проверки.