iOS Objective C vs Swift

[hustlengrind]

Just wondering, what are the advantages of Objective C as opposed to Swift, and vice versa?

I read that if you are working for a company they generally expect you to have thorough knowledge of both; however, if you are an independent developer, what is more beneficial of knowing?

Thank you

 

[AxoNeuron]

Know both. lol. Some projects will require you to work on Swift, others will require Objective-C. A lot of the projects I've worked on required a good knowledge of both. But once you know Swift, it's easier to learn Objective-C, and visa versa.

 

[1458279]

I know it sucks, but Axo is right, you probably need to know both. I started a big thread about this issue because at that time I thought Swift sucked. I'm changing my mind as I learn more about it and starting to like it.

One issue is that most code is written in ObjC, so if you want to use add ons, they'll probably be written in ObjC. The other issue is that a lot of the new tutorials are moving to Swift.

I'm going thru the latest Stanford iOS course now and they've dropped ObjC and only do Swift. It's looking like ObjC is not going to get the update attention that Swift is and Swift is now open source.

ObjC is very powerful and doesn't have any major problems with the add ons like database engines and others, where as Swift is still half baked.

One side to this is that it also depends on what you want to do, if you develop apps that don't use outside source or products, you can get away with just picking one. If you use some open source routines or 3rd party APIs, you might have to learn both.

It's not so bad once you jump in, a lot of code tends to be API calls, selection, iteration, and looping so you don't have to always be an expert on everything a language has to offer. Otherwise it's mostly just syntax.

 

[firewood]

Objective C is a superset of Standard C; and there's a ton of useful C source code out there, vastly more than there is for Swift. There are also more books and other reference materials using Objective C or C than there is with Swift.

 

[AxoNeuron]

Objective C is a superset of Standard C; and there's a ton of useful C source code out there, vastly more than there is for Swift. There are also more books and other reference materials using Objective C or C than there is with Swift.

Totally agreed there, there is SOOOO much useful C stuff out there that I'm really disappointed you can't use inline C with Swift.

 

[1458279]

Totally agreed there, there is SOOOO much useful C stuff out there that I'm really disappointed you can't use inline C with Swift.

Ok, I guess I haven't got to that point in Swift yet, but with the bridge they talk about, can you access C?

I have to agree about the half baked part on Swift. Either they put it out too early because they were concerned about how deep ObjC would be tied to iOS dev, or they made a mistake.

IMO, it's very different from an OS upgrade. With an OS upgrade, you can dump all over the apps that don't work any more and people can still get by. However, with a half baked language, you can't move your work over unless you find a way to make every thing work right.

Stanford really went all in with Swift, hardly any mention of any problems past mild glitches.

 

[firewood]

Swift code can call C functions, and bridge to Objective C which can contain arbitrary C code. Swift 2.x can even use C callbacks, IIRC.

You can partially port an Objective C app to Swift one class group or controller at at time. Several large companies are doing so. But many small devs just switch using Swift only for new apps.

 

[loon3y]

Swift code can call C functions, and bridge to Objective C which can contain arbitrary C code. Swift 2.x can even use C callbacks, IIRC.

You can partially port an Objective C app to Swift one class group or controller at at time. Several large companies are doing so. But many small devs just switch using Swift only for new apps.

this, maintaining swift with an inexperienced/junior developers of an existing B2B (business) app is impossible.


Either your going to waste a crap load of time testing or giving your customers an app that isn't fully tested.

I.E. something got deprecated or updated, and the printing doesn't work, can't save orders or you can save orders but you can't shoot it to the main system.


Etc etc. I've spent 1 1/2 years basically maintaining code with little development on features and optimization.

 

[firewood]

Another advantage of Objective C over Swift I recently heard about: A large corporation had to buy everyone in their development and test teams new high-end Mac Pros because the long build times for very large Swift apps was slowing down development cycles.

Incremental builds of large Objective C and C apps seems to still be clearly faster than for large all Swift apps.

 

[1458279]

this, maintaining swift with an inexperienced/junior developers of an existing B2B (business) app is impossible.


