5 ms·

I ran the “Convert > To Latest Swift Syntax” on an app with about six view controllers, four views, a network service, and three cocoapods. It worked surprising

I ran the “Convert > To Latest Swift Syntax” on an app with about six view controllers, four views, a network service, and three cocoapods. It worked surprisingly well, most of the changes were really just suggestions ("this var something could be a let something"), small change to how NSData unwraps. I did have to guess around an obscure compile issue (solution: "Clean Build Folder"), but after that it was clear sailing. My overall Swift experience has been terrific. I’m not the first to say this, but to anyone who’s wondering if it’s “ready”, yeah, it’s ready.

jonnynezbo 11y ago
+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-swift-2-and-cocoapods-38-2-now-getting-build-error-command-bin-s 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.
- w4 11y ago
  "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.
  - dv_says 11y ago
    Or for those who prefer automating, add this to ~/.bash_profile: alias nuke="rm -rf ~/Library/Developer/Xcode/DerivedData/"
    - seivan 11y ago
      I always advice people to put their DerivedData and build folder somewhere accessible. You can change it settings, don't use the default setting.
      - wingerlang 11y ago
        Good tip. As someone with quite a small main HDD I'll do this ASAP.
    - vitd 11y ago
      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.
- div 11y ago
  cmd+shift+k followed by cmd+alt+shift+k is a multiple-times-a-day incantation for me :)
emp 11y ago
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.
archagon 11y ago
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.
qzervaas 11y ago
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 http://streaksapp.com
gurkendoktor 11y ago
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 https://forums.developer.apple.com/message/50182#50182)
allsystemsgo 11y ago
That's a pretty small app. Sure, it's ready for smaller apps but, things aren't so great on larger scale apps.
- joslin01 11y ago
  This was being down-voted for no reason. He's right..
joslin01 11y ago
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. :)
- _jsn 11y ago
  Protocol extensions seem like a good way to get what you'd frequently want out of abstract classes. What's missing?
  - joslin01 11y ago
    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.

jonnynezbo 11y ago

+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-swift-2-and-cocoapods-38-2-now-getting-build-error-command-bin-s 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.

w4 11y ago
"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.
- dv_says 11y ago
  Or for those who prefer automating, add this to ~/.bash_profile: alias nuke="rm -rf ~/Library/Developer/Xcode/DerivedData/"
  - seivan 11y ago
    I always advice people to put their DerivedData and build folder somewhere accessible. You can change it settings, don't use the default setting.
    - wingerlang 11y ago
      Good tip. As someone with quite a small main HDD I'll do this ASAP.
  - vitd 11y ago
    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.
div 11y ago
cmd+shift+k followed by cmd+alt+shift+k is a multiple-times-a-day incantation for me :)

emp 11y ago

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.

archagon 11y ago

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.

qzervaas 11y ago

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 http://streaksapp.com

gurkendoktor 11y ago

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 https://forums.developer.apple.com/message/50182#50182)

allsystemsgo 11y ago

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

joslin01 11y ago
This was being down-voted for no reason. He's right..

joslin01 11y ago

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

_jsn 11y ago
Protocol extensions seem like a good way to get what you'd frequently want out of abstract classes. What's missing?
- joslin01 11y ago
  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.