
Ask HN: Is Swift ready for production yet? - flibble
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&#x27;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?
======
ary
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.

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

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

------
pkaler
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](http://www.swiftnews.co)

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

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

------
puls
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?

~~~
jbigelow76

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

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

~~~
ohnoesmyscv
Just what i was about to write.

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

------
melling
According to this blog, you'll get more correct code with Swift:

[http://www.sunsetlakesoftware.com/2014/12/02/why-were-
rewrit...](http://www.sunsetlakesoftware.com/2014/12/02/why-were-rewriting-
our-robotics-software-swift)

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](http://www.h4labs.com/dev/ios/swift.html)

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

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

~~~
pavlov
_... 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.

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

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

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

------
Arjuna
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?...](https://itunes.apple.com/us/app/rocket-
renegade/id955229059?mt=8)

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

[https://news.ycombinator.com/item?id=8888070](https://news.ycombinator.com/item?id=8888070)

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

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

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

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

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

~~~
slavoingilizov
[https://medium.com/@stigi/swift-cocoapods-
da09d8ba6dd2](https://medium.com/@stigi/swift-cocoapods-da09d8ba6dd2)

~~~
Osmium
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](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).

~~~
Alphasite_
Want macports semi developed by apple staff?

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

------
csolares23
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](https://itunes.apple.com/us/app/mappa/id931699397?mt=8)

------
harisamin
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](http://github.com/hamin/FayeSwift) and
will eventually update my mac app too
[https://itunes.apple.com/us/app/mackernews-hacker-news-
clien...](https://itunes.apple.com/us/app/mackernews-hacker-news-
client/id946730699?mt)

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

------
Zaheer
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...](http://readwrite.com/2014/10/02/slideshare-app-built-in-swift-
language)

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

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

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

------
incanus77
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](https://github.com/mapbox/?query=swift)

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

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

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

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

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

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

