Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I quit using SwiftUI

chsxf.dev

Post reply on HN
Print view View original

101–110 of 257 posts

Re: Why I quit using SwiftUI

#101

Post by ricardobeat »

kitsunesoba wrote: post #15

The main issue with SwiftUI is sheer lack of maturity. People don't think about it, but UIKit now has ~15 years of effort put into it, and got a serious boost from its shared roots with AppKit (even though big chunks of UIKit were freshly written, its structuring and API design were largely informed by AppKit), which has history tracing all the way back to the 1980s. Of course something as fresh out of the oven as Sw…

It is already three years old. I doubt AppKit, UIKit or any of the predecessors were in a bad state for three whole years after their launch.

Re: Why I quit using SwiftUI

#102

Post by dangus »

retskrad wrote: post #7

People nowadays praise Apple for their hardware, mainly their silicon - not their software. Maybe it's time for Apple to shake things up and promote someone else to VP of Software engineering?

I view it a different way: macOS and many of Apple's built-in apps/utilities are, at the very least, a less bad option compared to many others.

OS utilities like Image Capture, Preview, Apple's screenshot utilities, Spotlight, Quick Look, and quite a few others have been basically "killer apps" that make me want to use macOS over Windows for decades now.

Even basic areas like system settings have been a point of frustration for Windows for an extremely long time now, with Microsoft taking many years to truly migrate off of the Control Panel and deliver something half-decent in the Settings app. The Windows 11 iteration finally starts to feel like it's a little bit cohesive (but I still hate the Devices settings panel). The whole situation has really been a mess going back to Windows 8.

Another example: anytime someone says that printers universally suck I know immediately that they're Windows users because of just how much better Macs interact with printers and scanners and how much better and more reliable their configuration interface is. Apple single-handedly saved the entire printer industry from the depths of hell with AirPrint, before that Bonjour, and before that shipping OS X with preinstalled printer drivers.

Windows 10 couldn't decide what screenshot app I was supposed to use, thank goodness it's been consolidated after Windows 10's inclusion of two separate apps both worse than Apple's tooling.

Plus, Apple has to get credit for the sheer number of decently high quality non-enterprise apps that Apple just gives you for free.

Microsoft doesn't make anything that approaches the quality you get from Apple's free iMovie, Photos, Podcasts, Books, iTunes/Music, Contacts, Mail, Pages/Keynote/Numbers (without paying).

Re: Why I quit using SwiftUI

#103

Post by WanderPanda »

dpmitu wrote: post #31
coldcode wrote: post #4

Earlier quoted context omitted.

It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many com…

At my company we've been slowly rewriting our UIKit app in SwiftUI. We were due for a rewrite when SwiftUI dropped. I'd say we're about 75% done. For those "stupidly complex UIs", SwiftUI just doesn't have enough hooks for customization. And the improvements are too slow. Using SwiftUI has been bitter-sweet. It feels like you just can't use it to craft a high quality app that doesn't look like a generic iOS app.

Is looking like a generic iOS app that bad?! Especially here on HN where the sentiment is pro plain html etc. a generic iOS UI should be well received

Re: Why I quit using SwiftUI

#104

Post by choxi »

jph wrote: post #2

SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of…

You can integrate UIKit into SwiftUI, I always found that to be a pretty general purpose fallback on any missing functionality in SwiftUI.

Re: Why I quit using SwiftUI

#105

Post by bhedgeoser »

darinf wrote: post #98
jph wrote: post #2

SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of…

So wish they would decouple SwiftUI from the OS releases and opensource it!

..and from the crappy excuse for an IDE that they distribute along with their build tooling.

Re: Why I quit using SwiftUI

#106

Post by kitsunesoba »

ricardobeat wrote: post #101
kitsunesoba wrote: post #15

The main issue with SwiftUI is sheer lack of maturity. People don't think about it, but UIKit now has ~15 years of effort put into it, and got a serious boost from its shared roots with AppKit (even though big chunks of UIKit were freshly written, its structuring and API design were largely informed by AppKit), which has history tracing all the way back to the 1980s. Of course something as fresh out of the oven as Sw…

It is already three years old. I doubt AppKit, UIKit or any of the predecessors were in a bad state for three whole years after their launch.

I can’t speak for AppKit, but UIKit/Cocoa Touch was pretty rough early on. Major chunks of “standard” functionality were missing and standard widgets were somewhat inflexible. It was common to pull in third party libraries and write custom widget code for relatively basic things.

Based on my experience, the UIKit dev experience didn’t start to reach the level of completeness it’s known for now until some time between iOS 7 and 9… at least that’s when I remember the number of “required” third party libraries start to steeply decline.

Re: Why I quit using SwiftUI

#107

Post by AlotOfReading »

