Приложение iOS со Static Lib падает только при запуске Archive Build, загруженного Ad Hoc. Не удается воспроизвести в отладчике

Я понимаю, что это растяжка, и я не могу дать много информации, чтобы помочь, но я стремлюсь к чему-либо. Мое приложение находится под непрерывным развитием в течение 3 лет и никогда не видел ничего подобного. Недавно я опубликовал небольшой выпуск для Apple для выпуска, и два раза теперь он был отклонен для Crashing on Launch на ВСЕХ их устройствах.

Отчеты Crash указывают на некоторый код в статической библиотеке, но ключевые строки не становятся символическими. Пробовал Атос не повезло.

Ключевым моментом является то, что у меня есть 7 устройств, на которых я тестировал приложение, в каждом из режимов, о котором я могу думать, в частности, никакого подключения ни к чему: Wifi-OFF, AirplaneMode-ON, Location services-OFF. Я НИКОГДА не смогу имитировать то, что, как они утверждают, видят, что при каждом запуске приложения запускается при каждом запуске?!

Я нашел один отчет в AAPL Dev Forums, который звучал аналогично, но у него никогда не было объяснений относительно того, что было. После того, как он отправил приложение с множеством протоколов в отчаянии и попросил их отправить журналы. Они получили эту версию и... утвердили ее в течение нескольких часов.

У всех есть ЛЮБЫЕ идеи. Мне НЕОБХОДИМО освободить этот выпуск.

ПРИМЕЧАНИЕ: Решено

Это оказалось НЕ быть проблемой с слабым звеном. Мы видели только сбой при запуске приложения, используя Ad Hoc-дистрибутив версии Archive, как предложил Брэд... так что это было полезно.

Однако разрешение оказалось некоторыми флагами компилятора, которые я перечислял здесь: qaru.site/info/437658/...

Ответ 1

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

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

Это может быть раскрыто путем создания и архивирования приложения, а затем выбора для его распространения для ad hoc или корпоративного распространения. Возьмите .ipa и поместите его в iTunes и вручную загрузите его на одном из ваших тестовых устройств. Поведение приложения, подготовленного таким образом, может отличаться от построенного и установленного через Xcode, и должно быть ближе к тому, как будет действовать сборка, представленная для проверки.

В моем случае проблема была связана с отсутствием надлежащей слабой связи. В SDK, более новых, чем iOS 4.3, вам больше не нужно будет использовать слабые ссылки для всех фреймворков, если вы хотите условно использовать классы и функции, присутствующие в новых SDK, но отсутствующие в более старых. Если вы нацелились на 4.0 и выше, компоновщик должен теперь выполнять слабую связь на уровне классов и функций.

Однако это было неудачно для людей, использующих мою статическую библиотеку, которая проверяет время выполнения новых функций кеша текстур в iOS 5.0, но в этих архивных сборках это не удалось. Я никогда не видел его во всех своих тестах против устройств 4.x, потому что это было сделано путем установки через Xcode. В конце концов, мне нужно было, чтобы пользователи явно слабо связывали всю инфраструктуру Core Video, чтобы заставить приложения, использующие эту инфраструктуру, работать правильно при архивировании и установке через iTunes.

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