iOS Swift vs Objective-C: Which would you rather use?

[moonman239]

Craig Federighi unveiled a new programming language called Swift. He said this new programming language will make developing apps easier. There doesn't seem to be a good reason not to use Swift - the performance graphs indicated that apps developed using Swift will probably be no less efficient than if they were built using Objective-C, and your Swift apps can use Objective-C and C libraries.

Given this, which one would you developers rather use?

 

[mrxak]

Right now, without having gotten too far into the eBook yet, and mainly getting my information from WWDC videos, I'd say Swift. It just seems I'll be able to write code so much faster, and that code will be easier to read.

I also believe Swift will get a lot more support from Apple in the future.

Those things combined, if I was to start a new project today, it would probably be in Swift.

 

[firewood]

Not yet. It's still beta, and 1.0 language releases are rarely ready for production code.

Maybe a several months from now, after the compiler matures a bit, and for a project targeted for release after iOS 8 reaches 80% of the market. Until then, it's a fun playground learning toy.

 

[ArtOfWarfare]

I have a fairly young project, just started over a month ago, that will be staying in Obj-C.

Why? I looked at how much we'd put into our project so far, estimated how much we had left before an initial release in we stuck with Obj-C, how much time it would take to learn the new environment, tools, and language, and then how much time it would take to do it all from scratch in Swift.

I concluded that while if I'd known everything about Swift a few weeks ago, I would have used it instead, but I didn't. And I've sunk too much time in already, so I'll just stick with Obj-C for now.

After the initial release (expected sometime between August and September - another factor in not using Swift is that I don't think we'll be able to publish Swift apps in the App Store that soon) - we'll probably implement new stuff in Swift.

 

[Zwopple]

Not yet. It's still beta, and 1.0 language releases are rarely ready for production code.

Maybe a several months from now, after the compiler matures a bit, and for a project targeted for release after iOS 8 reaches 80% of the market. Until then, it's a fun playground learning toy.

It's been in development for 4 years already, most languages when released are nothing more than the language and compiler where as with Swift we have the full developer tools suite included which is huge progress.

Secondly, it already runs on iOS 7.0 so you don't need to worry about waiting for iOS 8 only apps to take advantage of it.

 

[firewood]

Secondly, it already runs on iOS 7.0 so you don't need to worry about waiting for iOS 8 only apps to take advantage of it.

You are correct that Swift targets iOS 7. But to say that it "runs" is overly gracious.

It still crashes a lot on simple playground code. Read the open radar's and developer forum bug reports. I doubt the complete Swift toolchain will be ready for building production quality iOS 7 apps until around the time iOS 8 is ready for it's .1 update.

But you are right. You don't need to wait if you want to waste your life stumbling over lots of new compiler (etc.) bugs.

 

[mrxak]

I found a bug where it gives an error, and then if you copy the code it has a problem with, and paste it right back in, the error goes away and the code works fine. I'm not totally sure what's going on there, but I'd say Xcode 6 is hardly ready for prime time. This, not to mention some language features don't even seem to be implemented yet.

That said, it's not too early to start designing, and writing some code. I just wouldn't trust it to actually compile code the eBook says I can write. Eventually those "not yet implemented" errors will go away and Xcode bugs will get fixed, and getting some experience and code written with the language in the meantime won't hurt.

If the question is what language we'd rather use, I don't think it's much of a question. Swift, all the way. Unfortunately Swift isn't as usable now as I'd like. Oh well. Maybe next week we'll get a new beta, maybe in a month or two everything will be implemented. But yeah, in an ideal world, I already enjoy coding in Swift a lot more than I did in Objective-C.

 

[Brian Y]

I found a bug where it gives an error, and then if you copy the code it has a problem with, and paste it right back in, the error goes away and the code works fine. I'm not totally sure what's going on there, but I'd say Xcode 6 is hardly ready for prime time. This, not to mention some language features don't even seem to be implemented yet.

That said, it's not too early to start designing, and writing some code. I just wouldn't trust it to actually compile code the eBook says I can write. Eventually those "not yet implemented" errors will go away and Xcode bugs will get fixed, and getting some experience and code written with the language in the meantime won't hurt.

If the question is what language we'd rather use, I don't think it's much of a question. Swift, all the way. Unfortunately Swift isn't as usable now as I'd like. Oh well. Maybe next week we'll get a new beta, maybe in a month or two everything will be implemented. But yeah, in an ideal world, I already enjoy coding in Swift a lot more than I did in Objective-C.

