Hacker News new | past | comments | ask | show | jobs | submit login
Swift 5.3 Will Be Supported on Windows and Additional Linux Distributions (infoq.com)
429 points by nan0 15 days ago | hide | past | web | favorite | 300 comments



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


    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


Yes, I totally agree with that.

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.


>Way way way way way harder, I'd think. It's basically never been done in the modern era.

Also never been really tried, except by second tier companies with small recourses like Trolltech/QT, or even smaller open source attempts like Wx.


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?


didnt openstep use the native win32 for the ui on windows?


Yes, for like 2 years, then it went under...


I’m interested in why you’d pick green potato’s


It's because they are poisonous, and also look roughly like a troll's testicles.


Ohhhhh, this would be super cool. One intuitive UI design system, my body is so ready.


Beeware did it

Embarcadero was able to do it with Delphi. Android, iOS, macOS, Windows, and Linux. Single codebase single UI.

It looks like the bear is in keeping up with all the platform updates all the time though.


Whether it is actually good is subjective though.

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.


> Electron ends up being the technology of choice for so many desktop apps.

probably because of the large number of JS only developers.


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.


So much this.

I work primarily in JS and PHP.

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.

JS is eternal.


PHP is absolutely still used on the “front end” Facebook still deploys loads of it in places. SSR is still better using PHP.


I think of "front end" as meaning "executed in browsers."

How are you using it?


I will never ever ever work with PHP again. It's dead.


While I hope never to work with it, in what concerns the tiny set of PHP files on my web site, it is alright.


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 beg to differ, having been doing GUI coding since a couple of decades.

Guess what, what in most of them I never had any issues to center elements, or create fake UI elements out of list items.

Also layout managers were already a thing back in 2000.


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.


You also don't need to estimating text size in QML, XAML, Forms, VCL, and when you need it is hardly any different than dealing with CSS fonts.

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.

Having access to libraries like React and its huge ecosystem is a big plus for productivity (example vs. Qt at https://news.ycombinator.com/item?id=23154315).

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


I think people would switch if it had Apple money behind it.

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.


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

Hey, have you checked out https://github.com/ec1oud/spreadsheet.qml?


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.


Heck if you go the Sciter route you can have a very well known approach but without going full Electron about it.


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.


Lazarus would like to have a word with you.


Right now people are using Electron. ‘Better’ is not that high a hill to climb.


100% correct


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.

[1] https://en.wikipedia.org/wiki/Dylan_(programming_language)


> Apple also isn't dogfooding much with Swift.

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.


The lack of a stable ABI had nothing to do with preventing Apple from shipping apps written in it.


>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 don't get the feeling you've really given it a fair chance, or tried to understand why it does what it does.

Swift really is much more readable than Objective-C, too.


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.


Your assertions aren't backed up by anything; your criticisms of Swift are superficial and reek of "I'm unfamiliar with it, therefore it's bad".

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.


At least all host of Accidental Tech podcast shared similar feeling.


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.


Curious to hear more about what SwiftUI does better than React… any place I can read more?


Sorry for the late reply.

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.


Errors in SwiftUI are significantly better in the recently released Swift 5.2, so this is clearly something they’re working on.


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.


If that were true wouldn't we be seeing a big increase in Dart adoption because of Flutter as well? I'm not seeing it.


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


> But whats important? A functioning app or good looking one?

Depends on your audience.


It probably will be good looking just wont be aesthatically consistent with new OS looks.


Both. If you have only one, you have a shit product nobody wants.


I'm not advocating for garbage looking products. All I'm saying is that lets be tolerant on looks because functionality matters the most


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.


IMO Flutter would have received far wider adoption now if it used Typescript instead of flogging the dead Dart horse.


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.

Swift is already way more popular than dart though.

But Swift doesn't run on Android, does it?


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.


If that library is open source I'd love to take a look at 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.


What would it provide that Qt + QML don't right now? (if we assume that the crossplatform GUI is the killer feature)


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?


The article context is Windows and Linux. I'm not sure where "mobile cross-platform is discussed".

But if you want to go to actual cross-platform-beyond-desktop, Qt is still massive on other devices. From cars to TVs to smart fridges.


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


Sure it did, in all these years my only native apps have been on personal projects.

In what concerns work, we use a mix of mobile Web, Xamarin, Cordova/PhoneGap, C++ with native views, depending on the customer requirements.


I'm sure licensing is a big one. It looks like SwiftUI is MIT license and Qt is dual licensed.


I think you are mixing up Swift and SwiftUI.

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.


A modern, powerful memory safe language? C++ is hardly a good choice for making casual small GUI apps.


Like Crystal, Go and Rust? (and QML for the basic events handling)

https://en.wikipedia.org/wiki/List_of_language_bindings_for_...


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('/');


Depends, if you are coding C in C++, or making use of idiomatic C++17 (eventually C++20).


except for the documentation the python (pyside2) bindings seem pretty complete.


Pricing and not being c++


LGPL is free and there are Qt bindings in pretty much all languages now (+ I mentioned QML for that reason).


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


I wonder whether GraalVM native image will play a bigger role in desktop apps in the future.

Kotlin + TornadoFX + native-image (if it is supported) sounds like a pretty comfortable to use UI stack.


Gluon has been putting a lot of work into native-image + JavaFX for cross platform. Im not sure if it'll catch on though.

It’s the sanest thing to do if you can write proper Java, and actually want to do so.


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


Microsoft is working on cross platform GUI framework. I am not sure how i feel them choosing react native instead of something like Flutter.

Maybe befause React native uses OS UI components while Flutter creates everything from scratch. https://microsoft.github.io/react-native-windows/


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


Microsoft also has Xamarin, which is a bigger deal for them than React Native.


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.


> Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework.

I wouldn't. I don't like Swift's syntax. The ecosystem would likely not be mature enough either.


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.


What don't you like about the syntax?


Swift is also a much nicer language than C# in my opinion.


I'd argue the other way around.

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.


no language has nullable value types as good as c# What's different from kotlin or typescript nullable value types + smartcasts?

I like C# for balancing both implement new features (in easier way IMO) and keep compatibility.

Could you argue why?


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


In regards to the memory model, I am not talking about reference counting, but rather [1].

1 - https://swift.org/blog/swift-5-exclusivity


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.


A colleagues computer lastly crashed. turned out pycharm took 14gb of ram..

wtf.


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?


would have to ask. i just recite his report :-)


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


