Also I think the decision to make combine a core building block of Apple UI development is a huge mistake. FRP is a plague on the industry, and everyone is going to figure that out in a couple years.
Also I think the decision to make combine a core building block of Apple UI development is a huge mistake. FRP is a plague on the industry, and everyone is going to figure that out in a couple years.
Why is FRP/Combine bad? What is better?
Not that it can't be handled well or used to good effect, but the idea of wandering into an unfamiliar FRP-based codebase which has been in the hands of multiple non-expert maintainers over a couple years is really the stuff of nightmares.
edit: answering what's better
Normal flow of control is better. You want to be able to look at a function, and see which functions are called from inside that function. And you want to be able to search all instances and see every place where a function is used.
You don't want to have some black-box scheduler who's calling all your functions for you. That's how you end up with mysterious action at a distance, becuase you didn't know about the extra subscriber your colleague put on a publisher somewhere else in the codebase, or something strange happening because of an order-of-operations issue which is difficult to understand.
I kinda agree that SwiftUI runtime uses a lot of opaque magic and documentation is still under-par. However, I am very glad Apple went the React way – I tried UIKit after I was writing React for few years and it felt very dated and laborious. Yeah, React isn't FRP, but declarative UI with code FTW.
But to be fair, the comment you linked is not a prophecy it was a lamentation
I would imagine a few years after SwiftUI becomes the primary UI stack used by iOS developers, many of them will be cursing Combine's name, as it will be clear most of the problems making iOS developers' lives difficult will be coming from FRP.
Edit: Is it Factory Reset Protection?