[HN Gopher] I Quit Using SwiftUI
___________________________________________________________________
I Quit Using SwiftUI
Author : geoffeg
Score : 133 points
Date : 2022-08-28 17:53 UTC (5 hours ago)
(HTM) web link (chsxf.dev)
(TXT) w3m dump (chsxf.dev)
| ChildOfChaos wrote:
| Ugh.
|
| I haven't really coded things since I was a kid and since I have
| an iPad/iPhone/iMac and wanted to learn how to code again and
| potentially use it as a side hustle or some sort of future money
| making opportunity, I decided to learn swift/swiftUI and i'm
| currently taking an online course, but when I read through hacker
| news, all I see is articles bashing it constantly.
| [deleted]
| retskrad wrote:
| 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?
| bsaul wrote:
| I'm with you, however mac os remain the best dekstop OS and iOS
| remain the best mobile one, even after all those years. So,
| they must be doing something right..
| GrabbinD33ze69 wrote:
| I agree, in my experience, MacOS is one of the most reliable
| operating systems I've used in terms of lack of crashes or
| spurrious bugs; the most common bug I see is my mouse pointer
| dissapearing, which is fixed by opening the tasks view.
| pohuing wrote:
| If only they could so something about the truly terrible
| window switching crap, where you'll have to hit the same
| icon in your doc multiple times to eventually with a bit of
| luck get to the window you wanted. Why can't we have window
| previews like Windows has had since Windows 7 or just about
| every DE on Linux
| mml wrote:
| hold down option when you release the selection to force
| hidden windows up. i too hate this behavior.
| DelightOne wrote:
| My mouse pointer also disappeared for a time when it by
| accident crossed over to my iPad. After disabling that
| feature it never happened again.
| ohgodplsno wrote:
| iOS lacks many features that have been standard on Android
| for years and the only reason it feels so smooth is because
| the UI thread has pretty much the highest QoL that anything
| can ever have. iOS would rather drop your network call than
| drop a single frame.
|
| Android variants all have things that iOS can only dream of
| having in five years (notifications was a fun one), just
| spread very unevenly throughout manufacturers. Samsung
| currently has a very good Android build.
|
| Calling it the best is very far fetched.
| dangus wrote:
| The copying of features isn't one-sided. Both companies
| have had firsts there:
| https://www.popsci.com/story/diy/stolen-features-android-
| app...
|
| When I switched from Android to iOS in 2016, I was shocked
| at how little was different, and I can only assume gulf has
| narrowed since then. A lot of features Android users just
| _assume_ iOS users don 't have are there: vendor-agnostic
| password manager integration, Safari browser extensions,
| Safari content (ad) blocker API (Chrome is restricting ad-
| blockers soon!), more complete home screen customization
| and widgets, lock screen customization and widgets (iOS 16,
| upcoming), custom third-party keyboards,
| grouped/customizable notification system, native console
| wireless controller support from all three consoles.
|
| Features like granular privacy controls and screen
| recording (with the exception of some obscure Android OEM
| builds) debuted on iOS first.
|
| I'd be skeptical with anyone declaring either platform
| "best," I think they're both roughly equivalent.
|
| However, I do think that anyone who uses macOS is insane to
| go with Android. There are simply too many useful
| integrations between the platforms to ignore, combined with
| the fact that, even if the iPhone isn't _the best phone_ ,
| it's usually in the top handful of choices in terms the
| overall package.
| FpUser wrote:
| >"...however mac os remain the best dekstop OS..."
|
| I would say this is a matter of opinion.
| dangus wrote:
| 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).
| stephc_int13 wrote:
| Any UI code running on a modern CPU should take close to 0ms to
| update, no matter how many buttons, toggles, sliders and shadows.
|
| For the rendering part, it depends, I'd say it should take
| between 0.5 and 2ms with many layers, a lot or transparency and
| not much care for optimization.
| kevingadd wrote:
| In my experience working with IMGUI-style libraries, it's
| definitely feasible to perform full layout and rendering for
| complex UI in 1-2ms at most. For simpler applications it should
| be basically free. It's depressing that people are willing to
| accept complex, slow layout APIs at this point considering it's
| been possible for stuff to be fast for a long time.
|
| Perhaps surprisingly, the most expensive part is usually text
| layout and rendering - text shaping is just really expensive
| and in the industry standard libraries it can take a long time
| to lay out a string, so you have to aggressively cache and do
| fancy things to get good performance. ASCII text is fast,
| though.
| jmull wrote:
| The declarative, "reactive" approach is good, and worthy of
| rolling out a new UI API even given that Apple has an excellent
| MVC-style API...
|
| But it looks like the task was somewhat beyond the people who had
| the responsibility for rolling out SwiftUI at Apple.
|
| We're several years in to SwiftUI.
|
| Apple's in a tough spot now. I'm really glad I don't have
| anything too high-stakes dependent on it. (I only have a project
| with ~200 hours invested -- not zero! -- it's heavily UI, but
| it's tiny... maybe ~30-40 hours to port to UIKit, if needs be.)
| TazeTSchnitzel wrote:
| The post didn't go into much detail as to why it seems to be so
| slow. Is SwiftUI recreating an entire UI's worth of components
| when a state update happens?
| bsaul wrote:
| To me that's the red flag. That an experienced game developer
| wasn't able to properly troubleshoot down to the correct level,
| but ended up facing a black box and gave up.
| ohgodplsno wrote:
| I am not developing on Apple platforms, but just like any
| reactive UI framework, i am almost certain the documentation
| of SwiftUI starts with a massive red flag that says "make
| your updates granular and don't repost a whole ass struct on
| every frame" at the very beginning which is exactly what the
| author seems to be doing.
|
| If all you want is a declarative UI, just dump in ImGui and
| be done with it.
| yakubin wrote:
| ImGui doesn't give you native OS widgets.
| bowsamic wrote:
| Well that's supposed to be the point of SwiftUI. You write
| out your declarative structure, let the library worry about
| how to make it fast, and move on with your day. They
| literally introduced it that way. Obviously that is very
| detached from reality
| [deleted]
| solarmist wrote:
| It sounds like SwiftUI is capable, but not performant for his use
| case. Fair enough.
| pixel_tracing wrote:
| The entire view shouldn't be redrawn but certain views only (not
| the entire tree) maybe look into prevent entire view from being
| redrawn itself (React does this too and you can prevent redraw
| without utilizing useMemo by understanding it's internals)
| tadfisher wrote:
| Compose bakes this into the framework at the function level. By
| default, if the function parameters are immutable and the
| function doesn't return a value (basically emits compositions
| by calling other Composable functions) the entire composition
| is memoized and the function can be skipped.
|
| The tricky part is knowing what is immutable, because standard
| JVM collections are not.
| jph wrote:
| 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 code examples for how to
| escape out of SwiftUI to handle more-complex cases, and 2)
| accelerate Xcode speedups of SwiftUI testing-and-instrumentation
| techniques such as View testing (e.g. ViewInspector) and
| integration testing vs. unit testing (e.g. reactive vs.
| dependency injection vs. extension tests vs. protocol tests etc.)
| choxi wrote:
| You can integrate UIKit into SwiftUI, I always found that to be
| a pretty general purpose fallback on any missing functionality
| in SwiftUI.
| coldcode wrote:
| 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 companies who
| try to support back at least 1 year.
|
| Will it ever be mainstream for iOS/MacOS? Maybe, if Apple would
| use it way more than they have so far, thus improvement by
| dogfooding. It is nice to build apps this way, but there are
| way too many bizarre gotchas still for most people unless you
| can live with more flexible designs.
| dpmitu wrote:
| 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.
| WanderPanda wrote:
| 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
| ozgung wrote:
| > 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.
| azemetre wrote:
| 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.
| aYsY4dDQ2NrcNzA wrote:
| It's like Design for Machining, if you're fabricating
| metal parts.
| elpakal wrote:
| > but at the same time the docs are terribly lacking at how to
| handle any kind of edge cases.
|
| I agree that Apple's documentation needs help (this year's
| improvements are a nice step) but can we really expect them to
| provide extensive documentation for handling edge cases (you're
| telling me UIKit docs offer that)?
| heavyset_go wrote:
| Yes, I expect a trillion dollar company to invest in good
| documentation of their dev products.
| worik wrote:
| My feeling is that Apple hates the developers that develop
| the software that makes them rich.
|
| Forcing myself to be rational "hate" is probably too strong
| a word. If you are down the Apple cul-de-sac there is
| really no turning back. So investing in things like code
| examples for all of their API (there are a few, a very few)
| is a waste for Apple. It does not attract new developers
| and the old ones are stuck in the cul-de-sac.
| diffeomorphism wrote:
| That sounds very different from what was written? The
| complaint was about "lacking ... any kind of" yet you write
| about "extensive documentation".
|
| There obviously is a trade off with how much you can/should
| expect, but "you cannot expect 9/10" is not a valid reply to
| "it currently is 3/10".
| elpakal wrote:
| well thats good because I didn't say "you cannot expect",
| did I?
| darinf wrote:
| So wish they would decouple SwiftUI from the OS releases and
| opensource it!
| bhedgeoser wrote:
| ..and from the crappy excuse for an IDE that they distribute
| along with their build tooling.
| ChrisMarshallNY wrote:
| I like what SwiftUI will become, but I'm not there. yet.
|
| The current project that I'm working on, is pretty big. It peaked
| at 40 screens, but I'm trying to get it down to half that.
|
| I've been working on it for two years. I also wrote one of the
| backends (and most of another).
|
| There was _no way_ that I was going to start on a project of that
| complexity on SwiftUI, which, at the time I started, had only
| been demonstrated in a few small projects. I already knew that
| UIKit could do it.
|
| But I think that SwiftUI will become the standard, sooner or
| later. I look forward to being able to write more reactive
| applications in it. In my experience, if I use UIKit, it's a
| fairly bad idea to stray from the old MVC model (This, I have
| learned. _< Pulls up shirt>_ See this scar?).
| brailsafe wrote:
| I quite like SwiftUI most of the time, and have got past most of
| hurdles, such as integrating state with menubar views. But my
| biggest hangup is that it's used for 3 different platforms with 3
| different sets of variation, and most tutorials focus on iOS
| foobarding wrote:
| Dealing with SwiftUI recreating Views too often can be a
| challenge. I would have liked to have seen more details on how
| this guy setup his models.
|
| In my experience, you definitely have to minimize work done in
| Views and maybe avoid `@Published` properties on your model in
| favor of more explicit calls to `objectWillChange.send()` to
| signal when you really are ready for the Views to be updated.
| SwiftUI does not seem to do a very good job of coalescing by
| default.
| socialdemocrat wrote:
| I spent only about half an hour with Swift UI to decide it was
| bot worth it. Looks sleek but the underlying technology is too
| complex IMHO.
| bowsamic wrote:
| I agree. The amount of plumbing behind the scenes is really
| complex. This immediately becomes apparent if, for example, you
| want to use @AppStorage with something that isn't a very simple
| type. Then suddenly you are in no mans land reading Combine
| documentation with no examples
| seanalltogether wrote:
| I just wish that Apple had used this big effort to update their
| ui tooling to instead 1. Bring in stylesheets to UIKit/AppKit,
| 2. Let us define UIKit/Appkit views with simple straightforward
| xml like android or xaml.
| mrtksn wrote:
| The author talks about SwiftUI on macOS, which I also find to be
| much much more buggy than what's on iOS.
|
| Very unexpected things happen, like items in a specific region in
| the App UI stop responding to clicks next time once you interact
| with them.
|
| However I find it fine on iOS and the issues are usually around
| Apple changing something in the behaviour of the UI or API and
| breaking it, then you need to fix it for specific versions of the
| iOS. That's what you get when a framework is not mature yet, I
| guess.
|
| That said, I don't think there's a turning back. It might be
| buggy but it definitely feels like the right way of building UI.
|
| Oh, about the performance, you can build very sluggish or very
| responsive UI with SwiftUI because there's a night and day
| performance cost difference between "re-calculating and re-
| drawing" the UI and adjusting a property of it. Always try to
| structure your components in a way that changes happen by
| changing passed values instead of inserting or re-doing the
| views.
|
| SwiftUI works quite a bit like React, many performance lessons
| from React will translate into SwiftUI.
| [deleted]
| guelo wrote:
| Tying the SwiftUI version to the iOS version is seriously
| asinine. In the Android world Compose is a regular library so
| devs can pick the version. That's partly why there has been
| much more adoption of Compose even though it was released years
| later than SwiftUI.
| mrtksn wrote:
| I wonder what is the technical justification for it too, if
| any. I mean, sure - you can save space by making it a dynamic
| library that is shipped with the OS but considering how
| immature it is, shipping a specific version of it with the
| app should be an option IMHO.
| coldtea wrote:
| > _I wonder what is the technical justification for it too,
| if any._
|
| Well, apps using it get a uniform look, that uniformly
| changes when the OS look is updated so that it matches it,
| and more importantly, they and also get to have the same
| widgets and widget functionality [1].
|
| Unlike, say, Windows where you have 20 generations of MS
| GUI lib versions, with different looks and behavior,
| running at the same time, even from MS apps themselves...
|
| [1] Yes, Apple has its share of inconsistencies (e.g. Swift
| UI vs regular Cocoa UI). But nothing like what would have
| resulted if they allowed apps with different historical
| macOS UI libs/versions to be installed at the same time
| independently from the OS UI libs.
| mrtksn wrote:
| Good point actually.
| sofixa wrote:
| It's probably the same as the technical justification for
| why Safari updates are bundled with iOS and not separate,
| why XCode only runs on macOS, why no other browsers are
| allowed on iOS, why macOS can't have separate scroll
| directions between mouse and touchpad and many many others.
| It's Apple's ecosystem, nobody is asking you, you're
| holding it wrong.
| bliteben wrote:
| Scroll direction is because everyone needs a mouse that
| you have to turn upside down to charge
| mrtksn wrote:
| The meme about the Magic Mouse charging upside down is
| really silly. There's a real good reason to be like that
| and you charge it once a month.
|
| In the case of Magic Mouse, there's really a case of
| holding it wrong too. People hold it wrong and thats why
| they also complain about the ergonomics.
|
| Truly excellent but misunderstood product.
| AlotOfReading wrote:
| I've worked on mice before and frankly I have no clue
| what sort of technical requirement would lead to an
| upside down charging requirement and disabling the
| functionality in the meantime. Can you explain what that
| reason might be?
|
| Also if most people can't just pick up the mouse and use
| it, it's a broken design. In my particular case, it's so
| much smaller than my palm that I'm sure _any_ grip would
| result in RSI.
| mrtksn wrote:
| Simple, the front is not thick enough to accommodate a
| common port like USB or Lightning. If you put it on the
| sides, it defies the purpose.
|
| Changing the design to accommodate a port in the front
| doesn't make sense because the primary function of the
| device is to act as a human-computer interface and
| optimising the design for that purpose is paramount,
| charging is not a primary function but something that we
| have to do with electronics and as a result having long
| battery life and short charging process is good enough
| solution(the battery lasts about a month, charging takes
| about 2 hours but will work for hours even with a few
| minutes or charging). Why would you compromise a design
| for something that needs to be done occasionally and can
| be done out of the service(i.e. at nigh, when not using
| it).
| AlotOfReading wrote:
| 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. Another example of an
| interface in the same position is laser keyboards.
| They're also very cool designs, but the the fact that
| tapping on solid surfaces starts to hurt after awhile
| precludes them from being 'good' HCI.
| mrtksn wrote:
| 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 you have this use
| case of using mouse 24/7 everyday, this must be some kind
| of industrial operation and obviously this mouse is not
| for you but for everyone else it's a non-issue.
| AlotOfReading wrote:
| 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...
| mrtksn wrote:
| Sure, better notifications can help. Maybe once idle, can
| send a notification to the phone to make the user put it
| on charge overnight.
|
| I had the occasion where the battery died by surprise.
| That's why I keep repeating that the device works for
| hours after few minutes o charging, you don't have to
| fully charge it before use.
| johannes1234321 wrote:
| They can ship security updates themselves, which
| immediately fix all apps. Otherwise apps eventually never
| update.
|
| Also apps don't get the new "improved" styles etc if they
| don't have it in the system, which takes away the
| consistency Apple aims for.
|
| And then: It's Apple ...
| pohuing wrote:
| Style changes and quickly become usability and
| accessibility issues. I'd rather my app continues to work
| well as I tested it, than having to test all of the shit
| on every other OS patch.
| jen20 wrote:
| I hope you don't apply the same philosophy to security
| patches.
| callmeal wrote:
| My guess would be a monetary justification. After all you
| can't just have developers working on year old laptops and
| devices when you can make them buy new ones by making this
| one simple change.
| coldtea wrote:
| These kind of "conspiracy theories" for this or that what
| amounts to negligible money always make me cringe. Not
| that companies don't do shitty things for money. But they
| don't do things like that for negligible money compared
| to their other operations, especially since there are far
| more important reasons to do them...
|
| The reason is platform coherence and control, and lock-
| step updates. To avoid cases like this:
|
| https://segmentfault.com/a/1190000040213084/en
|
| https://ntdotdev.wordpress.com/2021/02/06/state-of-the-
| windo...
|
| ...and not the insignificant money that could be made
| from devs updating a laptop a little earlier (especially
| since you can trivially use a still supported 5-6 year
| old laptop anyway with the newest Apple OS, and you
| wouldn't see any major performance issue, except in cases
| like the Intel to ARM switching. So what would they gain?
| Developers forced not to use an 8 or 10 year old laptop?
| As if they would?).
| jules wrote:
| The potential profit from that is a rounding error for
| Apple.
| adamnemecek wrote:
| I like SwiftUI even if most of my views are still
| NSViewRepresentables, it makes the application structure so much
| nicer and I don't have to use Interface Builder as much. I know
| you can use AppKit without Interface Builder but it's more
| annoying.
| solomatov wrote:
| What surprises me the most is that Apple didn't open source it
| even many years since unveiling has passed. It doesn't look to me
| that they have any risks here. The library could be used only on
| Apple platforms. It will let users submit fix PRs, and make
| debugging code (by framework users) much easier.
| worik wrote:
| They will be embarrassed, perhaps, about code quality
| kitsunesoba wrote:
| 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 SwiftUI is isn't
| going to be able to compare in terms of polish or capability.
|
| So for now I'm sticking to UIKit in the apps I'm responsible for.
| I think SwiftUI's day in the sun is coming, but it's not here
| quite yet.
|
| That doesn't mean that there aren't issues with how it's being
| engineered and documented, though. It has serious shortcomings
| that need to be shored up, and hopefully that happens with its
| maturation.
| ricardobeat wrote:
| 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.
| kitsunesoba wrote:
| 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.
| rudedogg wrote:
| 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 hidden, but
| it's there, and you're going to have to interact with it to do
| anything non-trivial.
|
| - Is SwiftUI the way?
|
| SwiftUI has enabled me to build out huge amounts of beautiful UI
| quickly - faster than anything I've ever used. But you _will_ run
| into things you can 't do, forcing you have to fall back to
| AppKit/UIKit. And the area where AppKit/SwiftUI meet will
| disappoint and frustrate you. I just got done refactoring a huge
| amount of my app to use the "AppKit App Lifecycle" instead of the
| SwiftUI App lifecycle since I need some specific windowing
| behavior. Now I can't use .toolbar, .menu, and other stuff, which
| makes things much more complicated for me, and forces me to think
| about both SwiftUI/AppKit. Switching mental models like that, and
| trying to remember all the intricacies of both SwiftUI and AppKit
| is rough.
|
| --------------
|
| Regarding the performance issues of this specific post, my guess
| is they put everything into an ObservableObject, and used
| @Published properties to get bindings for their UI controls. This
| means any view with a reference to the ObservableObject gets re-
| rendered when @Published values change. Instead you need to silo
| your changes, so your entire App isn't redrawn every frame. This
| goes back to the complexity - it's not straightforward at all.
| jules wrote:
| How do you silo the changes? The issue was that changing a
| property of an object caused the inspector to be redrawn. With
| old fashioned UI libraries you would only change the value of
| one text field in the inspector. Can this be achieved with
| SwiftUI? To be honest I'm surprised that it's that slow even if
| the entire inspector is redrawn. Surely on a modern computer
| you can redraw a couple of text fields at 30fps?
| rudedogg wrote:
| See this answer: https://swiftui-lab.com/digital-
| lounges-2022/#data-15
|
| > Surely on a modern computer you can redraw a couple of text
| fields at 30fps?
|
| Yeah this is the tricky thing, with how (I'm guessing) the
| code looks, you would think it's only updating the text
| fields. But in reality it's probably re-rendering the entire
| hierarchy using the @EnvironmentObject. So the SceneKit view
| gets setup and rendered every update of the Slider.
|
| ------------------
|
| I have real-time color pickers for changing all windows in my
| app. Same with font sizes. It's possible to make it work, you
| just have to modify your design (which is unfortunate).
| jules wrote:
| Ah I see, so each of the values that are shown in the
| inspector should become its own observable object? That
| sounds reasonable.
|
| > But in reality it's probably re-rendering the entire
| hierarchy using the @EnvironmentObject. So the SceneKit
| view gets setup and rendered every update of the Slider.
|
| I get that this is slower than only updating the single
| value, but what I don't understand is why even this is so
| slow? Browsers can render the right hand side of this
| inspector UI (https://chsxf.dev/assets/posts/5/map-editor-
| with-inspector.p...) at reasonable speed _even if you
| rebuild the entire DOM_ for the fields in the inspector. I
| mean, it 's one checkbox, one slider, and 7 text boxes and
| a bunch of labels. What is taking so much time here?
| darinf wrote:
| Yeah you end up designing models not to be logically separated
| but to instead isolate updates to Views. In theory those should
| align but they don't always. And the method of finding objects
| thru the environment makes it all too easy to have big models
| that everything is listening too which of course really hurts
| perf. So easy to hold SwiftUI wrong.
| pandatigox wrote:
| 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!
| rudedogg wrote:
| > 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.
| stackedinserter wrote:
| In 2022 developing software for iOS (now iPhoneOS) feels like
| you're working for Apple for free.
|
| You have to look closely to new requirements that they roll out
| every few months. You should use Apple products in your app or
| gtfo (e.g. login with Apple ID). You have to update your laptop
| every few years because Xcode (which is monumental PoS) requires
| new MacOS that your hardware doesn't support. And when you go
| through all this trouble, you have to literally beg Apply to
| admit a new version of your app. You even have to pay Apple to be
| able to write apps for their phones/tablets.
|
| I'm so glad I jumped off iOS development a few years ago.
|
| If you're a young developer and still not decided what area suits
| you the most, think twice before entering iOS and MacOS
| development.
| [deleted]
| qudat wrote:
| I couldn't agree more, especially the bit about Xcode. I don't
| even do apple development but still have to deal with it on
| every upgrade. What a pain
| Apocryphon wrote:
| 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.
| mhoad wrote:
| 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 and the rest of the project is incredibly well
| supported and documented and most importantly as you hinted at
| genuinely cross platform.
|
| It's a much better bet for basically any project outside of one
| that you know for a fact is only ever going to target Apple
| operating systems.
| Bolkan wrote:
| > Flutter is currently rewriting a key part of their graphics
| rendering pipeline as we speak
|
| Source?
| Apocryphon wrote:
| To elaborate upon my previous post:
|
| 1. SwiftUI seems mainly suited for building quick proof-of-
| concept simple intro apps, with the difficult 20% still out
| of reach. Which doesn't sound all that different from the
| notorious downsides of cross-platform frameworks, some of
| which can allow for small simple apps to be quickly spun up,
| but the tough under-the-hood cases still intractable.
|
| 2. Flutter, and React Native are more mature than SwiftUI is
| right now. SwiftUI will get there, and maybe it's only 1-2
| years away, but it still hasn't hit its Swift 5 moment yet.
| That opens up the possibility of breaking API or even
| conceptual changes until then.
| aaaaaaaaaaab wrote:
| People burn an astounding amount of CPU and brain cycles
| pretending that UIs are something they are not. (i.e. "pure"
| functions)
|
| I hope Apple never goes the way Microsoft did with their fad UI
| toolkits that utterly destroyed developer trust in native Windows
| development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are
| pretty wise for keeping SwiftUI be the "for kids" vanity UI
| toolkit to lure in React webdevs, while keeping UIKit and AppKit
| for serious stuff.
| marcosdumay wrote:
| The ironic thing is that functional reactive idiom is not about
| pure functions. It's about dealing with the impurity only once,
| at state management.
|
| But if you don't keep track of the impurity dependencies on
| your language, you will need to rediscover those dependencies
| during compilation, and besides surprising the developer all
| the time, that's a really nasty problem to solve. That's why
| it's always solved badly.
| criddell wrote:
| MFC? As somebody who has worked with MFC in some way or another
| for the past 25 years, there are worse examples out there. The
| beauty of MFC was that it was pretty simple layer on top of
| Win32 and the source code was provided. You can continue to use
| it with some of their newest stuff using XAML Islands.
| rudedogg wrote:
| > They are pretty wise for keeping SwiftUI be the "for kids"
| vanity UI toolkit to lure in React webdevs, while keeping UIKit
| and AppKit for serious stuff.
|
| At WWDC 2022 they specifically said that Swift+SwiftUI is the
| best way to build apps, and the future of their platforms. I
| thought AppKit/UIKit would stick around, but I guess not.
|
| ---------------------------
|
| Edit: Here's the direct quote from the "Platforms State of the
| Union":
|
| > We're continuing to expand our adoption of SwiftUI across our
| apps and system interfaces. For example, iOS's new Lock Screen
| widgets were designed from the ground up using SwiftUI. The new
| Font Book app was completely rewritten with it. And the modern,
| forward-looking design of the new macOS System Settings app was
| built using it. Swift and SwiftUI were designed from the start
| to provide a single, native language and API for all Apple
| platforms. You can learn them once and apply them everywhere.
| Whether your vision is to provide quick access to information
| at a glance on Apple Watch, productivity tools on MacBook Pro
| and iPad, new experiences on iPhone, or a new way to relax with
| Apple TV, Swift, SwiftUI, and Xcode provide a next-generation
| integrated development platform to help you build apps for all
| of our products. Now, if you have an existing app, it's easy to
| adopt these new technologies incrementally. And if you're new
| to our platforms or if you're starting a brand-new app, the
| best way to build an app is with Swift and SwiftUI.
|
| The slide had a Swift, SwiftUI, and Xcode logo with nothing
| else.
| bowsamic wrote:
| There is no evidence to suggest that Apple are deprecating
| AppKit and UIKit
| ChrisMarshallNY wrote:
| It'll be around for many years.
|
| I know, for a fact, that some AAA applications are still
| using ObjC.
|
| Also, I am quite sure (but don't _know_ ) that Apple still
| has a plenty big ObjC codebase at home.
| aaaaaaaaaaab wrote:
| Some? More like _all_ AAA applications use ~100% ObjC. I
| 'm talking about apps like Facebook, Messenger,
| Instagram, YouTube, etc.
| ChrisMarshallNY wrote:
| This is likely true. I only know of a couple, but I'm
| quite sure that there are legacy codebases up the yin-
| yang.
|
| Either that, or Electron/Xamarin/React Native.
|
| I am not really a fan of the hybrid apps. I was just
| watching Slack go crazy on my iPad, a few minutes ago.
| Someone wrote:
| Supertankers turn slowly, but if the captain tells you the
| ship will turn, you better believe it, even if you don't
| see the ship turning yet.
|
| Having said that, even though Apple indicates it will turn,
| it still may change its mind halfway through.
| worik wrote:
| > but if the captain tells you the ship will turn, you
| better believe it,
|
| What Apple says at their circus show is not the same
| weight as the captain of a ship telling you the ship's
| course.
| aaaaaaaaaaab wrote:
| Don't read too much into it. That's just PR.
|
| I'll start getting concerned when they rewrite any of their
| serious apps in Swift(UI). (i.e. Logic, FCP, Xcode, Finder,
| Instruments, iMessage, Mail, Calendar, etc.)
| [deleted]
| bowsamic wrote:
| I just don't get what purpose it really solves over UIKit.
| Everything seems far more complicated in SwiftUI, and the data
| dependence problems it solves did not ever really seem to be a
| huge issue in UIKit anyway.
|
| Apple's sell for SwiftUI was "it's like going to a chef who knows
| how to cook for you" instead of "cooking yourself". But is that
| really a good thing? Do we really want to be taking less control
| of our applications when we write them?
|
| The worst part is all these tutorials that have to combine
| SwiftUI and UIKit because the former is very buggy in certain
| cases, like navigation trees on iOS have really janky animations
| using SwiftUI. So you have to coordinate all your Views using
| UIKit. It just seems barely easier to use SwiftUI most of the
| time.
|
| EDIT: Basically, in summary, it seems like a very complicated
| (look at the crazy language features they had to add for it) plus
| very opaque ("it magically does it for you just how you wanted")
| way to write the same apps you were already writing fine in UIKit
| and AppKit
| aaaaaaaaaaab wrote:
| I have some friends at Apple... The story goes something like
| this: SwiftUI came about because someone who has never been a
| software engineer, got concerned about losing mindshare to
| ReactNative et al. So this person created a "task force" to
| deal with the problem by tacking something on top of UIKit that
| resembles React, to create a "friendly" ingress funnel into the
| iOS world.
| andrekandre wrote:
| > SwiftUI came about because someone who has never been a
| software engineer
|
| so... management?
| worik wrote:
| > I profiled the whole thing and discovered several things
|
| Well done
|
| After two years with Xcode/Swift/SwiftUI I never succeeded in
| getting anything useful out of the profiler.
| ncmncm wrote:
| Coding for a walled garden will always be an exercise in
| futility.
|
| The tooling will always be less mature than you can find
| elsewhere. And in the end, all you have is a thing that works
| only in the walled garden.
|
| Of course this observation is not limited to any particular
| garden.
| data-leon wrote:
| Built an macOS app (https://posturenet.app) to monitor my
| posture in real time with SwiftUI last year for fun.
|
| The lack of support for Video and Camera from SwiftUI was the
| most challenging part for me as a newbie Mac dev.
|
| Took me a few weekends to get the core part done (ML and
| algorithm), but hooking up all the UI components and connecting
| them with the video stream gave me so many headaches.
|
| With that said, it was still much easier for me (complete newbie
| to Mac App at the time) to learn and develop in SwiftUI than
| UIKit.
|
| Hope SwiftUI keeps getting better and keeps investing in the
| team.
| robertbmenke wrote:
| My SwiftUI codebase for https://equater.app definitely has some
| "// TODO: when apple fixes X" comments, but there's no denying
| the MASSIVE developer velocity I gained from using the framework.
|
| If the bugs are bad enough I can always do something custom in
| UIKit via UIViewRepresentable.
| dmitriid wrote:
| > I profiled the whole thing and discovered several things.
| First, the view provided by the selectable object was completely
| recreated with every redraw. I gained some performance back by
| caching it, but things remained barely usable.
|
| That... is exactly the same thing with React. You don't notice
| everything is redrawn until suddenly everything is unbearably
| slow. And then it's useMemo etc. galore.
|
| I'll withhold my judgement on SwiftUI for now though.
| solomatov wrote:
| IMO, you shouldn't use React-like tools in performance critical
| UI code. Direct DOM manipulation in such cases is much better
| and more maintainable option. I.e., it's easier to maintain
| straightforward direct DOM manipulations than all the tuning
| around making a React-like system more performant.
| jollybean wrote:
| Then why use it anywhere?
|
| I have never fully bought into this notion that the
| components should rebuild themselves in this kind of
| stateless manner.
|
| I think this like an intellectual obsession with functional
| programming mapped onto the UI Tree. I can't fathom why it's
| 'better'.
|
| The reactive aspects of the middle tier of the program -
| that's progress. But the reactive components, I'm not sure
| about that.
| solomatov wrote:
| >Then why use it anywhere?
|
| To write code quicker, and make it easier to maintain. If
| it's a moderately complicated UI, then I could code it up
| much faster in React (my guess is around 10x). IMO, React
| isn't about functional programming, it's just a good DSL
| for writing UI.
| dmitriid wrote:
| > To write code quicker, and make it easier to maintain.
|
| Yes, it's faster to write. Is it easier to maintain?
| Doubtful. Especially when you inevitably run into issues
| that your whole UI re-renders a couple of hundred of
| times a second, and you have to go in and butcher
| everything with useMemos, caching etc.
| worik wrote:
| > To write code quicker, and make it easier to maintain.
|
| It makes the easy things easier. A common problem for
| these sorts of tools. It is help with the hard things
| that we need.
|
| Edit - I have experience with SwiftUI not React.
| jollybean wrote:
| I don't buy that '10x' gain at all.
|
| React Native doesn't seem to have any degree of
| simplification vis-a-vis regular Android Views for
| example.
|
| On the web - that's a different story entirely, but when
| doing strict comparison I just don't really buy it for
| mobile apps.
|
| The amount of code is similar, but with React you have to
| deal with extra layers of abstraction, and some things
| are obfuscated by the framework. No performance gain and
| often a performance lost.
| dmitriid wrote:
| There are levels to reactivity, and React (and apparently
| Swift UI) are not granular enough. There's an amazing
| presentation that explores reactivity here: https://github-
| com.translate.goog/nin-jin/slides/tree/master... (auto
| translated with Google)
|
| On the web frameworks like Solid.js are exploring these
| fine-grained reactivity approaches to actually re-render
| only what's needed, and not huge chunks of UI
___________________________________________________________________
(page generated 2022-08-28 23:00 UTC)