30k lines of SwiftUI in production later

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.

I am a heavy user of Flutter. Even for simple things if I need to throw together a UI for my own use and then throw it away, I default to Flutter simply because I have become proficient at boot strapping a Flutter project. This is especially true now that they support desktop applications.

For this application, it sounds like the underlying services are not very platform specific, so on that level it seems like Flutter is a good choice. My concern would be that the developers seem very focused on the quality of the experience of even micro-interactions. My experience in Flutter would say that this degree of attention to detail would be hard to get right with Flutter, especially without choosing a platform to focus on, in which case the cross-platform benefits of Flutter are minimized.

Whether delaying an MVP for months to achieve that quality in the user interactions is an interesting side debate, though.

Flutter has massive performance issues, is based on a dead end language nothing else uses that lacks basic features, and worst of all is essentially Google developed.

Native devs are going to make a lot of money rebuilding apps for companies foolish enough to base their entire company on a Google “product”

>> implementing the most challenging parts of your UI as a sanity check

How are you supposed to do this if you don’t yet have proficiency in the language/framework/toolset?

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.

Something else is going on, I have no such delay with @Focus set onAppear { }

You won’t throw any of that away, you can structure your app around SwiftUI and drop in to UIKit for custom controls whenever you want.

This is a good idea for MapKit and web views at the moment, and probably the camera.

> 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 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.

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

