Whither Swift?

http://lapcatsoftware.com/articles/whither-swift.html

102 117 9 years ago

mikek• 9 years ago

I think the plan has always been that Swift is the future, but Objective C will be around for a long time. Think a 30-year horizon.

Humdeee• 9 years ago

I would agree with this. I'm imagining Obj-C to eventually be Apple's COBOL. Even presently, a lot more job postings regarding iOS development are expecting Swift experience than even a year ago.

wmil• 9 years ago

Microsoft has managed to keep VB and C# alive and well supported even though its major codebases are in C++.

I don't think it's as big of a problem as the author seem to think it is.

pjmlp7• 9 years ago

Actually even though C++ has first class support on UWP, I have noticed that the language focus at Microsoft developer presentations is showing it more for lower layers of the OS and games, with C# and VB being targeted for apps development, with F# getting the data science part.

simonh5• 9 years ago

That's exactly the point. All the talk from Microsoft about dev platforms has been about C# and .NET for over a decade now, but their flagship apps are actually still developed in C++.

nickpeterson2• 9 years ago

F# isn't really aimed at data science, thats a common misconception ( I believe MS has ceased describing it that way). It's basically just a general purpose, functionally oriented language.

WayneBro• 9 years ago

The author says "Objective-C and Swift cannot continue to coexist indefinitely." but their only supporting argument is that a multi-lingual platform is bad because nobody will know what language to choose.

This is the same charge that has been leveled against Microsoft since they don't use .NET to produce every single piece of Microsoft software. Has that somehow stopped .NET from continuing to grow? No, it has not.

Off-topic: Learned a new word reading this. Lacuna ~ an unfilled space or interval; a gap. Thanks!

edw2• 9 years ago

It was also the name of the mind-erasing company in Eternal Sunshine of the Spotless mind. That is a much better way to learn that particular word than this content-free meth-binge of an essay.

brennen2• 9 years ago

"meth-binge"?

I feel like it's possible you have not known very many people on actual meth.

paulddraper2• 9 years ago

Or JVM...

Java, Groovy, Scala, Closure

Will they exist "indefinitely"? Well, all language have a lifetime, but these will/have coexisted for decades.

icpmacdo• 9 years ago

Quick spelling correction I think you mean Clojure. You got me searching for a new programming language that has a namespace conflict with a programming concept :) .

astrodust• 9 years ago

Perl and Python. Ruby and Rust.

It's almost as if people have more tools than they know what to do with!

fusiongyro• 9 years ago

Not exactly the same thing since Oracle isn't maintaining any of those outside Java.

pvg2• 9 years ago

It's an even sillier charge because the bulk of Apple's software relies on the Objective C runtime, including everything written in Swift. It's a multi-lingual platform where the new thing is (mostly) a language and one specifically designed to interoperate with the existing frameworks and runtime. The problem the article spends so much thought on feels like not much of a problem.

bangonkeyboard4• 9 years ago

Microsoft actively maintains backward compatibility for Windows programs that are decades old. Apple reliably breaks waves of apps on a yearly schedule.

You can't take one company's culture and apply it to a radically different one.

coldtea2• 9 years ago

Apple reliably breaks waves of apps on a yearly schedule.

Not by suddenly stopping support for their previously sole language, so it's a moot point.

At worse, they deprecate some APIs.

makecheck• 9 years ago

Conversion to Swift is not something that must be done 100% at once (due to reuse of the Objective-C back-end), nor is it wise to change quickly (due to source and binary incompatibilities that have been very clearly documented for the first few Swift versions). Slow-moving engineering teams, even within Apple, are just being wise; they can still be firmly behind the move to Swift.

iainmerrick4• 9 years ago

This is nothing but inconclusive speculation. It mostly focuses on whether and when Obj-C will be retired, so the title should really be "whither Objective-C?"

melling• 9 years ago

His whole argument is that if Apple had to pick one language today, it would be Objective C because internally they have largely stuck with Objective C up to now.

Well, Apple isn't going to pick one language today. They might deprecate Objective C in 5 or 10 years, but in the near term nothing should change. They're infamous for dropping "legacy" so I wouldn't rule out Objective C having a finite lifespan.

