
Swift 2 Apps in the App Store - julien_c
https://developer.apple.com/swift/blog/?id=32
======
Eric_WVGG
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
+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...](http://stackoverflow.com/questions/32586144/upgraded-to-swift-2-and-
cocoapods-38-2-now-getting-build-error-command-bin-s)

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
"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
Or for those who prefer automating, add this to ~/.bash_profile:

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

~~~
seivan
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
Good tip. As someone with quite a small main HDD I'll do this ASAP.

------
Tobias42
If your Swift app is using SpriteKit it might take a little longer to get it
ready for the App Store:
[https://forums.developer.apple.com/thread/17463](https://forums.developer.apple.com/thread/17463)

Apple really screwed up SpriteKit badly in the new version. I'm experiencing
almost all of the problems mentioned in the forum.

~~~
rsy96
I scanned the post and it seemed the issues are regardless of the language.

~~~
Tobias42
That's true. I didn't want to badmouth swift, I quite enjoy developing with
it. I guess I just needed to vent my anger about SpriteKit a little.

------
melling
I maintain a database of Swift resources:
[http://www.h4labs.com/dev/ios/swift.html](http://www.h4labs.com/dev/ios/swift.html)

It appears that most iOS devs who blog are using Swift.

------
bsaul
Here's my prediction : apple is currently working on a replacement framework
for cocoa (at least uikit), that will be writen for swift first, taking
advantage of its great special features.

My other guess is that it will come in time for ios 10 and be cross-platform (
aka work on mac os as well as ios).

I have absolutely zero inside info, but the fact is cocoa felts great and
elegant on ios3 , but with all the latest additions it now starts to feel old
and convoluted. Objective-c has been patched incredibly well but can only go
so far, and the convergence of hardware between devices makes the distinction
between computers and tablets more and more obsolete.

~~~
archagon
Plus, OSX needs a UIKit-style revival, especially with all the recent
grumbling about the Mac App Store. Having just written an OSX app after doing
UIKit for several years, it feels incredibly old and clunky in comparison.
Even simple layer transform animations are for the most part unsupported!

------
bionsuba
Ok cool, but where's the source code? It's been almost three months since the
announcement and no ones even mentioning it anymore.

~~~
rdsnsca
This was ask on Reddit recently, and Chris Lattner answered:

[https://www.reddit.com/r/swift/comments/3kbjjn/so_swift_isnt...](https://www.reddit.com/r/swift/comments/3kbjjn/so_swift_isnt_open_source_yet_then/)

We are still on track to open source Swift (including Linux support) "by the
end of 2015" as promised, more details will come out when they can.

-Chris

------
gorena
Swift 2 is fantastic _except_ (har har) for exceptions. Optional<T> has been
hanging out, monad-y and all, since v1. Why not Result<T, E>? You can't
flatMap exceptions, and the Swift 2 implementation even throws away type data
(or hides it, at least). Huh?

~~~
ridiculous_fish
I guess you mean the new do-try-catch syntax? IMO it's quite lovely, and
strikes exactly the right balance between the checked exception tyranny of
Java, and the strap-in-and-good-luck wild west of C++.

My favorite feature of Swift's exceptions is the 'try' syntax required at the
call site. This isn't like Java's try syntax: every call that may raise an
exception needs a try, even if all you want to do is rethrow the exception.
But the syntax is lightweight: just preface the call with 'try', it doesn't
make a new scope. This makes the abnormal control flow explicit, addressing
one of the strongest critiques of Java-style exceptions.

My second favorite features is the 'try!' syntax. This is the escape hatch:
Swift's version of the empty-catch-block pattern of Java, except that it's 1.
much more lightweight, because it doesn't introduce a new scope, and 2. the
default behavior is to abort instead of swallow. It's perfect for non-
production code like tests.

Regarding "you can't flatMap exceptions," I would respond that exceptions are
meant to be exceptional, and this is what justifies the abnormal control flow.
The do-try-catch syntax is an adequate substitute for flatMap, and more
lightweight than requiring explicit unpacking of every return value ala Go.

But as you say, the hiding of type data is definitely weird. For those
following along at home, Swift requires explicitly annotating functions that
may throw errors, but not what those errors are, so you have to refer to the
documentation. Also the compiler will complain if you don't have a backstop
exception handler. Lastly, it introduces a magic variable 'error' that is
defined within catch blocks: convenient but it feels ad-hoc.

~~~
gorena
Well, for example, try/catch don't work asynchronously, so you can't pass it
to a callback (or use it in a SignalProducer in RAC). If failure/success is
Just Another Value, it works everywhere that values work. That they already
use an ADT for nullability it what confuses me - ".None, but with an error"
isn't a far off concept from that.

antitypical/Result already provides Result.init(() throws -> T) -> Result<T,
E>, so it's easy enough to work around, at least.

The magic variable stuff exists in didSet as well, weird and sketchy to use.
Would prefer it to be explicit in all cases.

