Skip to content

Instantly share code, notes, and snippets.

@icPJmobile

icPJmobile/iOS-SDKExterneEtAPITierces.md

Last active February 13, 2020 10:28
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 8 You must be signed in to fork a gist
  • Save icPJmobile/fed7723f8ede3bfa095559d2c57e1a51 to your computer and use it in GitHub Desktop.
Save icPJmobile/fed7723f8ede3bfa095559d2c57e1a51 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
iOS-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 PagesJaunes. 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.

  • Le SDK doit gerer tout son log dans l'app Console de macOS a travers l'api OSLog afin de ne pas polluer la console de l'app hote(Apple Logging, Exemple d'utilisation de OSLog)

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

  • Est ce que le SDK utilise __attribute__ ((deprecated("Cet méthode est déprécier veuillez utiliser XYZ"))) les méthodes déprécier est ce que vous pouvez utiliser source

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

  • Est ce que le SDK suis ces principes en terme de vie privée Better Apps through Better Privacy ?

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

  • Le SDK doit respecter et enforcer les regles de l'AppStore car des apps ont déjà été bannie parce que un SDK et le client qui l'utilisait n'y faisait pas attention Teemo aka Databerries a causer Le Figaro, Marmiton, Closer, Akinator, VDM, Challenges a étre bannie ou retirer du store temporairement. C'est a dire nous empecher de faire des conneries en l'utilisant et nous pousser a bien suivre et comprendre les règles afin d'éviter les surprises.

  • L'équipe derrière le SDK doit communiquer en case de crise par exemple récemment AppSee est rentrer dans le viseur d'Apple et leur actions a été de nous prevenir rapidement d'enlever le SDK de l'app.

  • Le SDK doit passer le linter de cocoapods pod lib lint SDK.podspec --no-clean --verbose --swift-version=4.2 --use-libraries avec --use-libraries afin de garantir que le SDK puisse se builder de facon static avec la --swift-version=4.2 pour garantir le support de la dernière version de Swift.

  • Avoir un moyen de suivre le volume de probleme majeur d'une plateforme Crash en prod d'accengage et prevoir une compensation en cas de probleme majeur

  • Le SDK doit faire moins de 50mo afin de pouvoir etre mis sur notre repository Github avec le reste du code du projet

  • 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/JWT 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)
  • Le SDK ne doit pas se baser sur fichier UserDefault.standard elle doit le sien et le maintenir a coté car le UserDefault.standard peut etre fortement modifier voir flusher par l'app.

Fonctionnalités appréciables:

  • l'utilisation de HTTP/2
  • l'utilisation de NSURLSession (URL Session Programming Guide).
  • 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.

Stat d'utilisation du SDK

On doit pouvoir tester les stats d’un SDK avec un outils comme http://metrics.cocoapods.org/api/v1/pods et avoir les metrics d’utilisation de ce dernier cela nous permet de voir combien d’app l’utilise et depuis combien de temps il existe combien de fois il est télécharger etc...

http://metrics.cocoapods.org/api/v1/pods/UrbanAirship-iOS-SDK

“download_total”: 4.027.732,
“app_total”: 8.107,
“created_at”: “2015-05-25 09:09:00 UTC”,
“updated_at”: “2018-10-11 09:15:30 UTC”,
    
    
http://metrics.cocoapods.org/api/v1/pods/Alamofire

“download_total”: 42.097.177,
“app_total”: 662.839,
“created_at”: “2015-05-25 09:37:27 UTC”,
“updated_at”: “2018-10-11 09:16:33 UTC”,


http://metrics.cocoapods.org/api/v1/pods/Appsee

“download_total”: 2.658.359,
“app_total”: 12.954,
“created_at”: “2015-05-25 09:21:19 UTC”,
“updated_at”: “2018-10-11 09:15:55 UTC”,


http://metrics.cocoapods.org/api/v1/pods/Fabric

“download_total”: 50.998.892,
“app_total”: 325.405,
“created_at”: “2015-05-25 09:06:20 UTC”,
“updated_at”: “2018-10-11 09:15:23 UTC”,

http://metrics.cocoapods.org/api/v1/pods/Firebase

“download_total”: 23.877.096,
“app_total”: 479.914,
“created_at”: “2015-05-25 09:12:58 UTC”,
“updated_at”: “2018-10-11 09:15:40 UTC”,

On préfere les SDKs qui sont utiliser par plus de 5.000 apps on ne souhaite pas être les testeurs d’un nouveau SDK mais exploiter des outils stable, solide et optimiser pour le mobile.

Documentation

@icPJmobile
Copy link
Author

Ajouter le low data mode

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