Des apps iOS plantent à cause du SDK Facebook [MAJ : problème corrigé]

Stéphane Moussie |

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.


Tags
avatar Xavier Briole | 

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 !

avatar gwen | 

@xbriole

Ça ne changera rien. Il y auras toujours le sign in de Facebook à côté de celui d’Apple.

avatar Furious Angel | 

Est-ce qu’il y a une seule bonne nouvelle chez Facebook en ce moment ?

avatar dodomu | 

@Furious Angel

Oui, tout le monde commence à se rendre compte que c’est moisi🤩

avatar Ktv75 | 

Pas ce problème avec apple plans et Apple music 😉🙂

avatar Glop0606 | 

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.

avatar Ichigo-Roku | 

Tu peux désinstaller la moitié des tes applications. Tu as énormément d'applications qui proposent de se connecter via Facebook.

avatar gwen | 

@Ichigo-Roku

La moitié, tu es optimiste. On es proche du 100% en fonction des logiciels installés.

avatar Oliviou | 

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 ?)

avatar Boboss29 | 

@Oliviou

Software développement kit. C'est en gros une trousse à outils.

avatar ThibaultV | 

C'est expliqué dernière ligne de l'article...

avatar hexley | 

Ok je comprends pourquoi quelques jeux et Instagram plantent !
Merci

avatar alan1bangkok | 

suis en 12.4.7
jamais eu Facebook
Spotify plante aussi
 est concerné donc
sur mon Redmi avec androïd pas de plantage

avatar iMinh | 

C'est le cas pour Viber

avatar sImPOD | 

Appli Radio France out as well.

avatar Oliviou | 

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...

avatar Siilver777 | 

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

avatar beteldor | 

Et les développeurs sont incapables de faire en sorte que leur appli ne plante pas quand y’a un dysfonctionnement chez Facebook ?
Absurde.

avatar Siilver777 | 

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.

avatar iftwst | 

@Siilver777

Ah Facebook. Si dispensable.

avatar beteldor | 

@Siilver777

C’est bien évidemment possible puisque de nombreuses apps comme Deliveroo continuent de fonctionner parfaitement.

avatar Nico_Belgium | 

@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.

avatar dodomu | 

@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...

avatar beteldor | 

@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

avatar sebasto72 | 

@beteldor

Ben voilà, exactement. Fonctionnement attendu d’une application écrite correctement... Merci pour l’exemple :)

avatar Nico_Belgium | 

@beteldor

Je ne pense pas que ce soit lié au problème en question ;-)

avatar beteldor | 

@Nico_Belgium

De quoi parles-tu ?

avatar sebasto72 | 

@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.

avatar Nico_Belgium | 

@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..

avatar sebasto72 | 

@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.

avatar Nico_Belgium | 

@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.

avatar sebasto72 | 

@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...

avatar Nico_Belgium | 

@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 :)

avatar sebasto72 | 

@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.

avatar Nico_Belgium | 

@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 »

avatar Nico_Belgium | 
avatar sebasto72 | 

@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...

avatar Nico_Belgium | 

@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 ^^’

avatar sebasto72 | 

@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 !

avatar Nico_Belgium | 

@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.

avatar MarcMame | 

@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.

avatar sebasto72 | 

@MarcMame

Pour une phase préliminaire d’initialisation, ça peut s’expliquer, non ?

avatar MarcMame | 

@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.

avatar sebasto72 | 

@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 !

avatar Tignus | 

@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..

avatar beteldor | 

@Tignus

Yep,
Tiens Cafeyn aussi a continué de fonctionner normalement...

avatar dodomu | 

@Tignus

Exactement 😙

avatar sebasto72 | 

@beteldor

+1

avatar bidibout | 

Gros soucis de mon côté ce matin avec Molotov mais sur tvOS 🤔 Je ne sais pas si c'est lié.

avatar Rez2a | 

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

CONNEXION UTILISATEUR