The only thing that's worse than a first generation language, is a first generation compiler.

Compilers are very complex things - there's a lot of optimisation, etc that goes on under the hood - and it's something which is impossible to perfect in such a short space of time. For this reason, I personally feel swift will have a very short lived lifespan.

gcc is 27 years old now. There are still compiler level bug fixes, and compiler bugs, unlike regular code, tend to be very complex. For example, take this bug fixed in the latest version:

On AArch64, the singleton vector types int64x1_t, uint64x1_t and float64x1_t exported by arm_neon.h are defined to be the same as their base types. This results in incorrect application of parameter passing rules to arguments of types int64x1_t and uint64x1_t, with respect to the AAPCS64 ABI specification. In addition, names of C++ functions with parameters of these types (including float64x1_t) are not mangled correctly. The current typedef declarations also unintentionally allow implicit casting between singleton vector types and their base types. These issues will be resolved in a near future release. See PR60825 for more information.

Given that it took apple so long to patch simple application level errors, such as the iOS 7 springboard crashes, I very much doubt Apple has the skill set these days to maintain a compiler during its early stages.

 

[subsonix]

gcc is 27 years old now. There are still compiler level bug fixes, and compiler bugs, unlike regular code, tend to be very complex. For example, take this bug fixed in the latest version:

But AArch64 is not 27 years old, it's new in ARMv8. Also, Apple uses Clang which is developed at Apple.

Given that it took apple so long to patch simple application level errors, such as the iOS 7 springboard crashes, I very much doubt Apple has the skill set these days to maintain a compiler during its early stages.

They already do with C, C++ and Obj-C with Clang and LLVM.

 

[iMacBooked]

I'd say go with Swift, it will definitely be a better overall experience and has more possibilities for what the future might bring us.
But as long as it's in beta, people my hesitate doing the switch, which is understandable.

 

[mrxak]

Compilers are very complex things - there's a lot of optimisation, etc that goes on under the hood - and it's something which is impossible to perfect in such a short space of time. For this reason, I personally feel swift will have a very short lived lifespan.

Somebody said this about every language ever. It's true for some, to be sure, but do you really think Apple isn't serious about making this their flagship language of the future?

Xcode 6, a beta, is buggy right now. It hadn't had a whole lot of eyes on it before Monday evening. I can certainly forgive Apple for that.

And besides, they've been working on the language inside Apple for 4 years already. The guy who created Swift also created LLVM and Clang. I'd say they have some skill at their disposal, and to be clear, the teams that write the applications are very different than the ones that write apps for iOS.

I can understand a person not liking Swift. But to suggest that Swift won't be around for very long is really just insane.

 

[Brian Y]

Somebody said this about every language ever. It's true for some, to be sure, but do you really think Apple isn't serious about making this their flagship language of the future?

Xcode 6, a beta, is buggy right now. It hadn't had a whole lot of eyes on it before Monday evening. I can certainly forgive Apple for that.

And besides, they've been working on the language inside Apple for 4 years already. The guy who created Swift also created LLVM and Clang. I'd say they have some skill at their disposal, and to be clear, the teams that write the applications are very different than the ones that write apps for iOS.

I can understand a person not liking Swift. But to suggest that Swift won't be around for very long is really just insane.

It's not really insane, it's just my opinion, there's no need for the subtle attack. Swift has been a bit of a joke thus far (emoji for var names, really?), and honestly, this "developer preview", which is essentially what - 3 or 4 months from public launch, is going to need MUCH more than 4 months work before release. Heck, when a programming language is still giving "NotImplementedYet" errors, 4 months before it's supposed to be generally available, it shows that the developers behind the language really aren't ready.

I'd love for Apple to move away from Objective-C fully. It's a language I really hate.

Apple aren't the sole developers of clang. They have others (including google) helping them out. Plus, objective C has been around for donkey's years. And clang was in development for over 2 years before it was released.

A brand new programming language, and a brand new compiler, cannot physically go from a state where it's giving "NotImplementedYet" to general availability in 4 months, AND go through proper testing. Any developer that starts using Swift in production is the crazy one. If you want a comparison, gcc, for example, was released after what 3 years of development in '87, and wasn't considered stable enough to use until '91. And this is with people like Richard Stallman at the wheel.

 

[xStep]

