Coming from Obj-C - Problems switching to Swift

Hi,


I have been writing Apps in Objective-C since 2008. In the last year (2014) while I was working on a very large project I realized that somehow my understanding of Objective-C got so large that I was able to write good and usefull code very very fast. So it took 6 years of constant coding in Obj-C to get a deep understanding of it and to build up enough experience to say that I am able to write good code very fast in Objective-C.


A few weeks ago I started working with Swift - I really like the fact that there are no Header-Files anymore and I understand that there are a lot of things that can help me write code much faster. But I am still having problems to switch - mainly because I am still thinking too much objective-c-ish when writing in Swift.


Problem is, I really don't see any advantage since I am still faster in Objective-C. And since I am currently starting a new software-project I really tend to stick with Objective-C since I already have a concept about how I implement the basic stuff in Objective-C .. Trying this in Swift I feel like being back in 2008.


But since I wanted to switch to Swift as soon as I begin starting to work on a new project I am asking myself if sticking with Objective-C might be a good Idea - I mean I am faster, and have a deep understanding of the things behind the scene when using Objective-C ... With Swift it's like being an amateur again ...


What do you think? How did you manage the switch to Swift? Any help, advices and opinios greatly appreciated ...


Thanks,


Simon

How did you manage the switch to Swift?

The way I’ve managed my Swift adoption has been to write a bunch of non-critical projects in Swift. In the early days of Swift working on these projects was quite frustrating, so I stuck with Objective-C for my real work. With Swift 2 that balance has tipped: as I write Objective-C code I find myself really missing Swift features, and so I’ve started using Swift for my real work.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Well this might be a good strategy. Unfortunately the new project will be a big one and that's mainly the reason why I think I stick with Obj-C this time but use Swift for small - nonsense - side-projects just to learn it ...


See, problem is: I am at a point where I don't have to ask myself "How to do that in Obj-C? What was that syntax like?". I do not have to think about that anymore because I speak Objective-C like my mother language ... A bit ;-D ... I can concentrate on logic and app structure. With Swift I have to think about "How you do that in Swift?" before I could even imagine working on the app itself ...


Thanks,


Simon

I think Quinn's approach of writing smaller side-projects in Swift works well here. It's what I have been doing myself. You shouldn't feel bad that you're writing your large project in Objective-C right now. While it's possible to write large projects in Swift now, there are both advantages and disadvantages to doing so, and you should untertake a project only if you can benefit from the advantages and are OK with the disadvantages. Without a better understanding of Swift, you won't know how to code to get the most benefit from Swift.


They day may or may not come when you wish that you had written the project in Swift, but if that day comes, it will be because you have a better understanding of Swift. If you started your large project in Swift today, you would probably look at your code in the future and wished you had written the project in better Swift, so you'd be at exactly the same place you'd be if you had started with Objective-C, but without the disadvantages of a large Swift project (e.g. longer compile times, evolving syntax and standard library, and more bugs because you don't understand how Swift works yet).


I would like to add that this will probably not be the last time you will have to shift languages during your career. Technology is an ever-shifting landscape, and there are many languages out there with their own ways of doing things, and you can never tell which one will end up being the best choice for your future projects. If you had asked me five years ago if I would ever be writing server-side JavaScript, I would have considered it unlikely, but Node.js is the tool that best fits a project I'm working on right now.


My point is that the ability to learn new languages and new paradigms is a skill in itself, and it's an important skill if you want to last for a long time in this profession. I would recommend continuously developing that skill. Once you feel like you have a good understanding of Swift and are using Swift by default, start a small side project in another language you don't know much about. Once you've gone through the process of learning a few languages this way, it will become easier to pick up new languages more quickly, so when the next transition comes and you're faced with this situation again, you'll be better equipped to handle it.

I have been writing Objective-C apps since 1992 (so long ago that we mostly called them 'programs' back then!). In general I have been happy with what I have accomplished with Objective-C. In addition, I have written quite a few apps in other languages: Java, Javascript, Ruby, Python, the usual suspects. Naturally when using the more modern languages I began to notice the 'heaviness' of Objective-C.


So, as soon as Swift came out, I was on board and writing my own personal apps in it. I'm now eager to get my first Swift job (I do freelancing) and hope it will be soon.


One thing I've noticed is that in addition to the new language, I found myself acting like the proverbial child in the toy shop, running with wide eyes from one shiny new thing to the next. So, in addition to the new language, I was constantly uncovering new gems in the standard library (OOOooooh PermutationGenerator, no idea what it does or how to use it, but I just must spend lots of time figuring it out!). And, people started releasing new frameworks and libraries on Github and I had to rush over and try those (I've gotten into more than one 'reactive programming' framework, and none of them is particularly trivial).


So, I think I could possibly have written a Swift 'version' of an Objective-C app after just a few weeks PROVIDING I had not had to cram in every new additional feature available, in other words, if I had stuck to the same classes and mechanisms I would have used in Objective-C.


So, I'm not saying either way is correct or better, but it may be worthwhile to consider when planning: how much additional time will be required to write a Swift version of a particular app based not only on the difference in language, but the possible differences in style and additional libraries/frameworks you might want to try (or intentionally avoid so as _not_ to increase the time unnecessarily).

QOUTE:" ... So, I think I could possibly have written a Swift 'version' of an Objective-C app after just a few weeks PROVIDING I had not had to cram in every new additional feature available, in other words, if I had stuck to the same classes and mechanisms I would have used in Objective-C. ..."


- Yes. I totally agree and I guess thats mainly the problem with Swift - or at least the problem I had when starting working with it. I was quite of overloaded with all the new stuff so that I asked myself how to implement stuff I do know on Objective-C with all that new features. Problem was / is that I think that I HAVE to use all the new features - But when stuck to same classes and mechanisms it might be easier ...


And I already did a small test this evening. It took me 30 minutes to write a basic infrastructure for my upcoming project. I tried to re-write that in Swift and it took just 10 minutes AND mostly important - half the code! .. I think I begin to understand ..


Anyway guys, thank you so much!


Simon

Coming from Obj-C - Problems switching to Swift
 
 
Q