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

111–120 of 124 posts

Re: 30k lines of SwiftUI in production later

#111

Post by jb1991 »

solarkraft wrote: post #108
jb1991 wrote: post #24

I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent wi…

> if only I could easily bring in my toolset of choice, whether it is Elm, Redux, etc, with all the power that native controls on iOS have, that would be awesome. SwiftUI is the only valid answer Time for the obvious question: Why not React Native?

I’d rather go with SwiftUI than resort to a different set of compromises with React Native.

Re: 30k lines of SwiftUI in production later

#112

Post by LudwigNagasena »

GeekyBear wrote: post #90
LudwigNagasena wrote: post #88

Earlier quoted context omitted.

Different tasks require different timescales. It seems reasonable to expect the biggest company in the world with some of the best software developers and UI designers to be able to produce a polished UI library for their own device that runs on their own software and hardware given that they have been developing UI solutions for 30 years.

Microsoft is just as big as Apple. So they should be capable of immediately writing an ARM emulator for their own longstanding Windows API's running on their own hardware, right?

I don’t think that the situations are comparable. ARM/x86 and UI are quite different.

Re: 30k lines of SwiftUI in production later

#113

Post by GeekyBear »

LudwigNagasena wrote: post #112
GeekyBear wrote: post #90

Earlier quoted context omitted.

Microsoft is just as big as Apple. So they should be capable of immediately writing an ARM emulator for their own longstanding Windows API's running on their own hardware, right?

I don’t think that the situations are comparable. ARM/x86 and UI are quite different.

I don't think the time lag between the first release of Windows on ARM in 2012 and finally gaining the ability to (badly) run x86 programs a decade later is comparable.

>I’d have only Slack open, and switching between channels would still take almost three seconds (yes, I timed it on my phone). Spotify, also with nothing in the background, would take 11 seconds to open, then be frozen for another four seconds before I could finally press play. When I typed in Chrome, I often saw significant lag, which led to all kinds of typos (because my words weren’t coming out until well after I’d written them). I’d try to watch YouTube videos, and the video would freeze while the audio continued. I’d use the Surface Pen to annotate a PDF, and my strokes would either be frustratingly late or not show up at all. I’d try to open Lightroom, and it would freeze multiple times and then crash.

It quickly became clear that I should try to stick to apps that were running natively on Arm.

https://www.theverge.com/23421326/microsoft-surface-pro-9-ar...

Re: 30k lines of SwiftUI in production later

#114

Post by GeekyBear »

alexashka wrote: post #97
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…

> Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic Is it? Should I expect my M1 macbook to break in unexpected ways for a decade before it works too? M1 is new, like SwiftUI is new, how come it actually works? Apple devs have stockholm syndrome.

> M1 is new

Leaks of Apple doing test ports of MacOS to it's ARM chips dated way back to 2011.

So, not new at all.

Re: 30k lines of SwiftUI in production later

#115

Post by DelightOne »

newZWhoDis wrote: post #64
DelightOne wrote: post #16

TLDR: 1) Don't watch too much state with Observable/EvironmentObject. When any watched property changes EVERYTHING RELOADS every time. 2) ScrollView.scrollTo is bugged with ForEach. 3) TextField and keyboard-interactions can be slow and buggy.

The trick for 1) is to use @Observed object on a state class inside your app struct then push to views via @Published combine streams so you can map/filter/reduce. Storing massive state in every view/child view/grandchild view is both stupid and wasteful. 2 and 3 I can’t reproduce.

Yep! I currently use Composable Architecture for the same purpose.

Re: 30k lines of SwiftUI in production later

#116

Post by deergomoo »

jb1991 wrote: post #24

I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent wi…

I only have a passing familiarly with iOS development, but I wonder if it would be possible to lay a declarative-ish data binding layer over the top of UIKit?

I mean I guess that’s sorta what React Native does, so it must be.

Re: 30k lines of SwiftUI in production later

#117

Post by akmarinov »

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…

Flutter makes the least sense from all the cross platform technologies.

React Native has 1000s of people with experience in React, with experience in JavaScript/Typescript. There's people with 10+ years of experience.

There's a very small percentage of Flutter devs, since Dart is barely used in Flutter. It being very knew, there's almost no one comparatively.

If you're a company and go with Flutter, you'd be constantly trying to find people for your project.

Even if Flutter is 2x as faster to write code for or 2x as performant than React Native, etc - it doesn't matter if you can't find the people to scale and churn.

Then there's the whole "when will Google kill it" with them doing Flutter and Jetpack Compose and then there's also Kotlin Multiplatform (not from Google), it seems like they're a layoff away from shutting it down.

You know Meta will keep React Native around for decades, since a lot of their stuff is built on it.

Re: 30k lines of SwiftUI in production later

#118

Post by akmarinov »

solarkraft wrote: post #108
jb1991 wrote: post #24

I love declarative UIs and still long for the days I was writing early front-end React apps nearly a decade ago and how amazing it felt for a UI to behave that way. Years later, today I work primarily in iOS and would love to do this on that platform, but every time I read an article like this, my head hurts. Workarounds for workarounds, a great many special cases that are quite unexpected. I've gotten very fluent wi…

> if only I could easily bring in my toolset of choice, whether it is Elm, Redux, etc, with all the power that native controls on iOS have, that would be awesome. SwiftUI is the only valid answer Time for the obvious question: Why not React Native?

I work with a big pharmaceutical company that you've heard of (one of the vaccines), they have a big React Native app that they use to run their studies.

2 years on, their RN devs can't get the app to compile with M1 macs, so they all use Intel macs. They can't update to a recent RN version (recent, not the latest), because a RN navigation library has an issue with it and they're just sitting around, waiting for someone to fix the open source library...

I could go on with the multitude of dependency hell issues they're having.

It's a huge pain.

Re: 30k lines of SwiftUI in production later

#119

Post by akmarinov »

newZWhoDis wrote: post #64
DelightOne wrote: post #16

TLDR: 1) Don't watch too much state with Observable/EvironmentObject. When any watched property changes EVERYTHING RELOADS every time. 2) ScrollView.scrollTo is bugged with ForEach. 3) TextField and keyboard-interactions can be slow and buggy.

The trick for 1) is to use @Observed object on a state class inside your app struct then push to views via @Published combine streams so you can map/filter/reduce. Storing massive state in every view/child view/grandchild view is both stupid and wasteful. 2 and 3 I can’t reproduce.

2 and 3 are fixed in iOS 15+

Re: 30k lines of SwiftUI in production later

#120

Post by akmarinov »

nodemaker wrote: post #95

How does everyone feel about hiring iOS devs in this environment? I feel like its too hard for SwiftUI devs to pick up UIKit when they get blocked and usually they just give up. Also in interviews junior devs have no clue about AutoLayout or UICollectionViews.

I don't know of anyone that calls themselves an iOS dev and doesn't know any UIKit.

Like how would you do a WebView in SwiftUI otherwise? There's a ton of things that SwiftUI doesn't have that you need to go down to UIKit for.

Post reply on HN