I found a bug where it gives an error, and then if you copy the code it has a problem with, and paste it right back in, the error goes away and the code works fine. I'm not totally sure what's going on there, but I'd say Xcode 6 is hardly ready for prime time. This, not to mention some language features don't even seem to be implemented yet.

That sure is quirky. I hope you filed a bug.

 

[Menneisyys2]

At least for the time being (the next, say, year), I will surely stay with Obj-C, particularly with my (numerous) AppStore apps' legacy, but continuously updated, Obj-C code compatible with even the earliest armv6 devices. It'd be some tremendous effort to rewrite the entire thing in Swift and I surely couldn't compile it for armv6.

In addition, I know Obj-C like the palm of my hand. This is another reason I don't want to leave it unless I'm forced to by, say, Apple's completely dropping support for it.

 

[1458279]

I had to cut across the grain on this (although I had to think about it)... I selected ObjC even thou I don't really like it.

The primary reason for picking ObjC is that I don't wan't making apps easier, I want them to be almost as hard as they are now.

Back in the old days there were a flood of easy program tools/languages. With that came a flood of "weekend warriors" that really didn't belong in the industry.

I was senior programmer at Visa and we contracted out a company to do a project. They had 3 'programmers' on site and one was debugging some code.

I looked at the code and told her the problem was reading the end of the file and she needed to check for an empty line.

Over an hour later, she was excited about having fixed the problem... it was an unchecked empty line, exactly what I told her it was.

The world is full of clueless people trying to learn just enough to get a job or make some money.

Computer programming is NOT the place for every "I'm one too" that want's to jump on board.

Another person from the same company dropped our entire active online SQL database in the middle of the day because he didn't want to check the script as I asked him to.

The ended up in court standing behind a contract that says they are not responsible for just about anything that would happen.

With over 1.25 million apps flooding the apps store, does any think we actually need more junk from every weekend warrior trying to get rich?

I'm an free market guy, but don't we have enough script engines already? Templates, reskins, multi-platform easy to learn products? How many do we have, 10, 20?

Does someone think Swift will be easier than all those scripting programs?

Does someone think these weekend warriors will jump from the scripting programs to Swift?

Does someone think a seasoned ObjC programmer will take the time to learn a new language for little or no gain?

Anyone ever hear of RubyMotion?

http://readwrite.com/2014/06/04/apple-swift-programming-language-wwdc#awesm=~oGgWSWsM063ZwI

Having said all that, I like what I see so far of Swift and will learn it, but I've learned so many languages at this point, why not add another

 

[AdonisSMU]

I had to cut across the grain on this (although I had to think about it)... I selected ObjC even thou I don't really like it.

The primary reason for picking ObjC is that I don't wan't making apps easier, I want them to be almost as hard as they are now.

Back in the old days there were a flood of easy program tools/languages. With that came a flood of "weekend warriors" that really didn't belong in the industry.

I was senior programmer at Visa and we contracted out a company to do a project. They had 3 'programmers' on site and one was debugging some code.

I looked at the code and told her the problem was reading the end of the file and she needed to check for an empty line.

Over an hour later, she was excited about having fixed the problem... it was an unchecked empty line, exactly what I told her it was.

The world is full of clueless people trying to learn just enough to get a job or make some money.

Computer programming is NOT the place for every "I'm one too" that want's to jump on board.

Another person from the same company dropped our entire active online SQL database in the middle of the day because he didn't want to check the script as I asked him to.

The ended up in court standing behind a contract that says they are not responsible for just about anything that would happen.

With over 1.25 million apps flooding the apps store, does any think we actually need more junk from every weekend warrior trying to get rich?

I'm an free market guy, but don't we have enough script engines already? Templates, reskins, multi-platform easy to learn products? How many do we have, 10, 20?

Does someone think Swift will be easier than all those scripting programs?

Does someone think these weekend warriors will jump from the scripting programs to Swift?

Does someone think a seasoned ObjC programmer will take the time to learn a new language for little or no gain?

Anyone ever hear of RubyMotion?

http://readwrite.com/2014/06/04/apple-swift-programming-language-wwdc#awesm=~oGgWSWsM063ZwI

Having said all that, I like what I see so far of Swift and will learn it, but I've learned so many languages at this point, why not add another