I think main goal is to increase market share in server-side development for swift.


Trying to pull a reverse os/2, interesting.


SwiftUI lacks many basic widgets like table.


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.


Creating a quality table widget would likely take more resources than the app in many cases


A CollectionView alternative you probably mean?


Whenever I've looked at examples on Swift on Linux in the past, the code always started with (hazy memory here) `use glibc` or similar, whereas the macOS version used a different library. So for example even just to produce a random number you had to use two completely different library functions imported with completely different names. All that to say: it's always felt to me like "cross-platform" for Swift means "the same syntax on a completely different platform." Has that changed, or will basic functionality on windows require a third completely different set of libraries?


It depends on what you're doing. Swift Foundation is cross platform for Windows/Linux/macOS and exposes apis for things like file systems, paths, process creation with the caveat that what a "Thread" is or what it means if a file is executable is a little different between platforms. If you're writing a cli tool you should be able stay mostly within the Swift stdlib and Foundation and that'll work on all platforms. As more libraries are ported to Windows (e.g. hopefully swift-nio), that should become more and more the case.

Where this isn't the case would be if performance mattered, some of Foundation system api implementations (at least, the Windows ones) can be a little inefficient since the Foundation api model and the Windows way of doing things doesn't always match and the Windows implementation has to do extra work to match the semantics.

Another would be UI wise, I haven't heard of plans for Apple to open source SwiftUI. Though since Swift can call into the native platform apis, it's quite possible to write a (perhaps not as slick) alternative.


Sounds like things have improved in the last couple years, thanks for the information. If they get to the point where a basic database-querying microservice will usually compile on all three platforms, I could imagine a lot more server-side interest in the language. Who knows?


FWIW it's already viable to use Swift in the micro-service use-case. If you're running logic inside containers it's trivial to get a Swift service up and running.


Random numbers, at least, are now part of the standard library.

As for the rest, it depends on what you consider "basic functionality". AppKit/UIKit is probably never going to be ported.


Probably UIKit versus Foundation. UIKit is iOS/Mac only and I think indirectly includes Foundation, which is where the essential non-UI APIs are.

All this really means is you don’t get the iOS UI tools for your Windows and Linux projects.


UIKit is iOS only, not Mac



This is really exciting. Every time I see something about Swift my thought process is "that looks like a lovely language but I don't build iOS/macOS apps, oh well". Maybe now I'll give it a real go.

Fun fact: Graydon Hoare, the original inventor of Rust, now works at Apple on Swift.


That's an outdated but sadly common perception. TensorFlow for example is pushing Swift pretty hard: https://www.tensorflow.org/swift/

Disclaimer: I work at Google but not on TensorFlow.


I don't believe TF4Swift will go anywhere.

Fortran, C++, Python and Julia drive the show and work with full tooling across UNIX flavours, Windows, macOS today.


I'd love to have a modern statically typed language with type inferencing etc. that can be used for scripting, working in a REPL, as well as compiling to native code.

I've never tried Swift, but it seems it could have all the required features. I guess it's just lacking a lot of libraries that work on Linux.


OCaml fits the bill.


Yeah, or Haskell.

