Me at 2:00 AM be like:

“WHY THE **FOOK** IS THIS CONSTRAINT BREAKING???”
“WHY IS XCODE SUCH A PIECE OF SHIT?”
“BROKE THE PROJECT FILES... HERE WE FUCKING GO AGAIN.”
“MEMORY ERRORS? H O W”

The morning after: "Oh... grammar error, missing ; and constraint written with a typo"

FML xD

Here we go again...
Why do you blame Xcode for your inability to code properly?

Broken project files? Never happened to me. I don't know what you are doing.

Memory errors? Well it's probably your lack of knowledge how the memory management works. And even then... how do you manage to get memory "errors"? Do you mean leaks? That's easy to avoid in objc and swift.

Same goes for constraints. Learn your shit and stop blaming Xcode and Apple!

@Lensflare Xcode is a shit pile, admit it you sad son of a bitch

@Lensflare I tend to protect Apple.

XCODE IS 24 GIGABYTES. *FOR AN IDE.*

Also, have you never heard of Derived Data? Sometimes just deleting it helps you compile a fucking project. Derived Data is cache that is almost all the time getting invalidated and outdated and shit.

@OmerFlame yeah I know about those problems and it sucks.

But the the things you have mentioned originally have nothing to do with those problems.

Btw I found that mostly you can just restart xcode (and maybe clean build before that) instead of clearing derived data.

@Lensflare not in my workload. I have @IBDesignables that literally need to be completely flushed from cache in order to render themselves correctly inside the Interface Builder. Also, my entire rant was just my frustrations, I never blamed broken constraints on Xcode. That’s on me.

@OmerFlame Interesting. I've never used @IBDesignable in real projects. Sad to hear that they are causing problems.

Currently I'm using SwiftUI and I have to restart Xcode once a day or so. Mostly when I mess with the project structure like renaming files. Fortunately, it's not that big of a deal because it's quick. Other than that, it runs very smoothly.

If you can afford to drop support for iOS 12, I'd suggest to try SwiftUI because you can wrap UIKit views inside SwiftUI views and use the previewer, which should serve a similar purpose as IBDesignable.

Or you could use SwiftUI as a dev tool to just preview your views without dropping iOS 12 support.

@Lensflare dude, SwiftUI is way too underpowered right now. If you want something which hasn’t been ported to SwiftUI yet, you will have to resort to wrappers and it’s a lost cause in the case of UIKit transitions. This is why I stopped developing my devRant rewrite on SwiftUI even though I progressed so much. I used to absolutely TRASH UIKit for its complexity but at the same time working around SwiftUI and constantly fighting against it, trying to bypass it and access the main UIHostingController and present view controllers from there. Please, for the love of god and everything that is sacred, if you are building something truly complicated, DITCH SWIFTUI WHILE YOU CAN!

@OmerFlame I am developing a complicated enterprise app.

It's true that you often need to fall back to UIKit but it works quite well.

The search bar in the navigation view required some hacks but it works.

Everything else with UIKit integration hasn't been a big problem yet.

@Lensflare try implementing a QLPreviewController with the UIView zoom transition, I dare you. I spent ONE MONTH on that on SwiftUI.

... and 15 minutes on UIKit. On UIKit it worked the first time. Writing these wrappers (that most of the time don’t preserve animations and stuff) is a huge waste of time in my opinion.

@OmerFlame but why didn't you just make this particular thing in UIKit and the remaining stuff in SwiftUI? You surely don't have an app that needs this special stuff everywhere 😆

@Lensflare when I make an app for iOS, I try to stick to the Apple-sanctioned design guidelines. This means animations, transitions, popups, blur views and a LOT more things that are just not supported on SwiftUI without performing hacks that would probably not be approved at all by Apple’s app review process (undocumented operations such as accessing the main UIHostingController). Lots of these things become VERY valid when you use UIKit.

@OmerFlame they are working very differently but the things you mentioned are supported.
I've managed to do some custom complicated animations and transitions without hacks.
Some stuff is even easier to achieve in SwiftUI.

For example, you give each view in a ForEach an id and based on that it can perform all kinds of custom insertion or move animations and transitions.

@Lensflare you cannot transition things that are UIKit-based because you have to access their underlying UIViews. The stock QLPreviewController zoom function? Tried for a fucking MONTH. Impossible. Because it’s a CONTROLLER, not a UIView. A controller takes all of the screen and it is presented on top if another controller. I know what I am saying since I have been trying for a month before switching to UIKit, where it took me literally 15 minutes to do it and it even worked flawlessly first time.

@OmerFlame I get that. You will need to animate transitions between UIKit views with UIKit. I suppose that means that the views containing them should also be UIKit (or maybe not?).

But most views won't need to be UIKit and you can animate them using SwiftUI.

I found a hack online which is able to access the ViewController from SwiftUI. It was for the SearchBar that I mentioned previously.

I don't know if that could solve your problem but you can find it here in case you are curious:

http://blog.eppz.eu/swiftui-search-...

@Lensflare but then another issue comes down the road: STATIC SIZING.

Let’s say that you wanna make a dynamically-loaded list with pretty complex layouts per cell. Because the sizes are not the same, the automatic constraints are related to ALL of the views so the algorithm falls back to recalculating them AGAIN, causing a glitchy spazz in the scrolling indicator in the list view. The next thing I tried is SwiftUI views INSIDE UITableViewCells. The cells couldn’t decide their own height EVEN THOUGH I gave UIKit clear instructions on how to calculate the height, and the cells just overlapped all the fucking time. Even if you’re gonna pull it off at some point, it’s still being rapidly developed and Apple might implement something for developers to use in the “magical one-lines solution” when you worked your fucking ass off for it one year too early. The effort just isn’t worth i for now...

@OmerFlame That's indeed something that I could not achieve also.
I tried to implement a flow layout with children of different widths and centered in each line.
I tried many different approaches and eventually gave up thinking it might be impossible 😄

@Lensflare seemingly easy fucking things that you could do in an afternoon on UIKit and it would probably take a fucking month of engineering on SwiftUI. These add up and up and up and up until you finally understand what Apple did: THEY ARE TEASING US WITH AN UNFINISHED LIB! My take? Let them finish it before using it constantly. Currently it’s not possible to work with this. Reddit agrees with me and most of StackOverflow does too...

@OmerFlame what you are seeing on reddit and SO might be biased because of course you will find more people discussing problems than people discussing things that are just working.

I disagree about it being unproductive. It has issues but the gains that I get from it do outweigh the problems for me.

I'm surprised how far you can actually get with SwiftUI alone.

What I find interesting is that the view you have about SwiftUI is the same view that I have about Xamarin after working with it (or rather fighting it) for years.
In my opinion Xamarin is not worth the trouble and is unfinished and bugged and costs more time than it saves.

SwiftUI is now already more polished and more production ready than Xamarin managed after what feels like a decade now.

And I feel like there are way more people that will assume that Xamarin is polished and complete and would have no problems using it in production.

This just buffles me.

@Lensflare SwiftUI is already pretty expansive, I'm not gonna say that it isn't, but they are also omitting really crucial shit like Table Views and Collection Views... and they SAID that they are not going to implement this any time soon.

@OmerFlame table view is List and collection view is LazyGrid.
As long as you don't need some special layout, they are doing the job.