iOS Objective C vs Swift

[throAU]

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

There is a lot more existing objective-C code out there.

That's the advantage of knowing Objective-C.

All that existing code isn't going to magically disappear and suddenly be replaced by swift, and if you're a developer getting paid by someone else to write/maintain code you'll likely be dealing with a lot more old objective-C code than swift.

The only (fully) swift code you'll find will be in new projects.

 

[firewood]

With Objective C and Swift, iOS development is sort-of in a scr*wed state right now. All the newbie tutorials and new API docs are in Swift. But a full-featured app needs to use a lot of iOS APIs that have been around for a long time. And all the example code and expertise (e.g. the answers on various forums to gnarly questions that you will run into) for this stuff is in Objective C. So, unless you are doing something trivial, you will end up mixing and matching, or not finding out how something should be coded in either language at all.

 

[Mascots]

With Objective C and Swift, iOS development is sort-of in a scr*wed state right now. All the newbie tutorials and new API docs are in Swift. But a full-featured app needs to use a lot of iOS APIs that have been around for a long time. And all the example code and expertise (e.g. the answers on various forums to gnarly questions that you will run into) for this stuff is in Objective C. So, unless you are doing something trivial, you will end up mixing and matching, or not finding out how something should be coded in either language at all.

It's not as hard as you're making it out to be. Any programmer who is willing to put in the effort has much more complicated hoops to jump through

 

[1458279]

In addition to the above:

ObjC is also C and C++ compliant

Produces much smaller app download size, I've hears Swift produces 3X larger app size.

Fewer problems with things like Core Data where things really aren't ironed out yet.

Known language, Swift is clearly redefining itself after nearly 2 years.

Imagine those that jumped in at the start. They'll have to go back and change all the ++ and For-Next loops. All for what? Is there a performance gain?

Another issue goes to the real heart of programming larger apps. If you have a large app, you probably already worked out database, threading, etc. If you've done several larger apps, you might have a known good code base already done.

Now, you'd have to dump all that, learn something new. What gain would you have?

Also, you have the issue if they are willing to redefine basic things like a For-Next or ++, what else are they willing to redefine and what are the standards for something to be redefined?

What if I don't like the == ? Can I have that redefined? Is a business really going to invest in a platform that would redefine things on a whim that has zero benefit to them?

 

[Mascots]

Transition. We could back and forth citing benefits and negatives to Swift and the fallible transition, but that doesn't change anything at all; Swift has had major adoption on iOS and has backing among all of the major players, small and large including those producing frameworks to those writing documentation for newer developers to pick up. And for good reason.

While you may see it as questionable, which is totally acceptable given the foundational change and prior experience, we are two years down this path of Swift and nearing a decade of aggressive expansion of the iOS frameworks. Apple doesn't offer backwards compatibility, as people would like think, but transitional states of which they have a golden star track record and Swift's interoperability with Objective-C is a signature. If it was any other way, I may find myself at a different side of the fence. But, the state of the development is clear and has always been.

There's momentum and with that comes trades offs, but Apple is looking down the road and the bumps along the way are sustainable and worth the end goal in their eyes. I agree.

For now, if those negatives really are too much for you, stick with Objective-C; there's a reason why it is still paralleled with Swift. However, I think you'd be kidding yourself by sticking your head in the dirt and completely trying to ignore Swift. It's a part of iOS just as UIKit.

 

[1458279]

Transition. We could back and forth citing benefits and negatives to Swift and the fallible transition, but that doesn't change anything at all; Swift has had major adoption on iOS and has backing among all of the major players, small and large including those producing frameworks to those writing documentation for newer developers to pick up. And for good reason.

While you may see it as questionable, which is totally acceptable given the foundational change and prior experience, we are two years down this path of Swift and nearing a decade of aggressive expansion of the iOS frameworks. Apple doesn't offer backwards compatibility, as people would like think, but transitional states of which they have a golden star track record and Swift's interoperability with Objective-C is a signature. If it was any other way, I may find myself at a different side of the fence. But, the state of the development is clear and has always been.

There's momentum and with that comes trades offs, but Apple is looking down the road and the bumps along the way are sustainable and worth the end goal in their eyes. I agree.

For now, if those negatives really are too much for you, stick with Objective-C; there's a reason why it is still paralleled with Swift. However, I think you'd be kidding yourself by sticking your head in the dirt and completely trying to ignore Swift. It's a part of iOS just as UIKit.

I started out very negative about Swift at the start. I thought it was an answer to a question nobody asked. Moreover, I didn't see that it had a clear advantage that couldn't have been achieved another way that would have offered less downside.

However, I'm learning it and liking many parts of it.

That doesn't aside the fact that some of these changes just don't add up. They made ++ and For-Next a part of Swift and then decided to take them out on a whim. Independent of how much that'll cost or save, there is still the issue of changing something without really considering the impact.

