Live data from Hacker News

Ask HN: Is Swift ready for production yet?

news.ycombinator.com

11–20 of 44 posts

Re: Ask HN: Is Swift ready for production yet?

#11
Eh, I haven't enjoyed the debugger in Xcode when using swift.

Unfortunately, many of us iOS developers work for clients. These projects are usually on timelines, and if writing the app entirely in Swift slows us down substantially, we will likely go with Obj-C.

Also, Obj-C isn't likely going anywhere.

Re: Ask HN: Is Swift ready for production yet?

#12
post #8

Sounds like an excuse to me. But, 'ready for production' is a relative term that must be considered in context. Apple is encouraging developers to submit apps with Swift, so clearly they think it's 'ready for production' in some contexts. If you're building an app for which an obscure, swift-specific bug may cause a critical security or safety issue for your customers then perhaps go with objective-c to sleep better…

Agreed on excuse. But if the vendor doesn't have people already familiar it might be worth asking whether it's worth paying for them to learn it if you don't already have an existing codebase that requires it.

I've been working in Swift,t he language itself is nice, the tooling and community documentation is a bit rough. For example Cocoapods support for Swift pods is still prerelease and there are a lot of small differences coming from Objective C that can require a little research.

I wouldn't write safety-critical code in either language though.

Re: Ask HN: Is Swift ready for production yet?

#15
Having 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 dependencies and wiring all of them into the build system via the GUI.

Re: Ask HN: Is Swift ready for production yet?

#18
Swift is ready for production. XCode isn't.

Even if your project is written in Swift, you can still use CocoaPods through bridging header, and you can use embedded frameworks for pure swift libraries (caveat: if you are targeting iOS 7, you need to copy and possibly modify the source of the frameworks you use because embedded frameworks are not supported in iOS7). Although Apple APIs are available with Swift, the documentation for some of the libraries still only provides examples in Obj-C.

My main issue right now is with the stability of XCode. SourceKit keeps crashing on me (every 30 minutes). It has become more stable with 6.1, but it used to crash when I had too many parameters in a function or when I was trying to mix Obj-C and Swift. Sometimes I get build errors and after a few calls to clean, I can build my app (go figure!). This makes developing in swift not as enjoyable as it could be.

Re: Ask HN: Is Swift ready for production yet?

#19

Having 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

Re: Ask HN: Is Swift ready for production yet?

#20
I'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 Xcode support and partly (if I'm honest) because it lets me do more dumb/unsafe things, which should probably be discouraged.

For me at least, the biggest problem I've found is that I have no intuition for best practices in Swift (when to use certain language features etc.), and that makes me wary that I'm writing bad Swift code, even if it's technically correct. I imagine it'll take time for the community to standardise on what makes for good Swift code, and for more extensive learning resources to be developed etc. Sticking to Objective-C for now certainly doesn't seem to be a bad thing.

Post reply on HN