How to Create a React Native App Using Typescript
Natam Oliveira | Nov 30, 2023
(Published in March, 5, 2015, at colincornaby.me)
On Twitter, I’ve been vocal that I don’t believe Obj-C is going away any time soon. For reference, Apple’s stance on the matter is:
“Objective-C is not going away, both Swift and Objective-C are first class citizens for doing Cocoa and Cocoa Touch development.”
It’s important to note that while there are a lot of community websites stating that Swift is the replacement for Obj-C, that has never been any sort of official position from Apple.
This “There can only be one language” phenomenon also seems entirely unique to the Apple developer community. The Windows .NET environment is up to approximately two dozen supported languages with a common API, and it’s made that community stronger, not weaker. Yet instead of taking advantage of a position where we have two languages, each with their own unique strengths, we’re asking which one should be sent to the chopping block.
But even if it’s just my opinion it’s a good thing to have two languages around, let’s review why realistically Apple probably isn’t going to stop development on either Swift or Obj-C.
It seems unnecessary to talk about why Swift will be sticking around, given that it’s the newer of the two languages. But Apple cutting a brand new language isn’t unread of, and there has been some concern that if too many developers are negative about Swift and stick with Obj-C, Apple might not give Swift the treatment some feel it deserves.
When OS X was first in development, Java was the hottest language on the market. Apple added Java as a first tier language to use with AppKit/Cocoa, and expected to see broad adoption. But developers never really adopted Java for writing Cocoa applications. Within a few versions support seemingly died out entirely. Java is a good example of Apple trying to diversify their language support, and backpedaling. (This is referring to the Cocoa/Java bridge, not the Java runtime you commonly see for pure Java apps that Oracle distributes today.)
Realistically, there are too many people at Apple that are genuinely excited about Swift for that to happen. The compiler team has done a lot of work to make Swift happen. And while with Java, developers were forced to deal with all the warts that were part of the language standard, the Swift language is still at a very flexible phase of it’s life cycle. If something is wrong with Swift, Apple can still fix it instead of scrapping it. Critical feedback isn’t going to hurt Swift, it’s going tobuild a better Swift that will be more widely adopted in the future.
I could say a lot here, but Obj-C continuing to be supported and enhanced really comes down to one simple thing: Apple has the largest code base of Obj-C in the world, and they need to keep maintaining, enhancing, and shipping it.
AppKit, UIKit, Foundation and friends simply will never be entirely rewritten in Swift. It’s not realistic, and if attempted, it would be a disaster. Remember how rewriting the C based mDNSResponder into the C++ based discoveryd has led to some serious networking issues in OS X Yosemite? Now imagine every Cocoa framework on iOS and Mac in a huge state of flux because of Swift rewrites. And the Mac frameworks are much larger with a much longer history.
Something much more realistic would be the gradual introduction of Swift code into Apple’s frameworks. And that seems like something that will almost certainly happen at some point. But considering that Apple is already under significant pressure to ship user facing features instead of backend enhancements, it could take Apple decades to gradually rewrite all of their frameworks in Swift. By the time such a transition is finished, OS X and iOS would likely be ready to be ready for retirement any way (and I do believe both OS X and iOS will continue to contain large amount of Obj-C code right up until the very end.)
It all comes down to a simple question: Is it better for Apple to spend the time, effort, and user goodwill to rewrite everything in Swift just for the sake of killing Obj-C? Or is it better to continue investing in much of the Obj-C code they have and continue enhancing Obj-C?
(Quick note: There has also been some speculation that Apple should write a new Swift only API to replace frameworks like AppKit and UIKit. While I personally don’t believe this is likely to happen, it also doesn’t change the reasoning here. There are too many applications out today written using AppKit and UIKit, and Apple is in no position to end support or deprecate either of those frameworks.)
This section should be taken with a large helping of “I don’t work for Apple, but…”
Swift is likely to continue along it’s present course. As the language evolves, I think it’s ability to bridge back and forth with Obj-C will be cleaned up, so it can be used side by side with Obj-C almost transparently.
Obj-C is likely to see similar changes. The biggest complaint, and the biggest driver of developers wanting to see the death of Obj-C, is that Obj-C classes don’t interface cleanly with some of the functionality of Swift. But I think we’ll see Obj-C enhanced to provide most, but not all, of the functionality Swift developers want to see when working with Obj-C code. Already we’re starting to see some of these changes with Xcode 6.3. Enhancing Obj-C to provide API that Swift developers want is the far cheaper and easier solution than Apple rewriting all their API in Swift. (Another possibility is that Apple could keep their base API in Obj-C, but have a set of extensions written in Swift, but I think that’s the less desirable option.)
Use the best tool for the job. Don’t be scared of multiple languages.
At this point, Swift and Obj-C still can’t entirely replace each other’s use cases. For example, Swift’s strong predictability and Obj-C’s dynamic model are, to a certain extent, directly opposed, and likely always will be. And that’s ok. That’s more than ok. That’s awesome. Because now you have choice.
Do you have some sort of crazy data model that needs to really dynamic? Objective-C is a really great tool for that! Are you writing a state machine that needs to be really predictable with solid type safety? Now you can use Swift!
Smart developers aren’t just going to pick one language and try to make that language do everything. Sure, a lot of developers are going to lean one way or the other in cases where either language would work. But if I had one thing to suggest to the community it would be this: We can build better, more amazing apps with two languages instead of one. Languages are tools. And it’s ok to use both a screwdriver and a hammer where each works best, even in the same project.
I wanted to put in a tiny footnote on my adoption of Swift so far. Because I work on a project where I can’t take the hit of the Swift static library, I haven’t incorporated Swift into any shipping code. I have started prototyping code in Swift playgrounds, and then porting to Obj-C. When the Swift library starts shipping as part of the OS, I’ll start shipping Swift and Obj-C code. Another sticking point for me is the lack of C++ support in Swift. A lot of our code is cross platform C++ code, which I can’t directly interface to with Swift. Until that’s fixed, there are certain classes I couldn’t even consider converting to Swift. But, if anything has been learned from this blog post, that’s totally ok.
* * * *
In addition, we do have two libraries of our own, written on both languages:
Check them out!
Giovanni writes content at Cheesecake Labs, top mobile app development company in Brazil. He enjoys creative actions by writing and expressing messages.
Karran Besen | Nov 16, 2023