I had a similar sentiment as the author here but am a little more bullish on it being ready for production. SwiftUI is clearly the future for Apple, it still has a lot of issues to work out, but you can start using it today pretty easily because there's a nice interface for integrating UIKit with SwiftUI.
There are obvious cons, like (previously) having to learn a new language, Objective-C, which has it's quirks. Documentation may not be very good in some instances. Tooling (Xcode/Interface Builder) may not be as good, or as complete, as tools like Visual Studio.
But of the pros, AppKit/UIKit do A LOT of work for you once you understand things. Things may not be consistent between UIKit/AppKit due to some ability to start over a bit with UIKit plus just different form factors and things, but they are consistent amongst each other and the UI components are all very high quality and flexible. The support libraries are also incredibly good.
SwiftUI should probably be labeled beta given it's not able to do everything UIKit can do, but they've made big strides with the OS releases coming this fall.
Objective-C has been of the worst language I ever had to use. Fortunately it is still possible to use good old C/C++ on iOS/macOS.
As a general rule, I don't like the way Apple wants to drag people into their walled garden, with a tech stack that will be mostly useless outside of it.
Swift is like Objective-C of Metal, we can discuss their respective merits, but it will never hide the fact that they are all bad cases of the infamous NIH syndrome.
I appreciate the author putting this post together. I am, however, having trouble squaring the overall positive tone of the piece with what seem like multiple show stopping problems. The bottom line I am taking away from this is you might not be able to ship your app at all if you use SwiftUI. Am I being too harsh? Or does that seem accurate?
I started building a side project in Swift/SwiftUI for the first time a few months back. It has quite simply been the most painful development experience to date (I've been a professional developer 16 years - front/back/many languages). I've wasted a huge number of days trying to get the damn thing to build reliably, or getting preview to work without hanging the machine or any number of random issues that generally go away if you just rebuild the project enough times... On a side project it's been a real motivation killer, instead of building my app I spend my time trawling through bug reports and trying to find workarounds for broken features. At this point I'm considering starting from scratch with Flutter. /rant
You should, it was the best decision I ever made - comfort and simplicity of writing ObjC (Dart) with an _amazing_ UI toolkit (that hopefully SwiftUI will eventually be if/when it grows up)
Flutter has been the most fun I've had writing mobile apps in a long time. Generally just works and with just a bit more effort you can even get the desktop version of your app running. Definitely recommend for a fun side project.
I’ve tried Flutter a few times and it doesn’t stick. Part of my issue is finding the stock cupertino widgets to look kinda off and the material design widgets to look out of place on iOS. Maybe Flutter is great for when you have a custom design to implement or you’re primarily targeting Android? I also strongly prefer Swift/Kotlin to Dart but I’m sure I’d get used to it.
The author and I have both been in the iOS community for over a decade. We likely have similar opinions that SwiftUI is interesting but still in incubation phase, and that the majority of SwiftUI's focus has been iOS support.
So a post showing how v2 of SwiftUI's limitations is a useful read because it's a reminder that it has more to go on the Mac - I expected that, and I bet he did. So it's positive in the sense that he wasn't disappointed, but that it met the (admittedly low) expectations of the author
The comments mainly relate to the Mac OS implementation, which is clearly very early and not fit for production. As he points out the iOS version is more stable. The company I work for are already shipping a SwiftUI iOS app, and plan another one.
I've been using SwiftUI for design and prototyping since release on iOS, to the point where it's faster for me to prototype on SwiftUI rather than Figma or Sketch. Particularly with animations and overall experience.
The problem for new people is the error reporting is still pretty bad, and it gets flakey if your views are too big. The key is to keep views small and compose them. It's also hard moving to a declarative model for UIKit devs who haven't done React.
Been writing an macOS app from scratch in SwiftUI (VM manager) and I can echo much of these concerns. Especially the random crashes and performance. Some other random issues I’ve ran into:
* Different Betas changing the layout and style and meaning of different attributes. The change isn’t so bad as the documentation. Most of the functionality is sparely documented so it’s impossible to tell if something “broke” or was “fixed” in a new beta. Stuff like .overlay() vs ZStack and how they appear. Stuff like how .padding() is calculated with the default args. Stuff like what the default list modifier does.
* Last beta forgot to ship some symbols in SwiftUI.framework and .toolbar (a modifier to draw a toolbar) was missing. The fact that it slipped notice and nobody talked about makes me suspect nobody is actually using it.
* Common functionality like creating a new window with a different layout is missing. In fact it seems to revolve iOS where new window means same view in a new window.
* Weird quirks like if you dismiss a modal sheet before falling a background task would cause layout issues and random state changes. But if you dismiss the sheet after calling GCD it doesn’t happen. It’s likely a race condition somewhere. Another example https://stackoverflow.com/questions/58404725/why-does-my-swi...
* Missing components like the activity indicator and the new settings tab design for TabView
* You either have no control over the layout or so much control it overwhelms you. For example if you wrap a View with Form it generates a right justified label and left justified field. It works for checkboxes and pickers but it doesn’t work for every component. If you want the same alignment for everything you have to throw away the work done by Form and completely define your own layout rules for everything.
* If you look up how to do anything, the “accepted” answer always feels hacked together and nobody can explain why it works. For example, if you look up how to force center alignment on any object there’s a blog post that’s about 20 pages that propose some solution that’s 200 LOC.
* Day to day, I feel very limited by the framework. At almost every point, I had to compromise the design vision with “what’s possible” in SwiftUI. And note this is a very “simple” app that manages VMs and allows you to change settings. Everything uses basic controls and there’s nothing exotic.
All this aside I still enjoyed using SwiftUI on most days. When it works, it feels like the future. Unfortunately v1/v2 is still very early and it’s filled with bugs. But people need to use it to find and report the bugs. I hope, like Swift, we’ll eventually be at a point where everyone uses it because it’s an upgrade from the previous technology without any compromises.
I suspect many of the cases where things are not documented as to what they'll produce or how the layout will look are intentional, as SwiftUI seems to have the (somewhat idealistic) goal of "looking right" and not only does it have to infer intent from what you've written it also needs to be flexible enough to adapt to Apple's design roadmap for the future. So there's no documentation, not only because there are so many special case quirks they've added to support layouts that are considered "best practice design" in UIKit that nobody can really keep up or discover, but also because if they tie something down too much they won't be able to change it to a new design or paradigm. I suspect that they really want for 2022 to roll around and be able to come out on the stage at a WWDC and say that all apps using SwiftUI already get support on their new AR headset, and all standard controls have been mapped to analogues on that platform. If you document NavigationView as being a vibrant view on the top with a large title and a scroll view under it, you can't do this.
Many of the bugs probably have more to do with the unshippability of macOS at the moment.
The author’s takeaway here is “If your target platform is iOS 14, you’re now good to go with hobby projects or individual screens in SwiftUI.”
I think that’s generally pretty reasonable but in my experience you won’t even be able to reach the end of your hobby app without hitting some wall where a feature you want is simple in UIKit and not supported at all yet in SwiftUI. SwiftUI is great, the paradigm is refreshing but unfortunately it just isn’t ready yet.
The way I've been doing it is to mix the two frameworks together and that seems to be working out, it's easy enough to wrap UIKit views in a SwiftUI project or go the otherway and introduce some SwiftUI components to a UIKit app. I feel we won't see "complete" SwiftUI apps for another 2 years or so, maybe thats the intention?
Building clients on other platforms makes you appreciate the freedom we have on the web.
Instead of waiting for Apple to fix SwiftUI, it's completely viable to bring your own abstractions, from React to Reason to Elm, to the web. And the cottage community that works on the most niche web abstraction is bigger than the Apple team allocated for SwiftUI.
It has its downsides, and sometimes we're all too eager to beat the drum of how bad the web can be, but it's also important to recognize the web as a fluke of history where we still have some control.
That said, I give Apple some credit for moving their own platform forward in a way that clearly borrows from what we've been doing with things like QML and React. I look forward to the day when my SwiftUI apps work well on both macOS and iOS. And it will be interesting if we reach a point where we don't need UIViewRepresentable because APIs like WKWebView have been adapted for the new declarative model.
I'm not really a developer myself, but I get the impression there's plenty of long-time Mac developers who like/enjoy making Cocoa apps with Objective-C and Swift, particularly in comparison to doing the same on Windows.
Outside of web-based technologies, what would you consider a "desirable option" for making UIs?
We do, but, it's mostly because we were raised on it and have a lot of ingroup memes for discrediting other options - my company forcing me to work outside iOS for the first time in several years was a real eye-opener.
I don't think Apple developers have the experience to see how far behind SwiftUI is and how little chance there is of them catching up, and I don't think non-Apple developers have the experience to see there's very little 'special' to ObjC or Swift.
Hmm, I don’t recognise this characterisation. I have been a web front-end specialist for quite some time, and have also developed large-scale native UIs for both macOS and iOS. My perspective would be that there is no clear winner. The Apple environment is absolutely _miles_ ahead of the web platform in several respects; the web offers greater flexibility that comes with a corresponding cost.
I’d agree at least that platform-specific developers can often keep themselves far too isolated. They really should be making an effort to work cross-platform as much as possible, because learning about the different patterns and techniques used in different environments is an incredible force multiplier.
As someone who is also a front end dev, can you share more? I’ve been getting into Swift development on my free nights, but between the horrendous Xcode IDE errors / lag and learning the ins and outs of a new strongly typed language, it makes me hug my vscode / js environment tighter to my chest
Maybe I'm conflating 'web framework' with 'anything that compiles down to JS'? It's impossible for me to think of areas where iOS dev felt miles ahead, but I can imagine if I was writing JS I'd feel that way (I'm really into Flutter lately)
Picking some features I like entirely at random: libdispatch, Core Data, comprehensive accessibility support, SpriteKit, Core Video, ARKit… basically, there are lot of powerful and reasonably consistent APIs (with good performance) that really make a bunch of development much more tractable. Some of these can be replicated on the web platform; others can't.
In any case, I'd assume those miles are only gained on iOS where Apple has gimped the newer web APIs.
I'm sure you appreciate why that kind of attitude is a bit silly and serves to demonstrate the exact effect I was initially talking about.
There's no way you think Apple is miles ahead on async programming and ORMs, the iOS community has been clamoring for replacements for both for years and there's _plenty_ of web libraries for both.
The rest looks like it's focused on graphics/stuff you wouldn't do on the web anyway - yes, the fact it's impossible on the web _means by definition Apple is miles ahead_, but claiming Apple is overall miles ahead on dev experience because of AR and video bitstream manipulation APIs is a bit blinkered, given very few developers get to use those APIs.
We’d like a swift version of Core Data (a graph of objects), not a ORM. For async programming we have GCD and reactive libraries, async await is on master already, a design document is expected this month.
> Picking some features I like entirely at random: Yada1, Yada2, Yada3...
Those are not features. Those are names of developer libraries.
What do you think they can do that's so much better?
> I'm sure you appreciate why that kind of attitude is a bit silly...
Apple clearly nerfs the web on iOS and there's nothing silly about acknowledging that. It's actually kinda silly pretending that they don't xD
> and serves to demonstrate the exact effect I was initially talking about.
Hmm, that's not very clear at all. You said "platform-specific developers can often keep themselves far too isolated", but the web isn't "platform-specific" it's 100% cross-platform and that's why Apple hates it.
Table views are the most striking example. Native table views were designed from the start to lazily load items, and so can trivially support very large lists.
The web has no APIs for this. Instead laziness is tacked on through JS, and invariably breaks find, scrolling, etc. Try scrolling to the bottom of your Chrome history: the scrollbar jumps and it's often not clear if/when you reach the bottom.
UITableView was a solved problem on the web by 2014 at the absolute latest.
iOS has scrollbar jumps unless you know the rendered height of every list item and the complete count of list items in advance (which is why Chrome jumps, it doesn't know the entire length of your web history, it's loading it in batches)
Of course Chrome knows the length of your web history: it's a trivial SQLite call. They just can't display it naturally, because there are no browser-provided APIs for lazy tables.
I do not agree that the JS implementations have "solved" lazy tables: they're all invariably broken. For example if you hit cmd-A to Select All, Chrome history just selects what is faulted in. If you scroll down eventually you find unselected items. Safari doesn't have this problem and the main reason is its use of native tables instead of web tables.
I agree this is a big hole in SwiftUI as well. A lazy table requires cooperation between the framework and the app, which is an awkward fit for declarative UI frameworks like SwiftUI and the web.
While it's not built in, this is totally solvable in a performant way on the web. Fastmail's web UI lazy loads in mailbox lists of messages (which for some users can be 1,000,000+ items long). The scrollbar is correct and you can jump to an arbitrary point. You can select all. We've had this for, I dunno, 7+ years now?
Fastmail is indeed a radical outlier on this front, by far the best of the bunch. Its lazy tables are still broken (Find and Print for example) but they get scrolling right, and that is significant.
It's not at all representative of the experience of using Gmail, Ymail, Hotmail. The web requires heroics to get quality.
Also, just having a standardized way to do a lot of things.
One such example is menus. Just about all Mac apps — even ported stuff using third party UI toolkits — hook into the standard menubar APIs, which means that every menu item of every app can have a key shortcut assigned (or reassigned) in System Preferences, even when the app's dev never bothered to add such configurability. Similarly, accessibility and scripting APIs can reliably grab the menu items of any app, improving automation and interoperability. One could probably even write a full replacement for the macOS global menubar without much fuss.
Compare this to Windows and Linux where it's quasi-normal for apps to implement menus their own way or eschew them altogether — there is no single way to grab menu items, just a ton of different possible ways, and if an app dev has decided to do their own thing you're just SoL.
- ARC looks like a mistake in retrospect - you trade 'GC overhead' for memory leaks
- keeping autolayout _and_ absolute frames looks like a mistake: a significant portion of SwiftUI overhead is spent in autolayout
- after working with Swift and _loving_ it between Swift 1 and 4, seeing the issues and watching Apple staff up and get more rigorous to solve them, stapling SwiftUI right now is unconsciable
- it requires contorting the language spec and the slow speed removes the one benefit of all the other frameworks, hot reload on device.
- Apple seems confused because they can _enumerate tractable work that would improve SwiftUI_, but the sum of that work is large enough to place a real, performant, cross platform Swift UI O(years) out (c.f. Swift's stable ABI clusterfoo)
At this point I actually prefer the cocoa methods of creating UI. This kind of tech also affects the architecture of the app that is utilising it - SwiftUI and the like seem to be quite prescriptive in terms of application structure, whereas with cocoa I feel that I have a lot more possibilities.
So are you developing for the sake of the process or for the sake of the result? The result is always faster and lighter if you don't pile additional abstraction layers on top of whatever your platform offers (DOM for web and Cocoa/AppKit for macOS).
Or one of the various alternatives... Flutter, React Native, Cordova, maybe a few others. There are also game app engines for games and game-like apps).
There are definitely fewer decent alternatives than for the web, but you aren't exactly starved.
Also, the context here is bug fix release cycles... no matter what you choose there will be bugs and release cycles that don't always match what you want for your app.
I think its cool if you have this high-level abstractions that help in productivity as long as you have a 'fallback mode' to a more powerful api.
This is even true for script languages for instance. This is what make Javascript or Python more powerful than the language let them be. Being able to 'fallback' to C if things are not working the way they should.
Having SwiftUI or React are ok, if you can call imperative UIKit api's or web DOM when you need it.
Im very skeptic that this model will be feasible for the more "hardcore" cases of applications. So its important to have a powerful way to control things in details.
In hindsight, the modularity and the power that the web UI api gives you today is something to admire.
Its hard to have other examples where the bazar model ended up with better tools than the cathedral model. Especially if the cathedral model had time to do it later with the technological advantage only experience gives you.
How can this possibly be true? Web UI frameworks are built on top of the browser platform, and browsers are built on top of native desktop platforms, so aren't native desktop platforms inherently more flexible than web UI frameworks?
Browsers largely aren't taking advantage of native UI frameworks (aside maybe from the window chrome and basic controls). Aside from the minimum required to get an OpenGL context (or whatever graphics tech) onto the screen they don't need to build on native UI.
Sure, they're technically building on top of the native UI frameworks, but only by completely ignoring all of their functionality.
I am by no means an expert in graphics architectures so I'm sure someone will be able to explain this better and more correctly than I can. But as I understand it, "native" is itself a layered stack of APIs as you can see in this diagram:
UIKit/AppKit is layered on top of Core Animation which is layered on top of Metal. Skia, the 2D graphics library that Chrome's rendering engine uses, is built on top of Metal (or at least transitioning to Metal from OpenGL on macOS).
So browsers have the same flexibility in principle as native UI toolkits and they are just as close to the metal. There is no inherent disadvantage. But flexibility is a double edged sword. It includes the ability to diverge from the platform look & feel. So that's where the debate has been raging on for decades.
In terms of performance I think any debate about optimisation of UI stacks pales in comparison to the question of where the data lives, who generates it, and how it gets to the CPU/GPU for processing and display.
Saying that "both use Metal and have layers in between therefore they are largely at the same place" doesn't really work, because the abstraction layer that they expose is at a vastly different place and the internal pipeline for both is also very different.
The converse is webassembly+webgl. There are different cases where i.e. SDL-based games are being ported to "Web" also Qt provides WebAssmebly support.
Developing GUIs in various form factors since the late 80's and I rather have a window context to draw whatever I need than faking menus with list items.
Project Houdini, WebGL + Web Assembly for the second coming of Flash alike tooling is thankfully already taking off.
Any software developer using any software released by Apple within it's first 2-3 years is a free beta tester.
Swift's core team recently found out that they don't understand the type system they've created - they were fixing compiler 'bugs' for months without getting anywhere, until one of them finally realized hey, I should probably attempt to understand what we've built, not just 'fix' a never ending stream of bugs we seem to be having.
Turns out, the type system they built guarantees 100% that type checking is undecidable (in software developer terms, you can crash the compiler by typing perfectly legal Swift code and nobody at Apple knows how to fix it without breaking existing code because they didn't even know they built a language that has this property up until very recently). They figured this out after announcing a stable ABI by the way. Upon discovery, some of the core team members said the discovery was great/nice work.
It's not like we have people who use mathematics to prove properties of type systems without any shadow of a doubt or anything. I wonder how many of them are working on Swift or are employed at Apple, within their multi-billion dollar R&D budget... I wouldn't at all be surprised if the answer was zero, given that it was a software developer who knew a little math who made this discovery.
The tone sounds histrionical because it is way ahead of the herd's perception. It's been terrifying to have feet in multiple communities, have a strong foot in Apple's community, and see how things are done over there and gotten worse over the years, particularly after Swift's release.
You raise an interesting point, but it is my understanding that Swift is by far not the only language that has a shaky foundation in terms of type theory. Other type systems can at least be unsound, I don't know if any of them is undecidable.
Even so, "undecidable" doesn't need to be a problem. It would be possible that the undecidable Swift program is such a random mess that nobody would be likely to write it by accident.
However, it is worth looking into more practical aspects of how Swift's type system works, and there I share your concerns. Swift is the _only_ language I have ever used where I have ever seen the error message "the type checker was unable to infer the type of this expression" etc. - sometimes on dead simple code. Worse, I once tried to write an expressive, generic, functional framework, only to discover that it was completely unusable because the type errors that Swift returned were simply wrong and to fix it you had to put in type annotations in a bunch of places (without necessarily knowing where, just from the error messages), making the whole API extremely verbose and not particularly declarative anymore.
> You raise an interesting point, but it is my understanding that Swift is by far not the only language that has a shaky foundation in terms of type theory. Other type systems can at least be unsound, I don't know if any of them is undecidable.
> the type errors that Swift returned were simply wrong and to fix it you had to put in type annotations in a bunch of places (without necessarily knowing where, just from the error messages)
> Turns out, the type system they built guarantees 100% that type checking is undecidable (in software developer terms, you can crash the compiler by typing perfectly legal Swift code and nobody at Apple knows how to fix it without breaking existing code because they didn't even know they built a language that has this property up until very recently).
Undecidability means there's no algorithm that is guaranteed to terminate, not that any algorithm will crash. In this case, using a completion procedure to convert the same-type constraints into a confluent rewrite system should be sufficient. If completion fails an error can be diagnosed. This shouldn't break any real code in practice.
> Turns out, the type system they built guarantees 100% that type checking is undecidable
Someone found this in Java as well. Accidental Turing completeness crops up everywhere, it's actually rather hard to ensure decidability. It's a favorite pastime of people in this area; I'm somewhat disappointed you didn't find it to be interesting. In any case, personal attacks against the Swift compiler engineers (many who are quite competent at the things you are claiming they are lacking) are not appropriate.
It's not quite that simple, OP is right, pace on Swift improvement slowed to a crawl for 3? years now as they played whack-a-mole with type inference and got to stable ABI. It was only supposed to take a year, and, it's utterly __shocking__ to find out the type inference whack-a-mole intractable _after_ pushing the stable ABI.
Working at FAANG is an abject lesson in learning that assuming 'competence' (i.e. knowing mastery-level detail, taking responsibility everywhere, and going off on world-creating tangents rather than fixing bugs) is damn rare, nearly all of my career's achievements have come of accepting that and doing deep dives into problems.
The issue OP mentioned is certainly not intractable to fix, and in general type inference doesn't have much to do with the stable ABI. The ABI work was about refactoring some compiler internals and implementing library evolution support, which as far as I'm aware is unique among statically-compiled languages: https://swift.org/blog/library-evolution/. There was also a lot of work on code size improvements, runtime memory usage, and compilation time. The pace at which language features are added is not the only valid measure of language development.
Those are all arguments your team has been repeating for a while, and I used to be amenable to, but am no longer given the amount of time that has elapsed.
Something is pretty broken over there, and it's especially not charming to read the team chiming in with 'lol haskell too!' - can I bill you for the type inference crashes and workarounds I've had to do because no one bothered saying anything until August 2020? https://twitter.com/krzyzanowskim/status/1305579668104331264...
I'll be happy to admit I'm wrong when Swift UI 2021 is rendering lazy lists just fine on Mac and iOS, otherwise, its just me hearing about ARC optimizations for the 50th time and trusting it.
https://twitter.com/jckarter/status/1305562770859933696?s=20
> it's actually rather hard to ensure decidability
How is it that a single person named Edwin Brady can think of, implement and have a programming language with a decidable type system that is more complex than Swift, working on it part-time?
I'm sorry, I consider a company worth a trillion dollars, sitting on billions of dollars it doesn't know what to spend on, that spends billions per year on R&D, to know the basic properties of the type system their most actively developed programming language uses.
By focusing entirely on the type system rather than building a programming language usable for actually building applications. Idris is a wonderful research language, but is awful as a language to write production software in.
I spent a month working on a SwiftUI app back in April. I hit a point where I was frustrated that I was wrestling with the limitations of the framework. I put the project on hold and was considering moving to React Native or UIKit.
I revisited the project after WWDC and found that some of the things I was frustrated with were improved and others just required a break and a fresh perspective to figure out. I recommend SwiftUI.
> These wrappers can cause issues, and as they’re written in Swift, there aren’t many possibilities to fix issues from the outside (unlike with swizzling in the earlier days).
I assume based on this Swift code can't be swizzled for some reason?
Swizzling uses the Objective-C runtime, which in turns handles the message passing mechanism. Unless you inherit from an NSObject, you can’t swizzle in Swift.
Unless you're building something on your own, in which case there is an (unoffically supported) attribute which you can use to opt-in to swizzling of methods. The difference being you have to opt-in, so you can't swizzle someone else's methods (unless they let you).
UIKit was a beautiful design: a thin wrapper for touch handling over CoreAnimation's butter-smooth rendering. A layout engine built from first principles (the Cassowary linear constraint solver) rather than some organically grown pile of hacks like the CSS box model or flexbox.
I'm fairly certain that the elegance and flexibility of the UIKit model, and its uncompromising focus on user experience over developer experience was a key contributor to iOS's success over its competitors.
I'm very sad that with SwiftUI Apple gave in to the tide and started catering to React devs with this gimmick immediate-mode framework on top of their existing retained-mode toolkit. The original NeXTSTEP engineers wouldn't have let this happen...
Craig Federighi also mentioned in an interview that the declarative model with bidirectional bindings was influenced by work at NeXT, referring to WebObjects.
I wonder if it's worth developing Mac applications anymore.
Apple's policies are hostile to its own developers (increasing restrictions on third party apps, the app store) and SwiftUI is not ready yet (for Mac development). I'm mad at Apple a lot. Why give them my time?
Because all of the fake-native apps absolutely suck and personally I am (genuinely) way the heck more likely to pay for your product or service if you offer me a real application.
Thank you for this post. I'm brand new to ios dev and I was contemplating Interface Builder vs SwiftUI, and hesitatingly went with Interface Builder. This article makes me feel a little better with the decision.
If you want to get a job you’ll likely need IB anyway. The core of SwiftUI is small enough right now that you can look into it on the side and wait another year for it to mature.
I’d say that waiting a few years for stability is not so different from past paradigm shifts.
Recall the early days of Mac OS X. It is easy to look back at something like version 10.6 and see how “nice” AppKit worked but it had already evolved quite a bit by then, over many years. If you go back further, like 10.2, you see many rough edges as the APIs were rapidly evolving.
In the beginning, Cocoa was clearly powerful but also surprisingly lacking in some areas compared to Carbon (at least, from a Mac-like UI point of view, as opposed to NeXT). Interface Builder had different UI element libraries for both APIs. Even the common UI elements between the two APIs were not necessarily identical: there were things you could do in one API but not the other. Furthermore, converting a Carbon program to a Cocoa program was a monumental task, requiring things to be downright rewritten for just a basic Cocoa foundation to work properly.
The big difference this time, in favor of Swift and SwiftUI, is that it is possible to integrate brand-new stuff very quickly. Right now, I can integrate: Objective-C, C++, AppKit, Swift, SwiftUI, and a wide variety of other things, and they all compile and link and run. There is nothing requiring me to rewrite 98% my Objective-C app just to integrate my first SwiftUI View. While YMMV, compared to past endeavors this appears to be a much more practical solution for jumping to a new technology.
> version 10.6 and see how “nice” AppKit worked but it had already evolved
I started programming on NeXT in 1991 and AppKit was already very nice (not "nice") back then.
Target/action, for example, was a revelation, together with the responder chain. Miles ahead of everything at the time as well as most if not all the stuff that followed. Now we're back to tightly coupling everything and calling it "progress".
He interpreted the Instruments profiling incorrectly. The biggest cost (2s) is coming from `closure #1: in ViewRendererHost.render(interval:updateDisplayList:)`
> Of the 10 seconds captured, 30 percent of them are used for the various retain/release and malloc calls in Swift and Objective-C
This is not indicated in the profile screenshot, though I will concede that perhaps it's showing up from the "inverted" view or something.
It's amazing just how little effort and code is required to build complex scalable layouts that Just Work.
Yes, it does require you to Think Different and you will have to change how you approach UI design if you're coming from legacy frameworks.
That's where the most frustrating aspect of SwiftUI lies, apart from the early bugs and lack of consensus, and this is where some people give up: having to change how you think. Just like Swift itself.
I was very excited about SwiftUI and spent a lot of time learning from videos and articles. In theory it's awesome and I was ready to create my first project. Most Apple docs, videos and evangelists talk about how easy it is and coming from React I was already familiar with the pattern.
Sadly, excitement lasted 1 month after I realized that it's not ready. Obscure error messages, random bugs in controls and other annoyances turned my initial excitement into frustration. I managed to make things work but had this feeling of it being fragile.
Incemening and decrementing is almost free, the cost is in allocating and releasing memory. If you allocate and release so many objects this starts to be an issue like here, with a GC the memory usage would be at the level of an Electron app.
Only for developers that lack the understanding that just because there is a GC that doesn't mean there aren't other means to manage memory, e.g. D, Nim, C#/F#/VB, Eiffel, Go.
116 comments
[ 3.9 ms ] story [ 165 ms ] threadI had a similar sentiment as the author here but am a little more bullish on it being ready for production. SwiftUI is clearly the future for Apple, it still has a lot of issues to work out, but you can start using it today pretty easily because there's a nice interface for integrating UIKit with SwiftUI.
But using a thin font in grey on a white background makes that quite impossible.
Please have some pity on people whose eyes aren't perfect.
https://beta.trimread.com/articles/38118
(you can also go to the main page of this site and enter the URL there)
Most people tend to confuse good design and good software, unfortunately.
There are obvious cons, like (previously) having to learn a new language, Objective-C, which has it's quirks. Documentation may not be very good in some instances. Tooling (Xcode/Interface Builder) may not be as good, or as complete, as tools like Visual Studio.
But of the pros, AppKit/UIKit do A LOT of work for you once you understand things. Things may not be consistent between UIKit/AppKit due to some ability to start over a bit with UIKit plus just different form factors and things, but they are consistent amongst each other and the UI components are all very high quality and flexible. The support libraries are also incredibly good.
SwiftUI should probably be labeled beta given it's not able to do everything UIKit can do, but they've made big strides with the OS releases coming this fall.
As a general rule, I don't like the way Apple wants to drag people into their walled garden, with a tech stack that will be mostly useless outside of it.
Swift is like Objective-C of Metal, we can discuss their respective merits, but it will never hide the fact that they are all bad cases of the infamous NIH syndrome.
So a post showing how v2 of SwiftUI's limitations is a useful read because it's a reminder that it has more to go on the Mac - I expected that, and I bet he did. So it's positive in the sense that he wasn't disappointed, but that it met the (admittedly low) expectations of the author
I've been using SwiftUI for design and prototyping since release on iOS, to the point where it's faster for me to prototype on SwiftUI rather than Figma or Sketch. Particularly with animations and overall experience.
The problem for new people is the error reporting is still pretty bad, and it gets flakey if your views are too big. The key is to keep views small and compose them. It's also hard moving to a declarative model for UIKit devs who haven't done React.
* Different Betas changing the layout and style and meaning of different attributes. The change isn’t so bad as the documentation. Most of the functionality is sparely documented so it’s impossible to tell if something “broke” or was “fixed” in a new beta. Stuff like .overlay() vs ZStack and how they appear. Stuff like how .padding() is calculated with the default args. Stuff like what the default list modifier does.
* Last beta forgot to ship some symbols in SwiftUI.framework and .toolbar (a modifier to draw a toolbar) was missing. The fact that it slipped notice and nobody talked about makes me suspect nobody is actually using it.
* Common functionality like creating a new window with a different layout is missing. In fact it seems to revolve iOS where new window means same view in a new window.
* Weird quirks like if you dismiss a modal sheet before falling a background task would cause layout issues and random state changes. But if you dismiss the sheet after calling GCD it doesn’t happen. It’s likely a race condition somewhere. Another example https://stackoverflow.com/questions/58404725/why-does-my-swi...
* Missing components like the activity indicator and the new settings tab design for TabView
* You either have no control over the layout or so much control it overwhelms you. For example if you wrap a View with Form it generates a right justified label and left justified field. It works for checkboxes and pickers but it doesn’t work for every component. If you want the same alignment for everything you have to throw away the work done by Form and completely define your own layout rules for everything.
* If you look up how to do anything, the “accepted” answer always feels hacked together and nobody can explain why it works. For example, if you look up how to force center alignment on any object there’s a blog post that’s about 20 pages that propose some solution that’s 200 LOC.
* Day to day, I feel very limited by the framework. At almost every point, I had to compromise the design vision with “what’s possible” in SwiftUI. And note this is a very “simple” app that manages VMs and allows you to change settings. Everything uses basic controls and there’s nothing exotic.
All this aside I still enjoyed using SwiftUI on most days. When it works, it feels like the future. Unfortunately v1/v2 is still very early and it’s filled with bugs. But people need to use it to find and report the bugs. I hope, like Swift, we’ll eventually be at a point where everyone uses it because it’s an upgrade from the previous technology without any compromises.
Many of the bugs probably have more to do with the unshippability of macOS at the moment.
I think that’s generally pretty reasonable but in my experience you won’t even be able to reach the end of your hobby app without hitting some wall where a feature you want is simple in UIKit and not supported at all yet in SwiftUI. SwiftUI is great, the paradigm is refreshing but unfortunately it just isn’t ready yet.
> I feel we won't see "complete" SwiftUI apps for another 2 years or so, maybe thats the intention?
Unsure about intention but it is definitely the expectation :)
Instead of waiting for Apple to fix SwiftUI, it's completely viable to bring your own abstractions, from React to Reason to Elm, to the web. And the cottage community that works on the most niche web abstraction is bigger than the Apple team allocated for SwiftUI.
It has its downsides, and sometimes we're all too eager to beat the drum of how bad the web can be, but it's also important to recognize the web as a fluke of history where we still have some control.
That said, I give Apple some credit for moving their own platform forward in a way that clearly borrows from what we've been doing with things like QML and React. I look forward to the day when my SwiftUI apps work well on both macOS and iOS. And it will be interesting if we reach a point where we don't need UIViewRepresentable because APIs like WKWebView have been adapted for the new declarative model.
Outside of web-based technologies, what would you consider a "desirable option" for making UIs?
I don't think Apple developers have the experience to see how far behind SwiftUI is and how little chance there is of them catching up, and I don't think non-Apple developers have the experience to see there's very little 'special' to ObjC or Swift.
I’d agree at least that platform-specific developers can often keep themselves far too isolated. They really should be making an effort to work cross-platform as much as possible, because learning about the different patterns and techniques used in different environments is an incredible force multiplier.
Such as?
In any case, I'd assume those miles are only gained on iOS where Apple has gimped the newer web APIs.
Picking some features I like entirely at random: libdispatch, Core Data, comprehensive accessibility support, SpriteKit, Core Video, ARKit… basically, there are lot of powerful and reasonably consistent APIs (with good performance) that really make a bunch of development much more tractable. Some of these can be replicated on the web platform; others can't.
In any case, I'd assume those miles are only gained on iOS where Apple has gimped the newer web APIs.
I'm sure you appreciate why that kind of attitude is a bit silly and serves to demonstrate the exact effect I was initially talking about.
The rest looks like it's focused on graphics/stuff you wouldn't do on the web anyway - yes, the fact it's impossible on the web _means by definition Apple is miles ahead_, but claiming Apple is overall miles ahead on dev experience because of AR and video bitstream manipulation APIs is a bit blinkered, given very few developers get to use those APIs.
Those are not features. Those are names of developer libraries.
What do you think they can do that's so much better?
> I'm sure you appreciate why that kind of attitude is a bit silly...
Apple clearly nerfs the web on iOS and there's nothing silly about acknowledging that. It's actually kinda silly pretending that they don't xD
> and serves to demonstrate the exact effect I was initially talking about.
Hmm, that's not very clear at all. You said "platform-specific developers can often keep themselves far too isolated", but the web isn't "platform-specific" it's 100% cross-platform and that's why Apple hates it.
The web has no APIs for this. Instead laziness is tacked on through JS, and invariably breaks find, scrolling, etc. Try scrolling to the bottom of your Chrome history: the scrollbar jumps and it's often not clear if/when you reach the bottom.
iOS has scrollbar jumps unless you know the rendered height of every list item and the complete count of list items in advance (which is why Chrome jumps, it doesn't know the entire length of your web history, it's loading it in batches)
Funnily enough, _SwiftUI doesn't support lazy table views_. Seriously. It's nuts.
I do not agree that the JS implementations have "solved" lazy tables: they're all invariably broken. For example if you hit cmd-A to Select All, Chrome history just selects what is faulted in. If you scroll down eventually you find unselected items. Safari doesn't have this problem and the main reason is its use of native tables instead of web tables.
I agree this is a big hole in SwiftUI as well. A lazy table requires cooperation between the framework and the app, which is an awkward fit for declarative UI frameworks like SwiftUI and the web.
It's not at all representative of the experience of using Gmail, Ymail, Hotmail. The web requires heroics to get quality.
macOS accessibility features alone have generally been light years ahead of Windows, for over a decade.
One such example is menus. Just about all Mac apps — even ported stuff using third party UI toolkits — hook into the standard menubar APIs, which means that every menu item of every app can have a key shortcut assigned (or reassigned) in System Preferences, even when the app's dev never bothered to add such configurability. Similarly, accessibility and scripting APIs can reliably grab the menu items of any app, improving automation and interoperability. One could probably even write a full replacement for the macOS global menubar without much fuss.
Compare this to Windows and Linux where it's quasi-normal for apps to implement menus their own way or eschew them altogether — there is no single way to grab menu items, just a ton of different possible ways, and if an app dev has decided to do their own thing you're just SoL.
- Flutter is the runaway winner, in general
- ARC looks like a mistake in retrospect - you trade 'GC overhead' for memory leaks
- keeping autolayout _and_ absolute frames looks like a mistake: a significant portion of SwiftUI overhead is spent in autolayout
- after working with Swift and _loving_ it between Swift 1 and 4, seeing the issues and watching Apple staff up and get more rigorous to solve them, stapling SwiftUI right now is unconsciable
- it requires contorting the language spec and the slow speed removes the one benefit of all the other frameworks, hot reload on device.
- Apple seems confused because they can _enumerate tractable work that would improve SwiftUI_, but the sum of that work is large enough to place a real, performant, cross platform Swift UI O(years) out (c.f. Swift's stable ABI clusterfoo)
How did people make iOS/macOS apps before SwiftUI? i.e. before 2020?
The idea of frame hierarchy is much more concrete in the autolayout world - which I guess helps the most.
Or one of the various alternatives... Flutter, React Native, Cordova, maybe a few others. There are also game app engines for games and game-like apps).
There are definitely fewer decent alternatives than for the web, but you aren't exactly starved.
Also, the context here is bug fix release cycles... no matter what you choose there will be bugs and release cycles that don't always match what you want for your app.
This is even true for script languages for instance. This is what make Javascript or Python more powerful than the language let them be. Being able to 'fallback' to C if things are not working the way they should.
Having SwiftUI or React are ok, if you can call imperative UIKit api's or web DOM when you need it.
Im very skeptic that this model will be feasible for the more "hardcore" cases of applications. So its important to have a powerful way to control things in details.
In hindsight, the modularity and the power that the web UI api gives you today is something to admire.
Its hard to have other examples where the bazar model ended up with better tools than the cathedral model. Especially if the cathedral model had time to do it later with the technological advantage only experience gives you.
Sure, they're technically building on top of the native UI frameworks, but only by completely ignoring all of their functionality.
https://developer.apple.com/library/archive/documentation/Co...
UIKit/AppKit is layered on top of Core Animation which is layered on top of Metal. Skia, the 2D graphics library that Chrome's rendering engine uses, is built on top of Metal (or at least transitioning to Metal from OpenGL on macOS).
So browsers have the same flexibility in principle as native UI toolkits and they are just as close to the metal. There is no inherent disadvantage. But flexibility is a double edged sword. It includes the ability to diverge from the platform look & feel. So that's where the debate has been raging on for decades.
In terms of performance I think any debate about optimisation of UI stacks pales in comparison to the question of where the data lives, who generates it, and how it gets to the CPU/GPU for processing and display.
If people want to use web technologies on the desktop, there is Electron.
The converse is not true.
Quite a few of the ‘cross platform’ toolkits work this way.
Developing GUIs in various form factors since the late 80's and I rather have a window context to draw whatever I need than faking menus with list items.
Project Houdini, WebGL + Web Assembly for the second coming of Flash alike tooling is thankfully already taking off.
Swift's core team recently found out that they don't understand the type system they've created - they were fixing compiler 'bugs' for months without getting anywhere, until one of them finally realized hey, I should probably attempt to understand what we've built, not just 'fix' a never ending stream of bugs we seem to be having.
Turns out, the type system they built guarantees 100% that type checking is undecidable (in software developer terms, you can crash the compiler by typing perfectly legal Swift code and nobody at Apple knows how to fix it without breaking existing code because they didn't even know they built a language that has this property up until very recently). They figured this out after announcing a stable ABI by the way. Upon discovery, some of the core team members said the discovery was great/nice work.
It's not like we have people who use mathematics to prove properties of type systems without any shadow of a doubt or anything. I wonder how many of them are working on Swift or are employed at Apple, within their multi-billion dollar R&D budget... I wouldn't at all be surprised if the answer was zero, given that it was a software developer who knew a little math who made this discovery.
The tone sounds histrionical because it is way ahead of the herd's perception. It's been terrifying to have feet in multiple communities, have a strong foot in Apple's community, and see how things are done over there and gotten worse over the years, particularly after Swift's release.
https://forums.swift.org/t/swift-type-checking-is-undecidabl...
Even so, "undecidable" doesn't need to be a problem. It would be possible that the undecidable Swift program is such a random mess that nobody would be likely to write it by accident.
However, it is worth looking into more practical aspects of how Swift's type system works, and there I share your concerns. Swift is the _only_ language I have ever used where I have ever seen the error message "the type checker was unable to infer the type of this expression" etc. - sometimes on dead simple code. Worse, I once tried to write an expressive, generic, functional framework, only to discover that it was completely unusable because the type errors that Swift returned were simply wrong and to fix it you had to put in type annotations in a bunch of places (without necessarily knowing where, just from the error messages), making the whole API extremely verbose and not particularly declarative anymore.
It's more common than you'd think: https://typing-is-hard.ch
> the type errors that Swift returned were simply wrong and to fix it you had to put in type annotations in a bunch of places (without necessarily knowing where, just from the error messages)
The diagnostics engine was completely overhauled in Swift 5.2, so this shouldn't happen anymore: https://swift.org/blog/new-diagnostic-arch-overview/
Keep in mind that Swift's type system is sound. It's just not decidable in its current state.
Undecidability means there's no algorithm that is guaranteed to terminate, not that any algorithm will crash. In this case, using a completion procedure to convert the same-type constraints into a confluent rewrite system should be sufficient. If completion fails an error can be diagnosed. This shouldn't break any real code in practice.
(It should be clear, but this is both factual and a joke. The core team is good people, Slava is good people, Slava is not on the core team.)
Someone found this in Java as well. Accidental Turing completeness crops up everywhere, it's actually rather hard to ensure decidability. It's a favorite pastime of people in this area; I'm somewhat disappointed you didn't find it to be interesting. In any case, personal attacks against the Swift compiler engineers (many who are quite competent at the things you are claiming they are lacking) are not appropriate.
Working at FAANG is an abject lesson in learning that assuming 'competence' (i.e. knowing mastery-level detail, taking responsibility everywhere, and going off on world-creating tangents rather than fixing bugs) is damn rare, nearly all of my career's achievements have come of accepting that and doing deep dives into problems.
Something is pretty broken over there, and it's especially not charming to read the team chiming in with 'lol haskell too!' - can I bill you for the type inference crashes and workarounds I've had to do because no one bothered saying anything until August 2020? https://twitter.com/krzyzanowskim/status/1305579668104331264...
I'll be happy to admit I'm wrong when Swift UI 2021 is rendering lazy lists just fine on Mac and iOS, otherwise, its just me hearing about ARC optimizations for the 50th time and trusting it. https://twitter.com/jckarter/status/1305562770859933696?s=20
That's not related to the decidability of that specific algorithm in the generics implementation, though.
Did you file bugs for the type checker problems you found? (I’m not being snarky; I’d love to take a look at them)
How is it that a single person named Edwin Brady can think of, implement and have a programming language with a decidable type system that is more complex than Swift, working on it part-time?
I'm sorry, I consider a company worth a trillion dollars, sitting on billions of dollars it doesn't know what to spend on, that spends billions per year on R&D, to know the basic properties of the type system their most actively developed programming language uses.
That's just me.
I revisited the project after WWDC and found that some of the things I was frustrated with were improved and others just required a break and a fresh perspective to figure out. I recommend SwiftUI.
I assume based on this Swift code can't be swizzled for some reason?
https://twitter.com/jckarter/status/1135730593537249282?lang...
I'm fairly certain that the elegance and flexibility of the UIKit model, and its uncompromising focus on user experience over developer experience was a key contributor to iOS's success over its competitors.
I'm very sad that with SwiftUI Apple gave in to the tide and started catering to React devs with this gimmick immediate-mode framework on top of their existing retained-mode toolkit. The original NeXTSTEP engineers wouldn't have let this happen...
There are literally senior vice presidents, who I assume had to sign off on SwiftUI, who were NeXTSTEP engineers.
though to be honest, i liked the bindings model in appkit better (much more component and visually driven)... shame it never came to be on iOS...
swift ui is pretty cool, but somehow i feel like im laying out an html webpage instead of an app... maybe its just me
Who?
(because some of them are still at Apple, including Hair Force One :)
I wanted to build a Mac native product but decided against it. Maybe in a couple of years.
Recall the early days of Mac OS X. It is easy to look back at something like version 10.6 and see how “nice” AppKit worked but it had already evolved quite a bit by then, over many years. If you go back further, like 10.2, you see many rough edges as the APIs were rapidly evolving.
In the beginning, Cocoa was clearly powerful but also surprisingly lacking in some areas compared to Carbon (at least, from a Mac-like UI point of view, as opposed to NeXT). Interface Builder had different UI element libraries for both APIs. Even the common UI elements between the two APIs were not necessarily identical: there were things you could do in one API but not the other. Furthermore, converting a Carbon program to a Cocoa program was a monumental task, requiring things to be downright rewritten for just a basic Cocoa foundation to work properly.
The big difference this time, in favor of Swift and SwiftUI, is that it is possible to integrate brand-new stuff very quickly. Right now, I can integrate: Objective-C, C++, AppKit, Swift, SwiftUI, and a wide variety of other things, and they all compile and link and run. There is nothing requiring me to rewrite 98% my Objective-C app just to integrate my first SwiftUI View. While YMMV, compared to past endeavors this appears to be a much more practical solution for jumping to a new technology.
I started programming on NeXT in 1991 and AppKit was already very nice (not "nice") back then.
Target/action, for example, was a revelation, together with the responder chain. Miles ahead of everything at the time as well as most if not all the stuff that followed. Now we're back to tightly coupling everything and calling it "progress".
> Of the 10 seconds captured, 30 percent of them are used for the various retain/release and malloc calls in Swift and Objective-C
This is not indicated in the profile screenshot, though I will concede that perhaps it's showing up from the "inverted" view or something.
https://twitter.com/InvadingOctopus/status/12792872846265794...
It's amazing just how little effort and code is required to build complex scalable layouts that Just Work.
Yes, it does require you to Think Different and you will have to change how you approach UI design if you're coming from legacy frameworks.
That's where the most frustrating aspect of SwiftUI lies, apart from the early bugs and lack of consensus, and this is where some people give up: having to change how you think. Just like Swift itself.
Sadly, excitement lasted 1 month after I realized that it's not ready. Obscure error messages, random bugs in controls and other annoyances turned my initial excitement into frustration. I managed to make things work but had this feeling of it being fragile.
I see the potential, hopefully in a few years.
Yep, the blazing speed of reference counting over tracing GC.
https://github.com/ixy-languages/ixy-languages
As for Electron, as React Native team has proven, Electron isn't the best example of JavaScript performance or memory usage, quite the opposite.
I can hardly wait the day that they manage to convince the VSCode team to migrate to React Native.