| This. The part about polluted mashup. I've developed and maintain 3 or so swift apps in the last 4 years. I also assist a colleague who ports and maintains them in Kotlin. At first I liked Swift. As a dynamic OO languages guy, I didn't like C++, and felt that Swift was a fresh approach to the non dynamic OO language. Over time, my enthusiasm has waned. For a while, I drank the value /struct programming koolaid. Too much. It turns out, that references are really really handy when your modeling real world things. Time and time again I've pushed myself to go the protocol route with structs, only to pull it out and just use simple single inheritance with real class based objects. The real trap I keep falling into is this. The Swift memory management story for objects is a fricking joke. First you have to constantly stress about ownership relationships, so that you don't get burned by cycles. And then you get to discover the various behind the scenes implicit refcointing rules around closures or passing methods directly in lieu of closures. And having to put [weak self] everywhere. So you react by using structs more. Because you believe it will be more efficient, etc. But structs come with their own problems. You put ids in your structs, because you need to assert identity of a given thing. Abstraction is more difficult. You get to dance with generics more. I've played with SwiftUI, I get the basic dream. It demos well. I could use it for simple CRUD style apps (which is what all the tutorials seem to be for). I'm just not sure how well it will scale to more complicated user interactions. As much as I don't like Android development and loathe Java, I'm forced to often just wish I could use Kotlin in iOS. It has its warts. And often there are too many ways to do one thing so that they can streamline a tiny amount of boilerplate away at the expense of consistency. But I fight it less. |