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

30k lines of SwiftUI in production later

blog.timing.is

Post reply on HN
Print view View original

31–40 of 124 posts

Re: 30k lines of SwiftUI in production later

#31

Post by jb1991 »

SpaghettiX wrote: post #21

> It took a few hours to fall in love with SwiftUI. > It was in development for 12 months. It would have been less if SwiftUI just gave. > At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart. This may be useful to someone trying to create something: In terms of software enginee…

The problem with solutions like Flutter is that many apps, especially iOS apps (though maybe not a calendar app), will often use powerful platform features on iOS that are not so readily available on other platforms, so some degree of platform-specific code is always going to be there -- maybe a lot of such code. For example, the amazing Core Image library, or writing Metal kernels (increasingly common since it is rather easy to leverage GPU compute on iOS and offers tremendous performance benefits), and other tools. If you are going to interact with that in Swift anyway, adding a new language and UI framework and extra layer of abstraction and communication to your app may not make sense.

Re: 30k lines of SwiftUI in production later

#32

Post by jb1991 »

mrtksn wrote: post #14
parker_mountain wrote: post #13

Earlier quoted context omitted.

The first, yes. The second, also yes. The third, also, also yes.

Okay, can you give some details on what's wrong for you? Like what is the better way to do it?

For starters, that Xcode's "vim" emulation doesn't even support arguably the most useful, common, and productive operator in vim -- the dot -- is embarrassing. So many developers depend on vim-like interaction for significant gains in productivity, but Xcode only got about halfway there, and not the better half.

Re: 30k lines of SwiftUI in production later

#33

Post by LudwigNagasena »

GeekyBear wrote: post #18

> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019. Apple (and Next) have been iterating on AppKit for three decades. The UIKit fork of AppKit for iOS is a decade and a half old. Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic. Apple has said that SwiftUI is "where the puck is going" so yo…

Why is it overoptimistic? It’s the same company, they should be able to leverage their past knowledge.

Re: 30k lines of SwiftUI in production later

#34

Post by toyg »

bsaul wrote: post #20

the worst isn't mentioned : not only is swiftui causing all kinds of glitches of it own, but despite being a brand new framework, it still locks you 100% to apple devices. I mean, i had hoped that with a declarative UI apple would at least create some kind of path to web or android renderering, making at least part of the code reusable somewhere. But no, still 100% lockin. Which to me is a HUGE missed opportunity.

What missed opportunity, Apple saw the opportunity right there and took it: the opportunity to reinforce the lock-in they always, always consider imperative to achieve.

People think Apple simply don't care about other platforms, but that's just not true. They do care - they care that developers should stay the hell away from them.

Re: 30k lines of SwiftUI in production later

#36

Post by bsaul »

toyg wrote: post #34
bsaul wrote: post #20

the worst isn't mentioned : not only is swiftui causing all kinds of glitches of it own, but despite being a brand new framework, it still locks you 100% to apple devices. I mean, i had hoped that with a declarative UI apple would at least create some kind of path to web or android renderering, making at least part of the code reusable somewhere. But no, still 100% lockin. Which to me is a HUGE missed opportunity.

What missed opportunity, Apple saw the opportunity right there and took it: the opportunity to reinforce the lock-in they always, always consider imperative to achieve. People think Apple simply don't care about other platforms, but that's just not true. They do care - they care that developers should stay the hell away from them.

i know, it's just completely delusional.

Thinking that a programming language can thrive in a walled garden is insane. They've been burned by this in the past with objc, i don't understand how they can try again.

Re: 30k lines of SwiftUI in production later

#37

Post by lapcat »

LudwigNagasena wrote: post #33
GeekyBear wrote: post #18

> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019. Apple (and Next) have been iterating on AppKit for three decades. The UIKit fork of AppKit for iOS is a decade and a half old. Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic. Apple has said that SwiftUI is "where the puck is going" so yo…

Why is it overoptimistic? It’s the same company, they should be able to leverage their past knowledge.

> It’s the same company, they should be able to leverage their past knowledge.

It's not the same company. Compare 2023 to 2003. Different CEO, mostly different leadership (only Eddy Cue and Phil Schiller remain), massive employee turnover and new hiring. Even the name is different: Apple Inc. vs. Apple Computer, Inc.

https://en.wikipedia.org/wiki/Ship_of_Theseus

Re: 30k lines of SwiftUI in production later

#38

Post by jb1991 »

dmitriid wrote: post #2

What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the battery as your device will doing orders of magnitude more work than necessary. You don't encounter lists of this length as often on web apps, but the same issue would apply if you did -- why do you think infinite scrolling only loads a few rows at a time until you scroll further? And how many times have you been on an "infinite scroll" web and as you scrolled, you had to wait for it to do the work for the next scrollable content. Happens to me often. Now take all those concerns and bundle them in a UI that is suppose to manage all this for you automatically via declarative behavior, and you can see why it's not as trivial as you suggest.

Re: 30k lines of SwiftUI in production later

#39

Post by WA »

jb1991 wrote: post #38
dmitriid wrote: post #2

What amazes me is that scrolling has never really been an issue in any native app? And yet here we are in 2023, with a native framework built for modern devices (where scrolling is the main interaction) that... inherits the worst behaviors of web of all things?

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the…

Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.

Re: 30k lines of SwiftUI in production later

#40

Post by jb1991 »

WA wrote: post #39
jb1991 wrote: post #38

Earlier quoted context omitted.

Scrolling is hardly a solved problem. On iOS, for example, using UIKit which is very mature and performant, to avoid performance issues with a scrollabe table of, for example, thousands or tens of thousands of items, you use an api that recycles UI components to support lazy loading and the lowest memory usage possible in such a scenario. If you jump in to do this naively, it will destroy the user experience and the…

Descriptions like these makes me wonder how we ever made a single computer game with millions of polygons that are in view or not and must be rendered accordingly.

Well at least what you describe would be sitting on a GPU using all the technologies (both hardware and software) developed for precisely that purpose.

Also keep in mind that the battery drain using those technologies to play a game does not scale to a normal mobile app when people expect their phone to be available all day.

Post reply on HN