framework swift 2 dans un projet swift 3
dream hope
Membre
Bonjour
J'ai créé un projet en utilisant xCode 8 et Swift 3.
Dans ce projet, je dois intégré un framework qui a été compiler en swift 2.
Et j'ai l'erreur suivante :
ld: /MonFmk.framework/MonFmk compiled with older version of Swift language (2.0) than previous files (3.0) for architecture armv7
J'ai tenté de mettre Use Legacy Swift Language Version à YES, mais la, c'est tout le projet en Swift 3 qui ne compile plus...
Sur le net, j'ai juste trouvé des explication pour convertir se Swift 2 à Swift 3, or je ne peux convertir ni le projet, ni le framework.
Auriez vous une solution ?
Merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Recompile la framework en Swift 3.
Tu ne peux de toute façon pas utiliser de framework preÌ-compileÌ avec Swift.
Il te faut les sources obligatoirement c'est le soucis d'instabiliteÌ d'ABI qui fait ça.
Avec Swift 4.0 on pourra de nouveau travailler comme on le faisait en Obj-C comme l'a dit CeÌroce. (enfin normalement, ça devait deÌjaÌ€ être le cas pour Swift 3.0
Ok, merci de vos réponse.
Je suis déçut de la part d'Apple, mais on va devoir faire avec.
Ca va pas encourager mon patron à passer à Swift...
Si tu lisais les docs Swift, c'est bien évident qu'il est un langage en pleine évolution. En adoptant Swift, il devrait être entendu que l'on devra réviser le code à chaque révision lu langage ou d'ABI.
Mais ce n'est pas pénible de le faire ; Xcode s'occupe de vous montrer la plupart des nouveautés et, de mon expérience, ça ne met que quelques minutes pour le faire.
En revanche, en restant en Objective-C, on n'aura pas les avantages de sécurité des types, etc que Swift on donne.
Et il aurait peut-être raison.
Quand je pense que certains développeurs ont convaincu leurs boites de réécrire complètement des apps en swift dès la sortie de Swift 1.0... c'est pas très pro comme attitude.
C'est le soucis quand on travaille avec des technologies émergentes.
C'était clair dès le deÌbut que Swift était en beta et qu'il allait évoluer avec du source breaking à la cleÌ...
Au boulot on a fait le choix de travailler sur des techno beta (voire alpha et parfois WIP si vous voulez mon avis) ça demande beaucoup de travail mais c'est le client qui veut ça. Donc c'est pas forceÌment pas pro comme comportement c'est juste être visionnaire et monter dans le train avant qu'il démarre.
Enfin, faudrait définir visionnaire.
Bonjour,
Si tu as trouvé ce framework sur GitHub essaye a tous hazard de voir si il existe une branche swift 3 de ce projet.
EÌ‚tre visionnaire dans ce cas c'est investir du temps dans une techno qui va devenir une norme à moyen ou long terme.
On connait tous Apple ici et on sait très bien que Swift prendra toÌ‚t ou tard la place d'Objective-C.
D'ici un an la majoriteÌ des clients vont vouloir du Swift presque exclusivement. Pourquoi ? Parce que c'est ce qu'on va utiliser sur un produit Apple durant les 20 prochaines années. Qu'est ce qui vaudra mieux alors ? Avoir du code en Obj-C qui va poser peu aÌ€ peu des problèmes et qu'il faudra réécrire en Swift ? Ou un code Swift qu'il suffirait de faire eÌvoluer (ou pas vu la stabilisation de l'ABI) ?
Je pense qu'on connait la reÌponse. Ici on ne parle pas d'un langage creÌeÌ sur du temps libre qui a un peu le vent en poupe mais d'un langage qui est porteÌ aussi bien par une multinationale que par une communauteÌ open-source (C++ est neÌ dans les bureaux d'AT&T et court depuis des lustres).
Alors, non, ça n'est pas deÌraisonnable que de se mettre à Swift le plus toÌ‚t possible parce que quand ça sera la norme –ou du moins très demandeÌ– ces entreprises auront une XP à faire valoir et deÌcrocheront plus facilement des contrats.
Tu connais peut-être cette citation :
Je dois avoir une étiquette "vieux con" sur le front car tu ne réponds pas vraiment à ce que j'écris mais tu réponds à quelqu'un qui dirait qu'il ne faut pas se mettre à Swift ou qu'il faut attendre le dernier moment.
J'ai écris un framework pour faire du Swift 2.2 côté serveur, pour me former à Swift, il y a un an. Donc je ne suis pas vraiment dans l'attentisme.
Je dis juste qu'à l'époque de swift 1.0, le fait de ré-écrire complètement une app existante codée en Objective C et qui fonctionne, en swift 1.0, c'est un peu une escroquerie. Ce n'est surement pas honnête, pas pro ou plutôt pas très déontologique.
Par contre, profiter d'une évolution, ou d'un nouveau développement pour faire du swift (surtout à partir de la version 2) je dis oui.
Je dirais même que pour démarrer aujourd'hui une nouvelle app en Objective-C et pas en swift, il faut vraiment avoir de bonnes raisons.
On se forme tous plus ou moins sur des contrats ou des projets, c'est nécessaire dans le développement informatique, mais il y a un curseur à positionner de manière déontologique entre le besoin de connaissances pratiques sur des nouvelles technologies et les besoins réels d'un projet.
Après, pourquoi pas si c'est assumé en tant qu'opération de comm' : "regardez comme on est moderne, on a déjà ré-écrit toute notre codebase en swift 1.0 beta. Venez chez nous, on est trop cool."
En tous cas, je ne travaillerai surement pas avec une boite qui profite des projets de ses clients pour se faire de l'XP et de la réputation en conseillant n'importe quoi. Dans ce cas, je vois bien dans leurs yeux que l'étiquette sur mon front, c'est "gros pigeon".
Il s'avère en fait que nous sommes d'accord.
Il est bien entendu relativement stupide de passer un app fonctionnelle dans un langage instable. C'est limite de l'heÌreÌsie.
Mais là , maintenant, meÌ‚me si Swift 4 risque d'être source breaking (et encore ils se taÌ‚tent, j'ai plus la source mais il m'a semblé voir passer ça sur la ML), il faut passer à Swift pour les nouveaux projets.
Cool d'avoir des infos de première main à ce sujet. Je me demandais si Swift 3 avait rempli ses objectifs ou pas.