Des apps iOS plantent à cause du SDK Facebook [MAJ : problème corrigé]
De nombreuses apps iOS rencontrent un problème identique en ce moment même : elles plantent au démarrage, ce qui est plutôt gênant. C'est le cas de Spotify, Waze, PUBG Mobile, Timepage, France Inter, Le Bon Coin, L'Équipe et d'autres.
Ce problème est causé par le SDK de Facebook intégré à ces apps. Même si vous n'avez pas installé l'application Facebook sur votre iPhone, vous êtes affecté. Ce SDK est utilisé par les applications pour connecter leurs utilisateurs via leur identifiant Facebook ou obtenir des statistiques d'utilisation.
Une épidémie de plantages identique avait eu lieu en mai (durant la nuit en France), déjà à cause du SDK de Facebook qui avait été mal configuré. Elle avait duré quelques heures. La liste de toutes les applications exploitant le SDK de Facebook est disponible sur App Sight. Notez que ces apps ne sont pas toutes victimes du bug, cela doit dépendre de la version du SDK embarquée.
Facebook est au courant du problème et travaille à le résoudre. Une issue a été ouverte sur GitHub.
Mise à jour à 14h40 : en activant le mode avion, vous pouvez lancer les apps affectées. Évidemment, sans connexion, certaines seront inutiles. Certains utilisateurs disent avoir réussi à contourner le bug pour Waze de la manière suivante : killer Waze (l'éjecter de la vue multitâche), activer le mode avion, lancer Waze, attendre que la carte s'affiche, puis désactiver le mode avion. Cette astuce ne fonctionne pas pour nous ; dès que nous désactivons le mode avion, Waze plante.
Mise à jour à 14h50 : le problème semble corrigé. D'après nos constatations, les applications affectées se lancent désormais. Facebook a réalisé un changement côté serveur.
On se rend compte a quel point toutes ces apps dépendent de Facebook et c'est grave. Vivement que le "Sign In with Apple" prenne le dessus !
@xbriole
Ça ne changera rien. Il y auras toujours le sign in de Facebook à côté de celui d’Apple.
Est-ce qu’il y a une seule bonne nouvelle chez Facebook en ce moment ?
@Furious Angel
Oui, tout le monde commence à se rendre compte que c’est moisi🤩
Pas ce problème avec apple plans et Apple music 😉🙂
Merci pour l’info. J’ignorai que Spotify avait avoir quelque chose à voire avec Facebook. Bon ben moi qui n’arrivait pas à me décider, ce sera Apple Music. A part WhatsApp que j’utilise par nécessité je n’installe par principe rien en rapport avec Facebook. C’est juste fou comme facebook est partout.
Tu peux désinstaller la moitié des tes applications. Tu as énormément d'applications qui proposent de se connecter via Facebook.
@Ichigo-Roku
La moitié, tu es optimiste. On es proche du 100% en fonction des logiciels installés.
Pardon mais je n’ai pas Facebook. Comment le SDK de Facebook peut-il faire planter les apps sur MON iPhone ?
(C’est quoi un SDK ?)
@Oliviou
Software développement kit. C'est en gros une trousse à outils.
C'est expliqué dernière ligne de l'article...
Ok je comprends pourquoi quelques jeux et Instagram plantent !
Merci
suis en 12.4.7
jamais eu Facebook
Spotify plante aussi
est concerné donc
sur mon Redmi avec androïd pas de plantage
C'est le cas pour Viber
Appli Radio France out as well.
Non mais c’est l’hallu ! C’est quoi un SDK ? Pourquoi ça fait planter des apps sur des iPhones qui n’ont pas Facebook ? Genre le mien?
Est-ce que Facebook est informé de mon activité sur Spotify ?
Si vous pouvez faire un article pour expliquer ça...
Software Development Kit. C'est comme une boîte à outil fournie par Facebook pour que les autres apps puissent intégrer simplement les fonctionnalités Facebook dans leurs apps (comme le Sign In With Facebook ou le partage).
Si il y a quelque chose qui fait planter ce SDK (du code de Facebook présent à l'intérieur de ce même SDK, entre autre), toute l'app plante, car ce n'est qu'au final que du code présent à l'intérieur même de l'app concernée, peu importe la provenance.
À mon avis, le SDK de Facebook doit très probablement communiquer avec un serveur qui ne renvoie plus la bonne info depuis aujourd'hui, ce qui destabilise le SDK qui plante. C'est la seule explication que je vois pour que ça plante sur TOUTES les apps EN MEME TEMPS
Et les développeurs sont incapables de faire en sorte que leur appli ne plante pas quand y’a un dysfonctionnement chez Facebook ?
Absurde.
Ce n'est tout simplement pas possible, car le code de Facebook est intégré à l'app, au final. L'erreur se produit donc au sein même de l'app, ce qui la fait planter.
@Siilver777
Ah Facebook. Si dispensable.
@Siilver777
C’est bien évidemment possible puisque de nombreuses apps comme Deliveroo continuent de fonctionner parfaitement.
@beteldor
Les développeurs n’ont pas la main sur ce que le SDK fait. Donc non je confirme que ce n’est normalement pas possible.
Si ça fonctionne sur deliveroo, c’est peut être tout simplement parce qu’ils n’utilisent pas le SDK et font appels directement à l’API ou en intègrent une autre version.
@Nico_Belgium
Ça doit être possible, ça dépend de plein de paramètres, mais de manière générale quand on utilise des sdk de tierce partie on contrôle un minimum ce qui se passe, et si ce dernier plante on peut attraper l’erreur au vol et continuer de faire tourner le programme, éventuellement sans la fonctionnalité du sdk, mais continuer quand même.
Après est possible que l’erreur ne soit pas attrapée, soit parce que le développeur de l’application ne le fait pas, ou parce que le sdk ne le permet pas...
@Nico_Belgium
?
J’ai le crashlog de Deliveroo sous les yeux. L’appli continue bien de fonctionner.
Exception type: NSInvalidArgumentException
Reason: -[NSNull count]: unrecognized selector sent to instance 0x1c2e64070
@beteldor
Ben voilà, exactement. Fonctionnement attendu d’une application écrite correctement... Merci pour l’exemple :)
@beteldor
Je ne pense pas que ce soit lié au problème en question ;-)
@Nico_Belgium
De quoi parles-tu ?
@Nico_Belgium
Bien sûr que si c’est possible. Et c’est même une des règles de base de développement : contrôler les réponses des fonctions appelées, externes comme internes, et contrôler aussi le comportement lors de l’appel, pour que justement, en cas de plantage d’une fonction, le programme appelant reprenne la main sans tout mettre par terre.
=> dans le cas présent, seule la fonction « se connecter avec FB » ne devrait pas fonctionner.
@sebasto72
Sauf que Facebook fait des opérations lors de l’initialisation même du SDK => sans gestion d’erreur.
Et c’est ce code obscur qui a entraîné des erreurs la dernière fois et qui en re entraînent encore aujourd’hui.
Tu penses que si c’était de la simple gestion d’erreur, des apps comme Spotify n’auraient certainement pas été touchées..
@Nico_Belgium
L’init est un appel de fonction comme un autre. Le développeur pourrait même se servir de ce plantage d’init pour griser le « connect with FB » ou afficher un message explicite à l’utilisateur lorsqu’il tentera d’utiliser la fonction Connect.
@sebasto72
Sauf que, il y a des fonctions qui renvoient un résultat (dont des éventuels codes d’erreurs) et d’autres qui n’en renvoient pas....
En l’occurrence l’initialisation est typiquement le genre de méthode à ne pas en renvoyer.
@Nico_Belgium
Ah ok. Je pense que tu confonds gestion des codes retour et gestion des exceptions...
En ultra simplifié, et en pseudo code :
Si on se contente de gérer les codes retour comme ceci :
If ( Init_FB_SDK <> ok)
Print « erreur »
Continue...
On est dans le cas que tu décris. Si Init_FB_SDK plante, toute l’appli plante.
Pour éviter cela, on encadre l’appel par une gestion d’exceptions
Try
{
If ( Init_FB_SDK = ok)
Print « erreur »
}
Catch (exceptionDeTouteSorte)
{
Print « FB inutilisable »
}
Continue...
Ce mécanisme existe depuis des décennies...
@sebasto72
Alors sauf que encore une fois.
Pour pouvoir obtenir une gestion d’erreur, la méthode appelée doit être prévue pour cela.
Typiquement en swift, elle doit posséder la mention « throws » pour signaler « hey je peux te renvoyer une erreur :-)
Si un développeur tente d’appeler une méthode qui throw sans prévoir la gestion d’erreur ( le fameux try que tu mentionnes), l’app ne compilera tout simplement pas.
Et si le développeur du SDK ne prévoit pas de « thrower » une erreur, les développeurs ne peuvent pas le prévoir non plus :)
@Nico_Belgium
La déclaration Throws permet de spécialiser les exceptions d’une méthode donnée. N’importe quel méthode est susceptible d’envoyer les exceptions définies par défaut dans le langage (MemoryException, IOException, etc).
Je ne suis pas familier de swift, mais vu qu’il est plus récent que Java ou Objective-C, je doute fort que cela soit différent.
@sebasto72
Et bien je t’invite à faire le test sur le playground ;-)
Func makeFatalError() {
fatalError(message: « crash »)
}
Do {
Try makeFatalError()
} catch {
print(« error »)
}
1) ça plante
2) le compilateur met un warning Indiquant que la méthode ne renverra rien en cas d’erreur car elle n’est pas « throws »
@sebasto72
Un peu de doc supplémentaire :)
https://stackoverflow.com/questions/41994538/swift-error-handling-for-methods-that-do-not-throw
@Nico_Belgium
Merci, j’ignorais cette spécificité de Swift. Choix assez radical quand même !
=> ça peut expliquer les crashes des applis en Swift.
=> Pour les autres, ça se gère. Et il semble que plusieurs applis le gèrent bien. Elles ne doivent pas être écrites en Swift...
@sebasto72
Probablement vu que visiblement en obj-c cela se gère comme ça ( moi aussi j’aurai appris un truc grâce à toi. Étant dev swift je ne connaissais pas ce mode de fonctionnement en java et en obj-c).
C’est vrai que cela permet moins de contrôle sur le code étranger, mais par contre cela oblige à plus de rigueur sur son propre code.
Cela empêche certainement des réflexes du genre « ça plante ? Pas grave. J’ai qu’à le stopper avec un try » et cela oblige souvent à chercher la vraie source du problème ^^’
@Nico_Belgium
Le diable se cache dans les détails oui !
C’est drôle ta dernière remarque sur les try/catch, quand j’ai découvert Java en 97, venant du C, je me suis dit « super les try/catch, au moins on gérera les erreurs correctement » 😂
La gestion des erreurs et les développements, on n’a pas fini d’en parler amha !
@sebasto72
Et de toute manière. Quand bien même le développeur ne prendrait pas en compte les dires erreurs, ce n’est pas ça qui ferait cracher le SDK dans son initialization. Ça le ferait craquer probablement plus tard pour une toute une autre raison, mais les apps ne planteraient pas toutes sur la même ligne située dans le SDK même.
@sebasto72
"dans le cas présent, seule la fonction « se connecter avec FB » ne devrait pas fonctionner."
Cette fonctionnalité n’a absolument aucune raison légitime de se connecter aux serveurs de FB tant qu’elle n’est pas sollicitée par l’utilisateur.
@MarcMame
Pour une phase préliminaire d’initialisation, ça peut s’expliquer, non ?
@sebasto72
"Pour une phase préliminaire d’initialisation, ça peut s’expliquer, non ?"
Je ne dis pas que ça ne peut pas s’expliquer je dis que ça ne devrait pas être actif par défaut.
@MarcMame
Idéalement oui je suis d’accord.
J’imagine que ça permet de réduire le temps de connection perçu par l’utilisateur (ce doit être idem pour Google, FB, et autres), si on veut une UX fluide, je suppose que c’est le plus simple et direct...
De nos jours, je vois même une nouvelle raison de changer cette façon de faire : le GreenIT, ça peut commencer par éviter des appels réseau pour rien !
@beteldor
Si, normalement ca existe. Il y a des moyens d'intercepter les erreurs et d'afficher un message comme quoi login via facebook est indispo par exemple mais si ça n'a pas été prévu, il faut mettre à jour l'appli concernée..
@Tignus
Yep,
Tiens Cafeyn aussi a continué de fonctionner normalement...
@Tignus
Exactement 😙
@beteldor
+1
Gros soucis de mon côté ce matin avec Molotov mais sur tvOS 🤔 Je ne sais pas si c'est lié.
Je crois que vu le nombre de commentaires confus, il serait bon de préciser dans l’article que ça n’a rien à voir avec l’appli Facebook en elle-même (ni le fait de l’avoir déjà installée ou pas), et que ce n’est pas non plus la faute d’Apple ou d’iOS.
Le problème, c’est que Facebook met à disposition des développeurs un « framework », en gros toute une collections de fonctions qu’ils ont fait eux-mêmes, et qui permet aux développeurs d’intégrer plus facilement la connexion via un compte Facebook dans leurs applis, ainsi que des méthodes de tracking de données, entre autres. Autant dire que pas mal d’applications embarquent le framework en question.
C’est ce framework qui déconne actuellement et rien d’autre. Si Facebook dit qu’ils peuvent régler le problème eux-mêmes, alors il ne sera pas nécessaire de mettre à jour les applications qui déconnent, c’est sans doute lié à un appel réseau quelconque. Mais effectivement c’est déjà la 2e fois que leur framework fait exploser un paquet d’applis en plein vol, ce n’est pas censé arriver.
Pages