Je dis OUI, quand vous le pouvez ! Cela dépend de l'image. Je suis d'accord avec Kevin sur les photographies, les images matricielles (informations en pixels) comme PNG et JPG sont la voie à suivre. Mais si vous faites des boutons ou des illustrations, et qu'un SVG est disponible, je vous recommande vivement de l'utiliser. Il s'agit d'utiliser une image vectorielle (instruction de dessin). Voici pourquoi.
Raison 1 : indépendance de résolution. Si vous utilisez des vecteurs, vous êtes à l'abri de l'avenir des écrans plus grands ou de plus haute résolution plus tard. Vous savez que cela va arriver !
Raison 2 : Une taille d'application plus petite. Si vous avez 1x, 2x et 3x rasters, vous pourriez facilement ajouter 10k de données raster à votre bundle pour chaque image, cela peut être beaucoup plus. Si vous avez 30 images, les calculs commencent à s'accumuler rapidement. Une instruction de dessin compilée sera bien inférieure à 1k. Vous pouvez facilement économiser des mégaoctets sans faire d'efforts. C'est aussi respecter le plan de données de votre utilisateur.
Raison 3 : une vitesse de démarrage de l'application plus rapide. Les images de votre dossier assets sont chargées au démarrage, ainsi que toutes vos bibliothèques. Plus vous avez d'images, plus il faut de temps pour passer de votre écran de lancement à votre premier écran. Vous pouvez sensiblement charger plus tôt.
Raison 4 : la perfection des pixels. Si votre UIImageView n'a pas exactement la taille de l'image, iOS l'interpole. Si l'image fait 300 pt, et que votre image n'a besoin que de 200 pt, elle est rétrécie. Ce n'est pas horrible, mais acceptable. En revanche, si votre image est de 100 pt et qu'elle doit être agrandie, vous obtenez des "dents de scie". Horrible. Avec le vecteur, vous dessinez un 200pt parfait pour correspondre à votre UIImageView, ce qui signifie la meilleure qualité toujours.
Mythe : il faut plus de temps pour dessiner le vecteur. Seulement si le fichier SVG est quelque chose de fou, comme 300k+, alors oui, le vecteur n'est pas une bonne idée. Mais pour 99% de vos images, c'est à peu près la même vitesse. Il est facile de faire un benchmark avec Instruments, donc ne croyez pas ce mythe. iOS met en cache UIImages, et nous parlons de vecteur à UIImage.
Comment faites-vous du vecteur alors ? Vous avez des options.
Option 1 : un actif PDF. Le plus simple est un vecteur dans un fichier PDF, mais vous ne bénéficiez pas de la raison n°3, car il est dans le bundle.
Option 2 : Charger dans une WebView. S'il vous plaît, ne le faites pas, vous ne faites que demander des ennuis. Certains SVG ne rendront pas du tout.
Option 3 : utiliser une bibliothèque tierce. Il y a des solutions dans GitHub, comme SVGKit, qui supportent une bonne partie, mais pas tout. Elles sont généralement gratuites.
Option 4 : PaintCode. C'est l'option que j'utilise, car elle présente une TONNE d'avantages. Il n'est pas gratuit, mais il vaut chaque centime. Il peut non seulement faire le code de dessin pour vous, mais aussi le code UIImage, avec mise à l'échelle. Sans parler de la possibilité d'animer ou de contrôler grandement chaque élément du dessin lui-même.
Par exemple, j'utilise PaintCode pour un indicateur de progression circulaire, comme le fait l'application App Store lorsque vous téléchargez. Je modifie simplement le point final d'un chemin. Si vous avez un actif, même un PDF, vous avez une seule couleur de teinte avec laquelle travailler pour l'ensemble de l'image, c'est tout. Ce qui est bien pour la plupart des boutons. PaintCode me permet de modifier n'importe quel trait et n'importe quel remplissage, indépendamment. Ainsi, je peux utiliser une seule image pour la progression, et non pas deux images ou plus. Cela demandera un certain effort au départ pour apprendre les bases de l'outil, mais vos capacités d'image passent à un tout autre niveau.
Donc, si vous voulez la perfection du pixel, la vitesse et la puissance, allez vers le vecteur. Si vous travaillez avec des designers, ils seront ravis. Il peut y avoir plus de raisons et d'options que je n'ai pas mentionnées, mais c'est un début.