Bashing against one technology or another is something we as developers are born with. Often, our comments are ungrounded, caused by our daily work or a particular problem we cannot solve. Sometimes, they are justified. I get to follow a large community of experienced iOS and macOS developers on Twitter. These last couple of days, a few heated discussions got my attention:
I totally hear what you are saying! These kinds of discussions are nothing new among Apple developers. I do not want to initiate flamewars here. I am by far the last person on Earth who could take a side, moreover, due to the fact that my Objective-C experience is fairly limited. Indeed, I have gained a bit of Swift knowledge over the past year or so, but that's mainly due to my interest in the language and less so because of the Apple developer ecosystem. I develop iOS apps, enjoy doing that, both as a hobby, and on a professional level, but I enjoy writing Swift, because I believe that the language has a potential far exceeding the limits of the Apple ecosystem (ping me if you want to chat about running Swift apps on the server 😉)
It is however, a bit distressing when you see the Apple developer community being torn between the new wave of Swift programmers, and those who would choose Objective-C and not look back. For many, it is not a decision hey can take themselves. The maturity of the projects, and the specific requirements often force developers choose one over the other. There are obvious pro and cons for each, and as said already, I wouldn't be the one to take a side. These discussions just got me thinking, what if Apple had chosen not to go forward with a completely new language, but tried to modernize a workhorse that has served the company for decades?
Looks like a little too late for that? I'd love to hear your opinions on this.
--
This post appeared originally on my blog
Top comments (8)
The complaints about the way interop is done seem to not take into account the other goodies Swift brings to the table. I, for one, don't see how a TypeScript approach would lead to a pleasant experience.
I have only done toy iOS development, but I certainly see the appeal of a language with a more mainstream syntax and a fresh take on some of the problems iOS devs might face.
@kaydacode You're about the biggest Swift fan I can think of. Thoughts here?
..cracks knuckles..
It really boils down to Objective C being extremely outdated.. and is/has been a big turn off for new or aspiring Apple devs. There will be a day when Swift has stabilized (which some argue it's begun) and Obj-C won't be accepted by Apple anymore. They've made that pretty clear as a goal. The problem is the really big apps in the App Store are slowly migrating.. and you can't kill off supporting your biggest players until they're fully converted.
Swift is a breath of fresh air and certainly is a game changer. Vapor puts Swift on the Server, Some other plugin supports Android development.. there's a lot of power here. It's friendly syntax and familiarity to JS devs is what will keep pulling developers into the Apple ecosystem.
I'm sure there's a list of pros and cons for both.. but bottom line, Apple's made it clear this is a goal.. so I would be learning it if you haven't already. :)
Hi Kim,
let me add a disclaimer: I know nothing about mobile development so I might be saying stuff that doesn't make sense :D
I read something about the biggest issue of bringing Swift to Android being that it can only talk to the Android NDK which is not exactly "primo" software.
By the power of Google I also just found out you can use Kotlin on iOS: albertgao.xyz/2018/01/14/how-to-cr...
Either option would probably help companies that have to rewrite the core business logic of their apps twice because of these two silos. I see it done by clients of mine, they have bugs, that could be totally avoided, in either one of the two apps because they have to write the same functionality twice by different teams.
The dream probably would be to have a core team of devs trained in either Kotlin or Swift to write the core of the app and then a specialized team to "wire" the core to the UI.
Does it make sense?
Sure, I'm not a fan of shared codebase because it usually results in one platform getting the short straw in some way shape or form.
But there is a lot of power available, and I'm excited to see how both languages evolve. It would be great if Apple and Google could get along to make something like one language work seamlessly on both platforms.. but Apple doesn't play nice, so I'm sure it'll only ever be accommodated by 3rd party work around which usually end up pretty hacky.
I Have A Dream
:)
Yeah, I think Apple and Google getting along on this might be science fiction. On the surface neither company benefits from making the two platforms interoperable.
Thanks for the tag Ben :)
I think if Swift did not exist, Apple would have found or created something else to replace Objective-C.
Objective-C is a hybrid language. Part C, part Objective. Over time, it has been enhanced incrementally. The syntax is awkward. It has a challenging learning curve. There are categories of programming errors that are poorly served by the language.
Apple has looked at several alternatives languages over the years, and tested the waters with them, but had not committed to any of them. Such as Dylan, and MacRuby.
Also, keep in mind, that Apple has made the transition between languages before. At one time, Object Pascal was the anointed language. Then the anointed language became C++, and all the Object Pascal developers were unhappy.
When Apple sold itself to Next, and NextStep became OS X, we got Objective-C along for the ride. But there was a divide... the Carbon and C++ camp, and the Cocoa and Objective-C camp. Eventually, Apple pulled the plug on Carbon. That was a bumpy ride.
Now the same kind of thing is happening for their premier language: emphasizing Swift, and (as I read the tea leaves) deprecating Objective-C. I don't know if Apple has officially called out Objective-C as being "deprecated", but I'm calling it that.
The one thought experiment I have is "If not Swift, what other language would Apple have considered?" Java? C#? D? Go? Scala? Haskell? (Ignoring Dylan and MacRuby.)
I think the reason Apple ultimately decided to charter Chris Lattner to invent Swift was that they had a list of language features that no other language fully satisfied. A critical one being "interop compatible with Objective-C and Cocoa"... that's a bit of a challenge!
I looked at Swift 1.0 as an early (and painful) alpha, Swift 2.0 as a beta, but Swift 3.0 as a good maturing language ready for prime time. Is Swift 3.0 the language that fulfilled all the language features that Apple desired? I don't know, but I reckon that some features got dropped while others were added late in the game.
I like Swift better than Objective-C. But it has quirks, some of which are due to the Cocoa bridging... but all in all, Swift is an amazing feat. On par with transitioning the platform from 68000 to PowerPC, or from PowerPC to Intel.
This is making the assumption that there was something wrong with Objective-C in the first place, and I'd argue that there wasn't. Sure, it has a look, feel and personality that is unique. But languages should have personality. Swift doesn't have one, it's just another language.
If Swift didn't exist I'd still build apps, Xcode would work better, I wouldn't have wasted hours on compiler bugs on each major Swift release, and there'd be fewer conferences.
All of this is true, but obviously tongue in cheek. I like Swift, it finally works fine. But when I go back to write Objective-C Xcode works better, things build faster, and I'm a little bit happier.
Why do I write in Swift at all, then, you're probably asking. Because it's the future, and I might as well be on board. Though I argue that I (and most of us) got on board way too early and wasted valuable time fighting a language that wasn't ready for prime time.
As far as interop goes, it's pretty impressive. If you've ever done any work with other language/environment interop you'll see (generally) Swift's version is pretty seamless.
I recently pulled in an ObjC library I wrote 8 years ago into a new Swift project and it just worked. That was pretty awesome. If you pull in Swift code that you wrote even a year ago it probably won't even build.