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

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

331–340 of 343 posts

Re: SwiftUI After 7 Years

#331

Post by andrekandre »

sirwhinesalot wrote: post #165
rayiner wrote: post #3

The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is…

The problem with ObjC was mainly syntax, bolted on over many years on top of a C core. It was grown rather than designed, and it shows. But there's nothing wrong with the runtime. Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's per…

i love swift, but i can't help but feel the same... after all this time we still can't get good error messages or fast incremental compilation; it just feels like we are boiling the ocean to get largely the same features but handled by the compiler now instead of the runtime (which has a lot of value, but i feel theres a balance to be had there idk)

if they had really just done objective-c without the c like, the original moniker said...

Re: SwiftUI After 7 Years

#332

Post by andrekandre »

troupo wrote: post #222
VerifiedReports wrote: post #135

Earlier quoted context omitted.

"@environment is super cool" Strong disagree on that. @environment is an amateurish hack, basically sugar-coating global variables as a solution to SwiftUI's poor design. I had a strong background in UIKit; then for a product I'm building for myself, I decided to go all-in on SwiftUI. This was after it had been around for four years or more. SwiftUI turned development, which I used to enjoy and feel good about, into…

> Unless your app is a trivial master/detail data-viewing app (as pretty much every SwiftUI example is), And it's pretty much incapable of making anything that is not a master/detail with endless lists within lists within lists. Just look at the shit that Apple regularly ships now: it's just endless lists of lists.

this is basically the settings app in mac os

Re: SwiftUI After 7 Years

#333

Post by andrekandre »

jshier wrote: post #58
emehex wrote: post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

Apple has been adding Observable support to UIKit as well, so it's easier than ever for state to be the source of truth in UIKit too. Anyone writing more than simple UIKit apps has known that for a long time, it's just big a huge pain to actually implement without a lot of custom code or a dependency like RxSwift. If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not…

  > If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.
apple/obj-c had bindings and automatic ui updates more than 20 years ago in appkit; apple could have added that capability to view controllers in ios a long time ago

Re: SwiftUI After 7 Years

#334

Post by andrekandre »

sunnybeetroot wrote: post #97
zer0x4d wrote: post #66

Earlier quoted context omitted.

Yeah I don't really understand their insistence on these videos. I don't have the time to watch an incredibly hard to watch present babywalk me through the code, hoping I'd catch one modifier I missed that fixes the issue. Just write some docs for god's sake.

They update the docs every year. The videos are for people who want a demonstration instead of reading docs and trying things manually to see the result.

  > They update the docs every year.
it doesn't help that docs are utter garbage... the fact everything is slopped into a video is so annoying

Re: SwiftUI After 7 Years

#335

Post by MichaelZuo »

spider-mario wrote: post #322
MichaelZuo wrote: post #319

Earlier quoted context omitted.

I’m not trying to prove anything…? I just don’t care that much either way about what others think if it’s adversarial, even if thousands of HN users come to this comment chain to opine about this or that macbook model. If you mean my claim that some team in Apple already knows about it, there’s literally no way to prove that to passing readers.

> I’m not trying to prove anything…? That’s exactly the point. Why would you expect others to even entertain a vague claim like that if you give them no reason to find it plausible? “Just test it yourself” (test what?) i.e. “prove me right yourself” is not going to be very successful.

[flagged]

Re: SwiftUI After 7 Years

#336

Post by MichaelZuo »

spider-mario wrote: post #323
MichaelZuo wrote: post #318

Earlier quoted context omitted.

Uh are you confused? I’m not the one claiming they refuse to test it, they are the ones who said so.

You are the one refusing to give any detail whatsoever (e.g. what task?) to substantiate your claim.

? You’re not even replying to the relevant comment.

Re: SwiftUI After 7 Years

#337

Post by badsectoracula »

mpweiher wrote: post #326
badsectoracula wrote: post #313

Earlier quoted context omitted.

> The difference is that for most games, throwing away the complete rendered graphics and re-rendering from the world model is often the right approach. Well, that is what "retained mode" GUIs (i.e. those using control/widget trees and such) do too. The immediate mode GUI to me always felt like an approach came up by people who do not really want to bother doing GUIs. In terms of games it is like mixing logic and pre…