AFAIK, For-Next has been around for a very, very long time. There didn't seem to be a problem with it, I've never heard a complaint about it. Now, they want to change it. Will the change actually make a program faster, more readable?

One of the things that made C/C++ last so long is that no one controlled it. It didn't change just to change. It went thru a process and IIRC, was voted on and I can't think of any changes that didn't offer some real positive value, but most importantly was being backward compatible.

I remember when Windows XP had a problem not long ago and most didn't realize that many systems still used it. I think it was ATMs that used it. Mobile may be new and changing, but having stable standards is certainly a plus.

 

[throAU]

Known language, Swift is clearly redefining itself after nearly 2 years.

Imagine those that jumped in at the start. They'll have to go back and change all the ++ and For-Next loops. All for what? Is there a performance gain?

Well yes, but i would wager that adjusting syntax (which xcode can help with) is less painful than debugging memory problems and auditing code for security issue due to pointer mis-use...

swings/roundabouts.

 

[1458279]

Well yes, but i would wager that adjusting syntax (which xcode can help with) is less painful than debugging memory problems and auditing code for security issue due to pointer mis-use...

swings/roundabouts.

Is there a memory problem or pointer mis-use with For-Next that I don't know about?

 

[throAU]

Is there a memory problem or pointer mis-use with For-Next that I don't know about?

Not talking about for-next.

Talking about swift being inherently safe vs. objc being inherently unsafe.

 

[1458279]

Not talking about for-next.

Talking about swift being inherently safe vs. objc being inherently unsafe.

Ok, I can see that, but we really need a language that's stable both with pointers and syntax changes. If it doesn't need to be changed, don't change it.

I remember Java and C# were doing safer pointers as well, great idea. Like I said, Swift isn't all bad.

Language is actually a special thing for programmers, it seems the amount of time it takes to learn might have something to do with it or maybe it's like sports teams IDK.

 

[Mascots]

Well, for can be completely replaced by for-in and stride, that's the reasoning behind it. At this point, it really was a construct added for the sake that languages normally have a similar construct, just like incrementers. And with those also gone, there is no reason to really maintain that standard of looping. They're both vestigial in Swift.
As noted in the Github:

A search of github's Swift gists suggests the approach is used primarily by those new to the language with minimal language skills and is abandoned as language mastery is achieved.

For fun, I saw that I was using it a grand total of twice across two applications, and each time my usage could be replaced by something that makes more syntactical sense. I also particularly enjoy the example they posted in the proposal.

 

[PhoneyDeveloper]

FWIW, I think that I use the decrement operator more in the for loops. The swift syntax for backwards iteration seems clunky to me.

But I'll live with it. As long as I can get my work done and there aren't a ton of traps for the unwary. Like these:

https://developer.ibm.com/swift/2016/01/27/seven-swift-snares-how-to-avoid-them/

 

[firewood]

Is there a memory problem or pointer mis-use with For-Next that I don't know about?

Actually, yes. The 3 element C-style for-loop allows almost arbitrary code inside a for-loop's test expression and update statements (e.g. the step update value might not be a constant, but could legally be a weird expression that accesses an aliased or bad pointer.)

The Swift 3 compiler won't need to check for such nonsense, and thus can possibly optimize the loop better.

for (i=0;i<5;i+=(3 - **x)) {
if (foo()) { i -= 4; *x = bar(); } else { i += *z; }
a += i;
}​

 

[lympero]

If you are familiar with Java or c# for example then learning swift should be much easier than objective c in my opinion.

 

[1458279]

If you are familiar with Java or c# for example then learning swift should be much easier than objective c in my opinion.

Couple of issues here. Swift does seem to be easier at the start, but some have pointed out that advanced Swift code is not easy. There's been a few examples given, but I haven't gotten to that point in Swift yet.

Second issue is what can be done in Swift that can't be done in C# or Java? Is there something that programmer haven't been able to do in Java/C#?

Now, the counter to that would be that Swift isn't bringing new capabilities to the ball game, but it's bringing safer, easier code to read.

My counter to that is code reuse. The real gain in computer programming isn't a more readable, safer quick sort, it's that we don't see the quick sort any more.

How many here have actually dug into the code to see how Apple does it's quick sort? [cricket sound here] ... ok, why hasn't anyone dug into Apple's quick sort?

A. Because we don't need to. It just works.

You really don't need to know how Apple does the corner flip animation, you just need to know how to use it. If we wrote more code like that, we'd see less code like that.

The goal should be to dig into Apple's quick sort and therefore make it more readable, it should be to make it work and leave it alone. Move on to a higher level of programming where you are selecting things that are already tried and tested.

Swift brings nothing to the ball game that the ball game didn't already have. The easy part would have been to see less of the under the hood code and more of the business logic that gets the job done.

It's a kinder, gentler knife being brought to a gun fight.

 

[firewood]

Second issue is what can be done in Swift that can't be done in C# or Java?