The author is right that the developer community has really embraced Swift. It is a much nicer language, with a lot less visual noise, for example.

As a quick aside, I've been working on a Cookbook for the Swift:

http://www.h4labs.com/dev/ios/swift_cookbook.html

And I've been adding to a Github repo with lots of little examples:

https://github.com/melling/ios_topics/blob/master/README.org

Finally, the Stanford CS193 course has start for Swift and iOS 10:

https://itunes.apple.com/us/course/developing-ios-10-apps-sw...

adamnemecek• 9 years ago

And of course Lattner has now left Apple, so he won't be there to take the criticism if his claim turns out to be false.

IIRC he said that he's going to still be on the core team of the language. I don't remember the email (and I can't find it right now) but I had the impression that for me, as a user, very little actually changed.

antfarm• 9 years ago

"This decision wasn't made lightly, and I want you all to know that I’m still completely committed to Swift. I plan to remain an active member of the Swift Core Team, as well as a contributor to the swift-evolution mailing list."

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

mahyarm• 9 years ago

Apple uses many languages internally. And swift & objective-c are very close in programming models in many ways. It's pretty natural for an ObjC dev to learn swift and vice versa I would imagine. If apple is having a hard time find new objective-c dev, but has swift devs, it will just train them.

A lot of code is in C++ at apple, like most of their graphics, UX & networking. Drivers in C. A lot of apps are non-ARC objective-C still and so on.

Also swift is not a solid enough language yet. Debuggers, compiling & indexing are too slow & unstable and there are things like ABI stability that are not delivered yet. I would give swift ~4+ years before it would be something to consider replacing Objective-C completely.

tolmasky6• 9 years ago

First off, this is very well written. Secondly, I'd like to state that I think that Objective-C and Cocoa were really good. I disagree with most of the design paradigms today, but I think the Objective-C/Cocoa ecosystem represented something approaching a local maxima in the mutable programming space. Maybe not even a maxima, as I was actually really happy with the direction it was going pre-Swift (KVO was starting to get good in NSTreeNode, the language additions were welcome, etc.)

All this to say: I think the Swift transition was really misguided, and I was incredibly surprised that that wasn't the general take at the time. Everything about it seemed not well-planned out: the fact that no one at Apple had heard of it (you have the world's best ObjC programmers in-house and don't bother to get internal buy-in first!), the fact that it was really a response to C++ not Objective-C (this is so clear when listening to Lattner, who incidentally, did most his programming in C++ it seems), the fact that they sold it as good for everything from scripting to systems programming (huge red flag), and on and on.

But the real concern here was the opportunity cost. What was the problem they were trying to solve with Swift? That square brackets were off-putting? That a group that until that point were totally bought into dynamic dispatch should switch gears completely to a strict typed language? If you ask me, the only goal that should have mattered was making development easier and expanding the scope of people that could approach the platform. And, for the record, I am sure they believe they attacked this problem, I clearly disagree however.

I think the real areas ripe for improvement were the tools. Look no further than Facebook, with React Native and the no-recompile workflows where you change the UI and see it instantly on your device. This would have been game changers in making development easier, not adding Maybes (and this is coming from someone who does immutable development now). Objective-C could have been evolved into the language they wanted. It would have probably taken just as long as however long this "transition" is going to take, and it would have given everyone immediate actionable benefits instead of being a binary switch that comes along with the pain of having to ship the runtime.

Instead, we have discussions about whether Foundation is going to be rewritten in Swift. This seems like such an incredible misprioritization. Essentially creating a situation for yourself where you have to burn everything down and start from scratch, all while in the meanwhile have the head-scratching platform where the base libraries are written in a dynamic language and user land code is a strict systems language.

The last thing I'll mention is the worrying lack of "purpose" for Swift. Talk to a Rust guy, and he WILL tell you the reason to use Rust. Talk to a Haskell person and they'll do the same. The sole reason for Swift seems to be "to take over the world". It is decidedly not a very opinionated language in that regard. In the ATP interview, Lattner even said that dynamic dispatch may be added later to Swift so no one should worry about it, it seems like such a kitchen sink. (I loved the bit where he said that if they add in multiline string literals they can probably "win" the scripting space). Not a lot of passion there.

aplummer2• 9 years ago

What was the problem they were trying to solve with Swift? That square brackets were off-putting?

If you think this is the difference between programming in Objective-C and Swift, you either haven't used swift much or are very misguided.

tolmasky6• 9 years ago

Although responding to this one cherry-picked snarky statement I made is probably a mistake as its almost certainly clear from, for example, another difference I list in the immediately following sentence, I will bite and state that you probably underestimate the "Objective-C is weird" complex it suffered throughout its entire lifetime, and that that almost certainly contributed to considering writing/approving an entirely new language. Additionally, the reason to call out the square brackets is that many of the other Swift differences could have been integrated into an evolved Objective-C.

dep_b3• 9 years ago

The last thing I'll mention is the worrying lack of "purpose" for Swift. Talk to a Haskell person and they'll do the same.

Really? Real type safety and no null pointer exceptions unless you really want it are not a purpose? A compact syntax that is still as descriptive as Objective-C's syntax?

My programs are much more stable in a lot of regards since I started using Swift.

tolmasky6• 9 years ago

I do not believe stability was the problem in iOS land (from my personal user perspective). The problems with iOS apps I experience most frequently come from a lack of handling asynchronous events and state management. I can frequently get programs into weird states due to clearly not handling edge cases in the way animations finish, or things loading before something else is ready, etc. I think attacking asynchronous flow management (the way countless other languages like JavaScript and Python and C# have with async/await for example) would have really demonstrated and understanding of the key space this language was going to be initially used for. Instead, async primitives are going to be missing for at least another version of the language, and programmers will remain using very primitive synchronous tools for managing increasingly complex asynchronous states demanded from ever more animation-heavy and internet-talking apps. I believe investing in asynchronous language additions for Objective-C would have lead to much more stability from a user perspective. And they aren't even mutually exclusive, Objective-C was already moving in the direction of more type safety and could have continued down that path.

Separately, I think people that have used languages like elm or Haskell would argue that Swift does not present a particularly strong example of "real type safety". Both from a language perspective (yes certainly stricter than some languages, but not as strong as others), but also from a culture perspective. Haskell/elm people I think have a true culture of correctness in code (and arguably Rust as well from the type-for-ownership-safety perspective), which Swift does not particularly share as far as I can tell. Don't get me wrong, it is in fact "stronger" than Objective-C, but I don't think its the slam dunk go-to language for mission critical software, or guaranteed to be safe software either mind you. Again, I think an indicator of this is the fact that the creator is convinced it could rock both systems programming AND scripting. I think most other languages, if asked the big "why?", would tell you THE raison d'être for its existence. Aside for "the standard language for iOS apps" default answer, I don't get a strong sense of that from Swift, if I did, I think there would be a lot of work in "Swift is for X, we don't want to be distracted by Y right now" (I think many people want to write server code in elm, but they staunchly want to NAIL UI programming, Rust wants to NAIL systems programming with safety, etc.) With Swift its always "oh once we add this feature, then it'll be perfect for that too".

patrickg_zill• 9 years ago

"change the UI and see it instantly" - I instantly thought of HyperCard. I wonder if a HyperCard like language/ui will ever make a comeback...

slavapestov3• 9 years ago

Yeah. Nothing has really come close to offering the same experience as HyperCard in my opinion. The key feature that no subsequent environment has really been able to copy is that there's no distinction between "running" and "editing" your program; while the UI is modal, this is mostly a convenience to avoid clutter, and fundamentally, your stack is always "running", whether you're authoring, editing data or just browsing.

slavapestov3• 9 years ago

Objective-C could have been evolved into the language they wanted.

Swift is memory safe -- I'm not sure how one could evolve Objective-C into that, without breaking compatibility with the C subset.

tolmasky6• 9 years ago

I think that would be the eventual goal, Objective-C minus C. Objective-C in a lot of ways was a vehicle for AppKit/UIKit, and that experience does not necessitate the C compatibility in my opinion. Don't get me wrong, the C compatibility is nice and allows some cool features when you need them, but I think it was more useful back in the day when performance was more of a concern, and a good FFI layer would be sufficient now.

JamilD• 9 years ago

Apple could convert its entire Objective-C code base to Swift if they wanted. They certainly have the resources. The amount of liquid assets they own is staggering, of a size unprecedented in history. Nevertheless, their current corporate culture suggests they cannot or will not perform this conversion.

But why? This would be an incredible waste of time and resources, to rewrite perfectly functional and working code. Rewrite it when you need to. Bloomberg still has 25m lines of FORTRAN [0] — there's no need to rewrite code when it works fine already.

[0] https://etrading.wordpress.com/2006/06/01/25-million-lines-o...

bangonkeyboard4• 9 years ago

But why? This would be an incredible waste of time and resources, to rewrite perfectly functional and working code. Rewrite it when you need to.

The functional mDNSResponder was rewritten and replaced with discoveryd, causing networking issues for millions of users. The popular Final Cut Pro was rewritten with FCPX, shedding many of its features and most of its userbase. The powerful and flexible QuickTime application and framework were rewritten and replaced with QTX, losing almost all of their functionality in the process. syslog(1) was deprecated and replaced with log(1), a more verbose and difficult to use tool, for no discernible reason.

Throwing away working code and rewriting it, of late most often for the worse, is something of a habit at Apple.

zeveb• 9 years ago

The perfectly reliable, predictable & functional headphone jack was replaced with a less-reliable, less-predictable & hence less-functional wireless headphone connexion too. C.f. https://discussions.apple.com/thread/7795564?start=0&tstart=...

astrange• 9 years ago

syslog(1) was deprecated and replaced with log(1), a more verbose and difficult to use tool, for no discernible reason.

The new log store contains (or tries to) every old file in /var/log and every log-level flag in the system, so you can search them all in one timeline. It also improves privacy because all the %@ formats can be censored after a short time.

coldtea2• 9 years ago

* If 2 was the plan, I really wish Apple had been more forthcoming about it. The message from Lattner would have been misleading at best. If Swift is the future, why not be absolutely clear with developers about that, and let us plan accordingly*

Because it's nowhere near a short or even mid term thing? It will take a decade or more to be able to move to Swift 100%, and even then, it will came with ample warnings years ahead to port your Obj-C code over.

frankus• 9 years ago

As far as I know all of Apple's framework code is in Objective-C, and there are two big problems standing in the way of converting it to Swift: AppKit and the like still has to support 32-bit apps (and it's apparently challenging to back-port that support to Swift) and Swift doesn't yet have ABI stability. (source: the SWIFT ADOPTION AT APPLE section here: http://atp.fm/205-chris-lattner-interview-transcript/)

leonatan2• 9 years ago

There are a lot more challenges than just ABI and 32 bit. Swift is not dynamic, lacks many of the features the ObjC runtime provides - so most of Apple's frameworks cannot actually be implemented in the same way with Swift. Basic stuff like KVC, KVO, responder chain, etc. go out of the window. And many of Apple engineers are not convinced throwing these technologies out of the window for some imaginary benefit from Swift is the right direction.

dep_b3• 9 years ago

Objective-C(++) are not going anywhere. I would start a new project in one of both languages without hesitation. It works, it's stable, there's tons of software out there and last but not least it's compatible with Swift.

fauigerzigerk5• 9 years ago

He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation.

If you look at the source code of the Swift standard library, "toll free" bridging code is everywhere. It even affects the language design of both Swift and Objective-C.

Yes there are still inefficiencies, but they are small. Apple has done everything humanly possible to make this interface efficient, seamless and sustainable.

So I think the plan is very clear: Don't force people (including Apple itself) to rewrite old code. Make it possible and desirable to add new features to old Objective-C projects in Swift. Maybe let Objective-C die of old age at some point in the very distant future.

There is a ton of evidence that they are in this dual mode for the long haul.

I think the one flaw in their strategy is that people who like Swift will start to hate the antiquated object oriented design of Cocoa and some lower level OS services.

My prediction is that more and more of Cocoa will be wrapped with idiomatic Swift code that Objective-C devs will not want to adopt. At that point, there will effectively be two competing system APIs.

The pressure to make a clean break with Cocoa will grow because some un-idiomatic parts of Cocoa will be hard to wrap and people will call for a modern replacement for Cocoa long before Objective-C is gone.

So I think, most of the friction in this transition will arise on the library side, not with the languages themselves.

glhaynes• 9 years ago

I'm least clear about whether a clean break with Cocoa will be needed. Perhaps most parts of Cocoa that don't match well with Swift will just be given more natural-feeling replacements? Obviously this can be complicated by dependencies, though.

Someone• 9 years ago

That would almost certainly lead to a break with Cocoa.

Those, for Swift programmers, more natural-feeling replacements will be harder to call from Objective-C than an API designed for Objective-C would be.

The only way to make neither side unhappy about it would be to provide two 100% equivalent interfaces, one for Cocoa and one for Carbon. That is unfeasible, so there will be differences. Even if they manage to write functionally and preformance-wise identical interfaces, not shipping them at the exact same time still would make the other side feel discriminated against.

I expect the first Swift-only library to appear on iOS because, on that platform, Apple can know exactly how much new code uses which language. That makes timing the transition easier. I also expect people to write glue code to call it from Objective-C, but that will be a rear-guard action.

A few years after that, I expect Apple to drop Cocoa. Deep below Swift, all the core stuff such as strings will still use the same code, but that will be hidden behind a Swift interface. After all, this is Apple, a company that isn't afraid to drop backwards compatibility. This is what happened with Carbon and Cocoa, too (how many years did that take?)

It won't happen overnight, though. Swift first needs to gain a few features (dynamism, more reflection, a frozen ABI, to mention a few), and the tooling must mature.

I think the first feature breaking interoperability with Objective-C may be a borrow checker, as that is something they have expressed interest in.

rtpg3• 9 years ago

I think Python is a good example of how things can happen.

Python's standard library includes a lot of pretty frustrating libraries, but offers a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage.

Think about requests vs. urllib (though technically requests' backend can be replaced).

I can imagine that Apple could write Swift libraries that are more idiomatic to the language by just wrapping Cocoa stuff. I mean, React Native can exist, so why can't this?

masklinn• 9 years ago

a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage. Think about requests vs. urllib (though technically requests' backend can be replaced).

To my knowledge, requests is implemented on top of urllib3 (a third-party library from which it gets most of its advanced feature), not the stdlib's urllib or urllib2.

fauigerzigerk5• 9 years ago

I agree that wrapping can and does work in most cases. But then there are times when it doesn't work without introducing a lot of complexity and/or inefficiency or without limiting design choices.

How will the new concurrency/parallelism facilities they are planning for Swift work with libdispatch queues? Will they want to build on GCD or not? Will whatever they do work for Objective-C just as conveniently? That's an open question in my view.

For an example why wrapping cannot work efficiently in all cases look no further than Python 2 vs Python 3 strings. They are conceptually too different.

With enough "waste" of resources everything can be wrapped. I don't know how React Native works. But React.js uses a virtual DOM that effectively doubles memory usage. That's what gives them the freedom to use a completely different approach to updating the UI.

I put "waste" in quotes because sometimes paying for a more productive and simpler system with higher resource consumption is the right thing to do. But in other cases it is not.

iainmerrick4• 9 years ago

I agree with you, but just to play devil's advocate, don't forget that Apple spent a lot of time and effort on toll-free bridging between Objective-C and Java back in the day.

Java was close to a first-class citizen on OS X and could even have eventually supplanted Obj-C (despite lacking some key features). Then Apple decided they didn't like Java any more, and running Java on OS X has been increasingly painful ever since.

I don't mean Swift would be ditched, if an analogous situation arose; rather, Apple could very easily decide to axe Obj-C if they don't feel like supporting it any more. They don't care at all about sunk costs (correctly, in most cases).

Kurtz79• 9 years ago

The obvious difference is that Apple had absolutely no control on Java's evolution as a language, that is clearly not the case with Swift.

fauigerzigerk5• 9 years ago

Toll-free bridging between a runtime that uses a tracing GC and one that doesn't share that exact same tracing GC is impossible. It's just a desperate stop gap.

Of course Apple could theoretically ditch Swift or Objective-C or replace both something else. But there is zero indication of any such intention.

pjmlp7• 9 years ago

He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation.

How come?!?

That is exactly what C++/CLI for .NET, and C++/CX for UWP applications are for.

fauigerzigerk5• 9 years ago

.NET came with massive additional resource consumption, with its very own comprehensive system API and with an entirely different resource management paradigm.

Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET.

Also, C++/CLI is not the language in which most people want to write .NET software, nor is it C++. It introduces an entirely new pointer syntax just to deal with resources that don't work with RAII. Its very existence proves that there is a huge gap to bridge.

You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. That's why we have all those isolated library ecosystems for Java, JavaScript, .NET, etc.

Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently.

But they decided to ape Java and balkanize their OS APIs. Now they are busy undoing the catastrophic damage they did to Win32. It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.

jupp0r• 9 years ago

The piece is really well written and makes some good points (especially about Apples code base, the costs of rewrites, etc.)

I'm still perplexed by the argument that there are boxes like "Objective-C programmer" or "C++ programmer" and that this categorization is a good abstraction for thinking about these problems. In earnest, nobody working as a developer can expect to use the same tools in 5-10 years that they are using today, especially in fields like mobile.

It's not that hard to learn a new programming language if the paradigms are known from another language. Swift is not that different from other imperative languages that there would be a particularly bad learning curve.

jamesk_au• 9 years ago

Chris Lattner talked about some of these issues on the Accidental Tech Podcast a few weeks ago: http://atp.fm/205-chris-lattner-interview-transcript/

It was a great episode and is worth the listen for those interested.

On Swift adoption at Apple:

"The Swift team itself has specific goals they need to achieve before there can be truly, across-the-board adoption at Apple. ABI stability is the number-one thing [35:30] that prevents framework developers, for example, from adopting Swift. That's a really important thing. That's one of the reasons it's always a really high priority. Swift has been adopted by application developers and other things. The Dock is public. Swift Playgrounds app is public. The Music app in iOS is publicly known. So there are definitely some big adopters.

More broadly though, the big problem is that I think, I won't speak for everybody but many, many people doing [36:00] Objective-C development at Apple are chomping at the bit. They want to be using Swift. It's really just a matter of getting the technology problems solved and checking off the things that are holding people back. It's not about people dragging their feet and not wanting to use it."

On whether to adopt Swift now:

"I don't [1:14:30] think Objective-C is going to go away anytime soon. Apple still supports C and C++ and there's no obvious benefit of dropping Objective-C, and obviously they have a ton of Objective-C code themselves."

He also described Apple's approach to some of the strategic questions that arose early on, such as whether to just invest in making Objective-C better instead of introducing Swift, and the various trade-offs involved.

lupinglade• 9 years ago

First off, I was always a huge obj-c fan, but I can tell you from first hand development of what is most certainly the largest and most complex pure Swift source tree that Swift has many serious advantages over obj-c. I am convinced we could not have such a stable product so quickly without it. It has immensely improved productivity. It has some shortcomings still and sometimes you do miss obj-c's dynamic dispatch, but on the whole Swift is far more than an evolution. I think Apple is definitely on the right track and you will see obj-c getting deprecated within the next 5 years or so. As others have mentioned, ABI stability is the number one issue preventing Apple from rewriting frameworks in Swift.

krzat• 9 years ago

How can our apps be stable when compiler is not stable.

stupidcar• 9 years ago

This article is the best example I've ever seen of how smart people can convince themselves of anything, no matter how absurd, if they want to believe it enough.

The author likes Objective C and doesn't like Swift. That's fine. But he's let that emotional state override his rationality to the point that it totally colors and distorts his thinking.

None of his arguments hold together. They're all speculation based on supposition based on guesswork, and all under-laid by an almost desperate desire that this fantasy will come true, and that Apple will drop Swift. It's like listening to a broken-hearted man explain how his ex-lover will soon return to him. How this is a test that only make their love stronger in the end, etc.

Apple aren't going to drop Swift. It is the future of iOS and macOS development, and the sooner the author accepts that and moves on with his life, the better.

redtree• 9 years ago

The author says, " Many developers have bet their livelihood on Swift."

sounds like you took offense to that and wrote..

"It's like listening to a broken-hearted man explain how his ex-lover will soon return to him."

leonatan2• 9 years ago

Can't refute any of the article's arguments? Go ad hominem instead!

This is a reddit-style comment, not HN.

bluejekyll2• 9 years ago

I read the entire thing, and didn't get the impression you got. This arricle is pointing out two clear issues for Swift that need to be overcome. 1) that the default language to have the broadest support is obj-c; I see a lot of companies preferring to ship obj-c when they need to support a framework for both obj-c and Swift. 2) Apple needs to more fully commit to replacing code internally with Swift, by say making the decision to stop building new feature support into obj-c and only target Swift.

This is more of a project management issue. It will be interesting to see what Apple ends up doing, but I agree with the article that long term support of both is not in Apple's best interests. Though my money is on Swift...

simonh5• 9 years ago

Why are either of those problems?

1) If some developers still prefer to develop in Obj-C, good for them. Of course Obj-C still has the broadest support, Swift is still in the process of taking it's training wheels off.

2) Why should Apple want to replace any of their Obj-C code? If it's good code and works well and a lot of other code depends on it, replacing it just for the sake of it would be pointless.

Partly all this depends on what you consider to be long term. Swift is coming to 3 years old. To my mind 5 years hence is the immediate future. Long term is like 20 years plus.

i386• 9 years ago

I did receive the same impression as you when I read the article. I am not sure where the idea of pulling the plug on either language came from (that was a huge leap based on zero evidence) but given the investment by Apple themselves and their entire ecosystem for almost 20 years, objective-c is here to stay. If you're looking for where innovation is coming from - thats Swift.

We've got the same strategy on the Jenkins project. Blue Ocean is where the user experience innovation is going to be coming from now on and there will be incremental improvements in Classic. However, there is no way we could ever pull the plug on the classic UI.

kenver• 9 years ago

Totally agree with you. Further to that he is assuming that picking up Swift or Objective-C is the hard part of developing in the Apple ecosystem, when in my view it's picking up the Cocoa and Cocoa Touch APIs which are shared by either language.

nathanvanfleet• 9 years ago

Or you know, maybe a massive company somehow pushed through a project that was incredibly expensive and time consuming but had no justifications or plan.

huangc10• 9 years ago

It's in Apple's best interest to continue supporting both. Why? Let's just remove the POV of app developers and simply look inside Apple.

The article mentioned a very important point. Apple itself has not adopted Swift as fast as the developer community. This is because (I don't know this for a fact, but am quite sure), a large portion of hw/sw engineers know how to write C, C++, and Obj-C. They don't just know how to write it, I bet a lot of them are damn good at it and if not, top in the industry. Why convert? As many mentioned in the comments, it would be a huge overhaul and what about Apple's internal engineers? Would they put themselves out of a job?...Not likely.

Maybe in 20 years (if there still is an Apple...), there will mostly be Swift engineers. I just don't see them shooting themselves in the foot by removing obj-c in the near future (as in 5-10 yrs).

haidj• 9 years ago

Does Swift support Windows and Linux?

If not, Swift will be doomed to be an Apple-specific language.

chc• 9 years ago

Swift officially supports Linux, and there is unofficial Windows support (and I remember them saying they planned to support Windows officially, though I don't know if that's still a goal).

dwills• 9 years ago

The Swift support on Linux is the bare minimum required to say "Swift supports Linux". I seriously doubt that Swift will ever be any more "portable" than Objective-C. That is, Swift, like Objective-C, is portable in theory, but nobody uses it for anything except to write programs for Apple's iOS/macOS platform.

joeld42• 9 years ago

I don't see any reason that Obj-C can't stick around for a long, long time, even if Swift is the "preferred" language.

Also, rumors of first-class support for Swift as a .NET family language are very interesting and would make the language much more realistic for cross-platform work. That could even lead to Unity support which would make me sooo happy. But I'm not the typical use case for sure.

georgeecollins• 9 years ago

What I dislike about this situation is that Apple wants me to make software that only works, or works best, on their device. I want to make software that is as portable as possible. I don't want my next programming language to come from someone who wants to lock me in. This makes me uncomfortable with Swift.

toyg3• 9 years ago

Like Objective-C is a realistic choice anywhere but on OSX...

If you play with Apple, you can only ask how high you have to jump. They will certainly not help you write cross-platform code, if they can avoid it. They practice lock-in very aggressively at all levels.

valleyer• 9 years ago

Yeah, it really was sneaky of Apple to convince NeXT to write their development framework in Objective-C a decade before they acquired them.

simonh5• 9 years ago

Ok I'll grant that this is true, but it's completely irrelevant to this discussion. What platform vendor prioritises cross-platform development options over their native offering? Exactly.

The reason Apple developed Swift rather than adopting another existing language is that they needed something that was a compatible and interoperable as possible with Obj-C. No other existing language had that to anywhere near the level Swift does. So really existing languages weren't a viable option given that goal.

Meanwhile Apple doesn't aggressively try to prevent cross platform development offerings from working fine on their platform. You can write Apps for iOS in pretty much any language you choose, even C#. Sure you lose some platform specific features, but that's due to the nature of cross platform lowest common denominator dynamics, not because Apple has 'aggressively' tried to block anything.

Finally, the fact that Swift was developed from scratch specifically in order to be as compatible with Obj-C argues strong against the premise of the article. If they'd adopted e.g. Dart or Go or something the article might make some sense, but Swift's Obj-C underpinnings are as clear a statement as Apple could possibly make that they're planning on supporting their existing Obj-C code base for the long haul.

delinka• 9 years ago

This author has also forgotten about the annotations that Apple has provided to make interoperability between Swift and Objective-C quite a bit easier. See "Swift API Design Guidelines" from WWDC 2016.

Moving on ... "If Apple had to deprecate one of the two languages today, which would they deprecate?" Why is that even a question? I don't understand the motivation here. What if Apple had to decide between mobile hardware and desktop hardware? I guess they'd drop everything that wasn't the biggest revenue generator...

simonh5• 9 years ago

Well exactly. Apple is opening a lot of stores in China with employees all speaking Chinese. Were all told 'China is the future'. Suppose Apple decided to standardise on one language for all their store. What would it be, English or Chinese? Equally daft.

If we take this perfectly sensible option, for which there is no obstacle to Apple pursuing it and which is Apple's stated intent off the table, which of these remaining bone headed options do you think Apple will choose? Er, who cares?

solidsnack9000• 9 years ago

The application development environment for C was not Cocoa but rather Carbon, and Carbon has been largely deprecated.

This might be the template for the transition from Objective-C to Swift. I would be interested in the author's thoughts on that -- how is it similar or different? One could see a situation where Objective-C is still there, like C, just not of interest to most app developers.

cxromos• 9 years ago

Eventually most of the open source libraries will be Swift based, therein lies the answer, for the developers and for Apple. Apple doesn't need to drop Objective-C, the community will. I work with both, and like them both, although Swift is far better language.

kirb• 9 years ago

This is a bad argument. Just because there’s a lot of chatter about Swift, doesn’t mean there’s more Swift code than ObjC out there. Of the 31 apps I have installed on my jailbroken phone, 9 contain libswift libraries. Of course, that doesn’t even mean the entire apps are written in Swift; most of the uses I see are for app extensions probably because they’re a more recent addition. Worse on my Mac – 7 out of 94 non-Apple apps installed.

You don’t throw away good code just because “eh, I like Swift better”. Couldn’t imagine having to justify rewriting good code to my employer. If it works, you keep shipping it till it breaks, then when it does break you spend a while fixing it and continue shipping it. Only when that becomes unviable do you consider rewriting it, and depending on the developer/project situation that may very well be in Swift.

Microsoft fell into the trap of rewriting good code with the failed Windows Longhorn project – for what was meant to be a minor release, they burned a heap of time rewriting large portions of Explorer (taskbar, start menu, folder windows) in C#. Explorer in all beta releases since the rewrite began were very unstable. They scrapped it and kept the existing C++ codebase. Fast forward now, Explorer still runs great in Windows 10 with the same C++ code, right? See also the Joel on Software article everyone usually links when this topic comes up: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Music, Calculator, and a minor part of the new Messages app were rewritten in Swift in iOS 10. Dock was supposedly rewritten in Swift in macOS Sierra, ditto Notification Center. Plenty of Touch Bar code is Swift. I think the fact that they’ve started to use Swift with new non-framework code is pretty important. But I’m certain there will still be ObjC in service for way longer than Apple removes its last line of it from the codebase. It can’t just be phased out like Rosetta or Carbon, especially when 3rd party apps are what keep iPhone sales up.

Whither Swift?

Related Stories