31–40 of 44 posts
Shameless promotion: https://itunes.apple.com/us/app/mappa/id931699397?mt=8
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
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.
Earlier quoted context omitted.
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/M…
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.
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 sup…
>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.
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 Xco…
... 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 explo…
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