[mdhughes]

As a Mac and iOS dev since 2005: For long-term survival and maintenance of your software, XIB and autolayout are slow toxins, and Swift is a swift-acting toxin. You won't be able to recompile your Swift code in a year. Or worse, it'll compile but be semantically different.

You won't be able to edit a XIB without fixing AL issues in 1-2 years, and the XIB will be unreadable in 5-10.

The part of Xcode that used to be Interface Builder is still useful for prototyping, but don't ship that!

Write complex UI in code. Autolayout strings in code aren't as bad as the obscure UI, but one can just as easily compute and set frames.

Choose any language except Swift.

Or, good luck with your walking-dead software.

[saagarjha]

Swift is slowly moving towards binary and source stability. Storyboards are more capable then they used to be–and they're literally XML. How can you make that unreadable?

[mdhughes]

Swift devs keep saying it'll get less fragile, then they rewrite "exceptions", or how strings work, or anything else and all your code has to be fixed line-by-line. I do not believe it'll be stable this decade.

Xcode stops supporting old features in XIB, or a class has a deprecated and then removed property, and the deserialization fails. XIB is not XML with a nice semantic DTD, it's an object serialization graph that happens to use XML.

[valuearb]

Nah, I switched to Swift at v1.0, the transitions have been relatively easy. Right now our app has 90k lines of code so Swift 3 was a day of work, but mostly automated.

Swift 4 is automatic. The trick to making the transitions easy is to not abuse the language with too clever code. Write clear, straightforward and easily msinatainavle code and it will rarely be broken.

[fleshweasel]

Ask Apple, who hide it from you in Xcode and riddle it with human-unreadable generated IDs and noise elements, in addition to needless reshuffling of elements after editing which overcomplicate your diffs and obscure the meaning of changes. Interface Builder in all its forms is indefensibly bad in execution.

[valuearb]

C++ and Objective C are like walking around with loaded shotguns aimed at your feet. It’s not a question of if you’ll blow your toes off but when.

I’ve written my highest quality apps in Swift. They virtually never crash. And updating my code once a year has been manageable, if not trivial most times.

[apple4ever]

C++ maybe, but not Objective-C.

I've written plenty of high quality apps in Objective-C. They virtually never crash. And I never have to update my code because the language changed.

Stick with Objective-C and abandon Swift.

[valuearb]

I spent 20 years in the Objective C world, and wrote my iOS apps in Objective C for nearly 5 years. If your apps virtually never crash you are an outlier, and you are working far too hard at it.

Swift's strong typing and optionals make it easy, fast and natural to write safe code, stuff I used to use masses of libraries to help me do in Objective C.

[mdhughes]

See also: https://mjtsai.com/blog/2017/11/09/enduring-xcode-and-source...

[rimliu]

Tell me more about being iOS developer since 2005. Swift and autolayout are god sent. Could not care less about storyboards. No, you cannot easily compute and set frames for all the cases covered by autolayout. You can compute, but not easily.

[mdhughes]

There's a computer called a Mac, and it's run OS X since 1999-2000, which was NeXTstep back to the 1980s, which is where Objective-C & Cocoa (NS = Next Step) come from.

I'm certainly better than average at geometry & visualizing a grid, but that's a skill most people can learn.

Those who do not learn history are doomed to be the butt of Santayana jokes.

[bsaul]

so, i your opinion, you'll find it easier to debug an objC project in 5years, than a swift one ?

i know companies that have trouble recruiting objc developers right now. i can't imagine how it's going to be like in 5 years.

[mdhughes]

Objective-C code from 30 years ago still compiles and works; many of the NS* APIs still used were stable by then. The tech whims of Kids Today™ don't tell you anything about long-term survival, because they haven't been alive as long as some of those codebases.

In 5 years, everyone doing Swift is either going to be rewriting their app for the 5th time, or switching to something less like quicksand.

[kitsunesoba]

>Objective-C code from 30 years ago still compiles and works; many of the NS* APIs still used were stable by then.

With the caveat of a huge pile of AppKit warnings and deprecations that will need to be fixed, and probably a number of Obj-C warnings stemming from llvm/clang being smarter than the gcc of 30 years ago.

This was my experience reviving an OS X 10.1-era project. It compiled and worked, but its warning+deprecation count was ridiculously high for the project size that the effort involved in fixing it all was scarcely (if at all) better than migrating to a major new version of Swift, and honestly it probably would've been better for a lot of those warnings to have been errors given how long the involved APIs had been deprecated.

I've also migrated a moderately complex app from Swift 3.2 to Swift 4. The transition was painless and amounted to little more than a couple dozen lines changed across the project. Most of it didn't change at all. There's no way that Swift users are going to be rewriting their apps once per year, especially if the UI and logic in these projects are reasonably well separated.

[valuearb]

Objective C apps will still be plagued by wild pointer issues and crashes 5 years from now, Swift apps won’t.

[apple4ever]

Since they aren't now, they won't be in 5 years either.

Swift apps won't be maintainable because it makes writing clever code so easy, so nobody will understand them.

[valuearb]

It's like, the opposite of what you wrote. Swift apps are much higher quality than Objective C apps today. I know because I write large commercial apps for a living and wrote in Objective C and object oriented C for 20 years.

There are too many ways to blow up your app from C. A disciplined developer who uses safe libraries/classes to shield themselves from dealing with naked pointers can succeed at making an Objective C app reasonably stable, but it's really hard.

Swift was designed to protect you from wild pointers. All you have to do is NEVER FORCE UNWRAP and 90% of the typical crashers can't happen. Our current app is 90,000 lines of Swift. It's been relatively easy to maintain and update with Swift versions, and it almost never crashes. Our crash rate is in the top 10% of Social Media apps.

You don't have to write clever code in Swift. Just use the strong typing and optionals, the language is succinct and powerful and you can be very productive (outside of compile times). Swift is the professional tool for building iOS apps, Objective C is fading away.

[bsaul]

stability is also helped by stagnant functionnalities. Swift is only 4 yo and aims at "total domination" aka both server client and system dev. it's perfectly fine for it to keep evolving, as long as it hasn't stepped a solid foot in each domain it's aiming at.

objc otoh isn't good and will never be good for anything other than appleOS development. i don't think betting on that tech today makes any sense. it lived a revival thanks to iOS , and it'll probably die when that platform has completed moving to swift.

[mdhughes]

OS X, iOS, and all new APIs consumed by Swift on those platforms are written in Obj-C or C++, never in Swift. So what's "stagnant"?

It's true that few others have adopted Objective-C, GNU & MS occasional efforts aside. Which is why I keep a number of languages in practice.

But fragile, power-hungry, slow-compiling Swift isn't going to beat out stable Java, or easy JS or PHP on servers, and outside iOS/OS X, building desktop software needs UI toolkit support and stability.

Which is my point: Building in Swift is total technical debt.

[bsaul]

i guess it all comes down to whether you believe swift is going to get better with time and solve its current issues ( the ones you mention),or if it's inherently a bad design. I'm betting on compilation speed and fragility improving a lot in the next two years. What matters to me is that the language type system is among the best ( enums and optionals) , and the general feeling when coding with the language is a real joy.

For objc, however I've never been able to say anything better than "i got used to it".

[apple4ever]

> Which is my point: Building in Swift is total technical debt.

That's the truth. Swift makes it easy to build clever, unmaintainable code.

The beauty of Objective-C is it is readable! And then easily maintainable.

[Apocryphon]

So does that mean that Objective-C will become like COBOL?

[apple4ever]

> Choose any language except Swift.

Bingo. Swift is terrible.