I recently met with a software development company to commission a new iOS app. I suggested that I wanted it written in Swift as opposed to Objective-C and was told that Swift isn't ready for production.<p>The app is a list based app, making use of the Map API and making HTTP calls. No complex maths or graphics involved.<p>What do you say? If not, why not?
In 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.<p>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.<p>Pros:<p>- Greater productivity through new "safety" features (lots of caveats here, see the Cons section for why).<p>- The expressiveness of Swift often means less code to read than with Objective-C. Hopefully that also means less bugs.<p>- Swift code is (to me) much easier to reason about than equivalent Objective-C.<p>- The language is just plain <i>nice</i>. This is subjective, and not relevant to your particular case.<p>Cons:<p>- The tooling is very immature. I have encountered multiple situations where the compiler itself crashes during a build.<p>- 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.<p>- Certain build problems are very difficult to diagnose. I have lost multiple days just searching for code changes that caused the compiler to crash.<p>- Xcode error reporting for Swift build problems can be vague, ambiguous, or non-existent.<p>- Xcode crashes, a lot. Technically this is nothing new, but since Xcode 6 I'd argue it has gotten measurably worse.<p>Swift is clearly going to be great, and it is clearly the future. Unfortunately the future isn't here yet.
I have been writing Swift for 6 months now. Almost every single day. I will be shipping an App to the App Store this month written in Swift. The language is fantastic and the future of what languages should look like Swift.<p>However, I do not do billable consulting work in Swift. I am twice as slow writing Swift than I am writing Objective-C. The toolchain is very brittle. The debugger is near unusable. The instruction pointer bounces all over the source file while debugging. SourceKit crashes all of the time. Multiple times an hour. And build times are about twice as slow as Objective-C builds.<p>Swift is fine for personal projects or small libraries. I'm not going to bill hours in Swift until another major release.<p>Btw, I send a weekly Swift newsletter: <a href="http://www.swiftnews.co" rel="nofollow">http://www.swiftnews.co</a>
As a datapoint: we build the Minuum Keyboard (<a href="http://minuum.com" rel="nofollow">http://minuum.com</a>), and our iOS version was written from the ground up in Swift. That is shipped in the App Store and has been since iOS 8 launched.<p>To echo much of the sentiment here: the language is definitely usable in production now. The tooling is <i>not</i> ready yet. We have wasted untold hours dealing with XCode crashing. If you're contracting this out keep in mind those hours.<p>There are also some issues with the bridging to Objective-C for Cocoa APIs. As an example: we've had a few cases where for performance reasons we've needed to replace Swift arrays with NSArray objects.<p>That said: there's a lot to like about the language and there are parts of our codebase that are really nice by virtue of being Swift.<p>EDIT: I want to agree with a number of people here about using the language your contractor is comfortable with. If you don't have a strong in-house reason to use Swift, Objective-C is going to be around for a long time, so I wouldn't worry about that.
Swift is ready for production. XCode isn't.<p>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.<p>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.
I'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.<p>The good:<p>- 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.<p>- Everything largely works as advertised; even for a super new language, the amount of total brokenness is minimal.<p>The bad:<p>- 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.<p>- The compiler is a lot slower than I think they mean for it to be.<p>- The debugger takes several seconds to evaluate an expression compared to almost instantaneous evaluation in Objective-C.<p>- 8 MB of standard library in your app binary.<p>The ugly:<p>- "SourceKitService crashed" messages in Xcode flashing on the screen at 30 hertz.<p>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?
When they say that, they probably just mean that their developers aren't up to speed yet on Swift, so they don't feel comfortable writing it in Swift.<p>You'd likely pay more for them to learn Swift on the job.
I think this decision needs to be taken on a case by case basis, instead of a universal answer. You need to evaluate the lifecycle of the project. If this project is going to be around for only 1 year (like a game or marketing campaign that quickly ramps up and then dies down), you're better off getting it done in Objective C. The client will be happier given their familiarity with Objective C, and you'll have an easier time explaining it to their in-house team.<p>However, if this is longer term bet like an app that's going to be in use after 3-5 years, you should have a honest discussion with the client about considering Swift. While Objective C is more well understood and supported right now, that might not be the case in 3-5 years. Most Apple developers would rather be writing Swift code in that timeframe, and any ObjC code will be perceived as "legacy", difficult to debug, and abandoned code that no one likes to touch.<p>I've worked on many iOS projects like this, which contain pre-ARC code, which no one likes to go near. Bugs in that code tend to be ignored and entire features are left to rust because the source code is so dated that it's better to leave it alone than risk breaking anything by modifying it. If this project could end up in that state, it's better to be future-proof and start with Swift. However, if it's a short term app, choose the path of least resistance, which seems to be Objective C at the moment.
According to this blog, you'll get more correct code with Swift:<p><a href="http://www.sunsetlakesoftware.com/2014/12/02/why-were-rewriting-our-robotics-software-swift" rel="nofollow">http://www.sunsetlakesoftware.com/2014/12/02/why-were-rewrit...</a><p>Over the lifetime of the software, anything you can do to reduce bugs is a win.<p>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: <a href="http://www.h4labs.com/dev/ios/swift.html" rel="nofollow">http://www.h4labs.com/dev/ios/swift.html</a>
I'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.<p>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.<p>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.
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.<p>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.
There is no correct answer. It really depends. If you use Swift like a different syntax for Objective-C, it's probably way faster to keep writing ObjC (because of the broken tooling).<p>If you can leverage other patterns, such as FP, you might be able to achieve a big speedup in writing Swift.<p>It also really depends on when you want to ship: if it's a bit more long-term, Swift might be a better bet (I'm assuming that in a few years from now, almost all iOS apps will be written in Swift). If it's more important that it's ready next month, ObjC might be better, because the devs will know exactly what it takes to ship it, and will almost certainly not run into unexpected issues with the language or compiler.<p>That said, I'm writing my next product 100% in Swift, and we're on schedule to ship in 2 weeks. I wouldn't have done it any other way, and have seen a big increase in productivity and fun.
It is production ready. It isn't without its quirks (specially Xcode support) but been using it for a while and works fine for production apps.<p>As jefflinwood mentioned, most likely they don't have the developers proficient in Swift and just want to downplay it. For me this is a red flag for the company.
Interesting coincidence... I developed a game [1] in Swift and posted it as a "Show HN" about an hour ago [2].<p>Initially, I admit that I did have some rough times as I worked through all of the Xcode 6 betas, and that was quite challenging. However, things have definitely gotten better with production releases of Xcode.<p>I know that it's a game and not a traditional app like you are developing, but I think my game shows that you can achieve a quality result with Swift.<p>[1] <a href="https://itunes.apple.com/us/app/rocket-renegade/id955229059?mt=8" rel="nofollow">https://itunes.apple.com/us/app/rocket-renegade/id955229059?...</a><p>[2] Show HN: Rocket Renegade, a Space Shooter for iOS in Swift<p><a href="https://news.ycombinator.com/item?id=8888070" rel="nofollow">https://news.ycombinator.com/item?id=8888070</a>
I 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.<p>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.<p>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).
My only real complaint is compilation time. I'm at around 3000 lines of code and maybe 30 files and it takes 2 minutes to compile and run. An Objective-C app would be less than a few seconds, but unfortunately Swift doesn't do incremental compilation.
Sounds like an excuse to me.<p>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.<p>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 at night. Although my impression is that Swift is stable enough even for this category of apps.<p>But, I'd wager that vast majority of apps out there do not fall under that category.
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.
I personally made an app using Mapkit that's in the App Store. It's not exactly a huge or complex app but it works fine. I think it all depends on if the developers feel comfortable writing it in Swift. But the truth is why do you want it to be written in Swift? Does it really matter?<p>Shameless promotion: <a href="https://itunes.apple.com/us/app/mappa/id931699397?mt=8" rel="nofollow">https://itunes.apple.com/us/app/mappa/id931699397?mt=8</a>
I’d say its ‘ready’ for prod but can still be a pain regarding tooling. I’ve written a Faye client in swift <a href="http://github.com/hamin/FayeSwift" rel="nofollow">http://github.com/hamin/FayeSwift</a> and will eventually update my mac app too <a href="https://itunes.apple.com/us/app/mackernews-hacker-news-client/id946730699?mt" rel="nofollow">https://itunes.apple.com/us/app/mackernews-hacker-news-clien...</a>
I 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)<p>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.<p>The language is ready, but most of the developers aren't.
XCode tooling support is limited in some areas but definitely production ready. LinkedIn's new SlideShare app is written completely in Swift:
<a href="http://readwrite.com/2014/10/02/slideshare-app-built-in-swift-language" rel="nofollow">http://readwrite.com/2014/10/02/slideshare-app-built-in-swif...</a>
Absolutely , we shipped our first enterprise swift app at Elementum ( Manufacture
<a href="https://appsto.re/us/Jfn34.i" rel="nofollow">https://appsto.re/us/Jfn34.i</a> ) at the end of last year. There was a learning curve but the metrics regarding lines of code , and time to market made it well worth it.
Swift is fine. I have released a Swift app that uses the maps api pretty extensively and it works great.<p>As BSousa mentions, xcode can be a bit flakey sometimes (syntax parser/autocomplete crashes sometimes) however it automatically restarts so it isn't really an issue.<p>I agree with BSousa that this FUD seems like a cultural red flag with the company.
One pro of using Swift which I haven't seen mentioned here is that you will be able to attract more developers to your project if you write it in Swift. Everyone wants to work on the new hotness. This is a long term value and could outweigh any short term shortcomings of the tools.
I'd agree with the sentiment that it's ready but not without its quirks. Check out some libraries I've been making in it per user request. Fun to write, terse, elegant.<p><a href="https://github.com/mapbox/?query=swift" rel="nofollow">https://github.com/mapbox/?query=swift</a>
Eh, I haven't enjoyed the debugger in Xcode when using swift.<p>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.<p>Also, Obj-C isn't likely going anywhere.
Yes, 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.