"Забагато файлів символів" після успішного надсилання моїх додатків


201

Я завантажив Xcode 6 GM і сьогодні подав два додатки Swift у магазин додатків. Обидва пройшли всю перевірку перед завантаженням та всі інші матеріали, які вони мали пройти, і були успішно відправлені. Але тоді я отримав два повідомлення від Apple ... по одній для кожної програми, і вони обидва сказали це:

Шановний розробник,

Ми виявили одну або декілька проблем із вашою нещодавньою доставкою для "xxxxxxxx" (ім'я програми видалено). Ваша доставка була успішною, але ви, можливо, захочете виправити наступні проблеми під час наступної доставки:

Занадто багато файлів символів - Ці символи мають відповідний зріз в будь-якому довічним [1431D977-72BC-308F-AB71-71529F25400B.symbols, 158C72A7-98AC-3F07-B2BE-88427591B413.symbols, 44973EAC-563E-340C-B549-55A5014A68BA.symbols , 678BF06F-0C3D-3A09-BFBF-699C7079FECD.симболи, 90907DDB-0400-38ED-BB5F-0C12333C0624.симболи, 93B79949-5757-374A-97B9-825AE1A61BFYAAABBF, AAAAA, ABB, BFB, A6A61B0, A5A, A5B, BFB, A8, A5, A, A, A, A, A, B, A, A -4422-32B8-8C40-CF9B45A2CCC6.symbols, B0CC9F7D-C542-3E18-A518-B28B7ECABE80.symbols, BF6A4C3B-6FA5-3C51-8404-19C2F132458D.symbols, C9D6E078-8E2A-39D9-8DEE-476916A69CEE.symbols, CF5320DF-AB31 -3845-BAD5-F6E51045D396.символи, D4967AA3-8FB0-3712-B0DE-7F4144AF8F4B.симболи, D813B314-AD37-31D4-B675-442052994495.symbols, DF42A13C-FFE-FFE-BF5-BF5-BF5-BD5-FFEE-BD5-F5E5F-BD5) -8F7D-C49A36CD5C65.символи]

Після виправлення неполадок ви можете використовувати Xcode або навантажувач програм для завантаження нового бінарного файлу в iTunes Connect.

З повагою,

Команда App Store

Я здогадуюсь, що насправді не має нічого спільного зі мною або моїми програмами ... і це лише вигадка дня першого подання програми Swift? Обидва додатки досі сидять у режимі "Очікування затвердження". Я, звичайно, не можу придумати нічого, що я міг би змінити, щоб змусити те, що вони сказали! Хтось ще подав додаток Swift і отримав цю відповідь? Подумайте, що я повинен просто проігнорувати це і чекати, щоб побачити, що станеться?


Моя сказала, що і Invalid Swift Support. Будь-яка ідея, чому я можу це отримати? Я використовую останній Xcode.
Делі

тут ця сама проблема, і моя програма не може надіслати на розгляд. через цю проблему. хтось вирішив?
yudun1989

1
тут же питання. представлений на розгляд у будь-якому випадку .. давайте подивимося, що станеться :)
dandoen

Обидва мої програми Swift були просто затверджені в App Store ... так що, мабуть, я нічого не хвилювався! Whew ... :)
Джим Барбер

Відповіді:


128

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

  1. Відкрийте вікно Організатор у Xcode
  2. Клацніть правою кнопкою миші архів, в якому була ця проблема, і виберіть "Показати у Finder".
  3. Клацніть правою кнопкою миші файл архіву та виберіть "Показати зміст пакета"
  4. У папці "dSYMs" ви побачите кілька файлів. Якщо ви запустите команду dwarfdumpконсолі в цих файлах, ви отримаєте список рядків UUID:

    dwarfdump -u MyFile.dSYM

Я впевнений, що ви знайдете відповідні UUID з електронної пошти Apple.

Щоб уникнути цього попередження, потрібно додати до свого архіву лише dSYMфайли вашої програми, а не бібліотеки. Для цього вам потрібно змінити конфігурацію збірки бібліотек, щоб не створювати dSYMфайл. Просто знайдіть у конфігурації "формат інформації про налагодження" та змініть її DWARF with dSYM Fileна DWARFлише.

Наприклад, на скріншоті нижче ви знайдете рамку iOS Stripe.

Скріншот налаштувань проекту Xcode


13
dwarfdump -u *у папці, щоб побачити всі UUID
Jon

@ Jon ooooh, чому я бачу це після того, як я зробив по черзі? :) все одно дякую!
Серж Рубенс

6
Чи видалення файлів dSYM означає, що будь-які збої, пов’язані з третьою стороною, більше не будуть символізуватися на Crashlytics (або будь-який інший інструмент звітування про аварії)?
Євгеніо

Якщо ви використовуєте firebase \ fabric, файли dsym слід використовувати для перегляду журналів аварій на сайті. Вони все ще працюють із цією зміною?
Маттіа Ланьєрі

91

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

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf'
        end
    end
end

Він встановить Формат інформації про налагодження у форматі DWARF лише для всіх ваших цілей Pod (не головна ціль програми)


@wzbozon Так, я прошу лише двічі перевірити. Тому що після того, як я це зробив, Crashlyticts перестають працювати. Дякую!
Сезар Родрігес

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

1
Я згоден. Але ви не побачите звітів про стручки Можна також встановити DWARF з файлом dSYM лише для деяких стручків, наприклад, для розробників.
Денис Кутлубаєв

