Objective-C isn't going anywhere, just like C++ hasn't gone anywhere, nor has C left the building either.
There are 124 public frameworks in the 10.10 sdk, 357 private ones. While a good chunk of these are written in Objective-C, a good deal of them are written in C, or Objective-C with the guts in C++. AVFoundation, for example, is mostly C++ in the "backend".
The amount of effort it would take to move those to Swift would be fairly substantial, and with no real gain. This doesn't mean that new frameworks won't be written in Swift, but still interoperable with Objective-C, this will probably happen - though I doubt it'll happen in my development lifetime. So we are looking at a gradual replacement of frameworks, or superseding with newer ones (QuickTime -> AVFoundation -> ???).
He brings up Carbon, but erroneously as Cocoa actually predates Carbon and Carbon was only meant to serve as a compatibility bridge from OS 9 to OS X. Carbon was meant to die.
I don't plan to switch to Swift unless I absolutely have to. I spend 14 hours a day developing for OS X, but my problem isn't Objective-C, it's the ambiguous documentation and mildly temperamental behavior of certain frameworks coughAVFoundationcough. I didn't need Swift, wasn't looking for Swift. I have nothing against it, I'm sure it's awesome, but language isn't my issue at this point, so I don't really have much to gain by it.
I appreciate your feedback, but I think you're reading an entirely different argument than what is presented in the article. It's not that everything is going to be rewritten in Swift (I'm not sure where you got that idea). Rather, the article is an exploration of what Swift without Obj-C & Cocoa could be, and under what circumstances that might become a reality.
If Swift doesn't have to accommodate Objective-C as it currently does, it's reasonable to assume that system frameworks will be designed and built in ways that make the most of Swift's language features, just as Cocoa currently does with Objective-C.
My initial enthusiasm for Swift faded pretty quickly when I tried to actually use it. The tooling is buggy and unstable. Code that calls Cocoa APIs is often no less verbose than ObjC. Every XCode release brings syntax-breaking changes. It feels like the language design was compromised by the requirement to bridge to Cocoa; all the strictness of the language is just a facade when you're manually casting every time you deal with a collection, for example. I guess I like the strict handling of nils in principle but in practice I've found this often means the user gets a crashed app instead of a more tolerable bug.
I'm getting out of iOS/OS X coding anyway for other reasons but even if I weren't I certainly wouldn't use Swift for production yet. Apple should not have pitched Swift as production-ready at WWDC. I think a lot of us would be less critical if it had been billed as the technology preview it was (and still is).
I'm really loving Swift, but Xcode has gotten atrocious. I have a keyboard app with 8 different sub-keyboards, and 80% of the time, when I open my project, Xcode gets stuck in indexing. You can't build, you can't close Xcode, you can't do anything but force-quit and hope it doesn't happen next time. There are also frequent SourceKit crashes, random crashes to the desktop, and incredibly laggy typing and auto-completion. WTF?
"I guess I like the strict handling of nils in principle but in practice I've found this often means the user gets a crashed app instead of a more tolerable bug."
How are you using optionals in such a way that it crashes your app? I've found that using optional chaining and the "if let" block guards your code against accidental nilling even more. My rule of thumb so far is to never ever use the "!" operator except for initialization. I've found that whenever I get a crash — which is rare these days — it's usually because I forced an optional, or possibly used "as" instead of "as?".
"All the strictness of the language is just a facade when you're manually casting every time you deal with a collection, for example."
I dunno, I kind of like the explicitness of (cocoaArray[i] as? ABMyObject). It's no more work than you'd be doing with a generic NSArray anyway, and you get type checking for free. (And, of course, all your Swift native arrays and maps don't have to follow this pattern.)
I'm glad I'm not the only one who feels that way. I read through the book on night 1 and was stoked to Swiftify my life, but was disappointed nearly as fast when I realized how icky Cocoa(Touch) was to implement in Swift. It felt unnatural, and I've used languages with named parameters before, but forcing the two paradigms together seems wrong.
Initially I was ripping my hair out with Swift, but after couple months of using it full time, things are much smoother now. I still have doubts on it's production-readiness though.
And the strictness is pretty badass imo. Objective-c feels very imprecise and unsafe in many ways.
Apple used quite a bit of fanfare (they're just good at it), but I never construed Swift to be more than a beta, and I still don't think that it's more than that.
I agree with most of what you are saying. I have no problem with Objective-C as well. I never had a problem with Objective-C and I have done Objective-C for over 10 years now…
But I would like to mention that people seem to overestimate the work required to "port" a framework from one language to another. Take 280North as an example. A tiny company (funded by ycombinator) founded by 2 ex Apple employees. They have developed a JavaScript variant of Objective-C (called Objective-J) and reimplemented the most important parts of AppKit. It took them a couple of months but in the end it all worked out, many people used (and are still using it) Cappuccino (name of the framework) and 280North was bought by Motorola for something like $20.000.000. So two guys => 1 language, a couple of frameworks in a matter of months.
Also I am sure you are aware that every year Apple introduces a ton of new frameworks and deprecates some frameworks. It would only take a couple of releases to deprecate 80% of the frameworks used by most apps and introduce replacements for them.
Swift without a new set of frameworks makes little sense IMHO. So either Swift will dies - just like GC did or it won't and then we will see new frameworks written in Swift.
Talking about GC… When Apple introduced GC they told us that it was the latest and greatest shit. It was the future. When introducing GC they told us that "hey - we have ported Xcode to GC - look it is that easy.". So they had more apps using GC from day 1 than using Swift from day 1 (well the WWDC app written in Swift does not count…). Apple had to ship GC-capable versions of their frameworks from day 1. They were even more committed to GC than they are now to Swift so it would not surprise me at all to see Swift let go in a couple of years and buried deep.
>Talking about GC… When Apple introduced GC they told us that it was the latest and greatest shit. It was the future. When introducing GC they told us that "hey - we have ported Xcode to GC - look it is that easy.". So they had more apps using GC from day 1 than using Swift from day 1 (well the WWDC app written in Swift does not count…). Apple had to ship GC-capable versions of their frameworks from day 1. They were even more committed to GC than they are now to Swift so it would not surprise me at all to see Swift let go in a couple of years and buried deep.
No way for Swift to "let go". It solves a problem (having a modern language for OS X to go forward") that Objective-C doesn't.
Besides swift makes sense even without a new set of frameworks. People use it already and are productive. Sure, Swift inspired frameworks would be a better fit, but that not a show-stopper.
GC wasn't that much a deal to let go, because they found a way to do the same thing without it (ARC). It's not like they had to rewrite anything for the new post-GC era.
> GC wasn't that much a deal to let go, because they found a way to do the same thing without it (ARC). It's not like they had to rewrite anything for the new post-GC era.
The official recommendation from Apple was to not transition for GC but only to use it for new projects or for complete rewrites. So it was a big deal for every developer who relied on GC.
And only because something is new does not mean it is modern. All of the concepts that Swift implements are fairly old. Swift is just new.
Though, look at QuickTime for example. That was deprecated in Mavericks, but it's going to be around for another few releases. AVFoundation (the framework I use the most) is used by FinalCut, iMovie, etc. so porting that isn't straight forward because it would break so much stuff. So I do think you'll see deprecation of certain things as maybe they move to design patterns that are a better fit for Swift, but entirely replacing AVFoundation would be straight up insane when it works so well (as long as you are doing everything by the rules laid out in a largely unwritten book).
One of the reasons why QTKit sticks around is that it has been around since 10.3 and it's foundation is even older going back to I think 1992.
So I think QTKit is an edge case and probably not used by a ton of developers directly. I think the 80/20 rules also applies here... by porting 20% of the frameworks you get 80% of the functionality.
That being said: I think that if it happens it will happen over time. Deprecating something in Mavericks does not mean that it has to be gone in the release after Mavericks. GC was with us for way too long... But you can replace almost anything within lets say 5-7 years. That would be 5-7 major releases.
Garbage Collection. Not that long ago Apple came out with full GC in Objective-C to a lot of fanfare (no more retain releases yay). Not long after that they said to just use ARC (which is compiler retain/releases) because the GC was not working well. Today, it's hard to find any mention of the GC.
If your app used GC then everything your app links against or loads at runtime has to be GC-compatible. So Apple had to make all of it's frameworks GC-compatible. But many 3rd-party frameworks didn't.
Also: If your app used WebView to load a web site which contained something with flash (YouTube, ...) then your GC app would crash immediately because WebView loaded the Flash plugin which was not GC-compatible.
Thus using a WebView to load arbitrary sites was incompatible with GC.
And for what it's worth, it took a hell of a lot longer than a couple of months to build something useful. Years later and it still isn't a full port of what was available at the time in Cocoa.
I saw a talk of one of you guys... you mentioned that it took a lot of experimentation before you even considered not using plain JS. But you should also not downplay your achievement! You did a great (maybe not complete) port of Objective-C/Cocoa which was good enough to be used by a lot of people and good enough for Motorola. :)
And Apple is certainly in a better position to do such ports than you were back then: They have the full source code of every framework they developed. I am not saying it is trivial or not much work but it is doable over a couple of years... don't you think? You have certainly more internal knowledge than I do.
14 hours a day, and your problem is ambiguous documentation and temperamental behavior? I don't mean to detract from your primary points, but 14 hours a day is quite a chunk of time. I hope its not your norm, because that just sucks.
10-14 hours a day is the norm and I still get in the gym, dinner with the wife, vigorous sex, a few games of vain glory and other facets of "normal life".
I also take weeks off at a time because I mostly work for myself. In fact, I've been traveling for the last 4 years (I moved to Vietnam from NYC about a year ago).
So, it might suck for you, but I would hardly say my life sucks because I work so much. Mostly because it isn't really work to me, but mostly because at 41 I know what balance works for me.
I have this image of you, in a dining room with a mirrored wall, having vigorous sex with your wife while she is eating a sensible dinner - trying to safely navigate a forkful of mixed greens. You are looking at yourself in the mirror and flexing interspersed with loud beckonings of "Am I VIGOROUS?! YES I AM! GETTING SHIT DONE!"
You get done, smack your own butt playfully, and walk out with your plates saying, "I have to get some other normal shit done. Love you!... and you too wife!"
I'm not saying there's anything wrong with you or your lifestyle... but when you awkwardly present the style of your sex life as part and parcel to normal living, it underlines that you are a bit detached from social norms, thus normal life.
BBC interviews people on the street...
BBC: So how are you getting on with life these days?
Person: Ahhh... well, it's mostly normal day to day stuff. Kids, pub, job, vigorous sex, groceries, some football or cricket when I can. Just normal all around.
Sorry, I just reread that and I didn't mean to come off like a dick. I'm just saying, I've found the balance that works for me and that work is not really work to me. I do get the normal things in, though sometimes at an accelerated pace. And I don't do the 14 hours every single day, but 10-12 hours is probably more the norm.
I actually think something like this might be my ideal -- spurts of intense work, followed by several weeks of not working at all. This is what I tended to do on personal projects when I was younger. I think this could be a quite healthy, long-term sustainable way to arrange work.
I've had many 14 hours days that were awesome, many of them included work. I agree, just because you don't like your "work" doesn't mean you should judge me for enjoying my "work". LOL
There is no reason not to use Swift, Swift can do all that Objective-C can do and more. The language, framework support and the compiler have reached 1.0, the only thing that keeps happening is an error message in Xcode that I can safely ignore and keep working. But projects written in Swift are safe for production.
The reason you could switch to Swift is that it is safer, less verbose (unless you interact with Objective-C) and more flexible. You can choose to use Swift in a way that you are just using Objective-C translated to Swift and ignore all the extras or you can choose to use all the extra goodies you get like map, reduce, currying, advanced switch case statements and more. These features aren't new but they are not common in a lower level language comparable to C++ and Objective-C.
Swift is comparable to Rust in that sense. Nobody needed Rust but Rust doesn't stop you from doing anything you could do before while it gives you a lot of extra goodies from higher level languages.
A lot of people tried Swift when it was in a beta and ran into problems with it and got frustrated. Then repeat those experiences all over the internet like it happened to them just yesterday. There's also a significant portion of the iOS development community that rejects AutoLayouts because it was too alien to them and the first iteration wasn't perfect.
Last but not least: you're not forced to use only Swift in any project. Of course it's easier to wrap C code in Objective-C and then use it with a bridge in your Swift project. I mix and match every day, I'm not going to rewrite perfectly sane Objective-C code because I'm doing a Swift project. Try to be pragmatic about it.
Truth is that Objective-C style libraries really do seem really cumbersome and verbose when you use it in much more lightweight Swift code.
Objective-C isn't going anywhere, just like C++ hasn't gone anywhere, nor has C left the building either.
There are 124 public frameworks in the 10.10 sdk, 357 private ones. While a good chunk of these are written in Objective-C, a good deal of them are written in C, or Objective-C with the guts in C++. AVFoundation, for example, is mostly C++ in the "backend".
The amount of effort it would take to move those to Swift would be fairly substantial, and with no real gain. This doesn't mean that new frameworks won't be written in Swift, but still interoperable with Objective-C, this will probably happen - though I doubt it'll happen in my development lifetime. So we are looking at a gradual replacement of frameworks, or superseding with newer ones (QuickTime -> AVFoundation -> ???).
He brings up Carbon, but erroneously as Cocoa actually predates Carbon and Carbon was only meant to serve as a compatibility bridge from OS 9 to OS X. Carbon was meant to die.
I don't plan to switch to Swift unless I absolutely have to. I spend 14 hours a day developing for OS X, but my problem isn't Objective-C, it's the ambiguous documentation and mildly temperamental behavior of certain frameworks coughAVFoundationcough. I didn't need Swift, wasn't looking for Swift. I have nothing against it, I'm sure it's awesome, but language isn't my issue at this point, so I don't really have much to gain by it.