iOS Learn Objective-C or Swift?

[klamse25]

Here is my background:
I have a good amount of experience working with C++.
I want to get into iOS development, but I'm conflicted.

Should I learn Objective-C right now? I already have a great book about it right now, but I'm afraid the language will become outdated with the release of swift.

Or should I wait until there are good books for Swift out? I see there are several books available for preorder on Amazon. But if I wait for them to come out, I will have lost valuable time I could have spent learning iOS development.

What should I do?

 

[Dookieman]

Here is my background:
I have a good amount of experience working with C++.
I want to get into iOS development, but I'm conflicted.

Should I learn Objective-C right now? I already have a great book about it right now, but I'm afraid the language will become outdated with the release of swift.

Or should I wait until there are good books for Swift out? I see there are several books available for preorder on Amazon. But if I wait for them to come out, I will have lost valuable time I could have spent learning iOS development.

What should I do?

Learn Objective-C for now and move on to Swift once it gets more stable and better coding guidelines are in place.

Xcode and Swift still don't play the greatest together, in my experience. There is still limited examples of how to do things in Swift compared to Objective-C, which has endless tutorials and answers to common questions.

Swift seems to be the direction Apple is headed, but learning Objective-C is in no way setting yourself back. All the APIs still use Objective-C so you'll be more familiar with it in the future.

 

[AxoNeuron]

Agreed. And every third party framework I've seen like Parse is still in objective c. Swift is great but Objective-C is awesome in my opinion. I appreciate the fact that since Objective-C is a superset of C, it will make learning C++ easier so that's another bonus. Since you already have experience in C++ I imagine you could learn Objective-C relatively painlessly, and it's easier to learn Swift when you know objective c.

 

[ArtOfWarfare]

Agreed. And every third party framework I've seen like Parse is still in objective c. Swift is great but Objective-C is awesome in my opinion. I appreciate the fact that since Objective-C is a superset of C, it will make learning C++ easier so that's another bonus. Since you already have experience in C++ I imagine you could learn Objective-C relatively painlessly, and it's easier to learn Swift when you know objective c.

Parse is available in both Objective-C and Swift, I think. They have examples in both languages.

 

[AxoNeuron]

Parse is available in both Objective-C and Swift, I think. They have examples in both languages.

Good point. I think most of it is available in Swift now. But it looks like you still need an Objective-C bridge file to import the parse framework in to the project.

Asides from Parse though there are thousands of frameworks and API's that don't exist in Swift yet.

 

[1458279]

Agreed. And every third party framework I've seen like Parse is still in objective c. Swift is great but Objective-C is awesome in my opinion. I appreciate the fact that since Objective-C is a superset of C, it will make learning C++ easier so that's another bonus. Since you already have experience in C++ I imagine you could learn Objective-C relatively painlessly, and it's easier to learn Swift when you know objective c.

Parse wouldn't have a reason to drop ObjC, it's a product that already works, even if they support Swift, they would still have no good reason to kill a product that already works for many people.

I wonder if there will ever be a reason for a 3rd party to "move over" to Swift. If Swift and ObjC can be used in the same app, what reason would someone have for converting something from ObjC to Swift?

I could see a wrapper for syntax or something like that, but 3rd party calls would be in ObjC or C and would work just the same, unless I'm missing something.

I remember some older pre-processors that would take command based languages and convert them to functions in order to make it easier for some to read.

 

[ArtOfWarfare]

Parse wouldn't have a reason to drop ObjC, it's a product that already works, even if they support Swift, they would still have no good reason to kill a product that already works for many people.

I wonder if there will ever be a reason for a 3rd party to "move over" to Swift. If Swift and ObjC can be used in the same app, what reason would someone have for converting something from ObjC to Swift?

You'd ditch it for the same reason that old code written in COBOL (for example), which still works perfectly fine, is moved over to other languages - there's a dwindling number of people who are still fluent in the language, meaning that maintaining it is becoming more difficult.

That's obviously not the case with Obj-C right now, but within a decade I expect there will be more programmers familiar with Swift than Obj-C and those that know Obj-C will be a dying breed, thus people will be shifting old Obj-C code over to Swift.

 

[AxoNeuron]

Parse wouldn't have a reason to drop ObjC, it's a product that already works, even if they support Swift, they would still have no good reason to kill a product that already works for many people.

I wonder if there will ever be a reason for a 3rd party to "move over" to Swift. If Swift and ObjC can be used in the same app, what reason would someone have for converting something from ObjC to Swift?

I could see a wrapper for syntax or something like that, but 3rd party calls would be in ObjC or C and would work just the same, unless I'm missing something.

I remember some older pre-processors that would take command based languages and convert them to functions in order to make it easier for some to read.

Yep, that's what I am saying. Parse isn't dropping Objective-C any time soon.

 

[dejo]

If Swift and ObjC can be used in the same app, what reason would someone have for converting something from ObjC to Swift?

That's the case for now. Who knows if Apple will decide to deprecate Objective-C at some point.

 

[1458279]

Correct me where I'm wrong, (I've never written a compiler)... compiled programming languages are in layers that "boil down" to machine code.

Example, some languages in the past would let you see the preprocessor output, you'd see your commands/function calls/etc... converted (processed) into something the compiler wanted to see.

Most well-followed development systems maintain a high level of backward compatibility. Usually this is determined by market demands. Is anyone making non-retina only version of their apps? With Apple, the market tends to jump on the latest pretty quick, but in the Swift V ObjC, you have a perfectly functional language already in use.

If you look at the advancements that we would want, they have little to do with the language and more to do with the APIs.

Apple made a pretty strong effort to allow more C++ code to work in Xcode, it seems they simply wanted to get more people into app dev. They didn't need to add more C++ support, but they did.

It seems clear that Swift is designed to reduce the time it takes to learn programming languages and is a great idea, because app development is more about learning APIs and designing better apps.

People don't buy (download) apps for the code, they don't see the code, they don't care... It could be written in Unity, Swift, ObjC, Cobol or all zeros and ones... they only see what the app does and how it does it.
Apple sees that, and is looking long term.

 

[nomore]

Swift looks great at first, but the lack of implicit type conversion will probably drive you crazy.

 

[iizmoo]

That's the case for now. Who knows if Apple will decide to deprecate Objective-C at some point.

If Apple was going to fully support Objective-C going forward, they wouldn't have bothered spending the time and effort to create Swift. They can start by very gently nudging us by releasing Swift only APIs a year or two down the road, within 5 I could see Apple forcing a significant conversion with the API.

OP, if you already know C++ well, it shouldn't take you more than a weekend or two to get going with Objective C. The big learning bit is in understanding the API concept and names, which is translatable into either Objective C or Swift. If you get it in one, shouldn't take you too long to convert to the other.

Swift has some instabilities right now, but that's affecting everyone, by the time they get the language and API stabalized, it'll be next year and you'll know enough IOS programming to actually deal with those small little nuance issues.

 

[firewood]

I wonder if there will ever be a reason for a 3rd party to "move over" to Swift. If Swift and ObjC can be used in the same app, what reason would someone have for converting something from ObjC to Swift?

For certain types of code (tons of base class method calls, etc.), Swift will produce faster (thus lower power, better for battery life) apps.

However, the Swift dev tools aren't stable, complete or well optimized yet, so the best path for a C/C++ programmer is to learn Objective C with ARC and the Apple frameworks first, as a good base for much of what one will need to know to eventually build apps in Swift.

 

[1458279]

If Apple was going to fully support Objective-C going forward, they wouldn't have bothered spending the time and effort to create Swift. They can start by very gently nudging us by releasing Swift only APIs a year or two down the road, within 5 I could see Apple forcing a significant conversion with the API.

Can they actually make APIs that are swift only? As I understand APIs, they are classes / methods that boil down to C functions.

In other words, you can write a full app right now in C, not just because ObjC is a super set of C, but because C is what is under the hood.

In fact, isn't OOP more about rules that the compiler enforces than anything to do with what the compiler puts out?

Methods are functions, classes are structures with rules.

Isn't it just a layer there to help programmers make better code?

Back in the old days, reading someones code was much more of a chore. Even if they made rules, they weren't always followed.

They came up with rules: naming conventions, strong data typing, etc...

So OOP make a programmer follow the rules, but in the end, it all gets boiled down to what the chip can read.

If Swift now supports everything ObjC supports in terms of API calls, then I don't see how they could rework the APIs so the ObjC is no longer supported.