But those have been out there in a more or less mature form for decades, with no major uptake in sight. I guess they're just too esoteric for them to reach critical mass. So here I am, stuck with bash/python/C, and dabbling a bit with Rust..


If you would like to work in finance or compiler development, there is enough uptake of ML derived languages.


OCaml definitely has some weirdness that come from its age though (char==byte thing for example.)


Yeah there are some quirks, but that wasn't part of OP's request.


Well, I did specify "modern", which arguably includes sane Unicode handling.

I think a reasonable compromise is to have "char" be a 32 bit type, whereas a "string" would be UTF8.


Not sure if I would call string handling in Swift sane, but to each its own.

I know it's had some mixed support for other platforms for a while, but it's hard to really invest time and effort into a language before you know it has official support.


didn't all of the original authors of TF4S, including Chris Lattner, leave?


Yes they all did


All of them?? Bad blood


Is tensoflow for swift even still a thing?


Some of the first bits of research using it just started coming out last month


I should really start looking at it again

(He doesn’t anymore, but he did)


Oh he doesn't? Didn't realize that


Yep! I’m not sure what he’s doing today.

We’ve had several folks go between the two teams, and they’re generally very friendly with each other!


Yes I certainly didn't mean it as a knock on Rust, but as a compliment to Swift


> I’m not sure what he’s doing today.

He seems to be back working on Stellar [1].

[1] https://github.com/stellar/stellar-core/commits?author=grayd...


But why?

Sure, there are people who want to tinker with it for fun, but outside of that what is the point in having Swift on Linux and Windows?

You can't use it to build mac or iOS apps on Linux because the important libraries aren't there. There is no cross platform UI and Apple isn't likely to port and support theirs from macOS. If you are into servers then you have plenty of better languages options with established ecosystems. Maybe there are some command line apps on macOS which can now be ported to Linux/Window, but beyond that, what is the point? Where is Apple trying to go with this?


It's a fully fledged programming language. An open-source programming language, at that, with a lot of community input and involvement.

Not a macOS or iOS app creation DSL.

It's also quite pleasant to use, and has already seen a few uses beyond macOS and iOS apps, including some backend development (Vapor, Kitura, SwiftNIO, probably others).

So you could use it to write command line tools. To write Linux or Windows apps. Or to write servers. Just like any other programming language.


I'd say swift is currently probably the best languages out there. Language features, standard library, performance, memory management.


I'm curious, how do people judge this?

Personally I have some significant experience with maybe 5 different languages, which is already more diverse than the average software dev as far as I know. But I still wouldn't be comfortable to judge something like this.

For instance, I haven't worked with Swift, but I find it hard to believe it's much better than, say, C#, Scala, or Typescript, regarding those metrics. Do you have experience in those languages?


It's subjective, naturally. I don't know if I'd be that enthusiastic, but I definitely like it a lot.

My main languages are Python and C++. I've also used Java, C#, Javascript but not Typescript, among others.

In my opinion Swift does a pretty good job at striking a balance between expressiveness/usability, safety and performance. If it gets more traction under Linux (including a larger ecosystem and better tooling around it) I'd definitely consider it for projects where Python could become a bottleneck but C++-level performance is not absolutely required.

On the other hand, other languages in a similar niche - Rust, Go, even D or Nim? are already more established outside of iOS/MacOS, so I don't know. My experience with Swift has definitely made me more interested in learning Rust, which seems quite similar in some respects.


[flagged]


Dismissive responses like this are frowned upon by the HN community guidelines. Give your reasonings, not a snide remark.


OK then:

- Slow compilation, I think even now immutably concatenating a handful of strings makes the compile time exponential.

- Over reliance on keywords and special case syntax, magic doesn't compose. A bunch of it just supports Optional for example.

- Xcode, nuff said.

- Equatable and Hashable for tuples were implemented with invisible compiler magic, so they wouldn't work with generics.

- Variance is hot garbage, it has variance, but no way to control it.

- No higher kinded types, so useful FP abstractions become a chore to implement.

- I regularly had compiler crashes on comparatively simple code.

- Sometimes absolute nonsense compile errors pointing at random parts of my code.

- SourceKit didn't handle basic stuff like type aliases.

Going on the various things I've seen since we switched our project to JavaScript from Swift it looks like the keyword soup has gotten worse.


Sounds like you describe the state of Swift at least three years ago. SourceKit just doesn't crash anymore on me anymore, ever. Compile times are quite good for me nowadays, still not as fast as Objective-C but then again you don't get compile time guarantees for free.


The exponential issue was still there in version 4 and I think 5 as well. Didn't say SourceKit crashed, but it was virtually useless because it functioned like a crap version of the language parser.


So what's particularly hard on the compiler are hard coded sets of data that have mixed types. For example a dictionary that reflects a JSON response that also has nested dictionaries.

