Ошибка приложения в выпуске, но не в отладке

Как я уже сказал в названии, я пишу приложение для iPhone, которое отлично работает в режиме отладки, но когда я его создаю и устанавливаю через TestFlight, он выходит из строя. Из-за журнала сбоев, возможно, придется что-то сделать с этими строками:

let path = NSBundle.mainBundle().pathForResource("PrinterList", ofType: "plist")
if path != nil {
    let printerDic = NSDictionary(contentsOfFile: path!)
    let printerList = NSArray(array: printerDic.allKeys)
    printerNames = printerList as [String]
}

Я использую фреймворк от Brother для печати без AirPrint, но я думаю, что это не проблема, потому что приложение выходит из строя, прежде чем что-то делать с каркасом. Он выходит из строя только в этом ViewController, где я выполняю эти строки. Мне нужна структура только в этом ViewController.

Ответы

Ответ 1

Существует множество причин, по которым приложение может выйти из строя в режиме деблокирования, но не в режиме отладки (например, различия в распределении памяти обнаруживают ошибку, которая фактически существует в обеих сборках.) Они могут выполнять большую работу по отслеживанию, даже с не-бета-компилятор/язык.

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

В настоящее время я откладываю рассмотрение этого вопроса. Отпустите без оптимизаций, пока мы не получим полную версию компилятора. Затем верните оптимизацию и посмотрите, есть ли у вас проблема. Если вы это сделаете, пришло время начать тратить свою энергию, пытаясь понять, является ли это ошибкой компилятора или ошибкой в ​​вашем собственном коде.

Ответ 2

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

Оптимизация всего модуля в соответствии с Apple:

Используйте оптимизацию всего модуля, чтобы сделать вывод о внутренних декларациях. Объявления с внутренним доступом (по умолчанию, если ничего не объявлено) отображаются только в модуле, где они объявлены. Потому как Swift обычно компилирует файлы, составляющие модуль отдельно, компилятор не может определить, является ли внутренняя декларация переопределяется в другом файле. Однако, если весь модуль Оптимизация включена, весь модуль скомпилирован вместе в то же время. Это позволяет компилятору делать выводы о весь модуль вместе и заключить окончательный на декларациях с внутренними если видимых переопределений нет.

Вы можете включить это в своих настройках проекта:

Whole Module Optimization

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

Ответ 3

Apple также описывает известную проблему. Я кратко опишу это в случае, если кто-то ищет ответ, а предыдущее решение не работает.

Проверьте свой crashlog на наличие ошибок, например

Dyld Error Message:
  Library not loaded: @rpath/libswiftCore.dylib

или

[....] [deny-mmap] mapped file has no team identifier and is not a platform binary:
/private/var/mobile/Containers/Bundle/Application/5D8FB2F7-1083-4564-94B2-0CB7DC75C9D1/YourAppNameHere.app/Frameworks/libswiftCore.dylib

и следуйте руководству Apple , если у вас есть аналогичный выход сбоя, как и выше.

PS: вы можете легко проверить журнал даже в окне Window → Device в XCode. щелкните мышью на устройстве и нажмите "Просмотреть журналы устройств".

Ответ 4

Чтобы уловить краш-тест, с уровнем оптимизации, установленным в Fastest, Smallest [-Os] в режиме отладки, чтобы более точно имитировать код, который будет создан и запущен на пользовательском устройстве.

Вы можете установить его в настройках сборки под Swift Compiler/Code Generation