I stopped coding in Swift about 3 years ago, and SwiftUI was green then, too. I don't expect it to become much better soon.
Not much comes to mind right now in terms of libraries, I just remember constantly thinking that on the Web it is just an "npm install" away, while in Swift I would just have to code it up myself. UIKit is powerful, of course, but just requires too much ceremony most of the time. And SwiftUI is just not reliable. Writing wrappers for C libraries is not my thing, thinking about all implications of different memory models etc. is exhausting, and I'd rather not waste my time on low-level stuff like that if it can be avoided.
Mostly I am thinking about how easy it is to do UI stuff in React, it's much simpler and quicker. The ceremony that XCode and UIKit require are exhausting, as well. Why exactly do I have to give 100 different icons via drag'n'drop for my app? Funny, the Electron app only requires one icon, and I just place it in the right path.
What's a PITA in JavaScript is the commonjs / ecmascript modules mess, but I have a standard template now for coding up a module so that it works for both, and since then I much prefer npm over the Swift package manager, as well.
Coding in the Apple ecosystem just feels sluggish to me now. It feels like the equivalent of a luxury prison. Being able to access things like general compute shaders via Metal is the only thing I miss, but I think via WebGPU this will be fixed soon enough, and in a cross-platform way at that. Just like Electron runs everywhere, not just on my Mac. So what if it is 200MB large compared to a few kilobytes? That doesn't really matter. That's a one time price you pay, and it is well worth it.
Maybe we’ve just been writing very different types of software but as noted earlier, it’s been very unusual for there to not be built in or third party solutions to problems I’ve encountered in UIKit/AppKit.
The ceremony involved seems pretty minimal to me considering the trouble saved. It’s a relatively small front loaded cost that precludes problems further down the line.
As for icons there’s a bunch of shell scripts, AppleScripts, etc that will take care of minor one-time annoyances like icon scaling (though there’s actually good reason for 1x, 2x, and 3x versions of images to be distinct… scaling a single high rez icon down tends to look like a terrible smugdy mess on “normal” DPI displays).
Sure, you can streamline the process of icon creation. The point is that Apple often sets up things in a "simplified" way which is not really simpler, just more annoying. There are no "normal" DPI displays in Apple's ecosystem anymore, so one SVG should always be fine in many cases.
Again, my main point is that coding Apple apps just takes too much time and ceremony compared to what you get out of it (an app that only runs in Apple's ecosystem). The only way to justify writing an app specifically for Apple products is when you depend on their special hardware and ecosystem features. Or of course if you don't care if your app runs anywhere else. Or if you have resources to blow.
Apple treats software as an extension of their hardware: Generality and abstraction do not count for much, as long as this makes it possible to fit the software tightly to their current hardware. That's nice for Apple, but not so much for a developer who doesn't care for much more than generic hardware features.
There’s plenty of people in the Apple ecosystem that still use normal-DPI monitors. 2560x1440 27” monitors are very commonly used with Macs for example, and it’s not unusual for iOS devices to get hooked up to 1080p TVs.
I’d say the investment is also worth it for those who don’t like developing lowest common denominator apps.
> I’d say the investment is also worth it for those who don’t like developing lowest common denominator apps.
If I look at Electron, that lowest common denominator is pretty high. I'd argue that if you put the same effort into an Electron app that you have to put into an Apple app, you get a much better Electron app compared to the Apple app. And you can run it on Linux and Windows.
So, unless there is something essential for your app you cannot do in Electron, not liking the lowest common denominator still fits into the resource blowing category. Hell, blowing resources can sure be fun!
Not much comes to mind right now in terms of libraries, I just remember constantly thinking that on the Web it is just an "npm install" away, while in Swift I would just have to code it up myself. UIKit is powerful, of course, but just requires too much ceremony most of the time. And SwiftUI is just not reliable. Writing wrappers for C libraries is not my thing, thinking about all implications of different memory models etc. is exhausting, and I'd rather not waste my time on low-level stuff like that if it can be avoided.
Mostly I am thinking about how easy it is to do UI stuff in React, it's much simpler and quicker. The ceremony that XCode and UIKit require are exhausting, as well. Why exactly do I have to give 100 different icons via drag'n'drop for my app? Funny, the Electron app only requires one icon, and I just place it in the right path.
What's a PITA in JavaScript is the commonjs / ecmascript modules mess, but I have a standard template now for coding up a module so that it works for both, and since then I much prefer npm over the Swift package manager, as well.
Coding in the Apple ecosystem just feels sluggish to me now. It feels like the equivalent of a luxury prison. Being able to access things like general compute shaders via Metal is the only thing I miss, but I think via WebGPU this will be fixed soon enough, and in a cross-platform way at that. Just like Electron runs everywhere, not just on my Mac. So what if it is 200MB large compared to a few kilobytes? That doesn't really matter. That's a one time price you pay, and it is well worth it.