A well jelled team, with senior engineers can be much more productive with Objective C.
But for beginners, swift looks less intimidating due to its syntax familiarity. The language pitfalls become apparent as you dive into it.
Perhaps that’s why swift in ML and other areas failed. People don’t like the language. In iOS you are forced to use it.
I hope the swift team does some hard thinking and start slashing features and make it Simpler.
What we got is something more complex than even Java. This is the same reason that Scala didn't take off (even though some people like it).
This just isn't true. Given equal familiarity, Swift will be vastly more productive at any skill level. Of course you can always tunnel deeper into more sophisticated solutions using Swift, since Obj-C lacks most of its capabilities, but that's hardly an equal comparison.
I have a lot of experience in both languages, and TBH it's just not true. I'm less productive in swift in many ways, mostly because of it's slow build and indexing times. It's infuriating.
You are still coding against the same UIKit and other apple libraries in both. SwiftUI has a chance to make it better, but it's incomplete and has bugs/gotchas that make it not as productive as UIKit when you run into that, which is pretty easy. But in an imaginary world where we got ObjectiveSwift instead, SwiftUI could have existed there and given the same productivity benefits.
Binary sizes ballooned because of the language. Binaries were significantly smaller in equivalent Obj-C programs than the swift ones, even when the standard swift library was finally baked into the OS.
It would be impossible to evolve Obj-C to add most of Swift's capabilities unless you drop binary and source back compatibility. At that point it's just another new language and you've lost the things you say made Obj-C simpler.
I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically developer productivity is bound by thinking of an appropriate solution to a problem and expressing that solution in a language. Given how much easier that expression is in Swift, especially if you spend a bit of time optimizing the language to your problem, the build time becomes rather incidental. Add to that Swift's ability to catch far more issues at build time and its language features and the Obj-C solution falls further and further behind. Even if your Obj-C solution builds faster it will likely be an inferior solution anyway.
I see you haven't worked in a swift code base that is more than a few engineers. Work in a project that is 20-80+ engineers and you slam into these issues very quickly. Last time I checked the inflection point starts around 100k lines of code.
Also 'thinking' of solutions often involves writing something and then trying it out in a build-edit-run cycle, and then integrating your thing into a larger app context, which also involves many build-edit-run cycles. Most people do not think of their solution in whole cloth in their head other than in a broad strokes manner and then start writing code. This means indexing and building matters greatly for actual productivity.
Indexing issues means your ide is not auto completing, click to definition doesn't work, and in the past, even syntax highlighting failed. Also when you have some half formed code, a lot of indexing functions start breaking in an annoying way, while I don't really recall this behavior in Objective-C code bases.
In practice I've found swift being 'able to catch issues more' is mostly strict nullability, better array / dictionary strictness and enums, which would actually be relatively simple to implement in an extended ObjectiveSwift. Strict generics would be more work, but you can add it to the language also as a version update. Dart showed how it's possible to add big changes like strict nullability to a language with their dart v1 -> v2 update. Objective-C could have gone down that path instead.
> Last time I checked the inflection point starts around 100k lines of code.
if your using swiftui + generics for your view models, depending on what your doing, be prepared to hit that limit at around 2000 lines, and then your app wont even compile...
Unless we have well researched data, it is just a opinion.
My opinion and experience is definitely different than yours, and I have seen that objective c leads to more productive teams if they are mostly senior people. (With a couple of libraries (just some helper categories on strings and arrays) and some sparse macros objective c becomes a very productive language. But it takes a senior team to do that well).
Meanwhile with swift you feel you have to please the compiler at every! step? And it really doesn’t lead to much safer language anyway (swift bugs are different) and you feel you have to fight the compiler in every way.
Objective c is less fuzzy, and while it lets you do dumb/fast things (especially important during prototyping) it gives you a clear ‘you are doing x wrong’ warning which gives you the best of both worlds
Fast prototyping when you need it, and safety when you need to ship (you can have a production build fail on just warnings)
Nullability isn't that big of an issue in practice. Every call in objective-c is equivalent to a variable?.thing call anyway, and in swift codebases most things become non-null fairly quick. It's probably the top feature of swift for me, which is ironic because it's relatively cheap (in compile time) to implement compared to many other things swift has.
And if you're doing nullability, you might as well add ADT enums, since that is usually how it's implemented.
These are the same stupid points people brought up when Swift was first released. I used to believe it too. Then I actually used the language and integrated it into existing codebases. The jump in quality and performance was notable and immediate. What you state here about both languages doesn't match any experience I've ever had or seen from other teams.
I have a rather complex application that is a mix of C++, ObjC and Swift. I humbly consider myself an expert in all three languages and worked on AppKit while employed at Apple. Perhaps Swift is slightly more accessible when you begin development. If you aren't familiar with ObjC syntax, Swift my look more familiar at first, but syntax quickly becomes familiar.
When you mention more sophisticated solutions using Swift, I am not sure what capabilities Obj-C lacks that would hamper it. Are you referring to the functional parts of the Swift language? Combine?
Lacking capabilities also means fewer decisions. If you want to model something in ObjC, it's a class, full stop. In Swift you have the choice between classes and structs. There are generally more degrees of freedom.
Just observe how much the iOS community talks about Swift patterns. Objective-C was more like Go, in that you accept your fate, keep things simple, and write some boilerplate code here and there. It seems to drive some people crazy, but it also avoids C++-style meta discussions about language features.
Whether this trade-off increases or decreases productivity depends on your team.
You’re correct, the post isn’t completely true- Swift syntax isn’t more familiar to beginners than ObjC is, because in their pursuit to take out the C, they also replaced several of the long-standing C patterns such as lack of prefix/postfix operators, standard for loops, parameter name and type ordering.
But for beginners, swift looks less intimidating due to its syntax familiarity. The language pitfalls become apparent as you dive into it.
Perhaps that’s why swift in ML and other areas failed. People don’t like the language. In iOS you are forced to use it.
I hope the swift team does some hard thinking and start slashing features and make it Simpler. What we got is something more complex than even Java. This is the same reason that Scala didn't take off (even though some people like it).