Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Is Swift ready for production yet?
69 points by flibble on Jan 14, 2015 | hide | past | favorite | 43 comments
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.

The app is a list based app, making use of the Map API and making HTTP calls. No complex maths or graphics involved.

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.

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.


The xcode problems sounds almost like Google's change to Android Studio from eclipse. Except, Android Studio was never as bad, and it got better very quickly. In fact, Andoid Studio is probably at least as good as eclipse for Android development.


Android Studio is much better than Eclipse already, and it was built on the already mature Intellij IDE.


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.

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.

Swift is fine for personal projects or small libraries. I'm not going to bill hours in Swift until another major release.

Btw, I send a weekly Swift newsletter: http://www.swiftnews.co


As a datapoint: we build the Minuum Keyboard (http://minuum.com), 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.

To echo much of the sentiment here: the language is definitely usable in production now. The tooling is not ready yet. We have wasted untold hours dealing with XCode crashing. If you're contracting this out keep in mind those hours.

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.

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.

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.

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.


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.

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?


    >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?
Unless the owner wants to be forever betrothed to the outsourcing company the language selection is a valid concern. For instance, [she|he] may want to take over updates when iOS9 comes out and plans on being proficient in Swift by then.

The owner should weigh why they wanted Swift in the first place vs. the consultant's recommendation and then decide from there.


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.

You'd likely pay more for them to learn Swift on the job.


Just what i was about to write.


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.

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.

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:

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


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.

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.


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.


... 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.


The Linux Philosophy of a kernel that runs on everything from a super computer to a smartphone is sort of misguided I think. You can write much smaller and potentially faster kernels if you focus on one architecture and use case, see for example the Oberon project (it uses a pascal descendant for its system language, also called Oberon) or the Mesa/Cedar system at Xerox Parc. With time I'm sure that kernel designs like the Singularity OS one will take over: Invent a systems programming language that allows for better static analysis and verification of driver protocols. Then run everything at ring 0 and identity mapped virtual address translation, with most of the applications written in memory safe languages or virtualized in app containers. That way context switches, which incur huge overhead, as well as heavy weight processes are a thing of the past.


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).

If you can leverage other patterns, such as FP, you might be able to achieve a big speedup in writing Swift.

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.

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.

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].

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.

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.

[1] https://itunes.apple.com/us/app/rocket-renegade/id955229059?...

[2] Show HN: Rocket Renegade, a Space Shooter for iOS in Swift

https://news.ycombinator.com/item?id=8888070


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.

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).


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.

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 at night. Although my impression is that Swift is stable enough even for this category of apps.

But, I'd wager that vast majority of apps out there do not fall under that category.


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.


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.


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).


Want macports semi developed by apple staff?


Yes, at least initially. I don't if any Apple employees still contribute to MacPorts, though. Apple does still provide hosting and infrastructure to the project, for what it's worth.


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?

Shameless promotion: https://itunes.apple.com/us/app/mappa/id931699397?mt=8


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...


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)

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.


XCode tooling support is limited in some areas but definitely production ready. LinkedIn's new SlideShare app is written completely in Swift: http://readwrite.com/2014/10/02/slideshare-app-built-in-swif...


Absolutely , we shipped our first enterprise swift app at Elementum ( Manufacture https://appsto.re/us/Jfn34.i ) 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.

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.

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.

https://github.com/mapbox/?query=swift


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.


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.


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.


If you are dead set on doing it in Swift shoot me an email and we can talk further about it. (Email in profile)


Has Apple shipped anything yet that runs in Swift? Can we tell?


Don't know if they have shipped anything major but the WWDC app was meant to be in Swift I think. You could probably tell if you get it in the debugger.


If I remember correctly, 2014's WWDC app was written in Swift.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: