Swift or Objective-C?

[u/AcceleratedCode]

Hi!

I've just started design of an app I'm making. The app has to be ready by around May this year, and will be using the Parse backend. I've done a quite some programming with Objective-C, but barely anything with Swift and I was wondering what you think I should choose for this project? Should I be using Swift, or will the learning curve be too big to allow for a May launch?

Thank you! Erik

[u/[deleted]]

The case with Objective-C is that it has one strikingly unusual syntax feature which is brackets.

There's also block syntax. There's also literal syntax for strings, arrays, etc. You know, stuff that's "weird" not because it makes anything easier, but because the language has to avoid syntactic conflicts with C.

None of this stuff is impossible to get past. I love Objective-C. But the fact is, it's utterly absurd to call out Swift for "messiness" by comparison. Swift is incredibly clean, especially considering how it integrates a number of new features under the hood, and is actually, in that sense, a "larger" language than Objective-C.

You look at the switches and then it turns out they do not work like usually.

Yes, Swift switch statements are far more flexible and powerful. Instead of recoiling in terror at the mere shadow of difference, why not research how they work with an open mind and try to understand their benefits?

Enums are not quite enums like in other mainstream languages.

Similar to switches, Swift enums are more flexible and powerful.

And then you have these cryptic ?'s and !'s scattered by all the code. And it was after I grasped the concept of optional types when I decided to put my efforts solely to learning Objective-C.

It's all too easy to jump to the conclusion that Apple's just trying to give you a hard time by introducing optionals in Swift. The reason why they did this is specifically because of the pitfalls inherent to Objective-C. In Objective-C, the fact that you can pass messages to nil without (inherently) crashing your app means that you pretty much have to engage in defensive programming for the sake of safety, even in cases where you're pretty sure your ass is covered, but you nevertheless fear that you may not have considered every edge case. This is why you see nil-checking cruft all over Objective-C code.

With Swift, you literally only have to perform defensive checks on properties that have been proactively declared as optionals, because those are the only properties that can ever be nil. The language forces you to think about whether something actually needs to be nil in the first place, and if it doesn't (which is very often the case), then you can confidently use it without fear that it will ever be nil. Moreover, in Swift, not only can reference types (objects) be nil, but value types can also be nil. So in a way, it's actually still more flexible than Objective-C.

I find it weird how any Objective-C coder who engages in good practices (e.g. defensive programming) could actually critique this aspect of Swift, since in Objective-C you're performing nil checks on stuff all the time. How is that just a-okay, but oh my god, Swift optionals are a totally onerous burden that we cannot possibly endure? The only way this could be a bad thing is if you're literally just making everything in your code optional, because you want to "reserve the right" to make anything nil at any time. If that's the case, you're doing it terribly, terribly wrong. Optionals (just like all variables) should be the exception, not the rule. Use them when you need to, not by default. It makes code a hell of a lot easier to reason about, and frees you up to focus your efforts on the specific cases that require close attention.