mrtksn wrote: post #96
AlotOfReading wrote: post #95

Earlier quoted context omitted.

So put the port on the side where you aren't supposed to grip it. If we assume that being totally nonfunctional for a couple hours a month is acceptable, merely being a bit inconvenient for the same period is surely an improvement. Also, we don't agree that the magic mouse is good human-computer interface because I'm starting from the position that causing physical pain automatically precludes it from that category.…

You can't put it at the side, the cable will interfere with the keyborad or the laptop that is on the left and won't work at all for the left handed people. I mean, if you really think that charging a few minutes a day or leave it charging overnight once a month is a deal breaker, simply don't buy it but this is not a bad design. It is very unrealistic to expect that the mouse will be used 24/7 every day forever. If…

Won't work at all for left-handed people, as opposed to now where it works for no one during the same period? Seems like an improvement, despite my doubts that it truly wouldn't work for left-handers.

Anyway, hopefully we can avoid wild mischaracterizations here. My expectation obviously isn't that things work 24/7 indefinitely. Think about how the typical user is going to discover that the battery is low. Either they'll get the notification just before it dies and have to charge it "soon" [1] or the mouse will simply die and force the matter. In some cases (think multi-user computer labs), the person who receives the notification and the person who has to charge the mouse might be two different people. I think it's reasonable to find waiting around on a mouse rather than whatever they were planning on doing irritating.

[1] https://apple.stackexchange.com/questions/254703/get-low-bat...

Re: Why I quit using SwiftUI

#108

Post by rudedogg »

pandatigox wrote: post #80
rudedogg wrote: post #34

I'm building an IDE in (mostly) SwiftUI, and have been using it since release, so I feel like I've worked with it more than most people. A couple observations: - SwiftUI is really complex It's going to take you at least a year to get used to the declarative way it works, and be able to make UIs without struggling to figure out how to shuffle data around. If you look at SwiftUI examples/code, most of the complexity is…

Out of curiosity, what framework/library/solution are you using for your text editor? I've been researching this space for a while and syntax highlighting text editors are rare and sparse. There is this: https://github.com/krzyzanowskim/STTextView for textkit2, but the author ended up writing his own text input client. How did you do about providing autocomplete, etc? Thanks!

> Out of curiosity, what framework/library/solution are you using for your text editor?

I'm still at the beginning of that part, but I'm doing it myself with TextKit 2 as well.

> I've been researching this space for a while and syntax highlighting text editors are rare and sparse.

I had the same experience as you when looking for information on how to go about it. I've come to the conclusion that no matter what an editor/IDE is going to be an ugly beast. This gave me some comfort in just forging ahead and trying to make good decisions as I go. And since I'm doing this all as a native app, I think I have a lot of wiggle room.

As far as syntax highlighting, I just recently started calling into Zig (the language I'm building this for), and using the tokenizer to do basic syntax highlighting. I'll need to go a bit deeper into the compiler to do more advanced highlighting, but it's cool to have it working.

> How did you do about providing autocomplete, etc?

I'm not there yet, but these are the things I'm looking forward to working on. I'm currently working on sort of "core" things and trying to design them well. Things like the settings, window management, a command palette, etc. Getting them close to right early on seems important.

I don't really do very technical posts, but I'm trying to blog a little about it: https://austinrude.com/tags/zig-ide/. My biggest issue is second-guessing using Swift/SwiftUI and not trying to do it all myself with Zig, leading me to procrastinate. But I'm pretty far along, and think I'll probably release something eventually.

Re: Why I quit using SwiftUI

#109

Post by Bolkan »

mhoad wrote: post #64
Apocryphon wrote: post #17

If I was to build a new mobile app using a shiny new declarative framework, I’d rather use Flutter, because at least that provides the benefit of targeting Android for free. Depending on the type and scale of the app, of course.

I know that the HN crowd has a weird relationship with both Apple and Google that go in two very different directions regardless of the evidence but honestly I think what you are proposing is actually a really good long term plan. Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak that should clear up the remaining issues people seem to have with it when it comes to performance…

> Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak

Source?

Re: Why I quit using SwiftUI

#110

Post by azemetre »

ozgung wrote: post #99
coldcode wrote: post #4

Earlier quoted context omitted.

It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many com…

> designers are asking for stupidly complex UI I think a mobile app should have a stupidly simple UI instead. Designers traditionally use a graphics program to design pixels. SwiftUI let’s you design layouts and components. Maybe designers should change how they design and start using SwiftUI as a design tool.

Your comment reminds me how asinine some Designs orgs have become at companies. Basically chasing fashion statements and demanding Engineers “just do it” with little consideration to the development, maintenance, and testing costs.

Modern development, at some companies, can truly feel regressive at times.

Post reply on HN