Swift Vs. Objective-C: Why the Future Favors Swift

snydeq writes: InfoWorld's Paul Solt argues that It's high time to make the switch to the more approachable, full-featured Swift for iOS and OS X app dev. He writes in Infoworld: "Programming languages don't die easily, but development shops that cling to fading paradigms do. If you're developing apps for mobile devices and you haven't investigated Swift, take note: Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms. Thanks to several key features, Swift has the potential to become the de-facto programming language for creating immersive, responsive, consumer-facing applications for years to come."

Comments

Uh...

[EmeraldBot]

Since when is embedded programming associated with "immersive, responsive, consumer-facing applications"? I don't think Swift is going to replace C anytime soon in that department.

Re:Uh...

[Entrope]

More to the point, who outside Apple develops embedded software for an Apple platform?

Re:Uh...

[ColdWetDog]

The NSA.

Re:Uh...

[Guy Harris]

Since when is embedded programming associated with "immersive, responsive, consumer-facing applications"? I don't think Swift is going to replace C anytime soon in that department.

It was not obvious from the summary what the heck was meant by "embedded programming". In TFA, in addition to the quoted paragraph, the word "embedded" is also used in "The ability to defer loading in a mobile app or an embedded app on Apple Watch will improve the perceived performance to the user.", "Swift provides the development community a direct way to influence a language that will be used to create apps, embedded systems (if Apple ever licenses an embedded framework and chip for third parties), and devices like the Apple Watch.", and "Ultimately, Swift is a more approachable full-featured programming language that will allow developers to not only build apps but also target embedded systems like the new lower-power Apple Watch for many years to come."

So if he's referring to the Apple Watch, maybe. If he's not, I'm not sure what the heck he's referring to; "embedded systems (if Apple ever licenses an embedded framework and chip for third parties)" sounds like hand-waving. Is he expecting Apple to be pushing Darwin into the *ahem* Internet of Things or some such?

Unlikely

[msobkow]

It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.

Re:Unlikely

[msobkow]

You don't get it, do you? Apple lives on open source code that they didn't write.

Re:Unlikely

[Trepidity]

I think a wholesale rewrite is unlikely, but I would guess that they are going to eventually do something about the GNU code they use. Apple doesn't like the GPLv3's patent clauses, so they have frozen all their imported GNU utilities at the latest GPLv2 version. Some of these are now getting quite old and not maintained upstream, so Apple has to handle even routine maintenance. They managed to transition off one big one by moving from gcc to clang/LLVM, but there is still a bunch of old GNU code shipped in the base system that I don't see them keeping forever. Now whether they rewrite it in Swift seems more questionable.

Re:Unlikely

[mark-t]

Because when it becomes acceptable to steal from somebody else, then one day it may become acceptable to steal from you.

Re:Unlikely

[Feral Nerd]

It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.

Precisely, that's what wrapper code has been for since I started coding back in the early 90s. It always cracks me up when people let fly gold nuggets like "...the Python implementation of OpenCV...". As far as I am aware, nobody rewrote all of OpenCV in Python, they created Python bindings which is a fancy way of saying they created a Python wrapper for OpenCV. Programmers don't always realise that the API's they are using are actually wrappers. I used to use a C++ Linear Algebra library but because I just installed it with yum or apt-get I didn't pay it much thought. it wasn't until I tried to compile it for an embedded computer that I realised the thing was actually a wrapper for a Fortran 77 library that was ported to Fortran 90 and then given a C++ wrapper and that made it a bit of a bitch to compile (largely due to the fact that I didn't know squat about Fortran). Apple will provide Swift wrappers for at least some of the C/C++ libraries and the ObjC stuff if that's necessary (never used Swift myself so I don't know how well ObjC libraries integrate into Swift). Any other approach would have Apple's developers busy doing nothing but rewriting and debugging ported code for the next decade at least. What interests me is how far up shit creek will a developer be if he/she realises that they need a C/C++/ObjC library for his Swift application?

On iOS platforms.

[FireballX301]

The future favors Swift only because Apple is going to phase out use of ObjC. That's it. Arguing about languages is silliness when Apple will likely force you into using Swift for iOS9 compatibility in the next 12 months.

Re:On iOS platforms.

[Dog-Cow]

How should Apple be able to force you to use one or the other?

should or could?

Apple can easily do both.

should: because Apple says so, and they control the App Store. Apple doesn't have to give a reason other than deprecation.

