«Trop de fichiers de symboles» après avoir soumis avec succès mes applications

199

J'ai téléchargé Xcode 6 GM et soumis deux applications Swift à l'App Store aujourd'hui. Les deux ont réussi toutes les vérifications avant téléchargement et tous les autres éléments qu'ils ont dû passer et ont été soumis avec succès. Mais ensuite, j'ai reçu deux e-mails d'Apple ... un pour chaque programme et ils ont tous deux dit ceci:

Cher développeur,

Nous avons découvert un ou plusieurs problèmes avec votre livraison récente pour "xxxxxxxx" (le nom de mon application a été supprimé). Votre livraison a réussi, mais vous souhaiterez peut-être corriger les problèmes suivants lors de votre prochaine livraison:

Trop de fichiers de symboles - Ces symboles n'ont aucune tranche correspondante dans un fichier binaire [1431D977-72BC-308F-AB71-71529F25400B.symbols, 158C72A7-98AC-3F07-B2BE-88427591B413.symbols, 44973EAC-563E-340C-B549-55A50 , 678BF06F-0C3D-3A09-BFBF-699C7079FECD.symbols, 90907DDB-0400-38ED-BB5F-0C12333C0624.symboles, 93B79949-5757-374A-97B9-825AE1A61B7F4BF-08A -4422-32B8-8C40-CF9B45A2CCC6.symbols, B0CC9F7D-C542-3E18-A518-B28B7ECABE80.symbols, BF6A4C3B-6FA5-3C51-8404-19C2F132458D.symbols, C9D6E8E69A8E69 -3845-BAD5-F6E51045D396.symboles, D4967AA3-8FB0-3712-B0DE-7F4144AF8F4B.symboles, D813B314-AD37-31D4-B675-442052994495.symboles, DF42A13F-08D21-3F5BF7CF -8F7D-C49A36CD5C65.symbols]

Après avoir corrigé les problèmes, vous pouvez utiliser Xcode ou Application Loader pour télécharger un nouveau binaire sur iTunes Connect.

Cordialement,

L'équipe App Store

Je vais deviner que cela n'a vraiment rien à voir avec moi ou mes applications ... et c'est juste une bizarrerie des soumissions d'applications Swift du premier jour? Les deux applications sont toujours en mode "En attente d'approbation". Je ne peux certainement pas penser à quoi que ce soit que je pourrais changer pour faire disparaître ce qu'ils ont dit! Quelqu'un d'autre a-t-il déjà soumis une application Swift et obtenu cette réponse? Vous pensez que je devrais simplement l'ignorer et attendre de voir ce qui se passe?

Jim Barber
la source
Le mien a dit cela et Invalid Swift Support. Une idée pourquoi je pourrais avoir ça? J'utilise le dernier Xcode.
Dehli
même problème ici, et mon application ne peut pas soumettre pour examen.en raison de ce problème.tout le monde a résolu?
yudun1989
1
même problème ici. soumis pour examen de toute façon .. voyons ce qui se passe :)
dandoen
Mes deux applications Swift viennent d'être approuvées sur l'App Store ... donc je suppose que je ne m'inquiétais pour rien! Ouf ... :)
Jim Barber

Réponses:

128

Cela se produit si vous incluez les informations de débogage de vos bibliothèques avec l'archive du projet mais n'incluez pas les binaires.

  1. Ouvrez la fenêtre Organiseur dans Xcode
  2. Faites un clic droit sur une archive qui a eu ce problème et sélectionnez "Afficher dans le Finder".
  3. Faites un clic droit sur le fichier d'archive et sélectionnez "Afficher le contenu du package"
  4. Dans le dossier "dSYMs", vous verrez plusieurs fichiers. Si vous exécutez la dwarfdumpcommande console sur ces fichiers, vous obtiendrez une liste de chaînes UUID:

    dwarfdump -u MyFile.dSYM

Je suis sûr que vous trouverez des UUID correspondants dans l'e-mail d'Apple.

Pour éviter cet avertissement, vous devez inclure dans votre archive uniquement les dSYMfichiers de votre application et non les bibliothèques. Pour cela, vous devez modifier la configuration de construction des bibliothèques pour ne pas générer de dSYMfichier. Recherchez simplement "debug information format" dans la configuration et changez-le de DWARF with dSYM Fileen DWARFseulement.

Par exemple, dans la capture d'écran ci-dessous, vous trouverez le framework Stripe iOS.

Capture d'écran des paramètres du projet Xcode

Mikhail Grebionkin
la source
13
dwarfdump -u *dans le dossier pour voir tous les UUID
Jon
@ Jon ooooh pourquoi je le vois après l'avoir fait un par un? :) de toute façon merci!
Serj Rubens
6
La suppression des fichiers dSYM signifie-t-elle que les plantages liés à des tiers ne seront plus symbolisés sur Crashlytics (ou tout autre outil de rapport de crash)?
Eugenio
Cependant, si vous utilisez firebase \ fabric, les fichiers dsym doivent être utilisés pour afficher les journaux de plantage sur le site. Travaillent-ils toujours avec ce changement?
Mattia Lancieri
88

Si vous avez rencontré ce problème lors de l'utilisation de CocoaPods, ajoutez ceci à votre 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

Il définira le format d'informations de débogage sur DWARF uniquement pour toutes vos cibles de pod uniquement (pas la cible principale de l'application)

Denis Kutlubaev
la source
@wzbozon Oui, je demande juste de revérifier. Parce qu'après l'avoir fait, Crashlyticts cesse de fonctionner. Merci!
Cesar Rodriguez
Crashlytics devrait continuer à fonctionner pour votre application, car ce script modifie les paramètres de génération des pods uniquement.
Stan
1
Je suis d'accord. Mais vous ne verrez pas de rapports pour les pods. On pourrait également définir DWARF avec le fichier dSYM pour certains pods uniquement, par exemple les pods de développement.
Denis Kutlubaev du
@Stan, dites-vous que Crashlytics continuera de fonctionner? Cesar Rodriguez semble dire que cela ne fonctionnera pas.
airowe
8
Cela l'a résolu pour moi. N'oubliez pas depod install
Firebear
17

Si vous utilisez CocoaPods et que votre application est configurée pour utiliser uniquement arm64 (c'est-à-dire qu'il n'y a que arm64 dans l'info.plist de votre projet)

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

alors vous pouvez essayer d'ajouter le script suivant dans votre Podfile pour résoudre ce problème.

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

ET

définissez toutes les cibles de vos projets (et non les cibles des pods) sur arm64 uniquement

Paramètres du projet Xcode

Référence de problème de CocoaPods Github

Jerry Chen
la source
Vraisemblablement, vous devriez également inclure arm64e maintenant, non?
cale
J'inclurais arm64s pour le simulateur. Il sera supprimé automatiquement pour les versions de versions.
cybergen
13

J'ai ce problème car le projet a une architecture valide arm64 où les cibles CocoaPods ont une architecture valide arm64, armv7 et armv7s .

Pour vérifier quelle cible possède quelle architecture valide, suivez les étapes suivantes

  1. Dans Xcode -> Fenêtre -> Organiseur
  2. Sélectionnez l'archive et révéler dans le Finder
  3. Sur le fichier .xcarchive , Afficher le contenu du package
  4. Ouvrez le terminal et indiquez le chemin du dossier dSYMs .

  5. Entrez la commande dwarfdump --uuid *et elle affichera la liste des UUID avec des architectures valides.

L'UUID correspondra à l'e-mail d'avertissement d'Apple

Le projet principal et la cible des cabosses de cacao supposent avoir la même architecture valide. Ce faisant, cela résoudra le problème.