They could, although, stop major upgrades to ObjC... They've improved a number of much needed things and it's C++ support has never been better, so what more do we really need?

Computer languages are like written languages (English, French, etc). You can write a book in English just as you could in French or Latin. At some point, you have plenty of verbs, nouns, etc... the real issue is more the story line of your book or factual research or plot and less about what the language offers.

 

[qweenapps]

In your place I would start with Objective-C is more closer to c/c++. A lot of frameworks and snippets/forum questions are still in Objective-c. And the system architecture of IOS stays the same with objc-c or swift. Building app experience is important then you can switch any time quite easy.

Don't be afraid that it will be deprecated (it won't be that soon). In programming you are "never a master" new stuff are constantly coming will come and go so we need to adapt/learn. As you can see yearly a new IOS is released new apis/frameworks/game frameworks/things/resolutions etc. As the time is passing you will catch up language quite quickly.

Just my two cents
Good luck!

 

[iizmoo]

Can they actually make APIs that are swift only? As I understand APIs, they are classes / methods that boil down to C functions.

In other words, you can write a full app right now in C, not just because ObjC is a super set of C, but because C is what is under the hood.

In fact, isn't OOP more about rules that the compiler enforces than anything to do with what the compiler puts out?

Methods are functions, classes are structures with rules.

Isn't it just a layer there to help programmers make better code?

Back in the old days, reading someones code was much more of a chore. Even if they made rules, they weren't always followed.

They came up with rules: naming conventions, strong data typing, etc...

So OOP make a programmer follow the rules, but in the end, it all gets boiled down to what the chip can read.

If Swift now supports everything ObjC supports in terms of API calls, then I don't see how they could rework the APIs so the ObjC is no longer supported.

They could, although, stop major upgrades to ObjC... They've improved a number of much needed things and it's C++ support has never been better, so what more do we really need?

Computer languages are like written languages (English, French, etc). You can write a book in English just as you could in French or Latin. At some point, you have plenty of verbs, nouns, etc... the real issue is more the story line of your book or factual research or plot and less about what the language offers.

All into assembly, or Intel x86-64 if you want to abstract it enough. But still, completely different compilers with different rules on optimization and auto memory management. Swift is not an extension of Objective-C, it's something Apple want to be able to play with at their pleasure. Just because you can have the API in 2 languages (or more), doesn't mean you'd always want to support that.

I didn't say they would re-work existing APIs, but I could see new kits or API coming out where Apple would drop the duality. It doesn't make business sense for them to support Objective C with future releases given that their PR push is to get people into the Swift ecology.

 

[1458279]

All into assembly, or Intel x86-64 if you want to abstract it enough. But still, completely different compilers with different rules on optimization and auto memory management. Swift is not an extension of Objective-C, it's something Apple want to be able to play with at their pleasure. Just because you can have the API in 2 languages (or more), doesn't mean you'd always want to support that.

I didn't say they would re-work existing APIs, but I could see new kits or API coming out where Apple would drop the duality. It doesn't make business sense for them to support Objective C with future releases given that their PR push is to get people into the Swift ecology.

That brings up a great point that I forgot about... Back in the old days, they had benchmarks for compilers... I bought the Wacom compiler which was known as producing the fastest programs.

Apple can control the output of the compiler or make a new compiler (they might have already done that) such that Swift apps run faster than ObjC apps...

If that's the case, and Swift has all the functionality of ObjC, that would change things.

I've heard Swift will be or is faster, but I haven't dug into it to see if it actually produces a faster overall general purpose app... Meaning that it's not just for games, but for all programs.

I'm a bit biased because I don't see these devices as content consumers or as game-only devices... I see them as computers for business apps, that also play games

 

[forcesteeler]

If Your New To Programming Learn Swift

If you already know C++, I would just Learn Objective C. It will take Years if Not Decades Before Swift Become Defacto Language.

 

[gbkrip]

Popular opinion among current iOS developers will tell you to learn Obj-C. There are some valid reasons to start with Obj-C like availability of third party tools that simply don't exist in Swift and learning Obj-C will teach you some important underlying programming concepts which Swift abstracts. However, I think for learning the IDE and the general process of iOS development, the much more intuitive syntax of Swift makes it a considerably better starting point.

 