Either your going to waste a crap load of time testing or giving your customers an app that isn't fully tested.

I.E. something got deprecated or updated, and the printing doesn't work, can't save orders or you can save orders but you can't shoot it to the main system.


Etc etc. I've spent 1 1/2 years basically maintaining code with little development on features and optimization.

Excellent point! We're getting to the point where larger ObjC based apps are becoming "legacy code". This is where programmers can become split. Some can write an app from scratch but don't have good skills maintaining legacy code.
A business that has a huge investment in legacy code, needs programmers that have been down that path before.

I worked for a logistics company that was entirely run on old legacy code and couldn't find anyone that wanted to work with the old code because it was a dead end job. They ran the old code for a decade after I left and they expanded the programmers from 1 to 30 just to be able to both maintain the old system and create a whole new system on a modern platform. VERY expensive process that yielded no gain for the business. Ironically, when I was 1st hired there, they said they were 2 weeks away from moving over to a new dev platform, years later, that move over was still pending that's when I left.

Most programmers don't understand the large business aspect of the value of software, they just study programming.

Swift has thrown a monkey wrench into the gears, businesses that don't have a good long term vision on the effects of this could find themselves out of business.

Short sighted companies will think they are saving money by hiring coders for cheap and using an easy language, they'll pay the price later (if they can afford it).

 

[Mascots]

Boohoo. This is how OS X, iOS, system frameworks, and other major things from Apple have been developed for years. There hasn't been a version yet that hasn't introduced backward compatibility issues, unknowns, or completely broken stuff, yet it's still one of the most popular operating systems for development because the breaks are for the greater good.

There have been 2 major backward compatibility breaks in Swift, all of which took under a few hours to migrate my multiple projects, none of which affected my production applications (since Swift is embedded in the app, unlike iOS components), and were well worth it to improve the language. I didn't have to migrate my projects until I'm ready, but I wanted to take advantage of what was brought - Hell, one can (and I have) even ran two versions of Xcode concurrently, working on separate branches to take your time migrating while stilling adding features. Any proficient developer will know and take advantage of all of the opportunities to stack, organize, and work through expected and unexpected progressions in frameworks and languages.

Let's be honest here, changing any component in any language gives room for error: there's no excuse for not taking advantage of utilities that have been supplied by Xcode for a long time now to ensure your code is operating as expected. The goal should be to be well rounded with your development tools, release stable & well tested updates, and understand and work with the platform you're on. I understand there's different POV's, but come on, we're developers. Things change, things break, we know that - blaming Swift for all of your ills, and nitpicking at it (while turning a blind eye to Objective-C, which is hardly a shining star) isn't going to remedy problems.

There's a lot of dumping on Swift here, but I've hardly seen anyone give explicit positives about Objective-C , so I'm going to give a few pros for Swift.

- A lot less syntax heavy; I've been writing a lot more Objective-C the last few days and I forget how syntax sensitive it is. There's a lot of nuances that I personally find annoying, regardless of their purpose, but the latter half of this fact is my opinion.
- Works along side Objective-C anyway, so has access to the Objective-C runtime (Swizzle me bro).
- Being actively developed, thus happily changing major pieces for the better (Error Handling!)
- With the above point, the larger changes help you to keep your apps in shape by making you reexamine pieces
- Swift is based on existing principals set into place and used in many modern, popular languages (Haskell!)