Jetpack Compose (Google's alternative on Android, that also works pretty much anywhere you can run a JVM and others like the web [1], terminals[2], powerpoints[3], iOS[4] if you squint, as well as pretty much anywhere you have an imperative API that you want to transform into a functional model[5]) is three years old and is infinitely more polished and has better tools than anything Apple has put out in all of SwiftUI's existence. Apple is bringing this upon themselves with their "major updates" concept for SwiftUI coming every other year, where components aren't even available on old versions of iOS. A UI toolkit is a library like any other, version it like a library and match patch releases.

[1] https://compose-web.ui.pages.jetbrains.team/

[2] https://github.com/JakeWharton/mosaic

[3] https://github.com/fgiris/composePPT

[4] https://touchlab.co/compose-ui-for-ios/

[5] https://github.com/googlemaps/android-maps-compose

> 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.

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 had hoped that with a declarative UI apple would at least create some kind of path to web or android renderering

LOL!

Any other vendor: Big maybe (Microsoft figured out a few iterations late that it might help against being left behind). Apple: Of course not.

Even for their cross-platform services they'd rather make the same app twice than accepting even a 20% higher likelihood that iOS apps also get released on Android.

EvironmentObject is a total foot gun for performance and causes a bunch of other issues. Core Data and SwiftUI are also awkward together. We ended up keeping Core Data at arms length and building our own internal framework to do dependency injection.

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.

This Equals behavior seems terribly unintuitive as well: https://swiftui-lab.com/equatableview/

When an object contains plain data, the equals interface is not used. That would so rough to debug the first time.

This is why: it's hard to get things right. When I started programming for Apple almost 20 years ago (mainly using Objective C), too many hours of my time were spent making sure that I was dealing with memory correctly. Easier in Objective C than C's primitive malloc/free, but still hard, even with the tools to help. During my time there, new things were tried: firstly garbage collection, and then automatic reference counting. This last got rolled into Swift, and hours spent looking for memory leaks or dangling pointers become a thing of the past. It is still possible to have memory problems in Swift, but mostly they can be avoided.

In the case of UI, use of a library is essential. And of course boring technology has libraries. But the real problem is layout: not just where your elements sit on the page, but where they go after the user resizes a window. In the early years, this was not too difficult because screens were mostly fixed size and in landscape mode. But now there are many aspect ratios, four possible orientations and so on. Apples earlier solution was a system called Layout Constraints. Frankly I found them really difficult to use, even when I stuck with the ones provided within Xcode. SwiftUI seems to me the exactly correct way to deal with layout complexity. Admittedly lots of it needs to be improved (as the article points out), but I would much rather use a declarative approach to layout than any alternatives I know of.

My thoughts exactly. With the problems reported in the article, I wouldn't want to use SwiftUI, no matter who else declares it “ready for production”.

I think scrolling has always been an issue with native apps, it’s a fundamentally hard problems to solve on CPU and memory constraints device (although modern phones are neither). Scrolling allows the user to move through huge amounts of data in a very short period of time, loading that data in, rendering it, then animating, all at 30-60fps is difficult.

The reason I suspect people don’t think scrolling was ever an issue (especially on iOS, I doubt Androids will share the same view), is because Apple spent so much time getting it right for the original iPhone. Correctly identifying that scroll behaviour was a kind of “killer app” for touch screens.

But in order to make that scroll behaviour so rock solid. They heavily constrained the problem and did bunch of visual tricks to make it appear smoother that it actually was. Most notably, native scroll views generally required that every individual scroll element was an identical size and shape. So you could cheat during the scrolling process by not actually rendering all the content while scrolling, just rendering the UI chrome (which was identical for every scroll item), and loading the content once the scroll velocity was low enough that there was time to load and render the details before they needed to be displayed.

The other thing that happened, was basically stopping any other compute from occurring. When you scrolled on the original iPhone (and for many generations afterwards), your phone basically dropped everything and dedicated all its compute to just scrolling the view. Not even code to compute the content of scroll elements was executed, you were expected to have done that before the scrolling started. This was most obvious in Safari, where JS execution was halted, and even page rendering was halted, so if you scrolled beyond the boundaries of what had already been rendered, you just got white.

With modern frameworks (and especially the web) there’s been a strong desire to deliver scrolling with a completely arbitrary set of scroll elements, that can all be different shapes, sizes, colours and trigger all manner of background computation. Modern devices are broadly capable of delivering that, but care is needed to exceed the available compute. That’s different from historical native frameworks, where they simply didn’t let people have that kind of flexibility. You got the handful of options the framework gave, and that’s it (which is why older iOS app all had identical scroll UI).

I don't think this is true, I recall an interview with the original Instagram people saying that it was not possible to scroll with that many photos and text being live rendered and they had to fake it with something like pre-rendering the UI as an image and scrolling that.

Scrolling has never been trivial. It’s very hard to build abstractions around it. For example UITableView required quite a lot of boilerplate and manual edge case code. Android’s abstractions have very similar issues.

So no, it’s never been a solved problem just like UI abstractions have never been a solved problem, so solved that there’s nothing to improve or explore.

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.

That isn't true; scrolling (and resizing) was a performance sinkhole for all kinds of apps that used the native table views (NSTableView and NSOutlineView), for many generations of Mac OS X.

They eventually added enough optimizations and performance cutouts to make it pretty easy to not fall in the hole with your app, so it hasn't been a problem with AppKit (or its younger 85% clone, UIKit) for a long while.

But I'm not surprised to hear Apple's much newer and not-very-related UI toolkit still has lots of those problems. That's one of the problems when not many developers actually use a technology — it's not just a popularity contest, having lots of users who complain is how you find a lot of the bugs and performance issues in your UI toolkits and app frameworks.

So lack of popularity often does mean there are probably a lot of those.

Scrolling on SwiftUI is extra bizarre because I often observe weird micro stutter. A scroll view with perfectly static text that never updates will sometimes scroll at what seems to be ~45fps. But really it’s more like it’s randomly dropping 1 out of every 4 or 5 frames or so. It also seems to be related to dragging the scroll view, because programmatic scrolling can be very smooth. (Also SwiftUI was weirdly capped at 60hz and couldn’t do 120hz until iOS16.2. Doesn’t make me confident that SwiftUI will ever get a lot of development love from Apple if it took over a year for SwiftUI to support a flagship feature from the iPhone).

AFAIK, you can also use VS code or CLion.

What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?

You don't have to use Xcode. You can use any IDE that can drive swiftc.

Haha couldnt have said it better.

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.

30k LoC is not a particularly large app. I have SwiftUI apps in excess of 100k LoC and plenty have larger than that.

Just my 2 cents.

But that's where the money's at :(

Native platform development is about going as smooth as possible. Otherwise React Native serves very well for mediocre quality stuff.