+1 for mentioning the "Clean Build Folder" issue. I was stuck on that for about an hour yesterday, then I found this post:

http://stackoverflow.com/questions/32586144/upgraded-to-swif...

I didn't know about using the Alt key to reveal "Clean Build Folder", and I've been doing iOS dev for years. I'll add this to the list of unhelpful compile errors that are fixed by cleaning the build.

"Clean Build Folder" is basically the "turn it off, then turn it back on" of Xcode. Almost anytime you get a weird compiler error on a project that compiled fine moments ago, it's solved by "Clean Build Folder."

Definitely a good trick to know.

Or for those who prefer automating, add this to ~/.bash_profile:

   alias nuke="rm -rf ~/Library/Developer/Xcode/DerivedData/"

That's pretty drastic. That nukes the derived data folder of all your Xcode projects. If you work on more than 1, using this to solve a problem in 1 will lead to needing to rebuild all of your projects. That seems a bit extreme for an issue in a single project.

I always advice people to put their DerivedData and build folder somewhere accessible. You can change it settings, don't use the default setting.

Good tip. As someone with quite a small main HDD I'll do this ASAP.

cmd+shift+k followed by cmd+alt+shift+k is a multiple-times-a-day incantation for me :)

Definitely ready. I've had a Swift app out for 4 months and it's been quite successful[1], with no Swift-related issues.

I've just updated the app to Swift 2 and it's all working great.

The only issue has been related to the new Bitcode feature in iOS, which isn't Swift-specific. It's been very difficult getting third-party libraries with Bitcode support, but Bitcode is required for watchOS 2 apps.

[1] http://streaksapp.com

I really like Swift too, but for serious usage, I find that it still gets kinda wonky in generics land. Also, not crazy about the fact that there's no such thing as abstract classes. A lot of iOS coding for me is stuff that builds on top of each other. You can subclass, but there's so many times when it's "all subclasses gotta just do this one or two things and base class can take care of rest." So what you do is define them in the base-class and throw "Must override" exception, but still, I wish this mechanic would somehow just get built-in.

Anyway, Swift is a great language though I don't mean to discredit it. It just doesn't take the spot of my #1 -- Scala. :)

Protocol extensions seem like a good way to get what you'd frequently want out of abstract classes. What's missing?

What I want (Scala land):

  trait Robot
    var serialCode = generateSerialCode()
  
    def gas
    
    def engine = Engine(gas)
    def body = Body(engine)

  class SunnyRobot extends Robot
    def gas = sun

  class OilyRobot extends Robot
    def gas = oil

Protocol extensions don't hold state. They are meant to provide default implementations for a type, not as a 1:1 relationship with the class it's implementing functionality for. Following what you're saying, I would be doing something like this:

* `extension Robot where Self = SunnyRobot { def gas() = ... }`

* `extension Robot where Self = OilyRobot { def gas() = ... }`

That looks all good and well, right? Ok, well now my sunny robot wants to find the sun and my oily robot wants to go find oil. How to provide functionality unique to each of them? Maybe I'm just not getting something, but I'm pretty sure protocol extensions are not the answer to the problem I'm trying to describe.

When you're working in front-end land, you can do your best to stay functional and be cool and all that jazz, but it's just a waste of time usually. You're going to use a lot of state and you just have to learn how to manage that effectively (IMO). What this boils down to for me is that I might build a cell that does 3 things great and will be on every cell, but then business designs call for 2 slightly different cells still based upon that main cell. Oh and when those different cells are tapped, different things should happen.

So again, I just go about doing it with the simple base class gonna throw you an exception unless you override the "abstract" method. This way, I get to keep state going down and classes can actually fill up naturally rather than playing the protocol game.

Wouldn't you define gas() and whatever class-specific methods in the class itself, instead of in extensions on the protocol?

    class SunnyRobot : Robot {
      func gas() { ... }
      func findSun() { ... }
    }

By defining `gas()` in the children, you can't take advantage of it in base class. For example, the base robot might know how to move and all that, but the sunny robot just needs to know where it's going.

Protocol extensions just don't cut it, I'm sorry. They're great for defining some default behavior and doing kinda-abstract-classes, but it's a different playing field in Swift/Obj-C than Java/Scala/C#/etc..

I think this[1] does what you want, unless I'm not understanding your problem description. AFAIK you are correct about protocol extensions not holding state. So I don't think you can implement the `var serialCode = generateSerialCode()` with just a protocol. But you could do it with a protocol + base class.

[1]: https://gist.github.com/jayrhynas/49945331e41314fc3ede

Edit: I just realized that with this method, the protocol extension is useless, you could just define `move` on Robot. So protocol extensions can give you a mix of abstract & default methods but if you need to inherit state you need to use a base class.

All uploaded builds of my iOS 9 content blocker, written in Swift 2 with Xcode 7 GM, were (and still are!) stuck "In Processing" on iTunes Connect.

I rewrote the extension in Objective C and uploaded another build, and after a few minutes, I was able to submit it to the App Store.

Just a random anecdote that made me go back into late adopter mode for the rest of the year. It's great that Swift mostly works, but I'm really scared of the times when it doesn't.

(Edit: Not just me - https://forums.developer.apple.com/message/50182#50182)

Swift 2 seems to have fixed one of my biggest bugbears about Swift 1: that if you command-clicked a function where one of the parameters was the wrong type, it wouldn't take you to the closest matching declaration in the headers (as it did in Obj-C) but would instead tell you that it couldn't find the function declaration. Now it seems to work! No more having to dig through the docs for small corrections.

Dunno about exceptions, though. I've seen lots of great arguments against them on HN and elsewhere, and the error reference (or alternatively double-return via tuple, especially since you can name tuple slots) seemed more clear.

I love Obj-C (probably because I love Smalltalk). Before Swift 2, I didn't see what the excitement was about. Since using Swift 2, I want to use it everywhere. I will miss some of the dynamic features of Obj-C, but there are other ways to get to the same end. The terseness of Swift while maintaining Obj-C clarity, is wonderful.

That's a pretty small app. Sure, it's ready for smaller apps but, things aren't so great on larger scale apps.

This was being down-voted for no reason. He's right..