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.
11–20 of 44 posts
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.
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…
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.
Has Apple shipped anything yet that runs in Swift? Can we tell?
Has Apple shipped anything yet that runs in Swift? Can we tell?
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.
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…
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.