It helps if you test declare it like:

    let json: [String: Any] = [ /** lots of fields here */ ]
String concatenation: could you give me a specific piece of code that fails? It could be that I really never write code that triggers the problem. Using the + operator to concatenate strings has some performance issues though.

I'm not telling you're crazy, I just noticed that things got so much faster in the past two years.


The string concatenation issue was that if you do a ++ b ++ c... When that got to about 6 variables that single line alone took a minute to compile. Go to 10 variables and just give up on ever seeing a result. I used to try it in online Swift REPLs and it was still happening with whatever was most recent a bit over a year ago.

OMG, they actually fixed the a + b + c... issue I assume in version 5 (5.1.1 is what I have available in NixOS).

Agreed. I have not seen any other language that is as pleasant to use. It is not perfect, but everything else is even further from perfect.


I use it for all kinds of things, like computer graphics and various tools in my CLI-driven workflows.

I find it nice to work with, because it has a lot of the nice features Rust does, like affine types, 1st class optional handling, decent single-threaded safety guarantees, and it has a very nice, ergonomic interface. Generally the performance characteristics are not what you would get with Rust, but I am generally more productive in Swift because I don't have to worry about the low level details.

There's definitely some downsides - cross platform support being one of them - but if I'm just working on a tool for me myself to use, I will generally reach for Swift because it's pleasant to work with. I would be happy if I could use it for projects which need to be deployed across different platforms.


I was not aware that swift had affine types. Never been a big fan of Swift, I loved objective-c, so there is some built in bias there.


> But why?

This is basic foundation building. It's true there aren't too many good use-cases for Swift on Windows or Linux now. But that can't really start to change until Swift has decent support for Windows and Linux.

Of course, it will take a lot more than this for Swift to catch on outside of its home territory. This is just one necessary step.

More broadly, I think we're still in the middle of the language wars, where the limitations of the historically dominant languages (like C, C++, Java, Javascript) have created openings for one or more newer languages. I think Apple and other Swift proponents would like Swift to become one of those newer established languages and take steps like these to at least keep it in the running.


They’re looking to build demand over time by making Swift available in as many places as possible.

And this is the Swift Open Source team, not Apple specifically. It’s not an Apple business decision (aside from lowering the learning hurdle for new iOS projects)

Not to mention there’s Swift for TensorFlow, would be nice if you could handle your code locally on a Windows machine: https://github.com/tensorflow/swift/blob/master/docs/WhySwif...


Exactly. Why would you buy into a language that is controlled by apple?

Apple's behavior with open source is kind of "throw it over the wall" which isn't really good leadership.

The good stuff at apple is frameworks and apps, none of it released.

For examples of this, look at Darwin on https://opensource.apple.com

They provide some sources, but they are not complete and are more to look at than to use.

I figure this got through the approval process because it could plausibly get developers to pay attention to apple without letting others exit the apple ecosystem.


I've begun using Swift for Linux to build sites on Publish (https://github.com/JohnSundell/Publish) on my CI.


Apple has to ensure that Swift is adopted as widely as possible to ensure that enough people in the world are theoretically able to submit apps to their store.


Nobody is submitting Windows apps written in Swift to the Mac App Store.


That’s not what I implied. Without a vibrant app ecosystem, way less iDevices would be sold. Without developers, the ecosystem suffers.


And without Mac hardware their sales suffer.


> It is not clear at the moment if Apple has any plans to port Swift UI to Windows and/or Linux

It seems pretty clear they have 0 plans on doing that. They could've open sourced it in the first place, along with Combine.

Not open sourcing Combine seems like a pretty short sighted decision to me.


The important aspect of SwiftUI is tight integration with AppKit and UIKit. SwiftUI for Win32 (or whatever) would be a completely different beast.

There's nothing stoping anyone from implementing such a thing, just as someone wrote a SwiftUI for HTML. All the pieces are there, but it would be a huge amount of work unrelated to SwiftUI on Mac and iOS.


It seems like it could still be coming. They might be following the same pattern for SwiftUI (and Combine) that they used with Swift itself:

1. Create and introduce it as proprietary

2. Iterate fast, changing a lot of things to improve it quickly.

3. Stablize

4. Open source it (and continue iterating with an open process)

The advantage to starting proprietary is the initial iteration phase can move move quickly and stay focused on the goals of the people in the controlling group.


Swift wasn't originally open-source, either.


Not only did they announce that it would be open source immediately, unlike the source code dump they did with WebKit, Apple made the entire git commit history public from the initial commit.


FWIW, WebKit's complete history is available in its Subversion repository, all the way back to the initial commits in 2001 when they were importing KHTML and convincing it to compile without Qt. Granted, there was around two years after Safari's initial release where Apple simply published source code drops, but the full code history has been public (first in CVS, then in SVN) since mid-2005.


