6 ms·

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.

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 9y ago
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 9y ago
  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 9y ago
    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.
- deleted 9y ago
  [deleted]
- fleshweasel 9y ago
  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.
bsaul 9y ago
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.
- Apocryphon 9y ago
  So does that mean that Objective-C will become like COBOL?
- mdhughes 9y ago
  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.
  - bsaul 9y ago
    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 9y ago
      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.
rimliu 9y ago
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 9y ago
  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.
valuearb 9y ago
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 9y ago
  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 9y ago
    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.
thopkinson 9y ago
you're trolling with the anti-swift stuff right?
mdhughes 9y ago
See also: https://mjtsai.com/blog/2017/11/09/enduring-xcode-and-sourcekitservice-problems/ https://mjtsai.com/blog/2017/11/09/enduring-xcode-and-source...
apple4ever 9y ago
> Choose any language except Swift. Bingo. Swift is terrible.

saagarjha 9y ago

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 9y ago
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 9y ago
  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.
deleted 9y ago
[deleted]
fleshweasel 9y ago
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.

bsaul 9y ago

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.

Apocryphon 9y ago
So does that mean that Objective-C will become like COBOL?
mdhughes 9y ago
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.
- bsaul 9y ago
  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 9y ago
    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.

rimliu 9y ago

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 9y ago
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.

valuearb 9y ago

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 9y ago
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 9y ago
  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.

thopkinson 9y ago

you're trolling with the anti-swift stuff right?

mdhughes 9y ago

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

apple4ever 9y ago

> Choose any language except Swift. Bingo. Swift is terrible.