People who can't program wont anyway. Weekend warriors don't last as programmers and you know this. Secondly, the free market works just fine. You will always have people with less experience than you. Maybe having a code review process and controls in place would've allowed you to avoid mistakes that your presumably less experienced contractors made. You are trying to place the blame on contractors when really you guys are VISA are the ones at fault for not having procedures (code reviews, limits on deployment access etc) in place for making changes to your software.

Making SWIFT is really to make people who are already developers work faster and more efficiently. What is so bad about programmers liking the language they work with? You can't learn SWIFT in a weekend. You have to fail a whole bunch of times before you become successful with any app. You put in literally hundreds and thousands of hours of work into them. There will always be people who do crappy things. Making the language accessible to people who already work in another language is a good thing.

 

[AxoNeuron]

I had to cut across the grain on this (although I had to think about it)... I selected ObjC even thou I don't really like it.

The primary reason for picking ObjC is that I don't wan't making apps easier, I want them to be almost as hard as they are now.

Back in the old days there were a flood of easy program tools/languages. With that came a flood of "weekend warriors" that really didn't belong in the industry.

I would agree that someone who doesn't really truly understand and appreciate software development shouldn't try to get a job in the industry. But that doesn't mean that software development should be a closed garden where only the "cool kids" get to play.

I think it would be fantastic if Swift turns out to be a much easier language to learn than Objective C. A lot of these "weekend warriors" won't be weekend warriors forever, I've known several who turned in to genius software developers.

The main difference here is if they're willing to learn the hard stuff, and be willing to admit when they don't know what they're doing, and to do the work to learn more. The problem here isn't that people learn to program in their spare time while doing something else, the problem is that some of these people look at software development as a potential salary as opposed to a fascinating way to create awesome new cool things. People who learn software development in order to make an easy buck and don't really find it exciting should do something else, I would agree with that.

 

[1458279]

Excellent point about Visa. They didn't take the time to review things and someone above us made the decision to go forward. Their test servers were a joke, the employees that were in charge of testing did nothing. So you called that one.

What I've seen is that most companies don't have a clue how to test something or design things that work.

 

[s2mikey]

Excellent point about Visa. They didn't take the time to review things and someone above us made the decision to go forward. Their test servers were a joke, the employees that were in charge of testing did nothing. So you called that one.

What I've seen is that most companies don't have a clue how to test something or design things that work.

Being in software QA, this comment really hits home. It's amazing what they'll send out even though we document many issues the software has. They don't care. It's all schedule based. Some manager has a checkmark on their calendar app and that means the software is going out regardless of how bad it is. Or, companies are just too cheap to spend upfront on QA and proper testing so they skip it. Of course, it costs them WAY more to fix it in the field but somehow that "saves" them money. Right.

 

[1458279]

Being in software QA, this comment really hits home. It's amazing what they'll send out even though we document many issues the software has. They don't care. It's all schedule based. Some manager has a checkmark on their calendar app and that means the software is going out regardless of how bad it is. Or, companies are just too cheap to spend upfront on QA and proper testing so they skip it. Of course, it costs them WAY more to fix it in the field but somehow that "saves" them money. Right.

The company I worked for before Visa sent out a whole crew to a large bank in order to install a project that a new programmer wrote. They had to come back early because it failed to work. Something that was pretty easy to check, but they didn't bother. I had no involvement in the project at all, didn't even know what it was or why they needed a new version of the stable product, yet they tried to blame me for it because I was the only person that knew how to program well.

I ended up quitting and working for their biggest competitor which later merged with Visa. They called me a few days after I quit and asked me where the source code was... I told them where it was... they then said they couldn't get it to compile

I met a programmer years later and he worked there, they had to rewrite everything from scratch with a whole new crew and my old boss nearly lost his job.

Too much politics and too many people that have no clue what they are doing, they're just looking for a good paycheck.

 

[firewood]

Compilers are very complex things - there's a lot of optimisation, etc that goes on under the hood - and it's something which is impossible to perfect in such a short space of time. For this reason, I personally feel swift will have a very short lived lifespan.

The opposite.

Swift was designed by the team that wrote Apple's production compiler toolchain. For OS X, it's a better compiler toolchain than gcc. Swift was designed to make it even easier and safer for the compiler and LLVM tools to check and optimize Swift code than given C, Obj C, or (yuk!) C++ source code.

The current problems are mostly with the front end and Playground, not the optimizer and code generator. Those easier issues will be mostly fixed in a few months.

So it's Objective C that may have a short horizon on it's active lifespan. Not Swift.