could: compiled swift code looks different than objective-C code. It also links against the swift runtime and not the objective-C runtime. It's not hard to tell the difference.

Re:On iOS platforms.

[Kyogreex]

I think you're missing the point FireballX301 is trying to make. It's not about the languages, it's about the tools. If Apple wants to move developers to Swift for whatever reason, there are ways they could enforce that to an extent by removing support for Objective-C within their tools. Sure, there may be third-party solutions that pop up (such as Xamarin with C#), but if Apple's tools don't support Objective-C code, I think that would effectively force quite a few developers to make the change.

With that said, I doubt Apple is going to do that, at least not yet.

Re:On iOS platforms.

[BronsCon]

This oft-quoted line of complete bullshit is why people think iOS and Apple's walled garden is more secure than any other mobile platform. The reality is that Apple gets a binary to review, just like Google, Microsoft, or Blackberry. Apple and Google actually review the binaries, even; and Google even actually catches some nasties (I'm sure Apple does, as well, but they aren't as transparent about it) and prevents them from entering the Play store. Apple has pulled malware from the iOS store in the past, but has never made any official comment on it, unlike Google, which does leave one wondering... Knowing that malware authors likely submit to both platforms at the same rate, we know how often Google rejects or removes malware from their store (because they publish the statistics), one should expect that Apple's numbers are roughly the same, but are they? If anyone has a link to some official (e.g. from Apple) stats on that, I'd love to see them.

Re:On iOS platforms.

[mridoni]

How should Apple be able to force you to use one or the other?

The same way they did when, under the old MacOS, they switched the preferred language from Pascal to C: all the documentation refers to the "new language" examples, all data structures are listed in the "new language" formats, some information needed for compatibility with the "old language" is omitted or brushed under the carpet, some data structures will favor the "new language" (e.g. C vs Pascal strings in system calls), etc.

Of course it will take time but they can do it, no doubt about that.

Re:On iOS platforms.

[F.Ultra]

It pretty much sucks

As an OS X/iOS dev who has used Swift...

[goosesensor]

I donno. "development shops that cling to fading paradigms do [die]." Obj-C is a perfectly good tool. Fortran and COBAL as still used all over the place. The only way Obj-C dev shops are going to die is if Apple makes it so (and I have no doubt they will). But I think this fundamental argument is flawed if not downright wrong.

Re:As an OS X/iOS dev who has used Swift...

[_merlin]

What's with the outbreak of people who can't spell COBOL? It's like kids are trying to sound older than they are by using jargon but completely screwing it up.

Debate settled. We know the future!

[Paradoks]

It's nice that there's a programming language debate where the future has been entirely settled. Thanks infoworld!

Re:Debate settled. We know the future!

[Half-pint HAL]

There's a new version of Siri, coded in Swift, that answers your questions about the future. It was released next December.

Re:Swift is destroying Rust.

[EmeraldBot]

The important thing to remember here is that Swift is absolutely destroying Rust.

Rust has been nothing but hype so far. Many Ruby on Rails hipsters have rallied around it, but they haven't actually managed to produce anything useful with it.

Anything that can be done using Rust can be done better by using C++.

C, C++ and Go are the dominant languages on Linux. Rust has made no inroads here.

C++ and C# are the dominant languages on Windows. Rust has made no inroads here.

Now that Swift is seeing tremendous uptake within the iOS and OS X sphere of influence, Rust has even less of a chance than it had before.

I think that Swift will be seen as the final nail in Rust's coffin. Swift has provided developers with productivity, while Rust has provided them with false hopes.

We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.

According to the TIOBE Index, Java has more usage than all three of them put together. I'd hardly call it a "minor player".

Objective-C was ahead of its time

[jblues]

Objective-C was ahead of its time. It uses messaging for communication between Objective-C, and using "the runtime" (a tiny virtual machine that is embedded into each executable) messages are resolved to a function pointer. Other compiled languages use static dispatch, vtable dispatch (allows overriding) or in-lining. However, messaging gives an advantage in that it affords features that are available in higher-level 'interpreted' or 'managed' languages:

• * Object introspection - describe the methods and properties of an object
• * Dynamic invocation - reflectively invoke methods of an object.
• * Method interception - add or reroute methods for all instances or a single instance of an objection, optionally calling the original.

The above features allow all kinds of useful things like Aspect Oriented Programming, instrumented objects at runtime (eg for object-relational-mapping), Cocoa's elegant property observers, etc. Another advantage is that Objective-C is close to the bare-metal so its very easy to take advantage of the above, while dropping back to raw C (or C++) as needed for performance tuning, which given the 95-5 rule is not too often.