Where? Here's the transcript of the initial announcement [1]. No mention of open source that I see.

Dr. Dobb's had an article in 2014 [2] which said "Swift is proprietary and closed: It is entirely controlled by Apple and there is no open source implementation."

EDIT: I found a HN post from 2015, just over a year after Swift was released, titled "Swift will be open source later this year" [3]. Not immediate at all.

[1]: https://asciiwwdc.com/2014/sessions/101 [2]: http://www.drdobbs.com/architecture-and-design/swift-objecti... [3]: https://news.ycombinator.com/item?id=9680982


They announced that it would be open-source in the future almost immediately.


Not "almost immediately". They announced it would be open source at WWDC 2015, a year after Swift was first introduced at WWDC 2014. The actual open source release then happened a few months later in December 2015.


hard to open source it when its implementation is tied to the XNU kernel


XNU is one of the few parts of macOS that is actually open source. I’d be pretty surprised though if swiftUI were deeply dependent on the kernel itself, rather than on some graphics toolkit within macOS


It’s largely dependent (but not reliant) on the UI libraries.


Also worth noting that Saleem has also been working on a wrapper of Windows GDI for Swift. While it's not a port of SwiftUI, it looks pretty similar.

https://github.com/compnerd/swift-win32


Would be more interesting Swift on top of WinRT/xlang. https://github.com/Microsoft/xlang

That would also means you would be able to deal with WinUI XAML and all.


quite the juxtaposition to see windows events loop implemented in swift

    while GetMessageW(&msg, nil, 0, 0) {
      TranslateMessage(&msg)
      DispatchMessageW(&msg)
    }
but lib looks really good, i guess there goes my weekend


Thanks for sharing that, very exciting.

If by some stretch that means Swift can then make complete Windows programs, that could be good for consumers but particularly good for enterprise developers.


This is good news to me! I've been very interested in Swift for a long time, but mostly work doing web dev so it would only be useful to me if I could run it on Linux and it initially didn't have a great support story. I know it has been able to run on some Linuxes for a while, but it just didn't appear to be a great ecosystem. Now, there's interesting stuff happening for both backend and fronted (https://twitter.com/lrz/status/1250644001604042752).


The ecosystem isn't npm or anything but it's not terrible if you don't care about targeting Windows. The standard library is pretty good, and between C and Python interop there's generally always a way to do something even if there's not great library support directly in Swift.


> It is hard to think that any Windows programmer would prefer Swift as a language over .NET languages,

It's not hard for me to think that. I've never been interested in .Net languages, and I write stuff for both Linux and Windows. If it was just Swift the language and compiler, and I had to wrap Win32 API calls by hand, I'd happily use it.


XCode (and hence most of the useful parts of using the Apple development ecosystem) as of v11.4 won't install on Macs running Mojave it's actually better, in my view, to use Mono/C# and things like Xamarin than start off with Swift and think you can port the other way and not be forced into upgrading your laptop for the privilege of writing apps for Apple systems.


It may be tempting to go the middleware route, but whenever I worked with middleware I had completely unrelated issues to the underlying framework which either complicated matters, or made it impossible to fix specific bugs. Then there’s the issue that Apple has a pretty aggressive release schedule. For a middleware maintainer it takes pretty long (compared to Apple’s native solutions) to adapt to these changes (I’m thinking about things like the notch on the iPhone X and safe areas). Apple’s secrecy about their upcoming release schedules doesn’t help, but it’s just how things are.

And just a minor nitpick, Apple’s development environment is called Xcode, where just the X is written uppercase.


You can still get around this because it's still possible to run Hackintosh in a VM.


Okay, but surely that's a workaround for devs who are primarily on non-Mac systems who want to use native features for Mac. What's the win with Swift if I'm developing on Windows over using, say, C# and benefitting from all the support for my primary base and then using something like Xamarin.

I'm on a Mac already (Macbook with 10.14) - am I really going to have to run a VM because of a point release? (That goes for both the OS and Xcode so that's even more absurd)

The standard of their laptops is not good enough any more for me to justify the continued and continuous upgrades. Maybe access to their market would be but I'd need an existing set of customers to justify it, else Visual Studio et al look just as juicy.


> because of a point release

The second set of digits represents major releases. The third set represents point releases.

macOS has been out, using this versioning scheme for a little over 20 years. Don't belittle the work between major releases just because the first set of digits hasn't changed.

Windows Vista through Windows 8.1 are all 6.x, but nobody would claim that Vista and its service packs, 7 and its service pack, and the 8 family are minor upgrades — there were some colossal technical changes under the hood between each, especially regarding security and device drivers.

Same thing for major releases of macOS, even if the user-facing stuff doesn't appear to be all that different.