> Well, [throwing away the complete rendered graphics] is what "retained mode" GUIs (i.e. those using control/widget trees and such) do too. That turns out not to be the case. The widget tree is retained. When changes come in, the resulting damage from those changes is assessed and then the damaged parts are redrawn in an optimized fashion. https://developer.apple.com/documentation/AppKit/NSView/draw...

This is an optimization that some GUI systems do but it is not inherent to "retained mode" GUIs, does not apply to all systems nor all systems use it. I remember GUI systems even from late 90s/early 2000s composing their widget trees afresh when needed (and in games it was pretty much always the norm for GUI systems to work like that after engine started taking GPUs for granted). Some would limit the refresh to widgets overlapping the damage region reported by the OS (if a compositor was not running, for OSes since Vista) but even that is just an optimization.

On the other hand immediate mode GUIs are inherently like that because that is their core premise.

Re: SwiftUI After 7 Years

#338

Post by mthoms »

MichaelZuo wrote: post #318
mthoms wrote: post #312

Earlier quoted context omitted.

Since when did asking someone to give a single example to support their point become "noise"? How can they do any testing, if you refuse to tell them what to even look for?

Uh are you confused? I’m not the one claiming they refuse to test it, they are the ones who said so.

Tell us what to test.

Re: SwiftUI After 7 Years

#339

Post by mthoms »

MichaelZuo wrote: post #336
spider-mario wrote: post #323

Earlier quoted context omitted.

You are the one refusing to give any detail whatsoever (e.g. what task?) to substantiate your claim.

? You’re not even replying to the relevant comment.

Sure they are. You made this claim:

> My base 2019 macbook pro 15 on Mojave is actually faster than new macbook pros today on some tasks.

Then someone called your bluff and asked you to elaborate:

> Which tasks ? I don't believe your claims.

Yet, you still haven't answered the question. Why don't you just answer the question? Which tasks run faster on a 2019 MBP than a brand new MBP?

Re: SwiftUI After 7 Years

#340

Post by palata »

frizlab wrote: post #330
palata wrote: post #328

Earlier quoted context omitted.

Right. For me I think it is a bit more general than "just" the IDE. For a start, it's painful to install the apps I develop on Apple devices: it's limited in number, so once in a while I have to delete the sample apps I installed. Also I need to "trust the developer" for each app, and apparently more than once (everytime I uninstall the app maybe?), and it requires going through an unintuitive path in the settings an…

> it's limited in number, so once in a while I have to delete the sample apps I installed 10, but only for Apple accounts that are not a part of the Apple developer program (99$) AFAIK > regularly, I have to clean the cache, then clean the hidden cache, then quit Xcode, go and erase some DerivedData, restart Xcode and hope it works Yes and no… I have been an Apple platform developer for ages, and yes, this has been t…

Thanks for all the insights! To be clear, I didn't want to say that developing for Apple is impossible, right?

I totally trust that once you know how to deal with it, it's fine. But it is extremely frustrating to me as compared to pretty much any other system I have ever tried.

And your message seems to confirm my feeling. A bunch of "yes and no", "there is a workaround", "it's gotten better", "that's not ideal".

Just your explanation about the xcode project files being fine... you have to introduce xcodeproj, pbxproj, xchshareddata, xcuserdata, Info.plist, .DS_Store, and xcconfig. With xcconfig presumably making it easier to deal with the rest. I see how you can be comfortable with that system, but... that's more complicated than pretty much everything else I know, be it Rust, or C/C++ with CMake, or Gradle, or Python. Note that Android-Studio doesn't have project files per se, it's Gradle. Just like an IDE could use CMake.

I cannot read those xc files and pretend to understand them. Which is a problem because some of those at least are versioned and need to be reviewed. I can read a build.gradle.kts and understand what it does. For iOS I actually use "xcodegen" which looks a lot more like what I would fine sane. But that's a third-party tool.

Finally there is a difference between a solo developer and a company account. For a company, it's okay to pay the licence, or to have a custom registry. And for employees, it's fine to spend days handling all that because that's part of the job. But I hate having to touch Apple stuff in my free time, because the developer experience is terribly frustrating to me.

> It’s 90 days, and if I’m not mistaken google is also taking this route more and more, no? Locking up the platform, I mean.

Just to be clear: I didn't mean that I like Google, right? :-)

I hate what they are doing there, especially the remote attestation stuff. But I find AOSP pretty good, and open source. I am a GrapheneOS user, and that's the very best mobile OS I know by a long shot. And I owe that to Google releasing AOSP as open source.

Post reply on HN