framework swift 2 dans un projet swift 3

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


Réponses

  • CéroceCéroce Membre, Modérateur
    Les ABI ont changé entre Swift 2 et Swift 3. Elle ne seront stabilisées que dans Swift 4.
    Recompile la framework en Swift 3.
  • Tu ne peux de toute façon pas utiliser de framework pré-compilé avec Swift. 


    Il te faut les sources obligatoirement c'est le soucis d'instabilité 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 Céroce. (enfin normalement, ça devait dé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... :(


  • Joanna CarterJoanna Carter Membre, Modérateur

    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.


  • Ca va pas encourager mon patron à  passer à  Swift... :(


    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 début que Swift était en beta et qu'il allait évoluer avec du source breaking à  la clé...


     


    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 forcément pas pro comme comportement c'est juste être visionnaire et monter dans le train avant qu'il démarre. 


  • FKDEVFKDEV Membre
    novembre 2016 modifié #8
    Je reformule. Ce qui n'est pas pro ce n'est pas de travailler sur des technos émergentes, c'est de convaincre les décisonnaires qu'il faut adopter des technos émergentes quand ce n'est pas si nécessaire, juste parce qu'on a envie de travailler avec.
  • D'autre part, il ne suffit pas de sauter sur toute nouvelle techno un peu sexy pour être visionnaire.


    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.




  • D'autre part, il ne suffit pas de sauter sur toute nouvelle techno un peu sexy pour être visionnaire.


    Enfin, faudrait définir visionnaire.




    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 majorité 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 évoluer (ou pas vu la stabilisation de l'ABI) ?


     


    Je pense qu'on connait la réponse. Ici on ne parle pas d'un langage créé sur du temps libre qui a un peu le vent en poupe mais d'un langage qui est porté aussi bien par une multinationale que par une communauté open-source (C++ est né dans les bureaux d'AT&T et court depuis des lustres).


     


    Alors, non, ça n'est pas déraisonnable que de se mettre à  Swift le plus toÌ‚t possible parce que quand ça sera la norme –ou du moins très demandé– ces entreprises auront une XP à  faire valoir et décrocheront plus facilement des contrats.

  • Tu connais peut-être cette citation :


    Nous ne voyons pas les choses mêmes ; nous nous bornons, le plus souvent, à  lire des étiquettes collées sur elles. Henri Bergson.

     





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



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




    Il s'aveÌ€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'héré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. 



  • meÌ‚me si Swift 4 risque d'être source breaking 




     


    Cool d'avoir des infos de première main à  ce sujet. Je me demandais si Swift 3 avait rempli ses objectifs ou pas.

Connectez-vous ou Inscrivez-vous pour répondre.