Also, if your machine supports 10.14, it supports 10.15. The last MacBook Pro that dropped support for anything more recent came out in 2011. Nobody's asking you to buy a new laptop.


> The second set of digits represents major releases. The third set represents point releases.

It's called being facetious. Regardless, Xcode definitely does not use the 2nd digit for major releases[1], which does require 10.15.

> Windows Vista…

Completely irrelevant.

> Also, if your machine supports 10.14, it supports 10.15. The last MacBook Pro that dropped support for anything more recent came out in 2011.

Yeah, the reality for my machine is that the upgrade did not take, which is funny considering I only tried to upgrade because of the Xcode requirements.

> Nobody's asking you to buy a new laptop.

They sell hardware. If you think they introduce breaking changes to the operating system tied to the hardware because of necessity then I have a bridge to sell you.

[1] https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_(since_SwiftU...


> It's called being facetious

Then stop being facetious. It wasn't clear you were being facetious, anyway.

> Completely irrelevant

No, it isn't, not to the point I was making. You also don't get to decide what's relevant to a point someone else is making.

The point is that Vista's version number is 6.0, 7's was 6.1, 8's was 6.2, and 8.1's was 6.3. All seemingly minor version number bumps, all major releases.

> Yeah, the reality for my machine is that the upgrade did not take

That's unfortunate — but nobody else's problem. If you have a capable machine, harping on about ...

> They sell hardware

... doesn't really stand. They may be selling hardware — but you don't have to buy any.


Personally, I try to read in a charitable way by assuming that the person writing isn't being robotic - we may (most of us here) be techies but we're still human. I enjoy the wit of others, especially served wry.

Now, to versioning. There is no one standard for versioning. Again, we're mainly techies here, we know this (I hope). I like semver[1] (though I'm having doubts[2]), some prefer calver[3], others use versions as branding[4] (which extends beyond computing). Hence, the choice of version scheme chosen by another organisation or project has no relevance to any other project, their being in the same category or field or competing or whatever simply have no more relevance to this subject than Ford Escort MkII moving to MkIII.

If you're into recursion you might also try applying you "who gets to choose the relevance" logic beyond your own comments, it'll be enlightening.

Finally, if you're going to suggest that all X are capable of something but ignore exceptions to that to me smacks of dogmatism, and more importantly, of no help whatsoever to the person you're responding to.

If you have something helpful or insightful for me then please respond with that, else you can comment further up the thread with your thoughts about versioning and how a hardware company that has been fined for planned obsolescence via software updates[5] isn't angling for more purchases when it stops its dev environment being backwards compatible so it can support a half finished UI library.

[1] https://semver.org/

[2] https://www.youtube.com/watch?v=oyLBGkS5ICk A fascinating talk by Rich Hickey where he questions semver and the way we handle change as developers.

[3] https://calver.org/

[4] https://hbr.org/2011/05/the-best-way-to-name-your-product-20 It's interesting, they did lab tests:

> In laboratory and field studies involving hundreds of subjects, we found that when consumers see a brand-name continuation, they expect improvements to existing features. When they see a brand-name change, they expect fundamentally new features, and they perceive the product as riskier (likelier to fail or more prone to compatibility problems with previous products) but potentially more rewarding (higher in quality, more satisfying to use).

If OS X to macOS isn't a brand name change then what's the point (pun intended) of the 10?

[5] https://www.itworld.com/article/3316958/apple-and-samsung-fi... I got a free battery out of this one, perhaps I shouldn't complain? (wry humour alert;)

Edit: I managed to muck up the numbering. Is Markdown capable of off-by-one errors? I can make it happen.


> The standard of their laptops is not good enough any more

I'm with you on this. When I upgraded my 2015 MBP (or was it 2013?), I was still able to manually install new memory and SSD. Since then, newer MacBooks are not user-extensible, from what I hear, with sealed parts. They have a touchbar instead of function keys or escape (!), the keyboard quality is questionable, and there's no standard headphone jack. macOS has seen unstable releases with poor QA, with one bug bricking the machine.

In addition to those issues, I've been disappointed with Apple's stance and decisions about their proprietary operating system. I guess I've known all along, but it's become glaring. In newer versions I've noticed dark patterns, like being unable to set a different browser than Safari as the default application to open certain file extensions.

> the privilege of writing apps for Apple

This summarizes my feeling. Especially compared to what Microsoft has been pouring efforts into open-source, the way Apple is treating their long-time fans is luke warm at best, hostile at worst.

That's why, as excited I am about the potential of Swift as a cross-platform language, unless companies other than Apple are behind it, I won't be comfortable investing time into it.


There are other editors for Swift out there, like AppCode. I do hate the fact that I'm forced to upgrade to a new OS version somewhere within half a year. Cataline was barely tolerable when I had to jump to it.


