Pretty happy the Firefox for iOS team made the decision to go fully Swift about 14 months ago :-) Almost 60,000 lines later, no regrets. It is awesome.
Rough estimate is the Outlook app has over 70k lines of Swift, which is just over 50% of our codebase (the rest is Objective-C). That doesn't include external libraries.
One of our devs starting adding Swift code to the project about a year and a half ago. After that proved successful, the rest of the dev team then started getting up to speed. For the last 8 months, all development has been done in Swift.
We don't arbitrarily rewrite existing source, but if we're making changes to an existing Objective-C file, we evaluate if it would be worthwhile to rewrite in Swift. Often the answer is yes.
From our perspective, Swift is absolutely ready for primetime. For a large codebase like ours, it takes some time before you see direct benefits, but if you keep with it, I'm sure you won't regret it.
I should mention the downsides: the migration to Swift 2 took time, but it wasn't awful. I'm sure we'll have similar issues moving to Swift 3. Also our compilation times are quite a bit slower than with purely Objective-C.
I knew there was some churn in the Swift language but didn't think it was going to continue. I'm not using Swift now but will likely hold off a bit longer as a result. I did think they nailed the open source launch. Swift on the server is an exciting prospect, more competition is always good. While I'm not a Swift dev yet (I don't have a Mac thus mainly interested in the libre crossplatform launch), I've been keeping my eye on it with Swift Weekly.
I think 2016-2017 could well be the year(s) of Swift's ascension.
Have been using Swift since late 2014 (having used ObjC for many years prior to that).
Even with the occasional churn (eg move to 2.0 or 2.1), the sheer gain in productivity due to brevity, type checking, cleaner closures, and various other language features, easily outweighs any costs. I find myself being able to do more with less code, and cleaner code. It's cognitively way easier to build bigger abstractions.
We do have a few legacy bits that makes no business reason to port at this point, but Swift-to-legacy interop works well, too.
I would say the biggest step that made things usable was introduction of incremental builds in 1.2.
I think that approach (waiting to adopt) makes sense if you aren't already an ObjC developer. Less to unlearn. However, for an ObjC dev, waiting to adopt is only going to put you further behind the curve (the hard part won't be absorbing the changes from Swift 2 to Swift 3, its dropping your ObjC habits and learning what it means to write idiomatic Swift (which isn't going to drastically change between Swift revisions)).
Swift is a neat language but unfortunately doesn't fix the extremely verbose and archaic-feeling NextStep libraries that make Objective-C a pain to read or write:
let bar = foo.stringByReplacingOccurrencesOfString(" ", withString: "", options: .LiteralSearch, range: nil)
I know exactly what the first one does, without knowledge of the underlying API. I have no idea what the second one does. Does it replace occurrences of the first parameter with the second one, or vice versa? I assume it returns a copy of the string? What do I need to do to perform a case insensitive search? etc.
At some point soon if you want to find recent examples for iOS 8 and 9, they'll all be in Swift. iOS 10 will be announced in 4 months. Books, blogs, and perhaps all of Apple's examples, will be in Swift.
Sadly though, a lot of the books either are or will be out of date as more updates come to Swift and break existing code.
I've been working on and off with Swift since the beginning, it has a lot of great characteristics, but updates breaking code isn't something most developers have time to worry about.
Its funny yesterday I had a meeting with my 2 head course professors talking about this exact issue. A capstone project essentially requires a objectice c ios app but they have stopped producing reference books for them in IOS 8 && 9.
I've noticed that, and find it annoying that all of the major third party iOS learning resources- Big Nerd Ranch, Ray Wenderlich, Objc.io etc. have switched over to Swift without retaining Obj-C support, even though it's far from deprecated on iOS 9, and Swift is far being in a stable configuration. I have to applaud NSHipster for having code snippets in both, at least, even while they're books are now Swift-only.
I'm not an iOS developer but for the native modules that I developed for Cordova or React Native, Swift is definitely a much better and cleaner language to develop it.
Something to think about from end user Joe, here: A quick search seemed to indicate that Swift support (officially) began in iOS 7. Great, that's the version I'm on. If anything coming down the pipe for Swift depends on a later version, I'm not on board. I'm not going anywhere. A lot of users, myself included, have been burned when a version upgrade runs like a dog on old hardware...but unfortunately, I'm not going to spring for a new iPad every year, much to the chagrin of Apple. It'd be interesting to see how App Store success correlates with how many versions you can support.
It will be time for Swift when they stop making backwards-incompatible changes to the syntax and I can be sure my code from today will still compile tomorrow when I download the latest version of Xcode.
The alternative is to either stifle improvements, or to bloat the language. And we all know what that looks like looks at C++
I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. I'm happy to maintain my software in return of working with an elegant, cutting-edge, small, logical language.
Why is he talking as though using objects is out, and using value types is the only valid path with Swift?
Especially during a transition phase, which we are inescapably in right now, wouldn't it be pragmatic to continue using objects when needed, even if the eventual goal is to end up transitioning to protocol oriented programming?
In other words we don't need to conflate Swift with POP, which I think is what he's doing when he talks about the purported problems of NSNotificationCenter.
Kotlin looks somewhat like Swift (or Swift like Kotlin, depending on your perspective) and you get all the tools and libraries that have been built up over the years for server side programming on the JVM.
Int is a 64-bit data type and Int32 is 32-bits. The compiler refuses to infer that you want to lose data. Converting the other way, the compiler refuses to infer that you want to bloat your data.
CGFloat, depending on the runtime, may either be a Float or a Double, so explicitly converting to and from it is required.
Rather than create a byzantine set of rules about whether it is "safe" to convert from one type to another, Swift wisely requires that all type conversions be explicit.
Should one wait for Swift 3? The API/syntax changes are a concern. Code breaking changes aren't that great. Also last time I checked Swift still requires a 64bit iOS device.
Apple provides code migration support in Xcode, so when they break things it's mostly a mechanical and sometimes automatic update. I migrated our 50K lines of Swift code from Swift 1.2 to 2.x in a few hours.
It's totally different. Google officially stopped development and support for ADT in Eclipse. But Apple is still supporting Objective-C and most Apple's apps are written in Objective-C.
What bother me the most about Swift,
is it essentially a C# clone, actually worse, because C# has more features. It is a travesty that Apple chose to design yet another shit language when there are so many other alternatives. And now, like with Go, everybody is jumping on the band wagon because its Apple.
I've working in C# for eight years before switching to iOS. To me, Swift and C# similarity ends with use of curly braces.
C# is, in essence, better Java. Much, much better Java. Swift is a different language, it implements some new ideas (much more advanced type inference) and forces the programmer to thinks in a different way (by trying to eliminate nullability).
Swift is not a perfect language (my biggest gripe is very awkward generics implementation), but it is a good language, and it's getting better. Saying that it's "a shit language currently on the spot just because Apple" isn't fair, I think.
While I agree that Swift and C# share a lot of commonalities and are fairly similar languages, the better integration of Objective-C alone makes the new language worth it.
I don't know anyone in PL who thinks Swift is a bad language. It's a nice, conservative, tasteful design that uplifts some proven functional features. What's not to like?
I love C# and think it's a great language, but when it was as old as Swift is now it was widely perceived as a Java clone. In fact, even today C# and Java are much closer in language design philosophy and implementation than C# and Swift, and calling Swift a "C# clone" betrays a profound lack of familiarity with what Swift is or how it works.
And C# is a Java clone which is a C++ clone which is a C clone. Who cares if languages take other languages as inspiration? Would you prefer a Disney-like situation where innovation is stifled because that is no longer possible?
[+] [-] st3fan|10 years ago|reply
[+] [-] shawn-butler|10 years ago|reply
> cloc FireFox-ios/
1068 text files. 928 unique files. 303 files ignored.
C 1 files 10606 blank 51150 comment 94618 code
Swift 332 files 9660 blank 5808 comment 43474 code
EDIT: I give up trying to format the output correctly
[+] [-] ogmo|10 years ago|reply
One of our devs starting adding Swift code to the project about a year and a half ago. After that proved successful, the rest of the dev team then started getting up to speed. For the last 8 months, all development has been done in Swift.
We don't arbitrarily rewrite existing source, but if we're making changes to an existing Objective-C file, we evaluate if it would be worthwhile to rewrite in Swift. Often the answer is yes.
From our perspective, Swift is absolutely ready for primetime. For a large codebase like ours, it takes some time before you see direct benefits, but if you keep with it, I'm sure you won't regret it.
I should mention the downsides: the migration to Swift 2 took time, but it wasn't awful. I'm sure we'll have similar issues moving to Swift 3. Also our compilation times are quite a bit slower than with purely Objective-C.
[+] [-] brendanlim|10 years ago|reply
[+] [-] BuckRogers|10 years ago|reply
I think 2016-2017 could well be the year(s) of Swift's ascension.
[+] [-] lpsz|10 years ago|reply
Even with the occasional churn (eg move to 2.0 or 2.1), the sheer gain in productivity due to brevity, type checking, cleaner closures, and various other language features, easily outweighs any costs. I find myself being able to do more with less code, and cleaner code. It's cognitively way easier to build bigger abstractions.
We do have a few legacy bits that makes no business reason to port at this point, but Swift-to-legacy interop works well, too.
I would say the biggest step that made things usable was introduction of incremental builds in 1.2.
[+] [-] cellularmitosis|10 years ago|reply
[+] [-] dxhdr|10 years ago|reply
let bar = foo.stringByReplacingOccurrencesOfString(" ", withString: "", options: .LiteralSearch, range: nil)
Compare to any other language, say Python:
bar = foo.replace(" ", "")
[+] [-] schrototo|10 years ago|reply
[+] [-] rarepostinlurkr|10 years ago|reply
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
[+] [-] phatbyte|10 years ago|reply
[+] [-] st3fan|10 years ago|reply
[+] [-] melling|10 years ago|reply
http://www.h4labs.com/dev/ios/books
At some point soon if you want to find recent examples for iOS 8 and 9, they'll all be in Swift. iOS 10 will be announced in 4 months. Books, blogs, and perhaps all of Apple's examples, will be in Swift.
[+] [-] travisty|10 years ago|reply
I've been working on and off with Swift since the beginning, it has a lot of great characteristics, but updates breaking code isn't something most developers have time to worry about.
[+] [-] icpmacdo|10 years ago|reply
[+] [-] Apocryphon|10 years ago|reply
[+] [-] yrezgui|10 years ago|reply
[+] [-] tylerc230|10 years ago|reply
[+] [-] preordained|10 years ago|reply
[+] [-] thewarrior|10 years ago|reply
[+] [-] peterkelly|10 years ago|reply
[+] [-] sssilver|10 years ago|reply
I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. I'm happy to maintain my software in return of working with an elegant, cutting-edge, small, logical language.
[+] [-] st3fan|10 years ago|reply
[+] [-] natch|10 years ago|reply
Especially during a transition phase, which we are inescapably in right now, wouldn't it be pragmatic to continue using objects when needed, even if the eventual goal is to end up transitioning to protocol oriented programming?
In other words we don't need to conflate Swift with POP, which I think is what he's doing when he talks about the purported problems of NSNotificationCenter.
[+] [-] bsaul|10 years ago|reply
[+] [-] mike_hearn|10 years ago|reply
[+] [-] adwelly|10 years ago|reply
[+] [-] peterashford|10 years ago|reply
[+] [-] edwinnathaniel|10 years ago|reply
That section is gold.
[+] [-] tomwilson|10 years ago|reply
[+] [-] billconan|10 years ago|reply
I need to convert Int to In32 and CFloat to CGFloat a lot.
I wonder why there are so many basic types, and why can't they be simply converted to other types.
[+] [-] wolfsir|10 years ago|reply
CGFloat, depending on the runtime, may either be a Float or a Double, so explicitly converting to and from it is required.
Rather than create a byzantine set of rules about whether it is "safe" to convert from one type to another, Swift wisely requires that all type conversions be explicit.
[+] [-] frik|10 years ago|reply
[+] [-] jakobegger|10 years ago|reply
[+] [-] JimDabell|10 years ago|reply
Swift doesn't require 64-bit iOS, and never has as far as I recall.
[+] [-] pivo|10 years ago|reply
[+] [-] smegel|10 years ago|reply
[+] [-] vinceyuan|10 years ago|reply
[+] [-] R00TL3SS|10 years ago|reply
[+] [-] pmalynin|10 years ago|reply
Sigh.
[+] [-] millstone|10 years ago|reply
1. Swift collections and strings are value types, but in C# they are reference types
2. Swift strings are mutable, C# strings are not
3. C# by default allows reference types to be nil, Swift does not
4. Swift performs overflow checking by default, C# does not
5. Swift is reference counted, C# is GCed
6. Swift's inouts are very different from C#'s ref. For example, Swift's inouts support properties
7. Swift's error handling is quite different from C#'s exceptions, both in syntax and implementation
8. Swift's enums act as algebraic data types, C# has nothing like this
9. Swift's switch statements are much more flexible than C#, because of where clauses
and more.
These are some radical departures! The differences between Swift and C# are much greater than the differences between C# and Java.
[+] [-] apetrovic|10 years ago|reply
C# is, in essence, better Java. Much, much better Java. Swift is a different language, it implements some new ideas (much more advanced type inference) and forces the programmer to thinks in a different way (by trying to eliminate nullability).
Swift is not a perfect language (my biggest gripe is very awkward generics implementation), but it is a good language, and it's getting better. Saying that it's "a shit language currently on the spot just because Apple" isn't fair, I think.
[+] [-] pcwalton|10 years ago|reply
I don't know anyone in PL who thinks Swift is a bad language. It's a nice, conservative, tasteful design that uplifts some proven functional features. What's not to like?
[+] [-] austinz|10 years ago|reply
[+] [-] flamethroeaway|10 years ago|reply
[+] [-] akhilcacharya|10 years ago|reply
[+] [-] meddlepal|10 years ago|reply