Skip to content

Instantly share code, notes, and snippets.

@mackoj

mackoj/SDKExterneEtAPITierces.md

Forked from icPJmobile/iOS-SDKExterneEtAPITierces.md
Last active June 19, 2023 13:48
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mackoj/7f2a1166e707be9401b2d46635ec54a2 to your computer and use it in GitHub Desktop.
Save mackoj/7f2a1166e707be9401b2d46635ec54a2 to your computer and use it in GitHub Desktop.
Download ZIP
Lister ce à quoi les SDK externes et API tierces doivent se conformer avant d'être intégrés dans l'application iOS PagesJaunes. Le but est de ne pas limiter l'évolution de l'application si, par hasard, un SDK était mal conçu.
Raw
SDKExterneEtAPITierces.md

SDK Externe et API Tierces

Objectif : Lister ce à quoi les SDK externes et API tierces doivent se conformer avant d'être intégrés dans l'application iOS. Le but est de ne pas limiter l'évolution de l'application si, par hasard, un SDK était mal conçu.

Veuillez forker ce gist et mettre un ✅ devant ce que vous faites. Renvoyez nous son lien par mail avec l'explication de ce que vous ne faites pas et pourquoi ? 🙂

Besoin

  • On doit pouvoir influer sur les évolutions possibles du SDK afin qu'il puisse évoluer avec nous si besoin.

  • On doit avoir un contact technique direct (et non pas un quelqu'un du support commercial 😉). Cette personne doit avoir la possibilité d'influer sur l'évolution du SDK et nous renseigner techniquement dans un délais acceptable.

  • On doit avoir la possibilité d'envoyer des crashs lié au SDK et de suivre l'évolution de la correction de ces derniers.

  • Les performances du SDK ne doivent pas impacter l'app hôte Apple Performance Tips

  • La consommation réseau doit être raisonnable (faire le moins de requêtes possibles, grouper les requêtes, renvoyer les requêtes échouées au prochain lancement de l'app) et si possible les requêtes moins importantes devraient être étalées dans le temps afin de ne pas impacter négativement l'experience utilisateur.

  • Avoir une interface de test / debug / une console de test dans leur back-office et ou une API afin de simuler/forcer le fonctionnement du SDK est un plus non négligeable car il nous permettrait d'automatiser les tests de ce dernier dans notre application.

  • On souhaiterait avoir la possibilité de voir le code qui rentre dans son app et donc préfère ne pas utiliser de SDK avec des sources fermées. Car ce dernier peut faire des actions qui vont à l'encontre de nos CGU et donc pour nous le seul moyen de garantir de qui ce passe est d'avoir du code open source (ou avoir accès au repository privée sur GitHub) et pouvoir auditer toutes les requêtes effectuées par le SDK (à travers l'utilisation de NSURLProtocol par exemple sur iOS). Nous avons eu le problème dans le passé avec des SDKs qui récupéraient des informations utilisateurs sans notre consentement donc maintenant on est plus fermes sur ces questions.

  • Respecter la vie privée des utilisateurs et correctement sécuriser les données qu'ils exploitent (Security Overview / Secure Coding Guide)

  • Le SDK doit être conforme a la RGPD et le pouvoir le prouver

  • Le SDK doit être en mesure de justifier de l'utilisation de toutes les données utilisateur qu'il exploite si il n'en est pas capable il ne doit pas les exploiter

  • Le SDK doit avoir un support officiel de Cocoapods avec des liens encrypter(ssh/https) Trusting third party SDKs @KrauseFx

  • Le SDK doit être rapidement et complètement désactivable à distance par le fournisseur. C'est à dire désactiver tout les appels du SDK pour un temps donné (de 1h à 8000 ans). À l'initialisation de ce dernier, c'est la première chose qu'il doit verifier (activer ou bloquer en remote avant de faire quoique soit en gros).

  • L'entreprise doit maîtriser la technologie qu'elle met à notre disposition. C'est à dire qu'elle ne peut pas utiliser un SDK tier qu'elle-même ne maîtrise sinon :

    • on aura trop d'adhérence en cas d'évolution
    • on ne maîtrisera pas ce que deviennent nos données utilisateur
    • on aura encore moins de compréhension de ce qui est fait dans notre appli
    • les problèmes de sécurité / juridique associés seront encore plus élevés

Réseaux / API

Sécurité

Toutes les requêtes doivent être en HTTPS:

Si le certificat ou le serveur ne supportent pas ces pré-requis, le SDK ou l'API ne pourront pas être intégrés.

  • le support du certificate pinning est souhaité mais optionnel.
  • le support de l'OCSP Stapling est souhaité mais optionnel.
  • l'utilisation de protocole d'authentification standard tels que OAuth2 est souhaité.
  • Quel est le cipher utiliser : XXX

Voici la liste des ciphers supportés :

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Performance

  • le temps de réponse moyen doit être inférieur à 750 ms
  • le timeout côté serveur doit être inférieur à 1000 ms
  • l'utilisation de HTTP/2 est un plus appréciable
  • le support de l'IPv6 est primordiale

Documentation

Le SDK doit

Compatibilité:

  • supporter les OS >= iOS 10
  • être compatible avec les nouvelles versions d'iOS et d'Xcode dès leur sortie (versions betas et releases). Le SDK ne doit pas nous empêcher d'évoluer / avancer
  • être compatible Objective-C et Swift 4
  • doit faire toutes ses requêtes en HTTPS
  • avoir des slices armv7, armv7s, arm64, x86_64, i386 fonctionner dans le simulateur
  • supporter du Bitcode / App Slicing (App Thinning in Xcode)
  • supporter le semantic versioning
  • si nécessaire doit être compatible avec les extensions (Widget Today / Clavier / etc..) ainsi qu'avec les autres plateformes (watchOS / tvOS)

Fonctionnalités appréciables:

  • l'utilisation de HTTP/2
  • l'utilisation de NSURLSession (URL Session Programming Guide). Si il utilise NSURLSession , on doit pouvoir lui passer une liste de classes supportant le protocole NSURLProtocol et il doit les ajouter à sa NSURLSessionConfiguration en les ajoutant à sa propriété protocolClasses afin de pouvoir correctement auditer les requêtes qu'il effectue
  • avoir le code du SDK en open source (simplicité d'audit et de corrections de bugs, optimisation de performance, réduction du temps de démarrage de l'app car le SDK peut être directement inclut dans le projet et donc ne pas impacter le temps pre-main)
  • avec une API bien structurée Better Translation of Objective-C APIs Into Swift

Accessibilité:

SDK:

  • être fournis via un gestionnaire de dépendances tel que Cocoapods / Carthage / Swift Package Manager (il peut utiliser un repository privé, comment faire un repo privé)
  • s'il y a des ressources associées au SDK, elles doivent faire partie du package récupéré par le gestionnaire de dépendances
  • démarrer uniquement si on lui demande (ne doit pas démarrer tout seul / ne doit pas impacter l'app sans notre consentement )
  • éviter d'avoir des dépendances à des librairies tierces (AFNetworking, Reachability, etc...). Si c'est le cas, elles doivent être préfixées
  • la documentation du SDK doit être visible depuis Xcode en survolant les fonctions du SDK. Elle doit être disponible en Objective-C et en Swift 4
  • nous notifier s'il affiche de l'UI (___WillAppear, ___DidAppear, ___WillDisappear, ___DidDisappear) à travers un delegate ou des blocks
  • avoir une API simple et descriptive comme celle d'Apple (Coding Guidelines for Cocoa / Building Responsive and Efficient Apps with GCD / Better Translation of Objective-C APIs Into Swift) et réaliser avec des techniques actuelles ( Adopting Modern Objective-C)
  • avoir une API correctement annotée avec en terme de nullability ( Nullability and Objective-C, Import Objective-C Constants as Swift Types)
  • doit avoir une option afin de simplement le compiler de façon static, voir le livrer sous forme binaire (afin de réduire l'impact sur le temps de démarrage pre-main de l'app)
  • doit supporter le lowPowerModeEnabled (docs), décaler ces requêtes et réduire sont travail au minimum voire se désactiver dans ce cas
  • doit préférer les technologie natives d'iOS plutôt que de re-inventer la roue (par exemple utiliser ARKit si le SDK fait de la réalité augmentée ou Vision s'il analyse des visages ou encore CoreML/CoreImage s'il fait de la reconnaissance d'image)

Debug:

  • pouvoir activer le log avec différents niveaux de verbosité ou au contraire désactiver le log du SDK à 100%
  • nommer les threads utilisés pour qu'on puisse debugger en configurant la propriété **name ** de NSOperationQueue
  • être livré avec une app ou des apps de test qui utilisent ** toutes ** ses APIs et qui compile
  • si le SDK en a besoin le mieux est qu'il ait son propre fichier de configuration de type plist dissocié de l'info.plist afin de lui appliquer une configuration custom

Performance:

Le SDK ne doit pas

  • faire de swizzling
  • bloquer le main thread. Il doit pouvoir fonctionner correctement sur un thread autre que le main thread et ne doit pas assumer qu'il sera démarré sur le main thread sinon cela veut dire qu'il affiche et font des opérations nécessitant le main thread sans verifier qu'ils sont effectivement dessus.

Documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment