GOD ALMIGHTY I HATE SWIFT & XCODE...

Why the fuck does it take a horrendous amount of time to muck about with layout constraints. Why the heck does xcode choose to add constraint layouts to elements that already have pissing constraints! Why does dealing with something as trivial as tables have to be so god damn fucking involved when HTML and CSS let me create and style tables in fuck all lines.

And what the hell is up with how pissing long xcode takes just to figure out that 1 extra line of code I've just added. You jump to another file and xcode finally decides to be an ide again and bitch at the fact that you've forgotten to add some parameter or that they've decided to rename paramter "x" since version fuck nows what.

Working with abstract classes is fun, lets use protocols (because interfaces are too old school) and then lets tack on something we call extensions and then lets make people piss about with convenience initializers.

And lord almighty, what the fuck is up with casting, what all this ?! BS. What's wrong with just checking if the value is null in the first place, or whats wrong with giving something an initial value, oh because having to unwrap shit is more elegant right??

And good god, I need to own a fucking cinema screen just to have the storyboard open, there's less fucking panels on the Sistine Chapel ceiling
then there is in xcode.

I can't stand Swift's initializers. No other languages have the problem with constructors/initializers that Swift does. It's a complete failure of a feature and to hell with safety if it comes with this cost.

Just to illustrate how ridiculous it gets, I want to have a class where my initialization logic can be split among reusable parts. That is, the logic that initializes the class with no parameters has logic that I want to reuse in my other initializers. Simple DRY stuff. Well, the only way I can do that in Swift is if I use a convenience initializer that calls another one. But convenience initializers have completely different rules from designated initializers (again, something only Swift does).

For example, you can't access "self" until you call a designated initializer. You can't chain designated initializers, and if you want to chain anything in the same class you have to handcuff yourself by using a "convenience" initializer (there's nothing convenient about them, I might add).

So now I want to subclass my class and initialize myself using one of my superclass initializers. Oh but the one I want to call is a *convenience* initializer so I can't, unless I turn my new initializer into a convenience initializer. Except wait, a convenience initializer must delegate with self.init(), so it can't even call a superclass initializer!

And it just goes round and round and round. I don't know if I should try to convert all of my initializers to convenience initializers or the other way around.

Why all this nonsensical madness? Get rid of the distinction and go back to nice clean powerful initializers like Objective-C. I mean what does it have to take? This is a complete nightmare.

!rant
Loving the the fact that constructors in Swift (initializers) can fail (returning null/nil) and be async.

In C# there is no other way than using static methods instead.