[iizmoo]

That brings up a great point that I forgot about... Back in the old days, they had benchmarks for compilers... I bought the Wacom compiler which was known as producing the fastest programs.

Apple can control the output of the compiler or make a new compiler (they might have already done that) such that Swift apps run faster than ObjC apps...

If that's the case, and Swift has all the functionality of ObjC, that would change things.

I've heard Swift will be or is faster, but I haven't dug into it to see if it actually produces a faster overall general purpose app... Meaning that it's not just for games, but for all programs.

I'm a bit biased because I don't see these devices as content consumers or as game-only devices... I see them as computers for business apps, that also play games

I think an issue is optimization marking in the syntax. With C/C++ and by extension Objective-C, there was only so much you could to at the optimization level, and the languages were fast enough most of us didn't care. With Swift, and the ability to control language & compiler, it open avenues to mark special syntax that behave in completely unique ways allowing for more granular optimizations.

It's a wonderful language, I'm loving not having to ; at the end of every statement

 

[Barna Biro]

With Swift, and the ability to control language & compiler, it open avenues to mark special syntax that behave in completely unique ways allowing for more granular optimizations.

I think you're mixing some stuff up and because of this, you're using incorrect terms to describe how you feel about Swift. How exactly does Swift allow you to "control the language & compiler"? Are you referring to the "extensions" feature? Or were you trying to say that you like it because you can achieve the same thing with less code than before? ( just as you pointed out that you like not having to terminate things using a semicolon ) That's all cool, but neither has anything to do with "optimization"...

Optimization is an act, process or methodology. The degree of optimization that one can achieve has more to do with the abstraction level of the given programming language and the aptitudes of the individual attempting to perform the optimization. From this point of view, Swift is no better than its predecessors... Generally speaking, the higher level a programming language is, the more limited you usually are... BUT, the easier your life usually gets - programming-wise - because you don't have to worry about many things that other smart people have already thought about and abstracted away... letting you focus on doing other things instead.

 

[Pootan]

Because swift is fairly new, someone with experience, perhaps like your self can start creating tool sets and libraries. Potentially lucrative, definitely helpful for learning.

 

[iizmoo]

I think you're mixing some stuff up and because of this, you're using incorrect terms to describe how you feel about Swift. How exactly does Swift allow you to "control the language & compiler"? Are you referring to the "extensions" feature? Or were you trying to say that you like it because you can achieve the same thing with less code than before? ( just as you pointed out that you like not having to terminate things using a semicolon ) That's all cool, but neither has anything to do with "optimization"...

Optimization is an act, process or methodology. The degree of optimization that one can achieve has more to do with the abstraction level of the given programming language and the aptitudes of the individual attempting to perform the optimization. From this point of view, Swift is no better than its predecessors... Generally speaking, the higher level a programming language is, the more limited you usually are... BUT, the easier your life usually gets - programming-wise - because you don't have to worry about many things that other smart people have already thought about and abstracted away... letting you focus on doing other things instead.

I was referring to Apple controlling both the language and creation of the compiler and their ability and willingness to change it on a whim if they want/need to.

We were talking about language & compiler level optimization in term of speed vs objective C and other languages and what give Swift some of it interesting performance curves, not engineering level optimization.

My comment on ; was purely personal annoyance, nothing whatsoever to do with optimization or performance. I just hate ;

 

[kage207]

If Your New To Programming Learn Swift

If you already know C++, I would just Learn Objective C. It will take Years if Not Decades Before Swift Become Defacto Language.

You really think Apple will let that happen?

 

[1458279]

Swift doesn't have to become anything more than a language that works.

There's two issues here:

1. Swift working to develop apps for iOS

2. Swift being adopted by the software dev world. This has a direct impact on jobs, books, 3rd party support, etc...

Indie developers have a bonus if they play their cards right. They can put out an app and hope for the best and if it fails, they could have high demand skills for a great job.

If they select Swift and if it never gets adopted by the industry, those skills are going to be less marketable.

It'll probably take a while before we know how the industry adopts Swift, or even if they do.

If someone cares about jobs, they could monitor the job boards and see how ofter Swift comes up.

One upside to Swift is that you'd be spending less time learning syntax and more time learning APIs and Xcode and other things.