Thoughts on Swift and Objective-C (2022)

could not agree more with the author here.<p>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&#x27;t see it suited at all to the average app with less than 100kloc though.<p>points from the article:<p>&gt; […] but I personally think it&#x27;s harder to master Swift than to master Objective-C<p>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&#x27;t even have in simpler languages. <i>some</i> 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 (&lt;50kloc) and are better suited by simpler languages with high productivity.<p>(and you can always drop down to C if you see performance issues with Obj-C...)<p>&gt; I don&#x27;t see how I&#x27;m sacrificing safety by continuing to write Objective-C.<p>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.<p>our flagship app is still written in Objective-C and i see nothing to gain by switching to Swift.<p>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

I&#x27;m with the author. Also,<p>&gt; <i>Header files. Wait, what?!? Yes, I prefer having header files to not having header files.</i><p>I couldn&#x27;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&#x27;re generally much more dependent on Apple&#x27;s shitty incomplete documentation.

A devastating conclusion in the last sentence:<p>&gt; 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.

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.<p>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.<p>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.<p>I agree stability and compile times were an issue, but I think they’re getting to a fairly good place now.<p>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).

I&#x27;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&#x27;s nothing else I&#x27;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 <i>perfect</i> middle ground between manual maloc and a traditional mark&#x2F;sweep GC. The power and ergnomics of that language were probably almost single handedly responsible for the early success of the App Store.

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.

&gt; Header files. Wait, what?!? Yes, I prefer having header files to not having header files.<p>&gt; Verbosity. Wait, what?!? Yes, I prefer the verbosity of Objective-C method names.<p>I agree with a lot of what the author wrote, but this… this I cannot stand behind.

I largely agree with this. I&#x27;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&#x27;ve just never met a language with a larger surface area than Swift.<p>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.

Quoting:<p>&quot;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&#x27;re complaining about maintaining an API, which is not a good look, to be honest.&quot;<p>totally agree. I wanna see in one place the &quot;API&quot; namely:<p>- the name scope it&#x27;s in<p>- the return, in, and out params<p>- description with explicit language on what&#x27;s defined and undefined behavior in calling it<p>- in isolation without being blown away by the impl on first glance that&#x27;s interspersed with the API.<p>Quoting further:<p>&quot;If there&#x27;s no distinction between your interface and your implementation, then your architecture is likely not great.&quot;&quot;<p>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&#x27;m not interested in reading somebody&#x27;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&#x2F;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&#x2F;await in Swift is a huge leap forward, especially from the ever-rightward-moving blocks-within-blocks in Objective-C.<p>If you don&#x27;t see how you&#x27;re &quot;sacrificing safety by continuing to write Objective-C&quot;, 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.<p>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++&#x2F;OpenGL).<p>I spent a few hours looking at Swift and it seems simply worse in all dimensions that I am interested in.<p>Apple would benefit greatly by adopting standards instead of trying to push their own. Darwin was built on Unix&#x2F;BSD foundations, it was a good move.

Yes, Objective-C deserves more love.<p>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&#x27;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.

Criss Latner made a huge disservice to the iOS community. While the intentions were good (build a modern language), it completely failed to the &#x27;it is easy and fun to use&#x27;.<p>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 &#x27;Scala&#x27;, a language that is just over-complicated for no reason at all.<p>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&#x2F;array manipulation, you would have had a much better language that what Swift has become.<p>As in many cases, the sequel is often worse than the original.<p>If I was in charge of the Swift development, i&#x27;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.

(2022)

This may need an update. The compiler is more stable today, for example, even though the language continues to evolve rapidly.