> . It is hard to think that any Windows programmer would prefer Swift as a language over .NET languages, as many commenters pointed out on Reddit, but a port of Swift UI on Windows could be a game changer.
Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.
Creating a good cross-platform
GUI framework is probably harder
than creating a good cross-platform
language.
Way way way way way harder, I'd think. It's basically never been done in the modern era. All the successful ones from the past look (and work) like garbage on a modern desktop computer (I use gnucash for my dad's business, ha ha).
SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tell you that the current "native" experience sucks green potatoes. There are like 9 or 12 different UI technologies I must interact with each month. All with different text sizes and massively inconsistent UI paradigms.
So I think there is an opportunity here.
But, I bet SwiftUI → Web will come first. And if that happens, SwiftUI on Windows, and desktop Linux, will be a no-brainer and will happen.
And if it doesn't happen, then probably SwiftUI won't matter outside of the Apple ecosystem, and that will mean Swift won't matter much in the end, either. (EDIT: I don't mean Apple need do this and I don't expect they will. But SwiftUI is just an API; anybody could port it to whatever environment they want, and there are already some nascent third-party efforts to implement it for HTML/web.)
Full disclosure disclaimer: former NewtonScript programmer
I think the opportunity is particularly on how SwiftUI has been implemented in iOS, iPadOS and macOS, by relying on the native UI of each platform and providing a common abstraction for developers.
Instead of providing the same UI that works badly on every device, SwiftUI interprets each concept differently according to the platform.
For example, a Toggle in an iOS and iPadOS app looks like a on/off switch, while on macOS it's rendered as a checkbox. A Picker has is scrolling wheel on iOS but it's shown as radio boxes or a drop-down menu on macOS.
Navigation is also the same. On iOS, a NavigationView offers the drill-down navigation common to iPhone apps, while on macOS it creates a split master-detail interface.
Each implementation does so by using the native UI framework of each platform under the hood, UIKit on iOS, and AppKit on macOS. I don't know how UI development works on Windows, but my speculation is that a SwiftUI implementation would work the same way.
I can’t comment on SwiftUI in particular, but I’ve found that a lot of things like this tend to break down in most other cross platform GUI frameworks, falling into a kind of uncanny valley, where the experience ends up being either:
1. Native feeling, but sufficiently inflexible that only very simple, common UI patterns can be implemented
2. An “uncanny valley” native ui, where things are almost native but often feel wrong in subtle ways
I think that’s why Electron has succeeded where so many cross platform UI frameworks failed: it’s so obviously not native that it doesn’t fall into that “uncanny valley” anymore
The way they have implemented it for even their own "cross-platform" needs (where the "platforms" are really basically different versions of the same OS) works very well — the sickening, jaw-droppingly awful apps from Twitter, JIRA, etc that use the "Catalyst" system of porting iPad apps to Mac shows why the approach is really necessary.
(Those apps bring iPad metaphors to the Mac, so what should be a single interaction, picking something from a menu, is a jarring series of taps, swipes, and animated fuckery.)
If that "render the concept using the OS's native widgets" approach was necessary even for cross iOS-macOS apps, it will be even more necessary across Mac and Windows, where a lot of the UI conventions are wildly different, and sometimes literally the opposite (e.g. the standard placement of buttons).
And it's obviously the only way it could work for web apps.
Sun tried with Swing.. and they were not a second tier company at the time. Also previous versions of OSX (before the rename to macOS) included a special theme of Swing to make apps to look more native in OSX (Jobs was happy to announce that OSX supported Java... when Java was sexy).
Then when RIA was a buzzword Sun/Oracle tried to modernise Swing without success. Today the only big Swing apps that I know are Netbeans and maybe IntelliJ (but I think that IntelliJ has tons of customisations on top of it).
So is even hard for a big company too. I guess the problem is that the framework will be always behind the OS, and you need to recreate all the styles or to create a thin layer with the common denominator between platforms.
Is interesting that different approaches to cross-platform UI (draw all vs thin layer) goes back to Smalltalk. AFAIK the idea of Swing drawing all the UI came from VisualWorks, while the thin layer of SWT came from IBM VisualAge
>Sun tried with Swing.. and they were not a second tier company at the time.
Swing was ill thought from the beginning. Over-engineered, too complex, slow (as if there were 2-3 layers between the code and the drawing engine), and looking bad in every platform...
>So is even hard for a big company too. I guess the problem is that the framework will be always behind the OS, and you need to recreate all the styles or to create a thin layer with the common denominator between platforms.
I'm not so sure that's a problem. You can always look different than the OS, and do a good job at it. Millions use the Adobe Creative Suite, Cubase, Pro Tools, StudioPro, etc, and their non-native UI is the last thing they complain about...
Heck, even Electron apps do that. Why wouldn't users like apps that look different from the OS, the way Electron apps do, but with far less memory usage, much speedier drawing, and better integration options with native widgets when needed?
There are tons of existing cross-platform UI frameworks (Qt, wx, libui, JavaFX, TornadoFX, ...). The comment above says "Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework."
And yet people are still wondering why Electron ends up being the technology of choice for so many desktop apps.
JavaScript is a language that's neither abstracted from the basic programming concepts nor its syntax is alien. Most of the people who picked it up can learn many other mainstream programming languages in a week, if not a weekend. Add 1-2 more weeks and they're writing GUI code.
Yet, they don't.
JavaScript is popular for pragmatic reasons (a.k.a. "it delivers results"), so is PHP. They aren't the best languages, but developers who choose them aren't simpletons who can't code in other languages.
They are both deeply, deeply flawed (though I have learned to love JS's good parts, while I still hate PHP).
I have programmed in many languages - Java, Python, Scheme, and Bash are all ones I've worked in professionally, and I've spent plenty of time in Emacs Lisp. This doesn't touch on the ones I've tinkered with for fun.
JS and PHP are not the best languages, but they work, they're everywhere, and they're usually what your client already has in place.
Changing languages rarely delivers any actual business or end user value.
So, I work in what the client has.
JS will long outlast PHP, because it's such a massively deployed language and browsers can effectively never remove support for it.
PHP may slowly die out, since it's strictly on the backend, where you can choose your language.
I’d say electron became popular thanks to HTML, not JavaScript. IMO HTML is by far the “easiest” to use GUI framework because it is so unconstrained. It will end up a mess, but eventually you can get the result you want. This is not the case with native frameworks which come with a larger sets of rules on how they can be used.
I did UI development for quite a while too, and in my experience having very specific layouts (and look) in HTML is easier than in frameworks I used (Gtk, Qt, UIKit...).
Main difference is that HTML has affordances to size elements "upwards" whereas in other toolkits you need to do this manually (e.g.: estimating text size is a thing, in html you don't need to care about this)
Now, this also encourages original layouts which are untrue to platforms which is not a good thing imo.
I very much doubt that is a major reason. Language itself is rarely the issue, unless you're reusing code from other parts of the project (which many projects are, e.g. VS Code with Monaco).
I have spent far too much time on HN recently in related discussions.
Building custom UIs is also very easy with the flexibility that HTML provides (https://news.ycombinator.com/item?id=23164595), even though it can be done with other technologies (and there are some examples of that).
> Qt is pretty good but QtQuick can be fairly barren in some areas i.e. if you want a embedded spreadsheet you're out of luck unless you make your own.
Possibly, but that's if you include the part about making it look/feel native. If you just provide the tools the are just focused on the language and framework and let the people who care about making it look native on whichever platform it's running focus on that then I think it's doable.
Unlike things like react native you wouldn't be actually using the native components necessarily unless you can implement the UI frameworks components in terms of them. Otherwise they would need to be written from scratch.
I’ve thought enough about this problem that I don’t think it’s possible to recreate a “native” experience with a cross-platform app. You end up compromising on the nativeness every time. It makes more sense to me to use native GUI frameworks and program your functional logic in something like Rust.
A native look and feel is definitely an implicit assumption I held. You’re right that eliminating this requirement changes the level of difficulty significantly.
Personally I wouldn't mind creating a new UI for every platform I need to support as long as I could use the same language with the same build tools and reusing components between them.
That's a big if. From what I've read, SwiftUI isn't even a great Mac/iOS GUI framework yet. And Windows and Linux are drastically more different than those two.
I really enjoy swiftUI. It appears like it tried to emulate react and succeeded on a few fronts, is better in a few fronts (child modifying parent variable), and worse in a few fronts (side effects).
That being said, my experience with SwiftUI users is that they don't like it because it is so different from the standard Mac experience (props and re-renders and state...). And the documentation is poor (IMO has been Apple standard from MapkitJS to iOS Swift documentation to SwiftUI) which leads to a negative dev experience. Try finding what causes a component to re-render in SwiftUI vs React. If you find it great and please post it, but it's not easy to find in my simple research.
I’ve spent the last week learning SwiftUI to see how hard it would be to reimplement Notion in a performant way. It seems really ... unfinished. Like, the default List view is really hard to style. I spent 4 hours yesterday trying to get an unstyled text Button to have a hit target bigger than the characters themselves. Adding a frame with a background worked, but if the frame had no background (or a transparent background) then the hit target would stay tiny. I ended up fixing it by just reading through every property method in swiftui and guessing. It reminds me of web development in the early days of jQuery.
If the SwiftUI code were opensource it would be much more pleasant - I could paw through the code if I needed to, file issues, and so on. But the whole experience compared to writing typescript with VS Code is shockingly bad. With the preview open Xcode sometimes stutters so much that it misses key presses - so I’ll type a function name and it’ll come out missing letters, because apparently I wasn’t typing slowly enough for my $3000 computer from 2016 to keep up.
That Xcode gets trounced in developer experience by vs code - an IDE running on electron - is really a testament to the work Microsoft has put into performance. And it should be hugely embarrassing for Apple.
That is the thing I dont like about the current Apple.
They used to release things where you see they put a lot of thoughts into it. Now they are half baked. This isn't so much a problem on Apps ( The Product ) where it is constantly being updated and tweaked. But with code you have the hassle to try and keep up. And the pace of improvement is very very slow. To put things into perspective, Swift UI has been development for 4 years. Not exactly the state of things I would like it to be.
Apple also isn't dogfooding much with Swift. And I think that is great. In many ways I starting to feel Swift is like Dylan [1], it is new, it is exciting, and it is fun. But somehow after nearly 6 years Objective-C stills feels better. The syntax may still be god damn awful, but it is small enough to be called elegant. While Swift felt like C++ with better Syntax.
That's because it didn't have a stable ABI until Swift 5, released last year. Now that it does, a lot of their iOS/iPadOS apps have been rewritten, at least partially but sometimes fully, in Swift; this includes some of their Catalyst apps on Mojave and Catalina.
The only app I know for sure to be fully written in Swift, thus far, is the Apple Developer app (previously called WWDC), but I know there are others (they were mentioned in last year's WWDC sessions).
> Swift UI has been in development for 4 years
I must have missed this. Where did you hear this? I'd love to see more info about that.
>I must have missed this. Where did you hear this? I'd love to see more info about that.
Chris Lattner said in one of the pod cast, I think it was Accidental Tech, where Swift UI started before he left Apple. Since that was 3.5 years ago, Swift must have been close to 4 years of work.
Well, that may be, but we don't know when a concerted effort began. Just a guess, but this was probably a small team (or individual) trying some things out as an R&D project to see if it had legs. At some point there was enough promise so that the company put serious effort into it. That might have been 2 or 3 years ago. At any rate, it has company focus now.
> But somehow after nearly 6 years Objective-C stills feels better
This experience is shared by basically nobody? I used to love Objective-C, which was unusual even before Swift, but I would not in a million years switch back to using it. Swift is so much better in every single way.
I share it. I love Objective-C and feel its a far superior language over Swift. Swift is too clever by half, with its var, let, func, and the god awful question marks. Objective-C is verbose sure, but that helps readability. I'll never switch to Swift, as Objective-C is so much better in every single way.
I have on both counts. I tried it a couple times and hated it. I've read the book and others justifications for it, but disagree.
Swift is absolutely less readable than Objective-C. Objective-C is known for its verboseness, which makes it easy to read. Swift has all kinds of easy ways to make it less readable, like the question mark. There is no way one can objectively argue Swift is more readable than Objective-C.
Yeah. There are _aspects_ of Obj-C that are still nice, but as a whole I find Swift way better to work with on day to day basis. For that matter, I prefer it over syntactically similar languages like Kotlin too. If I could just write Swift everywhere that’d be great.
Needs to be said. Apple doesn't seem to give a toss about performance or developer experience so long as it has something to demo at its annual developer conference.
You can change state without all the annoying purely functional programming stuff ([... previousState, newValue]). Just change it.
You can change a prop passed in and even pass a new value up to the parent. So you know the pass a function down so the child can change a value in the parent? Just pass the variable you want changed down with @binding.
The official Apple tutorial gives you an idea what they were going for, but in practice it’s nowhere near that smooth.
In fact, most of the time I found myself staring at a “type too complex, add annotation” error. That one doesn’t actually mean your type is too complex, it just means you’re passing the wrong thing somewhere and instead of a useful error message the compiler just gave up and broke.
I certainly hope so, because this was definitely on Swift 5.2 . In general if you come in expecting a dev experience anywhere close to writing React in Typescript using VSCode, SwiftUI and Xcode both are a bit of a disappointment - it's slow, it's glitchy, autocomplete kind of sucks, never mind tooling like Prettier which I take for granted now.
Agreed. Just watched a recent tutorial on SwiftUI where changes to Hello World were taking a lifetime to update in canvas view. SwiftUI, like most of Apple's OS releases, is beta quality.
Although it technically has cross platform GUI, Flutter has actually reimplemented all the native OS widgets. As soon as the OS changes some look and feel your app will look out of date.
Yes it will look out of date. But whats important? A functioning app or good looking one? We all know that websites written for ie6 are out there today making millions in revenue. It always comes down to the functionality not the looks
You can be as tolerant as you want, that's not how things go for iOS apps. It's certainly not how things go on macOS except when there are no available alternatives.
Windows, Android, and the web, constantly changing so that there's never really been any sense of stability, blind a lot of developers to the fact that good design is both functionality AND looks.
When people complain about designs of controls being out of date, they don't only refer to looks. They refer to how they feel, behave — or more succinctly, don't correspond to the expectations set up by the rest of the system.
To reduce the debate down to looks vs. functionality is reducing things down to the wrong level, missing the forest for the trees, and ignoring the user — a person who often isn't able to express what they need but knows what they want, not often realising that they're the same thing.
Flutter is one of the fastest growing frameworks for the past two years and therefore dart too. It most likely will succeed cause of this pace and the community growing around it.
When flutter for desktop lands into beta I think it will pick up even more pace and would be very hard to ignore for a lot of companies.
But how will you give the same level of performance in a dynamic language? Typescript is only for type safety. It's still JS at the end. Dart is more modern with a VM during development and AOT compilation for production.
It does. It has been able to for some time now. A team I’ve worked with used it to build a cross-platform library. Swift wasn’t the first choice but the short story was they didn’t choose C++ because they didn’t want to hire C++ devs to maintain it.
Did the team look at Kotlin? Seems like Kotlin Native on iOS is a more viable alternative than Swift on Android right now for cross-platform development.
Every time mobile cross-platform is discussed, someone brings up Qt when it's less popular for mobile development than React Native, Flutter, Xamarin, or PhoneGap/Codova. Maybe even less than Ionic, NativeScript, or Appcelerator. Why even bother with such a niche solution? Are there even live cases of mobile apps using Qt?
> Every time mobile cross-platform is discussed, someone brings up Qt
For what it is worth I can't see anyone mentioning mobile and however weird this sounds, for me at least cross platform always implicitly meant across desktop platforms.
Cross platform on mobile never really happened, thanks to Steve Jobs, and I am kind of happy for it so far.
Swift is a programming language created by Apple, it's been cross-platform for a while but is now going to be officially supported on Windows. Swift is Apache licensed.
SwiftUI is a UI framework created by Apple for the Swift language, it's only available on Apple platforms, and it's proprietary.
Thanks for the correction! I knew of the distinction, but in my haste I was looking at a different repo (and I blanked that the source hasn't been released and licensed).
Swift looks to be Apache licensed. I'm fairly confident SwiftUI wouldn't have a commercial license, which is a major topic with using Qt.
Have you made any non-trivial use of the Qt bindings for those languages? Qt is a big and complex library, and most bindings are incomplete or poorly documented. As far as I know, PyQt is the only Qt binding is the only one that you can really rely on to work now and in the future.
There is PySide2/Qt for Python which are the official Python bindings for Qt by the Qt Company itself and they are close enough to the C++ API(since they are auto-generated) that it's possible to just use the C++ documentation and translate any C++ code into python nearly 1:1 (except things like QString where you can just use Pythons native types).
Not terribly complex, but not trivial either. Yes, there are missing pieces in non-python ones. But given that basics are handled, it's often pretty easy to add the pieces which you need.
Qml supports ES7 so you only really need to touch C++ if you're not making "casual small GUI apps". If you need to draw custom items or do low level networking then yeah you need to use C++ but even then Qt is much friendlier than using the standard libraries.
Here is a Qt C++ example:
QString str = "/a/b/c/";
auto parts = str.split('/');
Bindings are very limited except for maybe python. Using almost any binding you are destined to hit a bunch of roadblocks. Lots of people can’t use lgpl.
Hate to say it, but the sanest thing to do if you need a cross platform UI is use Java. Your other choice is Electron, which is way slower and uses many times as much ram
>Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.
Not really. I'm sure there are plenty who will just stick with Qt based options or even Electron.
I've seen a lot of stuff built in PyQt by people who aren't strictly developers and who learned Python only because it fits with some other aspect of their job. There isn't a lot to incentivise them in learning a new language.
Qt licensing can be problematic depending on your project. They also no longer publish LTS releases under an open-source license. Swift UI would presumably not be encumbered in this way.
I think they are choosing react native because they genuinely like react.
I don’t remember which video it was exactly, but one of the higher ups talked about future technologies within Microsoft and how they were doing more and more GUI-based thing with react. And if you look at it, they’ve done pretty amazing things within the JavaScript eco-system in general. Office 365 is amazing, Visual Studio Code is amazing and it just wouldn’t make sense for them to go from typescript to dart.
Especially when you consider how unfinished flutter is. We’re a C#/power shell with a little Python shop with a lot of Enterprise Microsoft techs. We still considered Flutter because Xamarin wasn’t working out for us and we’re not big on JS or big enough to do native, but flutter just doesn’t fill our needs either. That’s anecdotal, but the difference is that react and react native are proven techs and flutter still isn’t.
Yeah Flutter's main focus is mobile, they are working on Desktop Flutter, you can try it out on the master channel.
It looks like they are making progress, Chris Sells, a Flutter PM, tweeted
"While things have been delayed on the desktop side for Flutter due to the current crisis, the team has been working hard to bring both Windows and Linux support to alpha. I think you're going to be happy about what you see."
https://twitter.com/csells/status/1261036199294062592
What is the relative efficiency penalty these days, for using JavaScript to build the GUI, as opposed to using native code?
Like, isn’t VSCode all JavaScript? Surprisingly, this is probably what allowed Microsoft to build software that runs on both Window, Mac, and Linux! The JavaScript platform, ultimately became what Java dreamed of becoming back in the 1990s. And without the need to install a separate virtual machine layer, but at the expense of more inefficient code.
But VSCode is painfully slow, if you run it on an older PC.
And you’re not going to be running Windows 10 on a 15 year old PC anymore.
So could this mean, that software companies are going to force people to buy newer hardware, to run their programs? Most likely. Apple has programmed the consumer into spending unnecessarily for new hardware every year.
Best part about maturity. It matures. I would jump ship in a heartbeat to Swift. I don't use it because I can't use it in most places, and I am slowly learning to choose what I become an expert in. It sure isn't everything.
But when I did use it, I loved it. I've written in quite a few languages, and it is my favorite, but not my go-to because of its limited environment.
Not to mention that developing C# in Visual Studio or Rider feels years ahead of what's considered good enough IDE assistance in other languages. Comparable with Java even.
In some ways, Swift is a higher-level Rust. It places a lot more emphasis on functional programming, null safety, value types and immutability than C# does.
The more flexible memory management model added recently, native binaries, (as the default option) and even identifier: Type over type identifier is also a nice plus for me, I agree that the IDE situation is heavily in C#'s favor.
If C# is a nicer Java and Kotlin is a nicer C#, then Swift is a nicer Kotlin.
What would you argue C# has going for it over Swift?
null safety modern C# has optional chaining, Elvis operator and non nullable types
value types C# has value types contrary to Java (until
project Panama)
What would you argue C# has going for it over Swift? feature wise I don't know but it clearly has a far bigger lib ecosystem which is the most important criterion
Yes, some of these have been slowly added, similar with Java slowly moving to embrace features from Scala and Kotlin, but to me it doesn't feel as nice, rather sort of baked on and many of the libraries don't use these latest features.
Swift was designed to seamlessly blend functional and OO styles from the get go.
Fundamentally, there's still classes and inheritance everywhere in C#, which is also what I hated about Cocoa and using it from Swift before they came out with SwiftUI.
Now don't get me wrong, I am not saying C# is a bad language, just that when you compare it with Swift, Kotlin, Rust etc, it's clearly playing catchup.
> far bigger lib ecosystem which is the most important criterion
Going by that metric, you could argue there's no point to C#, because Java likely still wins handsomely on that front and maybe Java should just give it up to JavaScript anyway.
Clearly we don't just evaluate languages solely by the size of their ecosystem. There's a critical mass that needs to be achieved, but at some point there's 2-3 libs for everything you may want to do and simly having 5 more is not magically better, the same way having "millions of apps" on the App Store doesn't mean much if most of them are not that great and people stick to just a few.
As an example, the GUI situation on Windows clearly offers more choice for C# devs as to how they want to go about their GUI, but I'd argue the Windows GUI situation is a bit of a hot mess right now and SwiftUI seems like a breath of fresh air compared to that.
> Now don't get me wrong, I am not saying C# is a bad language, just that when you compare it with Swift, Kotlin, Rust etc, it's clearly playing catchup.
btw. it's the other way round. most modern stuff was in c# while the others played catchup and some still do.
no language has async/await implemented as good as c# has, no language has nullable value types as good as c# no languages has a reflection api that is really easy to use and if that isn't enough there are also expressions which are more like macros and due to the way how generics are implemented no internal api sucks.
btw. c# even has channels.
swift has nothing over c# and all features swift has were more likely be in c# before they were in swift.
A lot more emphasis on functional programming & nicer syntax around it, preference of value types over reference types and immutability by default/opt in mutability, nicer parsing with Codable, nice pattern matching and destructuring syntax, native binaries by default, more flexible memory management.
Modern C# has both destructuring and pattern matching in switchs.
The memory model of swift seems obscolete, reference counting does not catch reference cycles and swift isn't faster than C#
C# isn't really missing features vs swift but it might have a less modern syntax
I have doubts. We already have cross-platform languages with decent GUI like Java (people give it tons of shit but I bet you use a Java GUI every day without knowing it). Python has some decent ones too though.
And of course Electron, which is somehow even worse than Java.
PyCharm, by the virtue of running on JVM, doesn't take any more memory than allocated to it in VMOptions. So unless you go out of your way to give it too much memory, I am not sure PyCharm is going to take 14GB of memory. I am a heavy user of IntelliJ based products for a long time and I can't remember them taking enough memory to be a problem on a 16GB laptop.
Just out of curiosity, what was your colleague doing?
I have had IntelliJ open with multiple million+ line projects with thousands of source files and it hovers around 3GB. Its gotta be his settings. Java will use as much ram as you tell it to, it uses the extra ram to collect garbage less often.
Its super common to misconfigure Java to use all of your ram. You could have a terabyte and tell it to use everything and it will
To specify, it does contain what SwiftUI calls a List. And each row in the list can of course contain a number of widgets, so you can approximate a table.
However for the desktop, a good real table, with columns, would be nice.
Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.