Contrast these dynamic features, with C++ which fills another niche. Now the industry has had 30 years to forget how useful these features are, so Swift uses static and vtable dispatch. Given a virtual machine, with just-in-time compilation this is no problem, but as a compiled language it means forfeiting the above. Swift allows the above if a class extends a Cocoa Foundation class, but this problems are:

• * Developers are excited about writing 'pure' Swift.
• * The advantage or dynamic dispatch is that it can be applied to any class. Now if Swift adds compile-time AOP, this will only work with code that you have the source for.

• • I'm surprised more people didn't raise concerns about this.

Re:Objective-C was ahead of its time

[jblues]

* Object introspection - describe the methods and properties of an object * Dynamic invocation - reflectively invoke methods of an object. * Method interception - add or reroute methods for all instances or a single instance of an objection, optionally calling the original.

All that has nothing to do with "message passing".

You think so?

Runtime method interception is supported in languages that use vtable style dispatch rather than messaging, only because these languages feature a virtual machine, and class-loader. Otherwise the function-pointers are compiled right in. It is not possible to perform method interception without evil. With Objective-C we can perform method swizzling - modify the lookup table to resolve methods to a function pointer) or isa swizzling - change the 'class', to a dynamically generated one, for a given instance at runtime. Cocoao's property observers use this. Its not possible without messaging. This is why AOP frameworks for C++ are compile time only.

Object introspection & dynamic invocation : When methods are in-lined, statically dispatched or vtabled we can't reliably dynamically invoke a method. Even with the most flexible of these three, vtabling, we're still stripping the function name out so that its replaced with something like 'method[3]'. It doesn't have to be like this, but it is for C++ and Swift follows suit.

Re:Objective-C was ahead of its time

[jblues]

yea, yea yea; Python has all of that and is scripting language too boot. Google screwed up. Instead of java, morphed into android, they should have use python with a gtk stack.

Python is great, but Java, by virtue of having a virtual machine can supports method reflection, method interception and dynamically generating new methods or instrumenting classes too, even though it uses vtable dispatch. Its still considered a 'late binding' language because the class-loader provides a hook-point, prior to emitting a just-in-time compiled class, the class loader can check for method interceptions and emit and instrumented one. . The catch is that Android's Dalvik platform introduces some quirks into this.

Re:Objective-C was ahead of its time

[jblues]

E.g. Java supports reflection and introspection and: does not use message passing!

Read my comment again. I said that Java supports method interception while still using vtable dispatch. The reason for this is that it has a virtual machine and class-loader, which provides another point of interception. Examples of this are:

• * The hibernate library uses cglib, which is in turn uses asm, to provide managed objects. You write a plain-old Java object and hibernate instruments this at runtime.
• * Spring uses cglib or the aspectJ weaver to provide AOP features, such as annotation-based declarative transaction management or security

• (There is another in J2SE that provides interception called Java dynamic proxies, but this only works for interfaces.)

  The above techniques of method interception do not work in C++, which uses vtable dispatch, because there is no JVM and class-loader to provide an intercept point. Therefore when it comes to things like managed objects, the observer pattern, or other features that can benefit from runtime instrumentation, we can't have these, and the next best thing is compile-time instrumentation. Given that Apple replaced the runtime garbage collector, with compile-time ARC, we might see them continue to provide 'dynamic' features at compile-time.

  So dynamic method interception most certainly has everything to do with message passing - its how compiled-to-executable machine language languages achieve this

  When it comes to reflection, C++ strips out meta-data. There are libraries to work around this, but its not a language feature. And except for enumerating a classes properties, to enable tool support, Swift follows suit. So there is no list of a classes methods, and no dynamic invocation. Again, as I said, this part does not have to be this way, but C++ is like this, and Swift follow suit. So message passing is loosely related to reflection and dynamic invocation here, in that by default vtable dispatch strips out method meta-data.

What is Swift written in?

[Areyoukiddingme]

What is Swift written in?

It is built with the LLVM compiler framework included in Xcode 6, and uses the Objective-C runtime...

So... C. Ok, we're done here.

No wait. One more thing. It's the Objective-C runtime. Which means Objective-C programs will just keep running, as they ever have.

Swift and Objective-C code can be used in a single program, and by extension, C and C++ as well.

The new language can't supplant the old one while the old one exists in the same environment. More to the point, compatibility with Objective-C, C, and C++ was an explicit design goal. So you can just pack up all the bullshit about taking over the world.

