> It took a few hours to fall in love with SwiftUI.<p>> It was in development for 12 months. It would have been less if SwiftUI just gave.<p>> 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.<p>This may be useful to someone trying to create something:<p>In terms of software engineering, you took "a few hours to fall in love with SwiftUI." There could've been more evaluation done: reviewing existing complaints of SwiftUI, implementing the most challenging parts of your UI as a sanity check, or trying it in a small side project, hiring a developer that has used it before, etc. Also, why count lines of code, as opposed to describing features and challenging technical details. Lines of code doesn't signal anything (e.g. effort, quality, time spent, features, is it code generated?, etc.). Every line is an extra source of bugs.<p>In terms of product development, it took 1 year to ship the product, so after all that, you don't know if you have customers. That's fine for a side project, but this is a "bootstrapped operation behind schedule".<p>Alternative: I hear Flutter is quite productive. If you one to fall in love with technology, you'll like Flutter.
> we wanted to move our entry UI to open in a sheet and with immediate focus on the title TextField, but there’s a noticeable delay before the keyboard pops up. So we didn’t.<p>> when you are editing an entry, we want the title field’s cursor position to be at the beginning. But, alas, not possible.<p>That such basic functionality is not possible is astonishing. Especially the first one should be a common use case.
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 with UIKit and doing all sorts of custom controls and animations, and to abandon that comfort and productivity for another...year?... of a frustrating learning curve does not entice me to give it a try.<p>But I love the declarative paradigm so much; 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, but wow, I cannot get motivated to go down that rabbit hole.
> It could — and really should — have been easier, especially considering SwiftUI has had three major updates since it was announced in 2019.<p>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.<p>Expecting the same level of polish in SwiftUI after three years is a bit overoptimistic.<p>Apple has said that SwiftUI is "where the puck is going" so you can expect that they will keep on iterating on it for many years to come.
SwiftUI and UIKit compose well in both directions, so if you choose SwiftUI as your framework, but then run into a wall, it's an option to partially rewrite that difficult part with UIKit.<p>Of course if the problem is with the core of your application like the scrolling example in the article, this is not going to help you much.
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.<p>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.
Aside from any quirks in the rendering model -- at a more fundamental level I can't imagine what apple is thinking with the observable object data modeling approach -- and what [seems to be plans](<a href="https://forums.swift.org/t/pitch-observation/62051" rel="nofollow">https://forums.swift.org/t/pitch-observation/62051</a>) to expand it ... it feels like the ObservableObject style modeling approach has been tried a million times in various frameworks and always results in complex and difficult to debug systems -- codebases which make it inherently incredibly difficult to reason about "what happens when this data changes"<p>A Unidirectional flow + data flow-like solution makes so much more sense to me as the basis for sane data modeling for ui's ...
Given that a predominant paradigm in apps is the infinite scroll view that receives updates, it’s a tragedy that SwiftUI does not ship with a rock solid implementation and instead succumbs to jitter and scroll-into-view issues.
TLDR:<p>1) Don't watch too much state with Observable/EvironmentObject. When any watched property changes EVERYTHING RELOADS every time.<p>2) ScrollView.scrollTo is bugged with ForEach.<p>3) TextField and keyboard-interactions can be slow and buggy.
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 <i>the</i> main interaction) that... inherits the worst behaviors of web of all things?
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.
Is it possible to write an application of this scale with flutter without (or very little) infecting swift? probably can be written, but I would like to hear comments about what can be experienced in terms of performance and development.
I think the author was just pushing the boundaries of iOS development too much. You could tell in the app that the UI was complex and some guidelines were not followed. This is the consequence when you over engineer and over design and being fancy.