@Стан ти кажеш, що Crashlytics продовжить працювати? Сезар Родрігес каже, що це не вийде.
airowe

8
Це вирішило це для мене. Не забувайтеpod install
firebear

18

Якщо ви використовуєте CocoaPods, і ваш додаток налаштовано на використання arm64 (тобто у info.plist вашого проекту є тільки arm64)

<key>UIRequiredDeviceCapabilities</key>
<array>
    <string>arm64</string>
</array>

тоді ви можете спробувати додати наступний скрипт у свій Podfile, щоб вирішити цю проблему.

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ENABLE_BITCODE'] = 'NO'
      config.build_settings['ARCHS'] = 'arm64'
    end
  end
end

І

встановіть усі цілі ваших проектів (а не цілі в Pods) лише для arm64

Налаштування проекту Xcode

CocoaPods Github посилання на випуск


Імовірно, ви також повинні включати arm64e зараз, ні?
шим

Я б включив arm64 під тренажер. Він буде видалений автоматично для версій версій.
кіберген

13

У мене є ця проблема, оскільки проект має дійсну архітектуру arm64, де цілі CocoaPods мають дійсні архітектури arm64, armv7 та armv7s .

Щоб перевірити, яка ціль має, чинна архітектура, виконайте наступні кроки

  1. У Xcode -> Window -> Органайзер
  2. Виберіть архів та відкрийте у Finder
  3. У файлі .xcarchive Показати вміст пакета
  4. Відкрийте термінал і вкажіть шлях до папки dSYM .

  5. Введіть команду, dwarfdump --uuid *і вона покаже список UUID з дійсною архітектурою.

UUID буде відповідати попереджувальному електронному листу від Apple

Основна ціль проекту та какао-стручки передбачають однакову дійсну архітектуру. Тим самим він вирішить питання.


Я думаю, що це найкраще пояснює те, що відбувається. У мене є ці попередження лише про бібліотеки з архітектурою armv7, оскільки мій проект побудований лише для arm64. Залишається питання, чи варто додати armv7 до проекту чи видалити його з Pods.
Аріель Богдзевич

6

Працював для мене, включивши біт-код - він був вимкнений раніше

Увімкнути біткод - так

введіть тут опис зображення


1

Сказане допомогло усунути неполадки, але не вдалося вирішити. У нас був проект на iOS 12, але стручки 10 - призвели до набору файлів armv7. Оновлення стручка до iOS 12 вирішено миттєво.


0

Якщо ця проблема була виправлена, маючи однакову "Загальну" => "Інформація про розгортання" => "Ціль розгортання" для всіх моїх цілей.


0

У Xcode подивіться у Налаштуваннях збірки для "Стриптизуйте налагоджувальні символи під час копіювання" (COPY_PHASE_STRIP). Якщо це ввімкнено, символи налагодження опускаються з вашого .app та розміщуються у файлі .dSYM. Інакше ваш .app містить ці символи. (За замовчуванням символи налагодження знімаються з версій версій з причин затуплення. Напевно, ви не повинні змінювати цей параметр для конфігурації версії.)

Переконайтеся, що ви перевірили цю опцію в налаштуваннях проекту

https://possiblemobile.com/2015/03/symbolicating-your-ios-crash-reports/


0

Проблемою для мене була рядок у моєму build.xcconfigфайлі. Мені довелося зняти

IPHONEOS_DEPLOYMENT_TARGET = 11.0

яка встановлювала проект будувати лише для arm64 (а не arm7). Слідуючи крокам, @miOSя міг побачити, що проект стручки будується для обох.


1
stackoverflow.com/a/49063850/3293172 iOS 11 відмовився від підтримки armv7 та armv7s, тому потрібен лише arm64, якщо у вас є ціль розгортання> = iOS 11.0.
Аріель Богдзевич

-3

Для мене все було дуже просто. У мене була така ж проблема і не знала, що робити тиждень.

Після подачі архівованої заявки ви побачите сертифікат на розповсюдження у невеликому спливаючому вікні. Після нього є прапорець, який слід зняти. Після цього ви надішліть його та отримаєте електронний лист про файли символів. АЛЕ це не проблема. Це просто попередження; не помилка! Якщо ви знімите цей прапорець, ваш додаток буде надіслано правильно. Сподіваюся, це може вам допомогти.

Знімок екрана прапорця та спливаючого вікна:

Знімок екрана прапорця та спливаючого вікна


Я дуже сподіваюся, що ви будете детальніше .... Я не маю поняття, про який прапорець або спливаюче вікно ви говорите. Може, знімок екрана?
Луї Гонг

gyazo.com/6d7bb2035979cb75253ba92a40e8d898 Я думаю, що я це бачу, це саме цей
Луї Гонг,

6
Так, але це позбавить усіх символів із пакету, і тому ви не отримаєте символічних звітів про аварійну ситуацію? (Чи надають вони навіть символічні звіти про аварійне завершення в додатках App Store зараз із TestFlight?)
Markus Rautopuro

31
Це неправильне рішення проблеми. Це дозволяє уникнути симптому, а не вирішити проблему. Дивіться відповідь Міхаеля для опису того, як ви завантажуєте символи, які вам не потрібні. Ця відповідь перешкоджає завантаженню будь-яких символів, тим самим порушуючи позначення аварії через iTunesConnect
JConway

3
НЕ робіть цього, якщо ви цього не зможете проаналізувати у додатку в App Store на помилки аварій
user924
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.