Xcode isn't just an editor. AppCode doesn't provide its own compiler and stdlib.


I have a Swift Cookbook that I maintain on Github:

https://github.com/melling/SwiftCookBook


Wonder if some macOS only software will get ported to Windows once this happens. That if course is assuming there’s good support for the Windows APIs for building apps


It’s really the extensive Apple frameworks that make a Mac or iOS app — the layer written in Swift that’s not using UIKit or AVFoundation, etc, is probably minimal in comparison.

So, direct ports are unlikely to be made that much easier, but it definitely opens the door to more code sharing.

Plus, Swift is a really nice language — great to see it getting more adoption.


More likely Apple will just write server-side Swift code that we never see. I really hope they open some, the linux ecosystem for Swift is a little small


dunno about "never see." The last big server-side thing they made (to the best of my knowledge) is SwiftNIO, it's open source, and that was a huge deal for the Vapor project.


i only know of a couple of server side swift software and one of them by IBM was discontinued.


IBM's Kitura was never as popular as Vapor or Perfect. Plus, once Apple released SwiftNIO, much of the things people did use Kitura for were made redundant.


Apple is strengthening their services revenue. They week profit from the extra reach. Also, people will continue to but their hardware because the alternatives aren’t that great

Simple example.... the MacBook trackpad


Ten years ago when I was offered a choice, I told the office manager I wanted a MacBook because of the trackpad.

Apple’s trackpads are even better now. How has nobody figured out Apple’s 2010s trackpad technology?


How has nobody figured out Apple’s 2010s trackpad technology?

I think because the focus is so much on the trackpad technology itself, which may be a misplaced focus. My fear is that the solution may involve rearchitecting the entire application-GUI stack to get it working on Linux. Why? Because Apple's trackpad is not a mouse emulator, it's a first class input device all the way up to the application. Trying to make the driver really smart is fruitless if you throw out all of that rich information and try to reduce the inputs down to what a mouse is capable of.


It does involve the whole stack as explained here: https://pavelfatin.com/scrolling-with-pleasure/

Luckily Linux is closer to figuring it out than Windows and I'm watching several issues on libinput and wayland which are trying to address it.


Eh, I think you're overblowing it a bit. While Apple's trackpad does do some unique things (like Chinese character input[1]), most of the behavior that people are interested in emulating here can be reduced to the cursor position, click events, and (high-resolution) scroll events. The only part of this that isn't currently available on Linux, AFAIK, is the scrolling bits, and even that isn't critical.

[1]: https://support.apple.com/guide/chinese-input-method/use-tra...


It isn't just that. The scrolling in macOS is 2D (you can scroll a small rectangle inside a large one in any direction) and has position, velocity, acceleration, and a bounce effect on the boundaries of the content area. Additionally, you can pinch to zoom (in and out) and the zooming is smooth and continuous centred on the cursor location.

There are also various 3-finger swipe gestures, and force touch lets you click on things with different levels of force to do different things.

The only Linux application I've seen that uses smooth scrolling with acceleration is Firefox, and that isn't nearly as smooth as macOS scrolling (which is available in every application).


Two-axis scrolling isn't unique to macOS. The way that scrolling has traditionally been implemented on Linux (as mouse buttons 4 and 5) makes it difficult to implement any kind of continuous scrolling, but once you have one axis working, a second one isn't much harder.

The velocity and bounce effects on scrolling are implemented at the application layer. They don't depend on any unique features of the trackpad hardware or driver stack.

Zoom and swipe gestures are nice to have, but I don't think they're critical in the same kind of way that pointing and acceleration are.

Force Touch is more of a gimmick than anything. It's a relatively recent feature, and was only added to the Macbook Air in 2018; very few applications do anything interesting with it. Personally, I leave it turned off.


The velocity and bounce effects on scrolling are implemented at the application layer. They don't depend on any unique features of the trackpad hardware or driver stack.

I didn’t say they did. Oh macOS they’re not implemented by the application though, they’re implemented by the UI APIs and thus available to all applications for free. This is not the case on Linux.


It is the case on Linux. Both GTK and Qt have this built in for a while now:

https://developer.gnome.org/gtk3/stable/GtkScrolledWindow.ht...

https://doc.qt.io/qt-5/qscroller.html

Why it's not working on your applications is a different question.


The Force Touch trackpad was introduced in 2015. My 2015 MacBook Pro has one. I rarely use the “harder press” feature, but I love the adjustable click pressure (lightest setting for me), and how the same pressure anywhere on the trackpad works (as opposed to hinged models). I’m ruined for any other laptop just due to the excellent trackpad.


It’s used for drawing and illustration. Art is not a gimmick,

ArtIsts are one of apples most important cohorts. People here so condescending but why pretend like people don’t care about art or gaming?

Folks care far more about using their computer to make art than hating on Swift or Electron


