I’d say its ‘ready’ for prod but can still be a pain regarding tooling. I’ve written a Faye client in swift http://github.com/hamin/FayeSwift and will eventually update my mac app too https://itunes.apple.com/us/app/mackernews-hacker-news-clien...
Ask HN: Is Swift ready for production yet?
21–30 of 44 posts
Re: Ask HN: Is Swift ready for production yet?
#22Having written android apps and never having written an ObjC app, swift was a combination of confusion, aha moments, and wtfs. In particular, not so much the language itself, the lack of any kind of well supported and well used package management is rather lame. I don't know if this is something I should expect as I haven't worked with ObjC but coming from python and java land I don't really like submoduling in my de…
https://medium.com/@stigi/swift-cocoapods-da09d8ba6dd2
Since that's been written, CocoaPods has added Swift support. As of a few weeks ago it's currently available in beta (gem install cocoapods --pre).
To the OP, CocoaPods is probably the most widely-used package manager, but there's also Carthage too, which is decentralised: https://github.com/Carthage/Carthage
It'd be nice if Apple had an official package manager but they seem to want to stay out of it (see Homebrew/MacPorts on OS X too).
Re: Ask HN: Is Swift ready for production yet?
#23According to this blog, you'll get more correct code with Swift:
http://www.sunsetlakesoftware.com/2014/12/02/why-were-rewrit...
Over the lifetime of the software, anything you can do to reduce bugs is a win.
By the way, I maintain a list of Swift resources. I have almost 500 urls from the past 9 months, so you can see that Swift is gaining some adoption: http://www.h4labs.com/dev/ios/swift.html
Re: Ask HN: Is Swift ready for production yet?
#24In your case, no. It sounds like you're designing, not building, the app. Letting your contractors use the technology they are most familiar with and that has the most mature tooling (for the platform) is in your best interest. Apple will be supporting Objective-C for a long time to come so you lose nothing from sticking with what works.
I say this as someone who has written many thousands of lines of Swift over the last few months. In an effort to learn the language and explore some user experience ideas I decided to write as much of my app as I could in Swift (it stands at about 95%). Since starting in September of last year I've alternately loved and regretted choosing Swift. For reference, I'll list the pros and cons.
Pros:
- Greater productivity through new "safety" features (lots of caveats here, see the Cons section for why).
- The expressiveness of Swift often means less code to read than with Objective-C. Hopefully that also means less bugs.
- Swift code is (to me) much easier to reason about than equivalent Objective-C.
- The language is just plain nice. This is subjective, and not relevant to your particular case.
Cons:
- The tooling is very immature. I have encountered multiple situations where the compiler itself crashes during a build.
- The static analyzer for Swift code reports erroneous problems. Until you learn the situations it doesn't understand it can lead you down the wrong path to resolution.
- Certain build problems are very difficult to diagnose. I have lost multiple days just searching for code changes that caused the compiler to crash.
- Xcode error reporting for Swift build problems can be vague, ambiguous, or non-existent.
- Xcode crashes, a lot. Technically this is nothing new, but since Xcode 6 I'd argue it has gotten measurably worse.
Swift is clearly going to be great, and it is clearly the future. Unfortunately the future isn't here yet.
Re: Ask HN: Is Swift ready for production yet?
#25I've been coding full-time in Swift for the last three months and at this point our source base is about 10K lines of code. Given this experience, if I had to do it all over again, I'd probably choose Swift again.
The good:
- Swift is a far better language than Objective-C. It's much safer, the type system is great, and the functional features are a joy to use.
- Everything largely works as advertised; even for a super new language, the amount of total brokenness is minimal.
The bad:
- The current compiler's error messages are frequently bad to the point of being useless. Try to mutate an immutable dictionary? You get a type mismatch when you could get an error about immutability.
- The compiler is a lot slower than I think they mean for it to be.
- The debugger takes several seconds to evaluate an expression compared to almost instantaneous evaluation in Objective-C.
- 8 MB of standard library in your app binary.
The ugly:
- "SourceKitService crashed" messages in Xcode flashing on the screen at 30 hertz.
But at the end of the day, if you're hiring an outside company to do this, why does it matter to you what language it's written in? Shouldn't they be able to use their best tools?
Re: Ask HN: Is Swift ready for production yet?
#26Yes, it's production ready, but the quirks in tools are significant hindrance to productivity. I would estimate 1.2 ~ 1.5x longer to get it written in Swift.
Is tooling really that critical? Coming from JS, I can write whatever without any tooling at all. The need for heavy tooling in most other frontend dev is one of the reasons that I think that JS, despite all its issues at the moment, will come to rule interface development. The baseline in JS is that one can read, write, and understand it using only the human brain.
Re: Ask HN: Is Swift ready for production yet?
#27I'd say it depends on your definition of "production ready". The APIs are likely to be stable and well supported, but the current library does suffer some culture clashes, as they're mostly just done with Swift's Objective-C interop. A lot of the APIs are somewhat annoying to approach due to them being designed with Objective-C in mind. Most standard library APIs will be rife with implicit optionals and require extra type checking, especially if you're implementing delegates.
In particular, dealing with Core Data can be a holy mess with Swift because every single property on a Core Data object is dynamic and implicit optionals. Unlike Objective-C, which will happily pretend like nothing has happened (in many cases), Swift will explode quite spectacularly if you try to operate on nil values, and implicit optionals lets that happen without throwing type errors. Either be very careful with marshalling accesses to Core Data objects, or test thoroughly with different data patterns. Last thing you want is your app crashing because someone filled in data in your app that leaves a property set to nil.
I'd expect some resistance (on top of the "I need to learn a new language" part), and some swearing about all these "if let"'s or "I thought Swift meant no more null pointer exceptions!", but it's perfectly doable.
Re: Ask HN: Is Swift ready for production yet?
#28I have released an app with Swift and libraries in Obj-C. Now I am developing an iOS game completely in Swift working correctly even in iOS 7. (Apple provides libraries to support Swift in 7, but in iOS 8 is native)
I think is more the contractor doesn't have the experience or don't feel confortable enough deploying a Swift App. There are some issues with XCode and Swift, but nothing too critical.
The language is ready, but most of the developers aren't.
Re: Ask HN: Is Swift ready for production yet?
#29I've recently been re-writing an old pet project from Objective-C to Swift. I've found the Swift error messages incredibly unhelpful in Xcode compared to Objective-C, but the resulting code to be a lot more readable and concise (and therefore, importantly, much more maintainable). I find myself writing a lot less 'glue' code too. On balance, I probably found the Objective-C code easier to write, partly because of Xco…
... I probably found the Objective-C code easier to write, partly because of Xcode support and partly (if I'm honest) because it lets me do more dumb/unsafe things, which should probably be discouraged.
That same argument was used in the '80s by Pascal proponents against C.
Would the software we use today be better if it all were written in Pascal instead of C? Yes, there would certainly be less buffer overflow exploits... But also less power and features. C was simply more suited to building complex/powerful software than most other languages at the time. Can you imagine Linux in Pascal?
The way I feel about Swift is that it's a better C++ combined with some of the didactic/patronizing aspects of Pascal. That's probably a fine language for some uses, but I wish they had designed a better Objective-C instead.
Re: Ask HN: Is Swift ready for production yet?
#30I recently worked on a production app that used Swift. It's certainly possible, but I wouldn't recommend it (yet). Writing Swift is nicer and feels much more natural than Objective-C, but the tools are not there yet.
Xcode crashes often (even more frequently than with Objective-C), the compiler will probably also crash at some point during development. Compiling Swift code is also considerably slower than compiling Objective-C code. Error messages are often cryptic and debugging compiler bugs is very time consuming.
There's also a few places in Swift where things still need some more time to settle, framework support is tricky and some very basic tasks are harder than they should be (for example, getting a substring).