I understand that everyone likes their own way, but seriously, a lot of people are throwing their weight behind Swift because it's a good language, not because it's perfect (far from it) or they think it's fancier because it's just new and shiny (it is, but that's not why). No matter how often you stay stuck in a rut, if you want to continue experiencing the full experience of iOS development, you'll need to keep tabs on it.

Don't get me wrong, I don't think that Objective-C is a bad language, but I do think Swift is a far better one.

 

[1458279]

I remember when I started iOS programming and saw ObjC. I thought it was a strange backwards language. I've seen C/C++/C#/Java/VB and many others and I thought ObjC sucked. Then I gave it some time and it kind of sank in.

IMO, this is normal for any new language that a programmer sees. I thought VB sucked at 1st, then it was ok.

Compared to ObjC, Swift is now looking better all the time. I don't like the named params, 'inout' and unwrapped/optional is a bit different, but it's starting to look better.

+1 on the Swizzle and other ObjC runtime being there!

Big neg on the size of the apps, storage on mobile is a big issue and Apple isn't giving memory away cheap. Maybe that'll change in time.

Having said all that, I'd like to see some of the syntax become optional. Maybe it could be optional to use named params and 'inout' could be preprocessed from '&'.
I actually did this with a preprocessor many years ago.

Playground and IBDesignable are looking like cool tools

 

[loon3y]

Boohoo. This is how OS X, iOS, system frameworks, and other major things from Apple have been developed for years. There hasn't been a version yet that hasn't introduced backward compatibility issues, unknowns, or completely broken stuff, yet it's still one of the most popular operating systems for development because the breaks are for the greater good.

There have been 2 major backward compatibility breaks in Swift, all of which took under a few hours to migrate my multiple projects, none of which affected my production applications (since Swift is embedded in the app, unlike iOS components), and were well worth it to improve the language. I didn't have to migrate my projects until I'm ready, but I wanted to take advantage of what was brought - Hell, one can (and I have) even ran two versions of Xcode concurrently, working on separate branches to take your time migrating while stilling adding features. Any proficient developer will know and take advantage of all of the opportunities to stack, organize, and work through expected and unexpected progressions in frameworks and languages.

Let's be honest here, changing any component in any language gives room for error: there's no excuse for not taking advantage of utilities that have been supplied by Xcode for a long time now to ensure your code is operating as expected. The goal should be to be well rounded with your development tools, release stable & well tested updates, and understand and work with the platform you're on. I understand there's different POV's, but come on, we're developers. Things change, things break, we know that - blaming Swift for all of your ills, and nitpicking at it (while turning a blind eye to Objective-C, which is hardly a shining star) isn't going to remedy problems.

There's a lot of dumping on Swift here, but I've hardly seen anyone give explicit positives about Objective-C , so I'm going to give a few pros for Swift.

- A lot less syntax heavy; I've been writing a lot more Objective-C the last few days and I forget how syntax sensitive it is. There's a lot of nuances that I personally find annoying, regardless of their purpose, but the latter half of this fact is my opinion.
- Works along side Objective-C anyway, so has access to the Objective-C runtime (Swizzle me bro).
- Being actively developed, thus happily changing major pieces for the better (Error Handling!)
- With the above point, the larger changes help you to keep your apps in shape by making you reexamine pieces
- Swift is based on existing principals set into place and used in many modern, popular languages (Haskell!)

I understand that everyone likes their own way, but seriously, a lot of people are throwing their weight behind Swift because it's a good language, not because it's perfect (far from it) or they think it's fancier because it's just new and shiny (it is, but that's not why). No matter how often you stay stuck in a rut, if you want to continue experiencing the full experience of iOS development, you'll need to keep tabs on it.

Don't get me wrong, I don't think that Objective-C is a bad language, but I do think Swift is a far better one.

Yes its an easier and better language.

This doesn't make sense when you implement it into your current projects with junior programmers in india and you need to reach your deadlines.

With over 200 customers, and with multiple version of our ERP system and databases. You don't know how much crap we went through.

Obviously we didnt implement the UI testing, and I'm not sure we will until the second version when its fully developed in swift.

Doing unnecessary testing because the syntax was updated when all we wanted to do is change the splash screen or something of that sort

is a complete waste of time. And i can't give out a product that hasn't been fully tested, because if something goes wrong they cannot take orders or send orders to the system.

So yes, in my scenario it just doesn't work. If we had the skills, time, and money (as in hiring skilled enough developers and enough developers to handle our situation) it would but thats just not the case. Not to mention there isn't enough examples on swift yet for the junior developers.

Honestly, it starts with our company creating an office in india. Simple apps is ok, but with the time difference and the developers lack of business logic and work flow. its near impossible, not to mention they do not know how to properly maintain source codes and databases.

im pulling my hair out and going crazy. there goes my holidays.


Development has stalled to almost stand still.

 

[Mascots]

Development has stalled to almost stand still.

Whew and I agree, in that situation it totally does not make sense, so don't worry, I'm not particularly dinging you, more or less the naivety of the guy is now polluting the experience of people who's minds with crude, not production ready coding when you should be ready to soak up new concepts, not recoil from them. What a mess! I hope you well, because that's a terrible rut all around.

 

[1458279]

Yes its an easier and better language.

This doesn't make sense when you implement it into your current projects with junior programmers in india and you need to reach your deadlines.

With over 200 customers, and with multiple version of our ERP system and databases. You don't know how much crap we went through.

Obviously we didnt implement the UI testing, and I'm not sure we will until the second version when its fully developed in swift.

Doing unnecessary testing because the syntax was updated when all we wanted to do is change the splash screen or something of that sort

is a complete waste of time. And i can't give out a product that hasn't been fully tested, because if something goes wrong they cannot take orders or send orders to the system.

So yes, in my scenario it just doesn't work. If we had the skills, time, and money (as in hiring skilled enough developers and enough developers to handle our situation) it would but thats just not the case. Not to mention there isn't enough examples on swift yet for the junior developers.

Honestly, it starts with our company creating an office in india. Simple apps is ok, but with the time difference and the developers lack of business logic and work flow. its near impossible, not to mention they do not know how to properly maintain source codes and databases.

im pulling my hair out and going crazy. there goes my holidays.


Development has stalled to almost stand still.

I think this really points out a problem with the direction of software development.

Entry level programmers can bust out quick apps but lack the ability to do complex apps or even code that can be reused in complex apps. As the apps become more advanced, the value of entry level programmers fades.

This is exactly what happened back when C/C++ were the main languages. You couldn't get a job without several years background because they knew entry level programmers were of little or no value.

Apps become more advanced because of market demand and good routines that allow advanced programmers to be more productive.

Crappy code has no place in this world. Businesses need to think more long term, yet most go for the quick buck.

 

[eventailapp]

I would say that if you are starting iOS development just now then you should start by learning Swift. You will most certainly need to learn to read Objective-C, but it seems quite clear that Apple will continue improving Swift and relegate Objective-C to maintenance status.

So far there were no frameworks that are Swift-only but in my opinion this is just a matter of time. However be prepared to do some refactoring as others have stated, Swift's grammar is still a moving target.

 

[grandM]

Just wondering, what are the advantages of Objective C as opposed to Swift, and vice versa?

I read that if you are working for a company they generally expect you to have thorough knowledge of both; however, if you are an independent developer, what is more beneficial of knowing?

Thank you

I'd start out with swift. Once you are good at it you can decide if you still want to dive into objective-c.

 

[bjet767]

I'm a bit "old school" because I started with machine code and ended up in C and many of the variants. Personally I like the structure of Objective C and all its brackets and indents. For me, when the code gets a bit lengthy and complicated, it helps me remember where of the code is going.

The biggest reason to go to Swift is Apple is pushing it and many, if not most, of the coding examples are now being giving in Swift rathe than O C.

 

[1458279]

I'm a bit "old school" because I started with machine code and ended up in C and many of the variants. Personally I like the structure of Objective C and all its brackets and indents. For me, when the code gets a bit lengthy and complicated, it helps me remember where of the code is going.

The biggest reason to go to Swift is Apple is pushing it and many, if not most, of the coding examples are now being giving in Swift rathe than O C.

Not only the coding examples, but look at things being added Swift and NOT being added to ObjC.

It wasn't that long ago that ObjC was getting more and more C++ support and other areas of support. Now, that seems to be lagging.

I think ObjC is going to the back burner.

I was very much against this, but now I'm digging deeper into Swift and it's not that bad of a language.

 

[perlsyntax]

I starting to learn Swift and i start to like it.I learn Swift before i go to object C seem like swift is a bit easy then object C.I just hoping swift is going to be stable and not to many bugs in it.

Has anyone read the Big Nerd Ranch Swift programming book?

 

[bjet767]

One of the things I would like to see (or maybe it has already been implemented and I missed it) is the ability to put swift code inline with Objective C code, or the reverse.

The idea is this:

{
Objective C code;
swift code
objective C code;
}

The best of both worlds/syntax!

 

[1458279]

One of the things I would like to see (or maybe it has already been implemented and I missed it) is the ability to put swift code inline with Objective C code, or the reverse.

The idea is this:

{
Objective C code;
swift code
objective C code;
}

The best of both worlds/syntax!

I used a preprocessor to really change a language around. Some of the old "command line or statement based" languages would process into function calls by a preprocessor.

If you've ever seen a complex C program, you know it can get really complex.

This make me wonder, why can't we have C,C++,C#,ObjC, and Swift all inline?

I know it might get complex keeping track of memory things.

Can't even imagine how hard it would be to read some of that code

As far as Swift goes, I'm liking it now, but concerned about a split in the job market.

 

[firewood]

As far as Swift goes, I'm liking it now, but concerned about a split in the job market.

Yup. Swift seems to have killed Objective C popularity (TIOBE index, et.al.) much faster than Swift is rising in use. Apple may have killed its own mobile software dominance. Better isn't always best.

And mixing languages in-line would be a terrible mess: almost all the types and operators mean and do slightly different things between most 2 languages. Everyone (and maybe even the compiler and you ) would be confused what any extent code meant. It only works with Obj C because it's a *very* strict superset of C.

 

[1458279]

Yup. Swift seems to have killed Objective C popularity (TIOBE index, et.al.) much faster than Swift is rising in use. Apple may have killed its own mobile software dominance. Better isn't always best.

And mixing languages in-line would be a terrible mess: almost all the types and operators mean and do slightly different things between most 2 languages. Everyone (and maybe even the compiler and you ) would be confused what any extent code meant. It only works with Obj C because it's a *very* strict superset of C.

IMO, the "Apple may have killed it's own mobile software dominance" part is going to be tough to call at this point.
They might have fumbled with the interface to ObjC part and it's clear that Swift isn't fully baked yet, but maybe the gamble to get more starter programmers into the game, might pick up that slack.

I think it's a mistake for Apple to push one over the other. There's a TON of current code base in ObjC and little advantage to convert that code base for little or no actual gain.

IMO, the whole mobile industry is just getting started. It's like the PC industry after they introduced the Pentium chip. About that time it was seen as a real computer and not so much a toy.

 

[Dookieman]

My current opinion of Swift is that it is STILL not ready for prime time yet. Some basic 101 things still aren't working properly yet. I was starting to jump on the Swift bandwagon but now I'm hesitant as I got more familiar with the language.

e.g. Want to find the index of an object within an array of structs? Can't do it as is. You need to add the equatable extension to the struct class. I spent hours trying to figure out WHY I can't use the indexOf() method on the array. Maybe they wanted it this way, but there was ZERO indication of what was wrong, it gave some unrelated error that made no sense. This, in my opinion is something that should have been considered in 1.0, people use this all the time. Note: This only happens with pure structs, not a class of NSObject.

e.g. 2 You have an array of 10 items and want grab the items 7-9 (since it starts at 0). In Objective-C you can simply do something like NSArray *newArray = [oldArray subarrayWithinRange:NSRange: blah blah]; Works fine and as expected. In Swift? No. You get something called an ArraySlice which you can't assign to a new array. You have create a new array and typecast it to the ArraySlice before you can't use it as expected. Now maybe this done on purpose to give the dev TOTAL control but I doubt it. Most developers just want to grab objects 7-9 and create a new array. Again, the error was not obvious and took a lot of tinkering to finally figure out. Should have been 1.0 release.

This is basic 101 stuff Apple. You are trying to convince developers that Swift is the greatest thing and to drop Objective-C but Objective-C and other languages work as expected.