Swift certainly is a nice, impressive, modern language but it seems like Apple created a language they want themselves to rewrite OS frameworks with millions of lines of code. i could also see it as a rival to C++ in Game (engine) creation. i don't see it suited at all to the average app with less than 100kloc though.
points from the article:
> […] but I personally think it's harder to master Swift than to master Objective-C
absolutely. one can learn Objective-C in an afternoon if you know C - and master it in a few weeks. mastering Swift (like C++) could take decades.
why is that the case? because it is a very complex language with many advanced features (like C++) that solve problems that you don't even have in simpler languages. some of these features also solve problems for extremely complex projects or some performance requirements but the simple truth is that most apps on both mobile and desktop are relatively simple (<50kloc) and are better suited by simpler languages with high productivity.
(and you can always drop down to C if you see performance issues with Obj-C...)
> I don't see how I'm sacrificing safety by continuing to write Objective-C.
me neither. yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here - with a high price.
our flagship app is still written in Objective-C and i see nothing to gain by switching to Swift.
p.s. shameless plug, if you live and breathe Objective-C and want to work on a cool app (MacUpdater), drop me a line at jobs@corecode.io
> me neither. yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here - with a high price.
Citation seriously needed. Like just look at the entire history of memory safety related bugs and security issues.
have you ever had a look at any Objective-C codebase?
Objective-C is a high-level language and there usually is no memory manipulation. just because the possibility exists (via dropping down to the C part of it) doesn't mean it is done. ARC does memory management for you and there hasn't been the need for manual memory management in ages. even that was pretty hassle-free.
i can count the memory bugs i have seen our Objective-C projects in the past 10 years on one hand.
> entire history of memory safety related bugs and security issues
A citation is needed for the number of iOS projects that have more than a minuscule amount of code at the application level that risks memory unsafety.¹ The value proposition becomes stronger for the system frameworks that the app consumes, of course. (Although even the stdlib dips more than once into memory-unsafe Swift for performance.) But this brings us to another of the points from the article: is it really best to use one language for both use cases?
¹And additionally for whether those project would eliminate such code if rewritten in Swift.
> absolutely. one can learn Objective-C in an afternoon if you know C
...See, that last part you toss off as if it's practically a given, but it's really not.
Sure, when I was (and probably you were) first going to CS classes, being taught C was pretty much the standard thing. But that's much less true now, from all I've seen.
And why not? 20 years ago, it was much, much more likely that if you were a programmer, you were going to be working with C code at some point. Nowadays, you can easily have full mastery in a dozen different languages, all of which are in widespread demand, and never touch C. (Or C++. Or C#. Or Objective-C.)
Personally, where I am at this point in my career? If I wanted to write a small utility program that runs natively on macOS, I'd pick Swift over C 10 times out of 10. I'm roughly equally familiar with both of them (which is "moderately"), and I know enough about the pitfalls of C to know that I don't want to deal with them, and Swift handles almost all of the frustration of memory management for me.
Plus, there's a single authoritative source for information about Swift for when I run into something I'm unfamiliar with, forgot, or got confused about. If I try the same in C there's literally thousands of different sources, of varying authority, across every major and minor platform that's ever existed, and every version of C. It's fantastic that there's all that information out there, don't get me wrong, but when I'm trying to write a small utility to solve a specific problem, every time I run into something that's talking about the wrong C version, or the wrong platform, or just plain has bad information, is going to add one more bit of frustration that's likely to make me quit trying.
Yes, Apple's documentation is imperfect—but I always know that it is there, acting as a single authority for the language.
Fortunately, Apple has a decade or more of crash telemetry that tells them exactly how often users hit such problems running code from “seasoned programmers”!
> I think the reason why the "pro Obj C" lobby strikes such a nerve is that their personal preference is holding back the whole team.
You appear to be complaining about some anecdotal experience of yours. Exactly how many different teams have you been on where this happened?
It should be noted that the article author has been a lone developer since 2016 and hasn't belonged to or "held back" any teams during that time.
In any case, rewriting existing, working code is usually a bad idea regardless of the language, so if that's what you were aiming for on your team, it wouldn't be surprising to meet resistance on that.
> Objective C actively makes it harder to do such best practices
It is true though! Consider a simple example where you have two classes, with one depending on the other. As a best practice, I'd like to inject one class into the other's constructor, so I could do some unit testing.
Here is the Swift code:
class Dependency1 {
}
class Object1 {
private let dependency: Dependency1
init(dependency: Dependency1 = Dependency1()) {
self.dependency = dependency
}
}
Thats 9 lines of code in Swift and 31 lines of code in Objective C. If I have to type 3 times more code every time I want to break up big class into a few smaller ones, I am going to be much less likely to do it.
In other words, the sheer verbosity of Objective C will make even the most disciplined developer start cutting corners to reduce effort, which ultimately leads to codebases which are messier, harder to test and less flexible.
And finally, looking at the example above, is it really true that Objective C is easier to learn and understand than Swift? The code forces you to learn:
* What is an NSObject?
* How to create a private category on an class
* What does "alloc init" do, and why is it different than "new"?
* What is the difference between `self.dependency` and `_dependency`, and why does one let me change a "readonly" property?
* Why would `super init` return nil, and what does that mean?
For sure Swift also has its share of nuance, but I feel like the Objective C nuance is just baggage, while the Swift nuance opens the door to a richer feature set.
That ObjC code doesn't make sense, if you look at the logic of it. You said in a previous edit (you keep editing your comments endlessly) that you generated it with ChatGPT. Not to mention, your Swift code doesn't even compile.
Maybe try actually writing code in Xcode.
And maybe write your comments in a text editor and finish them before you post...
> Curious, which part of that Objective C code doesn't make sense to you?
For one thing, the initWithDependency: method ignores its argument! (Also it's unclear why it needs 2 blank lines just to jack up your line of code count.)
Does the class even need to declare -init? That's 6 more lines of code added for no apparent reason.
In general, everyone acknowledges that Swift is more terse and Objective-C is more verbose, so if your main complaint is just the number of lines of code, that's not particularly interesting.
> For one thing, the initWithDependency: method ignores its argument!
Yes good, callout, I edited the code to fix this mistake
> Does the class even need to declare -init?
You are basically making my point. Its totally normal engineer's reaction to look to erase this boilerplate by removing the dependency injection, or using a singleton. Overtime, those decisions make the codebase worse. In Swift, you simply don't have to make this tradeoff.
> if your main complaint is just the number of lines of code, that's not particularly interesting
Verbosity alone is a major problem - why would it be a good idea to use a language which takes more time to read and write to accomplish your goal? It's a disadvantage.
Another issue is a lack of expressiveness and a dumber type system. Stuff like union types and optionals all allow you to express your system in a more airtight way. The lack of these features leads to, you guessed it, more boilerplate in ObjC.
Ultimately, noone is arguing that you should rewrite your existing ObjC in Swift - if your code exists and works, leave it alone. But the article is arguing that Objective C is a "better" language for writing iOS apps, which doesn't make any sense for all the reasons above.
> You are basically making my point. Its totally normal engineer's reaction to look to erase this boilerplate by removing the dependency injection, or using a singleton.
You made me look at two classes, totally out of context, that didn't even work with the first code presented. And I have absolutely no clue how they would be used, so I can't properly evaluate them.
The boilerplate is fine as far as I'm concerned; you were the one who was obsessed with the number of lines of code, and it seemed to me you were exaggerating them for no apparent reason, so that's why I was looking to remove some.
> why would it be a good idea to use a language which takes more time to read
I don't agree with that. A more verbose language can be easier to read.
> and write
It's premature optimization. Personally, I don't spend the majority of my time typing in code. I spend a lot of time thinking, designing, running, testing, debugging, etc. The time spent typing in the code is not a big worry for me. If Swift is faster to type, but the compiler is a lot slower, and the damn debugger doesn't even work, that doesn't seem like a good tradeoff to me.
> But the article is arguing that Objective C is a "better" language for writing iOS apps
I was actually arguing that Objective-C is a better language for writing UIKit iOS apps, which is a more specific claim, given that the underlying frameworks are themselves Objective-C, for the reasons explained in the blog post.
> I think the reason why the "pro Obj C" lobby strikes such a nerve is that their personal preference is holding back the whole team.
What's holding back the team is Apple.
Apple could open-source Swift and Xcode (both really need the help) and port the relevant bits to Android and Windows. They could release Metal to the world or throw in with Vulkan.
The fact that they haven't tells you that all Apple is interested in is keeping you captive.
Many parts of the Swift toolchain are already open source [1], there is a Windows and even a WASM port [2].
The caveats are:
- Xcode indeed isn’t, but you can use sourcekit-lsp for Swift development with some compromises.
The experience has really improved the last few months thanks to the Swift Server Work Group [3].
- Apple platforms have their own Foundation implementation and the open-source one is incomplete.
> Header files. Wait, what?!? Yes, I prefer having header files to not having header files.
I couldn't agree more. Header files are searchable, by arbitrary independent tools, and support discoverability. Generated Swift interface docs force you into Xcode, yield zero discoverability and can be searched only after you generate them and have them open in the editor. You're generally much more dependent on Apple's shitty incomplete documentation.
Is this a tooling issue? For example, I absolutely love the rustdoc tool `cargo doc` which generates nice searchable docs. I find this has more value to me than header files. Does swift have something similar, or is it only Xcode that gives you a doc feature?
And to expand on this, I get docs for all the dependencies of the project generated at the same time, and can optionally generate docs for non-public interfaces.
Nice obeservation, cargo doc is Rust's header files. When developing a library in Rust, I usually use cargo doc to "see the crate from the user's perspective".
That explains why so many docs for Rust packages are just a spew of types and traits.
From the user perspective I really dislike just being thrown a bunch of types with minimal to no actual docs. It seems more common with Cstyle headers to add docs.
If it looks like that, then I think those developers did not take a look using the cargo doc perspective. I definitely do that to add docs in the right places. And warn(missing_docs) is good to use too (warn on any public item).
> I feel that the crap store lockdown and race to the bottom have drained much of the enthusiasm out of our industry, and left us in a state where we think the programming language is the most exciting thing in the world.
The post compares it with the enthusiasm about the iPhone as a platform in 2007.
A lot of the long hanging fruit has already been done since then, so it takes more effort to get kicks out of shipping an app that people use. Learning a new tool like a programming language is an easier way to get such kicks.
I largely share that conclusion. Apple's iron grip has squeezed most of the fun out of their platforms, for me at least. The phrase “crap store lockdown” is an ingenious find and hits the nail on the head.
I agree with the author on choosing the right tool for the job, 100%. But I think that obj c is less and less the right tool. Just my 2 cents.
With respect to the point about header files. Of course you can have an API in swift either by having your class conform to a protocol or using visibility modifiers.
Also the point about verbosity, the benefit is often in reading others code and being able to quickly grok it. Swift also has a number of functional methods (map, reduce, etc) that are really nice for this.
I agree stability and compile times were an issue, but I think they’re getting to a fairly good place now.
And lastly I like the additional protections swift offers when working in a large team with varied skill levels. Just because the author has been able to avoid crashes, it does not mean this will be the case for a junior dev on the team (and code reviews can miss some things).
> Swift also has a number of functional methods (map, reduce, etc) that are really nice for this.
writing functional extensions for base classes in ObjC takes like an hour and every seasoned ObjC programmer has those extensions in his toolkit/library anyway. so that doesn't sound like a killer argument for switching to Swift.
The problem with map/reduce/etc in ObjC is twofold:
- Objective-C doesn't support generic value types for function arguments
- Objective-C can't optimize away method calls and therefore value boxing
What that means in practice is that you can't write a generic version of map/reduce/etc without it being very slow even for things that should be very fast. If you want one that works efficiently for value types like integers, you must write a specialized version for each type.
(I have written and sometimes use for convenience ObjC map/reduce/etc implementations.)
This is unrealistic. Tons of "seasoned" ObjC programmers will take one or two orders of magnitude longer than an hour to write home-grown replacements for all the functional methods, and they frequently turn out limited in some way, or at least less performant.
Maybe you're implicitly arguing that those developers are irrelevant to the conversation of Swift vs ObjC, and I would disagree there too. Languages need to strike a balance between catering only to the most highly experienced and specialized developers, and hobbling themselves to be "idiot proof".
I've used countless languages professionally, but I only ever fell in love with Objective-C. Protocol Oriented Programming is sorely underutilized outside of it. And the subtle difference between message passing and method calling is an abstraction that totally changes how you think about building things in an object oriented environment for the better. There's nothing else I've found which has that amount of low level power (with the ability to drop into C at any time), while still having a world class, well documented OOP framework (NS) on top of it. And ARC is the perfect middle ground between manual maloc and a traditional mark/sweep GC. The power and ergnomics of that language were probably almost single handedly responsible for the early success of the App Store.
Agreed - though I prefer Swift, I loved my time with ObjC, and I can't say I even like any other language I've ever touched. There's no close 3rd place for me. And the gap widens when you take the ecosystems/frameworks into account.
One thing I never really grokked though is the practical implications of message-passing vs method-calling. I read plenty of material about how it's implemented, but never found a scenario where I thought about it. Everything was always still just method-calling to my forebrain. Do you have any resource that talks about the practical implications?
I haven’t used Swift enough to comment on the contrast, and I do sometimes wish for a bit more type inference in Objective-C (rather than having to keep clarifying that yes, -stringByReplacingOccurencesOfString:withString: is going to return [… drumroll …] a string). But I must admit that I too have a huge soft spot for Objective-C. Including those beautifully unambiguous selector names.
There are new programmers coming of age every day, so the proportion that even thinks about Objective-C at all (never mind advocates it) is going down down down.
Honestly, that seems doubtful. The C language has intense dominance and Objective-C puts a nice, minimal, object oriented wrapper on all of that while all the C developer tools remain effective.
> The only modern macOS framework that is still written in Objective-C is Metal
This is inaccurate. Extremely inaccurate, nearly 100% mistaken. Almost every macOS framework is still written in Objective-C, including AppKit and Foundation.
Not at all, I explicily mentioned "only modern" on purpose.
Most Objective-C stuff that is around, with exception of Metal, traces back to OS X and iOS early days, and carry with them the weight of maintenaince, and development costs of a rewrite.
Metal is the only post-Swift framework that was written in Objective-C.
> Metal is the only post-Swift framework that was written in Objective-C.
Still untrue. Again, see the referenced blog posts.
Indeed, aside from SwiftUI, which is still half-baked on macOS, I'm not aware of many Swift frameworks in the OS. After all, the frameworks still need to provide API to Objective-C apps, including Apple's own apps, not to mention 3rd party apps. The requirements to ship a Swift framework in the system, such as ABI stability and others, are a relatively recent addition to the language: https://www.swift.org/blog/abi-stability-and-more/
None of the related post mentions any other Objective-C framework written from scratch, XCode File=>New without dependencies on older technology, after Swift came to be.
> The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift, SwiftUI, and Xcode Previews.
>
> Tight integration in a development platform like this requires that all three pieces be designed and evolved together, both driving and driven by one another. Swift result builders were inspired by SwiftUI's compositional structure. SwiftUI's declarative views were enabled by Swift value types. And Xcode Previews was specifically designed for, and enabled by, both. Now, the result is the best development platform that we have ever built. And this year, Swift, SwiftUI, and Xcode all have fantastic updates that take this vision further, and make it even easier for you to build great apps for all of our platforms. And it all starts with Swift. Now Ben from the Swift team is gonna tell you all about what's next.
SwiftUI, Swift bindinds for Metal, the new macOS Dock, the new daemon launcher, the new documentation system, package infrastructure, the new background services, the server side frameworks, the new photos picker, playgrounds are all written in Swift.
Other than Metal, all the Objective-C code predates Swift, and is ongoing maintenaince work nothing else, that is why I am quoting that to you, Apple's own words at WWDC to make it clear for anyone that still isn't getting it, Objective-C is DONE, time to move on.
Objective-C is the VB 6, Win32, Forms, WPF of Apple's world, it isn't going away, it isn't getting updated either other than maintenance and security fixes.
> the new macOS Dock, the new daemon launcher, the new documentation system, package infrastructure, the new background services, the server side frameworks, the new photos picker, playgrounds are all written in Swift.
The Dock is an app, not a framework. The things you listed are not frameworks, aside from whatever you mean by "the server side frameworks", which being server-side would by definition not be in macOS.
"Framework" has a very specific meaning in the OS: a .framework bundle, providing a linkable executable and typically an API, with the system frameworks residing in /System/Library/Frameworks.
"Other than Metal, all the Objective-C code predates Swift, and is ongoing maintenaince work nothing else"
This is still false, you have nothing but anecdotal, cherry-picked evidence, the numbers from the blog posts I cited suggest otherwise, you appear to be quite ignorant, and I'm tired of arguing with you, so I'm indeed DONE here.
> We hope this is just the start of discussions about this exciting new project. In future posts, we want to discuss plans for the existing swift-corelibs-foundation project and figure out how we transition the ecosystem to the new unified implementation.
Also a lot of the verbosity of the Obj-C methods names in Apple’s frameworks carried straight over to Swift. And you can make your own method names as verbose as you want. So I am not really sure what the complaint actually is.
Not having header files has literally never been a problem for me. Xcode can auto generate a sort of pseudo-header definition file if you are pulling in someone else’s frameworks. And day to day app work mostly consist of writing code for the app, not writing a library or framework for others to use. You still have public and private methods. I guess not having separate header files makes it slightly easier to expose things you should probably keep private, but that really is just a thing that is solved by “just don’t do that.” Finally, a lot of times people will just have a private extension to a class that contains all the private methods anyway. So you basically just have everything combined in the same .swift file, where you have a “logical” header rather than a separate header file.
why would a verbose name (like stringByReplacingOccurrencesOfString:withString:) not be better than something short but completely meaningless and obscure like /strtol/? we have autocompletion these days...
> Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete).
can you elaborate? the verbosity is good while reading, because you know what it does even if you don't know the API in your sleep. how could there be a verbosity cost while reading?
Verbosity is in-place documentation. I personally like it.
I have personal projects where, as the original creator and maintainer of the codebase, I should easily be able to understand what happens. But time and time again I find my current self being grateful to my former self for 'documenting' methods calls and variables by being verbose.
[edit: removed typo]
I largely agree with this. I've been coding professionally a pretty long time and have worked with a wide variety of languages (including quite a lot of Objective C back in the day), and I've just never met a language with a larger surface area than Swift.
I can work with Swift and be productive with it, but at the same time, I feel like I still encounter new patterns, gotchas, property wrappers, language quirks, language changes, type-system oddities, etc, almost every day, and I have a hard time keeping track of it all.
"Header files.
Wait, what?!? Yes, I prefer having header files to not having header files. A lot of programmers complain about maintaining header files, but header files represent your API, so you're complaining about maintaining an API, which is not a good look, to be honest."
totally agree. I wanna see in one place the "API" namely:
- the name scope it's in
- the return, in, and out params
- description with explicit language on what's defined and undefined behavior in calling it
- in isolation without being blown away by the impl on first glance that's interspersed with the API.
Quoting further:
"If there's no distinction between your interface and your implementation, then your architecture is likely not great.""
Not sure about architecture, but good lord, programmers have to remember code is written to solve use cases AND be understandable by others. I want to read something written to be understood. I'm not interested in reading somebody's diary moonlighting as commercial code.
As someone who has spent their professional life writing Objective-C (first pre-ARC, then ARC), now mostly Swift, the biggest benefit of Swift over Obj-C is how much more difficult/explicit it is to write unsafe code. You can totally shoot yourself in the foot with Objective-C. Swift is much safer. That in itself has undoubtedly led to an industry-wide improvement in code. Not to mention, obviously, that async/await in Swift is a huge leap forward, especially from the ever-rightward-moving blocks-within-blocks in Objective-C.
If you don't see how you're "sacrificing safety by continuing to write Objective-C", then you are missing something, IMO.
The engineering culture at Apple is quite peculiar, and in my opinion, a bad fit for creating standards, especially programming languages.
I hated Objective-C when I had to deal with it, basically writing a wrapper around it for cross-platform compatibility of the framework I was using at the time (C++/OpenGL).
I spent a few hours looking at Swift and it seems simply worse in all dimensions that I am interested in.
Apple would benefit greatly by adopting standards instead of trying to push their own. Darwin was built on Unix/BSD foundations, it was a good move.
I find it perplexing that the language never took off for open source Unix development. For example, I tried GTK 4 not that long ago and was surprised how similar its design was with Cocoa (it even had auto-layout!). Unfortunately, the GObject system felt like a poor man's Objective-C. I understand the appeal of C over C++, but Objective-C would have been a perfect fit here. Feels like a missed opportunity.
Mostly because GNUStep was always WIP, and GCC implementation never fully covered all NeXTSTEP and later OS X capabilities, specially after Objective-C 2.0 came to be.
Criss Latner made a huge disservice to the iOS community. While the intentions were good (build a modern language), it completely failed to the 'it is easy and fun to use'.
Had a golden chance to build a next generation language that could have been the next modern Java or Python, used everywhere, but instead we got the iOS version of 'Scala', a language that is just over-complicated for no reason at all.
If you took the Objective-C, modernized the syntax (which is the biggest turn off for many), and add few of the modern utilities that is missing in string/array manipulation, you would have had a much better language that what Swift has become.
As in many cases, the sequel is often worse than the original.
If I was in charge of the Swift development, i'd consider a complete re-thinking of the language, and just remove the unnecessary complexity that is in every step of the language that make it not fun and not productive to use.
What would you expect from a developer who only used C++ for most of their career. Maybe the entire Swift compiler team was solving the problems they had with C++
Swift certainly is a nice, impressive, modern language but it seems like Apple created a language they want themselves to rewrite OS frameworks with millions of lines of code. i could also see it as a rival to C++ in Game (engine) creation. i don't see it suited at all to the average app with less than 100kloc though.
points from the article:
> […] but I personally think it's harder to master Swift than to master Objective-C
absolutely. one can learn Objective-C in an afternoon if you know C - and master it in a few weeks. mastering Swift (like C++) could take decades. why is that the case? because it is a very complex language with many advanced features (like C++) that solve problems that you don't even have in simpler languages. some of these features also solve problems for extremely complex projects or some performance requirements but the simple truth is that most apps on both mobile and desktop are relatively simple (<50kloc) and are better suited by simpler languages with high productivity.
(and you can always drop down to C if you see performance issues with Obj-C...)
> I don't see how I'm sacrificing safety by continuing to write Objective-C.
me neither. yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here - with a high price.
our flagship app is still written in Objective-C and i see nothing to gain by switching to Swift.
p.s. shameless plug, if you live and breathe Objective-C and want to work on a cool app (MacUpdater), drop me a line at jobs@corecode.io