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?
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.
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
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.
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.
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?
The owner should weigh why they wanted Swift in the first place vs. the consultant's recommendation and then decide from there.
You'd likely pay more for them to learn Swift on the job.
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.
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
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.
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.
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.
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.
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.
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
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).
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.
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.
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).
Shameless promotion: https://itunes.apple.com/us/app/mappa/id931699397?mt=8
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.
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.
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.