... brings nothing to the ball game that the ball game didn't already have.

Everything can be done in assembly language. What does any high level language bring? They're all Turing complete! Let all go back to coding in Basic with 6502 pokes.

 

[1458279]

Everything can be done in assembly language. What does any high level language bring? They're all Turing complete! Let all go back to coding in Basic with 6502 pokes.

Ok, there's one in every crowd I'll point out that C#, Java, and Swift are all at the same level or generation.

 

[eventailapp]

Ok, there's one in every crowd I'll point out that C#, Java, and Swift are all at the same level or generation.

They might be, but each language lugs along its legacy and Swift has the least of it. Also, for now, Swift developers do not fear breaking old code compatibility so there is still time to remove some useless cruft (as the before-mentioned for loops and increment/decrement operators).

For now, I find 'idiomatic' Swift code more readable than its Java counterpart (for example function calls without named parameters are appalling).

 

[1458279]

They might be, but each language lugs along its legacy and Swift has the least of it. Also, for now, Swift developers do not fear breaking old code compatibility so there is still time to remove some useless cruft (as the before-mentioned for loops and increment/decrement operators).

For now, I find 'idiomatic' Swift code more readable than its Java counterpart (for example function calls without named parameters are appalling).

Ok, good point. Didn't see that until you pointed that out. Swift does have the leg up on that. Maybe I have a slight 'new kid on the block' problem.
I'm actually liking most of Swift after having gone thru more of it. Maybe I've got a bit of a chip on the shoulder about having to learn yet another language.

 

[AxoNeuron]

They might be, but each language lugs along its legacy and Swift has the least of it. Also, for now, Swift developers do not fear breaking old code compatibility so there is still time to remove some useless cruft (as the before-mentioned for loops and increment/decrement operators).

For now, I find 'idiomatic' Swift code more readable than its Java counterpart (for example function calls without named parameters are appalling).

Whoever though of functions without named parameters needs to be shot. Multiple times. Hopefully in non critical areas of the body so that I can enjoy it longer.

 

[1458279]

Whoever though of functions without named parameters needs to be shot. Multiple times. Hopefully in non critical areas of the body so that I can enjoy it longer.

I didn't think of it, but have used it for many years and until now, never really had a problem with it. However, now that you mention it, it can get cumbersome to have to look up so many API calls.

 

[Hagrid]

1. You could develop mobile web apps for the original iPhone 2G 8+ years ago.

2. But some of us started doing mobile software development with PalmOS (or even PocketPC/WinMob, Brew, or Symbian). C code and 68000 asm using Metrowerks CodeWarrior on Mac OS 9. That's 11+ years more then you newbies for the resume.

3. And Apple Newton developers have even that beat. Integer Basic to NewtonScript to Swift anyone?

I still have my copy of CodeWarrior - both discs and manuals

 

[eventailapp]

Looks like someone wrote a book just about functional programming in Swift
https://www.objc.io/books/functional-swift/

I've got the book, thanks for the tip. So far the content seems quite nice although the beginning is quite basic. One criticism I would have is that the printed book is not of very nice quality.

 

[firewood]

... when you implement it into your current projects with junior programmers in india and you need to reach your deadlines ...

This is a management mistake, and a recipe for disaster using any programming language, even with one in which the offshore programmers claim they have some experience. Requiring the use of a new cleaner programming language, where they can't just recycle a heap of cr*ppy dated legacy code into your solution may actually create an advantage over the long run.

 

[loon3y]

This is a management mistake, and a recipe for disaster using any programming language, even with one in which the offshore programmers claim they have some experience. Requiring the use of a new cleaner programming language, where they can't just recycle a heap of cr*ppy dated legacy code into your solution may actually create an advantage over the long run.

Interesting, you think it would work? but the updating of the swift syntax just scares the hell out of me.


I'm going through hell right now, working 9AM-2AM visiting the customers during day and working at night with the india office (only 4 guys in USA now, 2 in LA, 2 IN NYC)

Version control is an issue, i mean simple grammar mistakes, cosmetics, no close button if you open something (just an example of the scenarios)

I mean it was just crazy, spaghetti code in our iOS and I have to support our ERP system customers, EDI, wholesale website, retail website, retail app , itradeshow app. All of which is a good foundation and good database with web services, but boy does the front end of everything needs work.


I'm losing my mind and I'm fighting day and night against swift with the owner/boss. because it stalled development for 2 years maintaining it. I mean not completely but we wasted the majority of the time updating swift and testing making sure the functions we already have worked.


Not to mention there isn't much swift help on the internet (might be more now), what should i do? We're undermanned as it is and its very hard to explain business logic to our indian programmers.

And we sell software to the fashion business with all those sizes, reports, shipping scenarios.

At this point I'm just venting, but yeah dude you really think so? Based of my experience my overseas iOS team is going to spend half the time learning.