miOS
la source
Je pense que cela explique le mieux ce qui se passe. Je n'ai ces avertissements que sur les bibliothèques avec l'architecture armv7 car mon projet est construit uniquement pour arm64. Reste à savoir si je devrais ajouter armv7 au projet ou le supprimer des pods.
Ariel Bogdziewicz
6

Fonctionné pour moi en activant le bitcode - il était éteint avant

Activer le Bitcode - Oui

entrez la description de l'image ici

Tarun Seera
la source
1

Ce qui précède a aidé à résoudre les problèmes, mais n'a pas pu résoudre. Nous avions un projet sur iOS 12 mais les pods 10 - ont conduit à un tas de fichiers armv7. La mise à jour du pod vers iOS 12 est résolue instantanément.

drees
la source
0

Le même problème a été résolu en ayant le même "Général" => "Infos de déploiement" => "Cible de déploiement" pour toutes mes cibles.

ARR
la source
0

Dans Xcode, recherchez dans «Build Settings for« Strip Debug Symbols During Copy »(COPY_PHASE_STRIP). Lorsqu'il est activé, les symboles de débogage sont omis de votre .app et placés dans un fichier .dSYM. Sinon, votre .app contient ces symboles. (Par défaut, les symboles de débogage sont supprimés des versions de version pour des raisons d'obscurcissement. Vous ne devriez probablement pas modifier ce paramètre pour la configuration de la version.)

Assurez-vous de cocher cette option dans les paramètres de construction du projet

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

Sanad Barjawi
la source
0

Le problème pour moi était une ligne dans mon build.xcconfigdossier. Je devais retirer

IPHONEOS_DEPLOYMENT_TARGET = 11.0

qui définissait le projet pour construire uniquement pour arm64 (et non arm7). En suivant les étapes, @miOSj'ai pu voir que le projet de pods était en cours de construction pour les deux.

Franc
la source
1
stackoverflow.com/a/49063850/3293172 iOS 11 a supprimé la prise en charge d'armv7 et d'armv7, il n'est donc nécessaire que d'arm64 si vous avez une cible de déploiement> = iOS 11.0.
Ariel Bogdziewicz
-2

Pour moi, tout était très simple. J'ai eu le même problème et je ne savais pas quoi faire pendant une semaine.

Après avoir soumis une demande archivée, vous verrez le certificat à distribuer dans une petite fenêtre contextuelle. Il y a une case à cocher après celle-ci, que vous devez décocher. Après cela, vous le soumettez et recevez un e-mail sur les fichiers de symboles. MAIS ce n'est pas un problème. C'est juste un avertissement; pas une erreur! Si vous décochez cette case, votre application sera envoyée correctement. J'espère que cela peut vous aider.

Capture d'écran de la case à cocher et de la fenêtre contextuelle:

Capture d'écran de la case à cocher et de la fenêtre contextuelle

lenden
la source
J'espère vraiment que vous seriez plus détaillé ... Je n'ai aucune idée de la case à cocher ou du popup dont vous parlez. Peut-être une capture d'écran?
Louis Hong
gyazo.com/6d7bb2035979cb75253ba92a40e8d898 Je pense que je le vois, c'est celui-ci
Louis Hong
5
Oui, mais cela supprimera tous les symboles du package et, par conséquent, vous ne recevrez pas de rapports d'incident symbolisés? (Fournissent-ils même des rapports d'incident symbolisés dans les applications App Store maintenant avec TestFlight?)
Markus Rautopuro
30
Ce n'est pas une solution valable au problème. Cela évite le symptôme et ne résout pas le problème. Voir la réponse de Mikhails pour une description de la façon dont vous téléchargez des symboles dont vous n'avez pas besoin. Cette réponse empêche de télécharger des symboles, cassant ainsi la symbolisation du crash via iTunesConnect
JConway
2
NE FAITES PAS cela, si vous le faites, vous ne pourrez pas analyser votre application sur l'App Store pour les erreurs de plantage
user924