More approachable?

[Dog-Cow]

I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.

let versus var
optionals, including implicit and explicit binding
differences between structs and classes (value versus reference)
generics
different ways of specifying parameters, including named and unnamed parameters
property declarations, including a multitude of shortcuts

The problem is, if you don't learn most of the syntax in all its variety, you'll have a hard time understanding any random code you come across. Learning by example helps make a language approachable.

Re:More approachable?

[MassacrE]

I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.

let versus var

const char* vs char* vs char const*
NSInteger vs const NSInteger
NSString vs NSMutableString

optionals, including implicit and explicit binding

NSInteger vs NSInteger*
nil vs NULL vs NSNull

differences between structs and classes (value versus reference)

NSInteger vs NSColor

generics

vs not having generics :-)

different ways of specifying parameters, including named and unnamed parameters

vs:
[NSString stringWithFormat: @"%@", value]
[NSString initWithFormat: @"%@" arguments: va_arg]
NSStringFromPoint(pt)

property declarations, including a multitude of shortcuts

vs
@property(readwrite,copy) NSString* foo;

The problem is, if you don't learn most of the syntax in all its variety, you'll have a hard time understanding any random code you come across. Learning by example helps make a language approachable.

The problem is that you are judging a new language's learning difficulty by comparing it to a language you already know.

That said, Swift is not solid enough to live there 100% yet. You have to understand both languages currently to really be efficient. Going forward, knowing both languages will just be a very desirable skill (but not essential).

Re:Swift is destroying Rust.

[lucm]

We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.

Baghdad Bob, is that you?

Swift is not ready to replace ObjC

[Anonymous Coward]

> 8. Swift supports dynamic libraries

The swift runtime is a static library (written in C++11) and linked in every executable, everytime there's an update to swift (runtime) you need to recompile all your code (see Apple's swift blog, first entry). This is why swift cannot be used for system API / libraries, at least until they have a stable runtime that can made a dynamic lib (like Obj-C is). But it being C++, I don't know if that ever gonna happen.

I disagree

[SuperKendall]

I've done Objective-C since before the release of the iOS App Store, and Swift almost full time since Apple released it last year...

Some of the things you mention beginners do not have to use (generics, and struts for example). To keep things simple to start with, they could just use classes instead.

I will agree that optionals might be a bit rough on the beginner - but perhaps not as starting from nothing, the concept of a bucket that holds a value instead of just using the value directly, would not be so foreign...

You also mention different ways to specify params, and shortcuts - but I see those as a major plus. You can just pick a level of detail that makes sense to you and work with that, until you feel comfortable with reducing further the syntax you use.

I think the function syntax is one of the cleanest and easiest styles to understand... I believe a few other languages have this form also, but in swift you just say something like "a function named takes in these params, and outputs those params" So it looks like:

func myFunc (a:String, b:Int) -> (a:String, b:Int)

it's just so balanced that you can have any number of things in or out.

There are a few things I think make Objective-C less approachable.

The separate header files, and the heavy modern use of private categories to define most internal properties confuse people as to where they need to define things.

Simply more verbose syntax all over. I like verbosity myself, I love named parameters... you get that with Swift though with a lot fewer characters typing.

Part of that extra syntax in ObjC is the shorthand to make arrays like @[] and @(value) to make NSNumbers... but in Swift Integer is treated the same as String, both are first class objects that you can do things with so it's more consistent. That in particular is I think a large benefit for newcomers.

Re:Swift is destroying Rust.

[TWX]

I suppose it depends on what you want to do with it, and what you see Java's future as a wholly-owned subsidiary of Oracle is.

I was studying programming in college when the hype for Java began. We were using C and C++. What was true then still holds true today, in that in C/C++ you can write operating systems and conventional programs, but in Java you are limited to conventional programs. Java has the theoretical interoperability feature between OSes and hardware platforms, but in practice there's a lot of customization to make programs actually do this, and if one has to write versions for several platforms, it's not a whole lot more burden to compile those and distribute binaries instead of Java runtimes.

As for servers, I've always liked the mindset of putting as little as possible on the production server beyond what its job is. Hell, the idea of statically-compiling everything to allow one to eliminate libraries, let alone compilers on the production box, appeals in that if someone does break in there's a lot less they can do once on there. Java for server-side applications flies in the face of that, there are more general-purpose tools on the server rather than less.

