I’ve been working with Objective-C since NeXTSTEP 3.2 and only really dabbling in Swift (my most recent ObjC gig was at Facebook, who were unlikely to port any time soon, and since then I’ve been working on Qt and node/react apps where both ObjC and Swift are irrelevant). It’s important to understand that this context biases my views heavily: at the time Swift came out I did not have the “ugh, square brackets” revulsion that had put people off learning ObjC.

I see ObjC as a single, neat idea (Smalltalk message-passing) coupled to a problematic but very well-understood execution context (C) that’s been maturing for decades.

I see Swift as a new, complex language with iffy tooling and Apple’s recent philosophy that we are going to make changes when we want and you are going to do a lot of busy-work to keep up with them because it’s good for you. But one big reason I still choose ObjC when I’m building a project where it and Swift are options is that I’m likely to be making a Cocoa app, using AppKit, UIKit, Core Data, PDFKit…frameworks built on Objective-C abstractions. Swift pushes the ObjC model out to the language’s edges and makes them opt-in, which is not great for using Objective-C frameworks.

I look at things like NeXT’s WebScript, MacRuby, mocl and the dozens of other Objective-* languages and wish we’d doubled down on a language designed with acceptance of the libobjc runtime library as a core abstraction, with objc_msgSend and friends as primitives in its execution machine.

[…] Apple’s recent philosophy that we are going to make changes when we want and you are going to do a lot of busy-work to keep up with them because it’s good for you.

It sucks in the medium term, but I’d rather they change stuff around than leave an ever-growing pile of imperfect features. I mostly write C++, and I love how you can do pretty much anything in the language if you need to, but holy cow I wish there weren’t so many legacy features. Stuff like std::auto_ptr gets deprecated, but core syntax of the language just keeps growing and growing. :(

Other routes are available. For example the Android compatibility library which lets you opt-in to APIs from different levels on a wide collection of runtime versions, or the Qt3 compatibility library for Qt4. What I don’t like about Apple’s approach is that every year there’s a bunch of announcements at WWDC of changes that you have to make if you want to submit an app come September. Their “deprecation” notice is “oh LOL we turned that off, you’d better update already”.

This makes me think about Microsoft transitioning from VB6/VB.NET to C#. Even though C# is clearly the “way of the future” in the .NET world. Microsoft still publishes all of their .NET API docs and examples in both languages, and pushes almost all language and framework features to VB.NET also. I think even now, if you wanted to be a strict VB’er, you might know you’re not on the main path and you might miss out on some syntax-sugar level stuff, but you’d still be able to get everything done that you could in C#.

That seems to be a contrast between Apple trying to bump off Obj-C even though they don’t seem quite ready to yet, and Swift itself maybe not being ready yet either. You could say that, while they make a nice user experience, they’re still figuring it out as far as managing a software language and ecosystem. Or you could also say that building a new language and giving it enough hype to catch on while also not completely starving your old language is a hard problem.

I see the Apple situation with Swift as being more akin to .Net inside Microsoft (the Windows team ignored it and eventually introduced WinRT instead) or Java inside Sun (no components of Solaris were written in Java; the HotJava browser was written by the Java team). Outwardly, they’re giving the impression that this new technology is the future. Internally adoption is slow.

Yeah that’s a transition that went a similar way. The split is interesting, if along different lines from Apples - Corporations seem to love .NET for internal tools and the web, but virtually all commercial Windows desktop apps are still done in C++ using MFC or Win32 AFAIK.

VB.NET is not like VB6, except in syntax. For all intents and purposes, VB6 users were left hanging. In spite of all the effort that Microsoft made to make porting easy. Microsoft stopped all development on VB6.

This is much worse than ObjectiveC -> Swift. At least you can still use ObjectiveC, if you want. And ObjectiveC still gets supported for all IOS updates.

I never worked with VB6, and don’t know that much about the transition to VB.NET. I suppose Microsoft is big enough to have done a bunch of different language transitions in a bunch of different ways. Though I thought you could still technically build apps in VB6, it’s just deprecated and hasn’t gotten any new features in a long time.