As someone who's put a ridiculous amount of effort into mouse-specific user experience, I agree. Apple's only physical/technical advantages are resolution and accuracy (and they only have that because they have software that justifies the cost). The real advantage is they spent research and engineering hours, LOTS of them, determining how to give the best user experience for the majority of their users, including users coming from other platforms with other expectations.


> AFAIK, is the scrolling bits, and even that isn't critical.

It seems that this is in fact the chief complaint of the folks who commented above you. It seems like they're saying that they choose to purchase alternative goods because of that behavior. That seems critical to me, no?


Most of the complaints I've heard about non-Apple trackpads focus more on pointing behavior -- finger tracking, pointer acceleration, palm rejection, etc. -- than scrolling.


That’s because those are old complaints. It’s a moving target though. People are still complaining about problems that were solved over a decade ago in macOS. Now there are a bunch of new features (described in my other comments) that need to be added if you want an experience as smooth and intuitive as macOS on a recent MacBook.


They don't care because, for all of the faults of Apple's desktop/laptop strategy, the non-Apple strategy continues to be "copy form factor, invest nothing in user experience".

Edit: I knew this would get downvotes, but it's true in my experience. The closest exception is Microsoft themselves, and even then their hardware focus is limited and mostly intended as a demonstration for their OS customers.


Agreed but with touchscreens the trackpad isnt so important.


So true.

I was talking to someone also in lockdown and she's in the market for a new laptop or iPad/keyboard.

She also wants to play games with family and friends and that's when she realized multiplayer and games in general on iOS and Mac were not a strength at all.

IMO, Apple's above-average hardware (at times, not all keyboards) is severely hurt by the lack of real gaming options on Mac or iOS.

I think that is even more glaring now in our present circumstances.


I dunno IMO the macbook trackpad is not good,

RSI inducing tap to click barely works and you have to enable a horribly implemented accessibility options just to drag with a gesture to each their own though

the reflective screens they put on those things also cause eye damage


> RSI inducing tap to click [...]

How does tap to click induce RSI? Surely it's easier on your wrist and hand than having to press a button with force.

> [...] tap to click barely works

That experience doesn't seem to square with most peoples' experience.

> [...] and you have to enable a horribly implemented accessibility options just to drag with a gesture

I'm guessing you mean that it's annoying that dragging with three fingers is hidden inside the Accessibility preference pane rather than more sensibly placed in Trackpad preferences.

It's true, that's a dumb place to put it — but that doesn't impact whether or not the MacBook trackpad itself is good, which is what you were asserting.

> the reflective screens they put on those things also cause eye damage

Okay, now you're just ranting.


When I started writing my Mac app, I made the somewhat nervous decision of going with Swift. So I am really quite excited to hear this news, since getting onto Windows is something I've always thought about as a possible future direction. Of course, there would be a ton of work to do, since many frameworks like Core Data etc are only available on Apple platforms…


They need objc2swift, something like c2rust[1], to speed up the legacy code upgrade. Transpiler and code refactoring tool, all while preserving the ability to run tests. Or, on the other side, c2rust should get an Objective C support as an input.

[1] https://github.com/immunant/c2rust


In my opinion, the integration between Objective-C and Swift is so incredibly seamless, that there's no need to translate existing Objective-C code.

When I started working at my current client, there was a huge existing Objective-C code base to talk to an internal HTTP API. I just started coding. When I needed to add functions, I subclassed Objective-C classes in Swift.


There is need to translate existing Objective-C code: on platforms where the Objective-C bridge is unavailable (Linux and Windows), Swift code can not call Objective-C code, nor toll-free bridge with Objective-C types, and therefore Objective-C types cannot be subclassed.

For non-Apple platforms, you have to use a different implementation of Foundation — which has pretty good but not identical coverage to Apple's one.

As a side note, it's always seemed clear to me that when Apple provides a new technology, they provide a stop-gap solution, like Carbon, for developers who, for a variety of possible reasons, may not be able or willing to use the new tech, like Cocoa.

The bridge between Objective-C and Swift has always seemed like Carbon to me.

Fortunately, unlike when Carbon was canned and rewriting for Cocoa seemed like a real chore, I don't think Apple will can the Objective-C bridge any time soon — but for Swift code now targeting or intending to target non-Apple platforms, it may be best to start thinking about migrating away from relying on the bridge now — decarbonify your Swift code.


Doesn't seem like there would be much demand to run legacy Objective-C code on other platforms, as it would most likely be strongly tied into macOS or iOS APIs that would be availble anyway.


Indeed. Although, some of the things that Apple's ObjC Foundation provides that aren't in Swift's cross-platform Foundation are sorely missed — but I doubt there's much impetus to put them in Swift's cross-platform Foundation, either.


Yeah, that could be an interesting use case.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: