Символізує звіти про збої в додатках iPhone

Я хочу спробувати і символізувати звіти про збої в додатку iPhone.

Я отримав звіти про збої з iTunes Connect. У мене є бінарний додаток, який я подав у App Store, і у мене є файл dSYM, який був створений у складі збірки.

У мене всі ці файли разом у одному каталозі, який індексується прожектором.

Що тепер?

Я спробував викликати:

symbolicatecrash crashreport.crash myApp.app.dSYM

і він просто виводить той самий текст, який є у звіті про збій, для початку, а не символічним.

Я щось роблю не так?

Кроки для аналізу звіту про аварійну ситуацію в Apple:

1. Скопіюйте .app-файл випуску, який було висунуто в appstore, файл .dSYM, який був створений на момент випуску, та звіт про збій, отриманий з APPLE у папку .

2. Відкрийте додаток терміналу та перейдіть до папки, створеної вище (за допомогою cdкоманди)

3. Біжи atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. Місце пам'яті повинно бути таким, коли додаток вийшов із ладу відповідно до звіту.

Наприклад: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

Це покаже точний рядок, назва методу, який призвів до збоїв.

Наприклад: [classname functionName:]; -510

Символізує IPA

якщо ми використовуємо IPA для символізації - просто перейменуйте розширення .ipa з .zip, витягніть його, тоді ми можемо отримати папку Payload, яка містить додаток. У цьому випадку нам не потрібен .dSYM файл.

Примітка

Це може працювати лише в тому випадку, якщо у бінарному додатку немає позбавлених символів. За замовчуванням реліз будує позбавлені символи. Ми можемо змінити його в налаштуваннях побудови проекту "Символи налагодження смужок під час копіювання" на "НІ".

Детальніше дивіться у цьому дописі

Прочитавши всі ці відповіді тут, щоб символізувати журнал аварій (і, нарешті, досягти успіху), я думаю, що тут відсутні деякі моменти, які є дійсно важливими для того, щоб визначити, чому виклик символічної аварії не дає символічного виводу.

Є три об’єкти, які повинні поєднуватися разом, коли символізують журнал аварій:

1. Сам файл журналу збоїв (тобто example.crash), експортований від організатора XCode або отриманий від iTunes Connect.
2. .appПакет (тобто example.app) , що саме по собі містить додаток бінарного належить до аварії журналу. Якщо у вас є .ipaпакет (тобто example.ipa), ви можете вилучити .appпакунок, розпакувавши .ipaпакет (тобто unzip example.ipa). Після цього .appпакет знаходиться у витягнутій Payload/папці.
3. .dSYMПакет , що містить символи налагодження (тобто example.app.dSYM)

Перед початком символізації слід перевірити, чи всі ці артефакти збігаються, а це означає, що журнал збоїв належить до наявного у вас двійкового файла та що символи налагодження - це ті, що створюються під час складання цього бінарного файлу.

Кожен бінарний файл посилається на UUID, який можна побачити у файлі журналу збоїв:

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

У цьому витягу журнал збоїв належить двійковому зображенню програми з назвою example.app/example з UUID aa5e633efda8346cab92b01320043dc3.

Ви можете перевірити UUID двійкового пакету, який ви маєте з dwarfdump:

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

Після цього слід перевірити, чи належать символи налагодження до цього двійкового файлу:

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

У цьому прикладі всі активи поєднуються разом, і ви повинні мати можливість символізувати свій стек-трек.

Перехід до symbolicatecrashсценарію:

У Xcode 8.3 ви повинні мати можливість викликати сценарій через

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

Якщо його немає там, ви можете запустити його find . -name symbolicatecrashу каталозі Xcode.app, щоб знайти його.

Як бачите, більше параметрів не задано. Таким чином, сценарій повинен знайти у вашому додатку бінарні та налагоджувальні символи, запустивши пошук у центрі уваги. Він здійснює пошук символів налагодження з певним індексом, який називається com_apple_xcode_dsym_uuids. Ви можете зробити цей пошук самостійно:

mdfind 'com_apple_xcode_dsym_uuids = *'

респ.

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

Перший виклик прожектора дає всі індексовані пакети dSYM, а другий - .dSYMпакунки з певним UUID. Якщо прожектор не знайде вашого .dSYMпакета, то symbolicatecrashне буде ні. Якщо ви робите все це, наприклад, у підпапці вашого ~/Desktopпрожектора, ви зможете знайти все.

Якщо ви symbolicatecrashзнайдете ваш .dSYMпакет, у рядку має бути такий рядок symbolicate.log:

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

Для пошуку у вашому .appпакеті вказується пошук у центрі уваги symbolicatecrash:

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

Якщо ви symbolicatecrashзнайдете ваш .appпакунок, у ньому повинен бути наступний витяг symbolicate.log:

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

Якщо всі ці ресурси знайдені symbolicatecrashнею, слід роздрукувати символічну версію журналу аварій.

Якщо ні, ви можете передати файли dSYM та .app безпосередньо.

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

Примітка: Символізований зворотний шлях буде виведений на термінал, а не symbolicate.log.

З останньою версією Xcode (3.2.2) ви можете перетягувати будь-які звіти про аварійне завершення в розділ Журнали пристроїв Організатора Xcode, і вони автоматично будуть символізовані для вас. Я думаю, що це найкраще працює, якщо ви створили цю версію програми за допомогою Build & Archive (також частина Xcode 3.2.2)

Я зробив це успішно, виконавши наступні кроки.

Крок 1: Створіть папку на робочому столі, я даю їй назву "CrashReport" і поміщую в неї три файли ("MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07-18.crash").

Крок 2: Відкрийте Finder і перейдіть у програму, де ви знайдете додаток Xcode, клацніть правою кнопкою миші та натисніть "Показати зміст пакета", після цього слідуйте цьому простому шляху. "Зміст-> Розробник-> Платформи-> iPhoneOS.platform-> Розробник-> Бібліотека-> PrivateFrameworks- > DTDeviceKit.framework -> Версії- > A-> Ресурси"

АБО

"Зміст-> Розробник-> Платформи-> iPhoneOS.platform-> Розробник-> Бібліотека-> PrivateFrameworks- > DTDeviceKitBase.framework -> Версії- > A-> Ресурси"

АБО

Для Xcode 6 і вище шлях - Applications / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Resources

Там, де ви знайдете файл "symbolicatecrash", скопіюйте це та вставте його у папку "CrashReport".

Крок 3: запустіть термінал, запустіть ці 3 команди

1. cd / Користувачі / mac38 / Настільний / CrashReport та натисніть кнопку Enter

2. експортувати DEVELOPER_DIR = "/ Програми / Xcode.app / Зміст / розробник" і натисніть Enter

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM і натисніть клавішу Enter Now Done .. (ПРИМІТКА: версії близько 6.4 або новіших версій не мають опції -A - просто залиште її).

Кроки для автоматичного позначення звіту про аварійну ситуацію за допомогою XCode:

ОНОВЛЕНО ДЛЯ XCODE 9

1. Підключіть будь-який пристрій iOS до свого Mac (так, фізичний, так, я знаю, це дурно)

2. Виберіть "Пристрої" у меню "Вікно"

3. Клацніть свій пристрій ліворуч та ПЕРЕГЛЯДУЙТЕ ЛОГИ ПРИСТРОЮ справа

4. Зачекайте. Це може зайняти хвилину, щоб показати. Може робити Command-Aтоді Deleteбуде прискорити цей процес.

5. Критичний незадокументований крок: перейменуйте звіт про збій, отриманий від iTunesConnect, від.txtрозширення до.crashрозширення

6. Перетягніть звіт про збій у цю область зліва

І тоді Xcode буде символізувати звіт про збій і відображатиме результати.

Джерело: https://developer.apple.com/library/ios/technotes/tn2151/_index.html

Я використовую Airbrake у своїх додатках, що робить досить непогану роботу з віддаленим журналом помилок.

Ось як я символізую їх з atos, якщо backtrace це потребує:

1. У Xcode (4.2) перейдіть до органайзера, клацніть правою кнопкою миші на архів, з якого був створений файл .ipa.

2. У терміналі, CD в xcarchive , наприклад ,MyCoolApp 10-27-11 1.30 PM.xcarchive

3. Введіть наступне atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (не забудьте одиничні цитати)

4. Я не включаю свій символ у цей дзвінок. У вас виходить блок-курсор у порожньому рядку.

5. Потім я копіюю / вставляю свій код символу в цей курсор блоку і натискаю клавішу Enter. Ви побачите щось на кшталт:

   -[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

6. Ви повернулися до курсору блоків і можете вставити інші символи.

Можливість пройти один заднім словом без повторного введення першого шматочка - це приємна економія часу.

Насолоджуйтесь!

Я також розміщую dsym, пакет програм та журнал аварійних зборів в одному каталозі перед запуском символічної аварії

Потім я використовую цю функцію, визначену в моєму .profile, щоб спростити запущений символічний збій:

function desym
{
    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

Додані там аргументи можуть вам допомогти.

Ви можете перевірити, чи переконатися, що прожектор "бачить" ваші файли дисмів, виконавши команду:

mdfind 'com_apple_xcode_dsym_uuids = *'

Шукайте dsym у своєму каталозі.

ПРИМІТКА. Станом на останній Xcode більше не існує каталогу розробників. Ви можете знайти цю утиліту тут:

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers‌ ions / A / Resources / symbolicatecrash

Просто проста та оновлена ​​відповідь на xcode 6.1.1.

КРОКИ

1.Xcode> Window> Devices.

2.Виберіть пристрій зі списку пристроїв у розділі ПРИЛАДИ.

3.Виберіть Перегляд журналів пристроїв.

4.За розділом Усі журнали ви можете перетягнути папку report.crash

5.Xcode автоматично символізує звіт про аварійне завершення роботи.

6. Ви можете знайти символічний звіт про аварію, зіставивши його Дата / час із датою / часом, зазначеною у вашому звіті про аварію.

Незважаючи на те, що я розробляв додатки вже кілька років, це мій перший випадок налагодження бінарного файлу, і я відчував себе повним NOOB, з'ясовуючи, де всі файли, тобто де * .app * .dSYM і журнали аварійних збоїв? Мені довелося прочитати кілька постів, щоб зрозуміти це. Картина коштує тисячі слів, і я сподіваюся, що ця публікація допоможе комусь іншим у майбутньому.

1- Спочатку перейдіть до itunesconnect та завантажте свої журнали аварій. ПРИМІТКА. У більшості випадків у вас може з’явитися щось на кшталт "Надсилається мало звітів для показу звіту". В основному недостатньо користувачів подали звіти про журнал аварій в Apple, і в цьому випадку ви нічого не можете зробити на цьому етапі.

2- Тепер, якщо ви не змінили свій код, оскільки ви подали свій двійковий файл в Apple, тоді запустіть Xcode для цього проекту і знову зробіть Product -> Archive. В іншому випадку просто знайдіть останній поданий двійковий файл і клацніть правою кнопкою миші на ньому.

У Xcode 4.2.1 відкрийте Організатор , потім перейдіть до Журналу бібліотеки / пристроїв та перетягніть .crash-файл у список журналів аварій. Він буде символічним для вас через кілька секунд.

Зауважте, що ви повинні використовувати той самий екземпляр Xcode, на якому було заархівовано оригінальну збірку (тобто архів для вашої збірки повинен існувати в Організаторі ).

За допомогою Xcode 4 завдання є ще простішим:

• відкрити Органайзер ,
• натисніть на Бібліотека | Увійти до пристрою в лівій колонці
• натисніть кнопку " Імпортувати " в нижній частині екрана ...

і вуаля. Файл журналу імпортується та символізується автоматично для вас. За умови, що ви архівували збірку за допомогою Xcode -> Product -> Archive .

Чарівний організатор Xcode не так чарівний щодо символізації моєї програми. У мене взагалі немає жодних символів для звітів про аварійне завершення роботи, які я повернув від Apple після невдалого подання програми.

Я спробував скористатися командним рядком, помістивши звіт про збій у ту ж папку, що і файл .app (який я подав у магазин) та файл .dSYM:

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

Це було лише символами для мого додатка, а не основним кодом основи, але це було краще, ніж дамп числа, який дає мені Організатор, і мені було достатньо, щоб знайти та виправити збій, який відбувся в моєму додатку. Якщо хтось знає, як розширити це, щоб отримати символи Фонду, це буде вдячно.

У моєму випадку я перетягував звіти про збої безпосередньо з Пошти до Організатора. Чомусь це не дозволило повідомленням про аварійне завершення набути символізму (я хотів би знати чому).

Спершу скопіювавши звіти про збої на робочий стіл, а потім перетягнувши їх звідти до Організатора, вони отримали належну символіку.

Я знаю дуже конкретний випадок. Але я подумав, що поділюся про всяк випадок.

Ось ще одна проблема, яку я маю з символічним збиттям - вона не працюватиме з програмами, які містять пробіли у своєму пакеті (наприклад, "Test App.app"). Примітка. Я не думаю, що ви можете мати пробіли в їх імені під час надсилання, тому ви все одно повинні видалити їх, але якщо у вас вже є збої, які потребують аналізу, виправіть символічний збиток (4,3 ГМ) як такий:

240c240
<         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
>         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
<             my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
>             my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

Для тих, хто використовує Airbrake, є суттєвий відгук вище, але це не спрацює для мене без налаштування:

Працює для деяких адрес пам'яті, але не для інших, не впевнений, чому ...

• Створіть новий редактор на робочому столі чи де завгодно
• Знайдіть архів, про який йде мова, в організаторі Xcode
• Двічі торкніться, щоб відкрити в пошуку
• Двічі торкніться, щоб показати вміст групи
• Скопіюйте .dSYM файл та .app файл у новий каталог
• CD в ​​новий реж
• Виконайте цю команду: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
• Термінал перейде в інтерактивний хід
• Вставте адресу пам'яті і натисніть клавішу Enter, вона виведе ім'я методу та номер рядка
• Крім того, введіть цю команду: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Щоб отримати інформацію лише для однієї адреси

Комбінація, яка працювала для мене:

1. Скопіюйте файл dSYM в каталог, де був звіт про збій
2. Розпакуйте файл ipa, що містить додаток ("распакуйте MyApp.ipa")
3. Скопіюйте бінарний додаток із отриманого вибухового навантаження в ту саму папку, що і звіт про збій та файл символів (щось на зразок "MyApp.app/MyApp")
4. Імпортуйте або повторно позначте звіт про збій з організатора Xcode

Використовуючи atos, я не зміг вирішити правильну інформацію про символи з адресами та зсувами, які були у звіті про збій. Коли я це зробив, я бачу щось більш значиме, і це здається законним слідом стека.

Мені довелося багато зламати сценарій символічного збою, щоб змусити його правильно працювати.

Наскільки я можу сказати, символічний збій прямо зараз вимагає, щоб .app знаходився в тому ж каталозі, що і .dsym. Він використовуватиме .dsym для пошуку .app, але dsym не використовує для пошуку символів.

Ви повинні зробити копію свого символічного збою перед тим, як спробувати ці патчі, які змусять його виглядати в dsym:

Приблизно лінія 212 у функції getSymbolPathFor_dsymUuid

212     my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

Навколо рядка 265 у функції matchUUID

265             return 1;

Це просто, після багато пошуку я знайшов чіткі кроки, щоб символізувати весь файл журналу аварій.

• скопіюйте у папку файли .app, crash_report та DSYM.
• підключіть пристрій за допомогою xcode
• Потім перейдіть до вікна -> виберіть пристрої -> переглянути журнали пристроїв
• Потім виберіть цей пристрій, видаліть усі журнали.
• перетягніть аварію на розділ журналу пристрою. це автоматично символізує збій. просто клацніть правою кнопкою миші на звіті та експортуйте його.

щасливе кодування,
Ріяз

Я вважаю за краще сценарій, який буде символізувати всі мої журнали аварій.

Передумови

Створіть папку і помістіть туди 4 речі:

1. symbolicatecrash сценарій perl - є багато відповідей ТА говорить про його місцезнаходження

2. Архів збірки, що відповідає збоям (від Xcode Organizer. Простий як Show in Finderі копіювати) [я не впевнений, що це потрібно]

3. Усі xccrashpointпакети - (від Xcode Organizer. Show in FinderВи можете скопіювати всі пакунки в каталог або одну xccrashpoint, яку ви хочете позначити)

4. Додайте цей короткий сценарій до каталогу:

   #!/bin/sh
   
   echo "cleaning old crashes from directory"
   rm -P *.crash
   rm -P *.xccrashpoint
   rm -r allCrashes
   echo "removed!"
   echo ""
   echo "--- START ---"
   echo ""
   
   mkdir allCrashes
   mkdir symboledCrashes
   find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \;
   
   cd allCrashes
   for crash in *.crash; do
       ../symbolicatecrash $crash > ../symboledCrashes/V$crash
   done
   cd ..
   
   echo ""
   echo "--- DONE ---"
   echo ""

Сценарій

Запустивши сценарій, ви отримаєте 2 каталоги.

1. allCrashes- всі крахи від усієї xccrashpointволі будуть там.

2. symboledCrashes - той самий збій, але зараз із усіма символами.

3. вам НЕ потрібно очищати каталог від старих збоїв перед запуском сценарію. він очиститься автоматично. Щасти!

Я з'ясував, що більшість запропонованих альтернатив не працювали в останніх XCode (протестовано з Xcode 10). Наприклад, мені не пощастило перетягнути .crash-журнали в Xcode -> Органайзер -> Журнали пристроїв - перегляд.

Я рекомендую використовувати інструмент Symbolicator https://github.com/agentsim/Symbolicator

• Сховище Git clone Symbolicator і компілювати та запускати з Xcode
• Скопіюйте .crash-файл (файл ascii, із слідом стека у випробовуванні файлу) та .xarchive збійного випуску в ту саму тимчасову папку
• Перетягніть файл .crash до значка Symbolicator в доці
• Через 5-30 секунд символізований файл аварії створюється в тій же папці, що і .crash та .xarchive

Щоб символізувати збої, Spotlight повинен бути в змозі знайти .dSYM-файл, який був сформований одночасно з бінарним файлом, який ви подали в Apple. Оскільки вона містить інформацію про символ, вам не пощастить, якщо її немає.

Я трохи розчулився з приводу того, що тут нічого, здається, не просто працює, тому я провів кілька розслідувань, і результат такий:

Налаштування: зворотний кінець QuincyKit, який отримує звіти. Жодна символіка не налаштована, тому що я не міг навіть зрозуміти, що вони пропонують мені зробити, щоб це працювало.

Виправлення: завантажте з Інтернету звіти про збої. Вони називаються "аварія" і за замовчуванням переходять у папку ~ / Downloads /. Зважаючи на це, цей скрипт "зробить правильно", і звіти про збої перейдуть у Xcode (Організатор, журнали пристроїв) та буде зроблено символізацію.

Сценарій:

#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode

if [ ! -e ~/Downloads/crash ]; then 
   echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
   exit 1
fi

cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx

datestr=`date "+%Y-%m-%d-%H%M%S"`

mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

Речі можна автоматизувати, куди можна перетягувати Xcode Organizer, виконуючи дві речі, якщо ви використовуєте QuincyKit / PLCR.

По-перше, ви повинні відредагувати віддалений скрипт admin / actionapi.php ~ рядок 202. Схоже, що часова мітка не відповідає правильності, тому файл закінчується ім'ям "аварії", який Xcode не розпізнає (він хоче щось крапка в точці):

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

По-друге, на стороні iOS в QuincyKit BWCrashReportTextFormatter.m ~ рядок 176 змініть, @"[TODO]"щоб @"TODO"обійти поганих символів.

atos припиняється, тому якщо ви працюєте з OSX 10.9 або новішою версією, можливо, вам доведеться запустити

xcrun atos

Попередження: / usr / bin / atos рухається і буде видалено з майбутнього випуску OS X. Тепер це доступно в інструментах для розробників Xcode, за допомогою яких можна викликати:xcrun atos

Мені подобається використовувати Textwrangler для точного виявлення помилок у оригінальній бінарній відхиленні завантаження програми. (Дані про збої будуть знайдені у вашому обліковому записі itunesConnect.) Використовуючи вищевказаний метод Sachin, я копіюю файл original.crash у TextWrangler, а потім копіюю файл, який я створив symbolicatecrash, в інший файл TextWrangler. Порівнюючи два файли відмінності. У файлі symbolicatecrash будуть відмінності, які вказують на кількість файлів та рядків проблем.

Ми використовуємо Google Crashlytics для контролю журналів аварійних збоїв. Це відчуття дуже своєчасне та зручне у використанні.

Посилання на документ: https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

Все про відсутність тканини dSYM включає інструмент для автоматичного завантаження dSYM вашого проекту. Інструмент виконується за допомогою сценарію / run, який додається до вашої фази збірки сценаріїв запуску під час процесу вбудованого процесу. Однак можуть виникати певні ситуації, коли завантаження dSYM не вдалося через унікальну конфігурацію проекту або якщо ви використовуєте Bitcode у вашому додатку. Якщо завантаження не вдалося, Crashlytics не зможе символізувати та відображати збої, і на панелі інструментів Fabric з'явиться повідомлення про відсутній dSYM.

Відсутній dSYM можна завантажувати вручну, дотримуючись наведених нижче кроків.

Примітка: як альтернатива автоматизованому інструменту завантаження dSYM, Fabric надає інструмент командного рядка (символи завантаження), який можна налаштувати вручну, щоб запуститись як частина процесу складання вашого проекту. Інструкції з налаштування див. У розділі символів для завантаження нижче.

...