Swift aujourd'hui
Draken
Membre
* prend une moue dédaigneuse * C'est même pas en Swift ton truc, juste du vieil Objectif-C.
Connectez-vous ou Inscrivez-vous pour répondre.
Draken
Membre
Réponses
J'apprendrai le swift quand ce sera plus avancé !
Euh .. t'es au courant qu'on est maintenant à Swift 1.2 ? Et que cela fait prés d'un an qu'Apple accepte les applications en Swift ? On n'ai plus à l'époque du Swift 1.0 version béta.
Oui mais la pleine puissance du Swift ne sera réellement disponible que lorsque les frameworks auront été ré-écrits.
UXKIt n'existe PAS, du moins pas officiellement. Difficile d'avoir des infos dessus. On en sauras certainement plus après la conférence développeur 2015. Mais cela n'a pas d'importance en fait.
Ce qui compte vraiment c'est la manière dont les applications communiquent avec les frameworks. Pour le moment, les applications Swift ont besoin de convertir leurs données en données Objective-C pour dialoguer avec certains frameworks. C'est le bridge (pont) dont en entend parler ici et là . Cela fait perdre un peu de performance au passage. C'est de ça que le rugbyfan parlait. Quand toutes les API seront réécrites pour dialoguer avec Obj-C et Swift, plus besoin de bridging. Rassure-toi, le développeur n'a pas besoin de s'occuper de ça, c'est traité en interne par le compilateur, sauf cas particulier.
ça s'améliore avec chaque version de Swift et de mise à jour des framework. Evidement, l'amélioration ne concerne que les frameworks de Yosemite et d'iOS 8. Les anciennes versions ne seront certainement pas optimisées pour la communication avec Swift. Mais ça marche quand même, avec la conversion automatique.
Ceci dit je mets un bémol car certaines APIs ObjC se portent très bien en Swift. A partir du moment où elles ont été correctement annotées avec les nullability + ARC annotations pour éviter les "!" intempestifs (ou les "Unmanaged<T>" pour les APIs CoreFoundation) et où les fonctionnalités nouvelles de Swift non dispo en ObjC (Generics, etc) n'ont pas plus d'intérêt que ça pour l'API en question, un framework écrit en ObjC peut tout à fait avoir une API Swift + que correcte, voire exactement l'API qu'on aurait imaginé si on avait écrit le framework directement en Swift.
Par exemple, je ne pense pas que je réécrirais un jour en Swift mon framework OHHTTPStubs. En effet, maintenant que j'ai correctement annoté l'API ObjC avec les __nullable ou __nonnull qui vont bien pour éviter les "!" intempestifs dans l'API traduite en Swift, l'API de mon framework écrit en ObjC est tout à fait acceptable en Swift. En témoignent les différents exemples d'usage de mon API dans ma page d'aide Wiki.
Mais bon, c'est sûr que pour d'autres frameworks, on a plutôt hâte qu'ils soient réécrits en Swift (ou du moins qu'il y ait un wrapper en Swift pour les adresser) car leur API profiterait efficacement des nouveautés de Swift telles que les Generics, les valeurs par défaut des paramètres, les enums avec associated values, etc.
Et là c'est clair que j'ai hâte de voir de plus en plus de libs écrites et pensées pour Swift, pour pouvoir commencer à sérieusement passer à Swift sans être obligé de continuer de penser en ObjC quand même juste à cause de l'interopérabilité. Mais la transition va encore prendre du temps, car créer une lib avec une API qui utilise les spécificités de Swift (Generics, etc) veut dire que cette lib ne sera pas utilisée par les apps ObjC-only, genre tous ceux qui veulent encore faire des applis qui ciblent iOS7.
A mon avis, tant que iOS9 ne sera pas sorti, et donc qu'on pourra commencer à considérer abandonner iOS7 (car en moyenne les apps supportent la version majeure actuelle et précédente, vu le taux d'adoption rapide d'iOS) et qu'on aura assez de libs Swift pour vraiment penser Swift sans trop penser ObjC, Swift restera encore un langage pour lequel un background ObjC sera fortement nécessaire. Ca veut pas dire qu'il ne faut pas s'y mettre, loin de là , mais ça veut dire qu'il est encore en progression et pas complètement final, et que pour une société dont le métier est de faire des applications pour des clients, avec une deadline pour leur fournir l'application finie, c'est encore un peu juste pour tenir les délais vu les nouvelles problématiques que peuvent poser un langage encore trop frais.
La plupart des agences, éditeurs de logiciels que j'ai pu rencontré me racontent que tous les nouveaux projets sont dorénavant conçus avec Swift.
Je suis passé à Swift également parce que ça apporte pas mal de nouveautés bien pratiques. Rien que faire les imports en objective-c me saoulait un peu.
Tu as ajoutés les annotations __nullable ou __nonnull juste dans l'objectif d'une meilleure interopérabilité avec Swift ?
Je veux dire par la, est-ce que tu utilises ces annotations dans tes projets Objective C ? ( qui ne sont pas Open source). Merci
c quoi le temps d'apprentissage de Swift pour un mec qui connait bien l'obj-C ? Pour l'heure, je n'y ai meme pas jeté un oeil mais je sais bien que je vais devoir y passer...
Difficile de répondre. Pour ma part je continue toujours d'apprendre de nouvelles choses sachant que Swift a pas mal évolué depuis sa première sortie.
Quand on a pratiqué pas mal de langages je trouve que c'est pas très long pour avoir les bases. Le plus long c'est toujours de connaà®tre les API.
Pour quiconque connait un langage de programmation objet et en comprend bien le principe "c'est ton cas, la syntaxe du Swift est appréhendable en 2/3h. La syntaxe de base est assez simple et tout est relativement du déjà -vu.
Là commence le vrai apprentissage, les type pure-Swift, les generics, les optionnals (j'ai mis du temps avec eux) et les petites subtilités vont te prendre 2/3 semaines si tu code en Swift tous les jours.
Sinon dans la mesure où tu connais déjà l'API Cocoa(-Touch) sache qu'à ce niveau rien ne change ou presque (mais c'est surtout des reste de conversions d'API faites à la pelle). Xcode sait encaisser plus de 10 lignes de Swift sans crasher, les messages d'erreur sont écrits dans un langage désormais compréhensible et il y a pas mal de contenu dispo.
Un dernier conseil: prend un projet simple que tu as fait, garde l'idée, ne regarde pas le code Obj-C (la partie métier à la limite si c'est un peut complexe) et code le en Swift en 1/2 semaines tu devrai être sorti du noir.
Je code en Swift day-one et j'en apprends tous les jours !
Après, comme je l'ai déjà expliqué dans mon message plus haut, ça dépend de quelles agences on parle.
- Pour les éditeurs de logiciels, cela a effectivement du sens car ils ont moins de pression sur les deadlines. Ils peuvent se permettre de passer en Swift, et donc de perdre un peu de temps le temps de monter en compétence, de perdre du temps sur des bugs qui ne sont pas dus au code (et donc prévu dans le temps de dev comme d'habitude) mais qui sont dus à Swift et aux bugs du compilateur lui-même, ou que tout le monde soit à niveau pour comprendre le code Swift de tout le monde. Et au final c'est le bon choix à faire, car il faudra bien y passer un jour, donc autant le faire maintenant, même si on passe le double de temps à développer en Swift au début que si on développait en Objective-C, car on connait ObJjC sur le bout des doigts alors qu'on doit apprendre Swift au fur et à mesure (et par exemple les logiques un peu particulières comme le fait que certaines choses se font via des functions globales plutôt que par une méthode d'instance sur une classe, etc)
- Pour une société de service, qui doit faire en série des applications pour leurs clients, clients qui demandent toujours des deadlines super serrées voire difficilement tenable, par contre ce n'est pas envisageable de passer à Swift en production sur un projet client, car le temps pour faire les premières applications en Swift sera en moyenne 2x plus important que si on la faisant en ObjC, et va justifier à ton client qu'il faut qu'il paye 2x plus cher pour un fonctionnel identique juste parce que tu vas mettre 2x plus de ressources ou de temps à la faire alors que c'est pas son problème... Alors bien sûr une fois que tout le monde est à niveau et une fois que tous les développeurs de la société de service seront aussi à l'aise en Swift qu'ils le sont en ObjC, ça ne posera plus de problème, mais contrairement à un éditeur de logiciel où les développeurs peuvent se permettre de prendre ce temps, dans une société de service cette montée en compétence ne peut pas se facturer sur le temps du client, donc il faut attendre que les gens aient des créneaux de formation ou de veille/capitalisation pour se former et monter en compétence hors projet. Or tout le monde ne montera donc pas en compétence en Swift en même temps, surtout si la société de service a beaucoup de contrats et de projets et donc peu de temps libre pour la veille/formation immédiatement, ce qui fait que si on commence un projet client en Swift avec quelques personnes maà®trisant Swift, mais que demain ce sont d'autres personnes qui doivent intervenir sur le projet, si elles ne sont pas encore à l'aise en Swift, elles vont ralentir la productivité et les délais clients ne seront pas maintenus...
En bref, quand on est société éditeur de logiciel on peut se permettre cette phase de transition, nécessitant du temps de formation et du temps supplémentaire à cause des nouvelles problématiques à aborder et avec lesquelles se familiariser. Quand on est indépendant et qu'on fait sa petite application sur l'AppStore, pour le plaisir ou parce que c'est sa source de revenus, on peut se le permettre aussi. Quand on est une société de service qui a des deadlines clients et qu'il est impossible de justifier qu'on va prendre + de temps pour une appli juste parce qu'on va la faire en Swift et qu'on est en montée en compétence dessus, c'est pas aussi simple.Je vois pas trop le rapport, puisqu'en Objective-C maintenant depuis l'arrivée des modules (LLVM livré avec Xcode 5 / SDK 7 de mémoire ?) tu fais les "@import" de la même manière que tu fais les "import" en Swift
En pratique, les annotations servent à indiquer si un paramètre (ou type de retour) peut être nil ou pas. En Swift cela a un impact sur l'API car tu vas avoir un Optional ou pas selon les cas. En ObjC cela ne change pas l'API donc je peux pas dire que "je m'en sers dans mes projets ObjC ou pas". Par contre, le fait de les avoir rajoutées permet à ceux qui utilisent ma lib d'avoir un warning si jamais ils utilisent "nil" pour un paramètre qui n'est pas sensé être nullable, donc oui ça apporte une sécurité quand même, même si en ObjC ça ne génère qu'un warning (là où en Swift c'est beaucoup plus fin, directement porté par le type et générant carrément une erreur de compilation si tu essayes de mettre nil à un non-Optional).
Dans l'ensemble pour les grandes lignes, je dirais que ça s'apprend assez vite.
Cela dépend de ton bagage technique et de ton passif de dev évidemment.
ok merci. Le manque de temps que l'on connait tous fait que je m'y suis pas encore penché.
Et ce qui est pénible, c'est d'avoir des applis complètes en Obj-C et se dire qu'il faudra sans doute es refaire en Swift dans les années à venir...
A moins qu'XCode ne propose un jour un convertisseur auto ? Un peu comme avec ARC...
Il y a un intérêt à prévoir une API Swift pour les librairies (Pods) existants parce que par définition eux seront amenés à être réutilisés et que c'est intéressant de leur faire profiter des nouvelles fonctionnalités de Swift (Generics, Enums avec Associated Values, etc) pour avoir des APIs plus harmonieuses alors que ces libs vont continuer à être utilisées dans des futurs projets. Mais pour du code d'un projet lui-même (et pas d'une lib qui sera réutilisée plus tard), tant qu'il marche, je vois pas l'intérêt de tout réécrire.
Quand à la façon de fournir une API Swift pour des librairies réutilisables déjà existantes et écrites en ObjC, pour profiter des fonctionnalités de Swift non présentes dans ObjC, il y a plusieurs façons de faire.
- La première est de réécrire toute la lib en Swift. Long et fastidieux pour un gain pas forcément prouvé, à part pour la beauté de la chose et le côté "ah c'est en pur Swift" pour les puristes.
- La seconde, bien plus flexible et adaptée, est de prévoir juste une façade. Tu prévois juste un wrapper Swift autour de ta lib ObjC, dont l'implémentation de chaque méthode Swift ne fait qu'appeler en interne la méthode ObjC de ta lib, juste dans le but de simplifier l'API, d'avoir une API "+ Swift" que celle initialement prévue quand tu as fait ta lib en ObjC, mais au final c'est juste un passe-plat.
Au final, je ne vois pas pourquoi tu voudrais réécrire en Swift du code déjà existant en ObjC, à part par puritanisme/perfectionnisme, ou alors juste à titre d'exercice.
non, je parle d'une application existante qui vit. Elle doit être mise à jour régulièrement tu es d'accord ?
Soit pour ajouter des fonctionnalités, soit pour suivre les évolutions iOS.
Faut il continuer à fonctionner en Obj-C ? Aura-t-on cette possibilité en 2018 par ex ?
Seul Dieu et Apple le savent .. Ceci dit, tu peux mélanger du code Swift et Objective-C dans la même application.
Je parlais des imports de nos propres classes.
Pour une nouvelle application, autant se mettre à Swift, mais pour une application existante, je pense honnêtement que même en 2018 tu pourras toujours utiliser ObjC.
Après, peut-être que certaines des nouvelles APIs de iOS9 et iOS10 ne seront disponibles qu'en Swift car feront usage des nouveautés propres à Swift (comme Generics ou Optionals ou Enums avec AssociatedValues), mais même si c'est le cas, ce n'est pas forcément un problème. ObjC et Swift étant inter-opérables, ça ne t'empêchera pas de faire un wrapper ObjC pour appeler le code Swift, ou de garder tout un pan de ton application en ObjC (genre des UIViewController qui ne bougeront pas de sitôt, etc) pendant que tu rajoute des nouvelles fonctionnalités / nouveaux écrans à ton application via du code Swift. "MyOtherViewController.swift" peut tout à fait cohabiter avec "MyFirstViewController.m", et "MySecondViewController.m" peut aussi appeler une méthode de "MyUtilityMethods.swift" qui déclarerait des classes Swift compatibles ObjC pour encapsuler du code Swift non-compatible ObjC... bref tout cela peut tout à fait cohabiter.
Je ne crois pas non plus à la disparition de l'objective-c à court terme. À long terme par contre je sais pas.
Ils ont l'air de vouloir pousser Swift et peut-être qu'ils délaisseront l'objective-c si une grande majorité des nouvelles applications est conçue en Swift ?
Ce sont de petites entreprises qui m'ont dit ça pas Google ou facebook xd
Perso je ne connais pas tous les rouages d'une entreprise mais si c'est une startup je pense que le choix Swift est logique contrairement à des Sociétés de services ou de grosses structures comme tu l'as si bien dis. D'autant plus que Swift est un formidable outil pour attirer des développeurs pas forcément motivés par l'apprentissage de l'objective-c. Donc passer ses nouveaux projets en Swift permet peut-être d'attirer de nouveaux développeurs plus facilement dans un secteur demandeur ?
ah ok. C'est bien ça. Je savais pas qu'on pouvais ajouter du swift dans une appli en objective-C. Pretty cool
Et iOS 7 alors ? Les applications Swift fonctionnent bien en iOS7, du moins sur le simulateur. Je n'ai pas testé sur un device physique.
Ouf !
Du coup, c'est iOS7 ou 8 pour publier des apps qui contiennent du swift ?
iOS 7 !
Bonsoir,
Un exemple de réécriture en Swift : https://www.youtube.com/watch?v=Tsxua7yeFcc
Qu'en pensez-vous ?
Mais dans l'ensemble je redis ici ce que je dis ces derniers temps :
- autant en début d'année, Swift était un peu trop jeune (mais intéressant de s'y mettre quand même pour pas être en reste) et surtout Xcode n'était pas mature,
- autant maintenant, il est temps de s'y mettre (à défaut de s'y mettre pour immédiatement faire passer ses applis existantes en Swift, au moins sérieusement s'amuser avec pour s'habituer au langage, y prendre goût et le maà®triser), Swift 2.0 dévoilé à la WWDC apporte encore un lot de nouvelles fonctionnalités du langage très intéressantes sur des constructions permettant d'améliorer la stabilité, et le compilateur Swift intégré dans Xcode est de mieux en mieux (non seulement depuis Swift 1.2 et Xcode 6.3 il ne crash plus comme dans les toutes premières Beta, mais avec Xcode 7 il y a encore de meilleurs messages d'erreur et intégrations)
Donc en bref je suis assez d'accord avec la vidéo qui dit que c'est un langage intéressant, qu'il "va falloir s'y mettre" (non pas dans le sens "c'est une obligation" " ceux qui veulent rester à l'ObjC le peuvent " mais plus dans le sens "vous avez tout intérêt vous allez y gagner croyez-moi"), car il permette effectivement d'augmenter la stabilité (par son typage fort entre autres mais pas que).Après que les gars de FinalCAD ait réécrit entièrement leur appli en Swift from scratch, alors qu'elle marchait déjà bien en ObjC (du moins je suppose), je ne suis pas sûr que ça en valait l'intérêt, à part pour l'exercice et le fait de se faire à Swift (évidemment l'intérêt ici est fort, mais par contre économiquement, dépenser du temps et des sous pour refaire un truc qui marche déjà correctement, c'était à mon sens pas nécessaire autrement que pour le plaisir d'avoir une excuse pour découvrir et s'entraà®ner au langage).
Certes ils avancent que maintenant qu'elle est tout en Swift, il y aura moins de Bugs (certainement vrai je suis d'accord), qu'elle sera plus rapide (ça c'est très probable, après est-ce que cette optimisation et gain de performance se ressentira effectivement par l'utilisateur, c'est moins sûr... quoique autant pour une app TableView ça soit négligeable, pour une app de CAO/CAD comme la leur, avec un volume d'objets conséquent et un algo de dessin potentiellement complexe, ça peut commencer à se ressentir), et qu'ils pourront ajouter des nouvelles fonctionnalités plus rapidement (très probable aussi, d'une part car une fois qu'on connait Swift c'est plus rapide à écrire qu'ObjC, et que les features qu'il apporte tels Value Types, Generics & co permettent d'amener de nouveaux patterns accélérant le dev).
Donc s'ils pouvaient se permettre de tout mettre en pause et de tout réécrire en Swift (d'autant que quand ils ont commencé le langage ne devait pas être encore très stable), ils ont de la chance et je les envie presque.
En pratique, à moins de pouvoir se permettre ce luxe (si on a pas de deadline on de budget / planning à tenir), je conseille plutôt soit de ne pas migrer les projets existants mais coder en Swift uniquement les nouveautés, soit de migrer progressivement, au fur et à mesure, tout en continuant de faire évoluer, plutôt que de tout stopper et recommencer...