I'm aware that I'm not in the majority for this stuff, and I didn't make programming my profession anyway so perhaps even I should be taken with a grain of salt, but it seems like in this speed to push features we've taken steps backward in real system security, and we're being bitten in the ass by it with ever increasing frequency. The very choice of programming language appears to be fundamental to that.

I'll start using Swift

[SpaghettiPattern]

I'll start adopting Swift as soon as it has an active community on most commercially interesting platforms. E.g. all UNIX derivatives, Windows, z/OS and Mac of course. When I have ample choice of programmers to hire. Not interested in technologies exclusively centered around one supplier.

Replace C?

[fozzy1015]

"Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms."

Not if you want to write something that compiles on other platforms. With Android/iOS being based on Linux/BSD it could very well make sense to write the back end of your app in C/C++ and only then branch into a different language as required by the GUI framework and other required proprietary APIs you'll be using.

Good grief.

[engineerErrant]

FYI, I'm an iOS developer who uses a mix of languages, including Ob-C, every day. My coworkers and I met Swift with a mildly positive reaction - it's a decent, if imperfect, effort. It's not the second coming of Christ, but it definitely isn't a bad thing to try to modernize some of Ob-C's age-related shortcomings. The notion that we'd re-write code just to use it is utterly laughable, but we could certainly see ourselves using it to start a new app, or maybe at our next jobs.

The OP, though, sounds like a marketing intern wrote it. To add a little historical perspective: our apps are a riotous mix of C and C++ (for Android portability) and Ob-C. We chose to do it this way, within the last 3 years, so this is not a legacy issue. Both C++ and Ob-C were, at one time, meant as "replacements" for C, and we know how that turned out.

Swift may very well become the preferred language over Ob-C within, say, 5 years, for Apple-specific development. But the breathless "it'll replace C!" rhetoric is just silly. Over the coming decades, C will surely fade, but it will be replaced by other, newer, even more amazing tech, not just Swift.

There's some of us who've seen this before...

[mark-t]

And we know from experience that WHENEVER somebody uses terms like "language <XYZ> is the future", it is inevitably baseless speculation, and often rests on the false belief that some single programming language, or any single technology for that matter, can actually be the "best" one.

Brooks said it best, There is No Silver Bullet

Re:Swift is destroying Rust.

[viperidaenz]

There's a shit load more "conventional programs" than there are operation systems
Java also solves your libraries and compile problem.

Last project I worked on the build server was Windows 2008, my dev PC was Windows 8.1 and test and production ran Linux. I don't even think prod was x86.
No cross-platform issues at all with ~ 100,000 lines of code.

You wanna Vegas that claim?

[Tablizer]

Predictions are like assholes; everybody has one.

Re:Swift is destroying Rust.

[goose-incarnated]

We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.

Wait, what? Swift is basically statistical noise at this point. "Dead" languages like ML and Pascal are higher in the tiobe index than swift is. It may become a force in the future but it's nowhere near that now.

Re:Swift is destroying Rust.

[goose-incarnated]

Pascal's not dead. Delphi targets every major hardware platform using Object Pascal and up to 64 bit code too.

In the tiobe list Pascal is listed separately from Delphi. Delphi is higher in ranking than pascal, which itself is higher in ranking than swift.

Swift for the system programming?

[ThePhilips]

People keep bringing up the Swift in context of system programming, but so far I haven't seen any concrete info about features of the language which make it even suitable for the system programming.

The thing is, even C++ was/is used for system programming, but its C++-ness is so castrated that it is hardly can be called C++ anymore.

I personally do not see any reason to replace C with another language, which I can't use to its fullest. On top of it, lots of C extensions are needed to make the system development efficient: code/data section assignment, untyped/unchecked memory access, memory/IO barriers, assembler intrinsic. None of that is part of C standard - all of it are vendor/compiler extensions. While Swift documentation is devoid of the similar features.

P.S. If Apple folks want to push the Swift into the embedded area... Good luck. Even C++ still struggles. Higher-end embedded system require proof of validity and literally all of the solver software is C-only. Most static/dynamic code analyzers - C-only too.

Re:Swift is destroying Rust.

[jythie]

Since when does Java not suffer from DLL hell? Maven tries to mitigate this, but does so about as elegantly as RPM....

Re:Swift is destroying Rust.

[ehynes]

The numbers a langpop.com may be "real", but they're also old - the page was last updated on October 2013. Swift's failure to show up isn't because it's "so low", it's because Swift wasn't unveiled until June of 2014.