Swift on Windows
swift.org
swift.org
I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why SwiftUI itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! Apple being Apple, each revision of SwiftUI is now glued to a singular release of a major revision of the OS. Instead, if Apple decided to built SwiftUI entirely in the open, then the foundational APIs that are closed-source would have to co-exist with the open source versions in order to work.
This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries.
So on the one hand, if you're a fan of Swift, you have yourself a nice hobby language you can play with on the weekend on your gaming PC. On the other, I'm not entirely sure what the point of this effort is for?!
Keep in mind, the UI code will be completely custom for Windows though.
So Swift programs on Windows will actually look and feel like a Windows program? Good.
> After an extensive discussion, we ended up with Electron as the front-end part of future Spark for Windows.
Apparently they use a Swift plugin for Nodejs
I'm not quite sure I understand your point. Are you saying Swift has no value outside of SwiftUI? It's a pretty nice general purpose language.
Bugs in Apple's internal variant are tied to OS releases, whereas bugs in the open source variant are tied to someone getting around to fixing it.
If Apple went all in on open source like Rust, or all in on proprietary/closed, then it would have more consistent messaging about what the language is for.
Is the situation that different from C# and windows API's?
https://github.com/dotnet/roslyn (c#)
https://github.com/dotnet/winforms (UI) https://github.com/dotnet/wpf (UI) https://github.com/dotnet/core (Foundation)
I don't consider the Win32 API itself part of .NET or C# as they've existed long before either.
> I don't consider the Win32 API itself part of .NET or C#
SwiftUI isn’t “part” of Swift either, it’s a proprietary application of Swift, and it’s fucking amazing, I don’t want to work with any other framework now.
That's one of the reasons AMD pushed Mantle, then pushed Vulkan and DX12 and dropped Mantle. The shape of the API better fits their model for driver development than OpenGL or DX prior to 11, and they're happy for their competitors to help build an ecosystem that works better on their products than the alternatives at the time.
IMO, this is the best model for library/API development if you can pull it off.
It has a runtime API that should work with different versions of the OS. There were changes to the compiler that they didn't talk about until after the fact though. After SwiftUI was announced they did run those through swift-evolution.
SwiftUI for the most part is just a runtime library, the compiler changes made things a bit nicer, but most of it could be achieved without compiler changes.
My clients app requires supporting iOS 11, but I’d love to start mixing in sone SwiftUI.
That's like how Catalysts runtime wasn't backported to older versions of macOS.
They could decouple those frameworks from the OS, but that adds other headaches and you eventually gotta draw the line somewhere so they tend to only add new frameworks with major OS updates.
The main purpose seems to be to enable developing back end server code in the same language and using the same service APIs as the client code on mobile and desktop.
Be careful not to confuse Swift with SwiftUI. SwiftUI is just a UI framework. It's the one Apple is pushing right now, but it doesn't really have any bearing on the cross-platform story for Swift. (I doubt it ever will -- I don't think Apple particularly wants to take it outside the Apple ecosystem, and it would be very high effort to do in any case.)
Swift is first and foremost Apple's own language for Apple's own frameworks. The frameworks aren't layered on top of an immutable language. The language is evolved to serve the frameworks' needs. This has already started with Objective-C 2.0, but with Swift it's even more obvious.
Yes, but that's neither here nor there. The changes in Swift to make SwiftUI easier can be used by others to implement their own (Windows, Linux, whatever) Swift UI frameworks as well.
Obviously Apple, as the core devs of Swift and sole devs of SwiftUI would have more influence on Swift direction.
It's an open project, but not some "community designed" language. On that regard, not very different from C#, Java, etc.
Very powerful, fast and close to the metal, but with uglier* syntax and not as productive as the next family of languages. Which are:
Java, C# and Swift (unlike C++ and Rust) for me are pointing into solving a very hot spot of programming, with the balance of power, being more pleasant to program in and feeling more productive.
Your code will be almost as fast as a C++ program, but you dont need to feel (that much) miserable writing stuff into it. (And i say this as someone that likes C++, but knows its not the most productive and pleasant experience)
It remedy some pain points of programming, that in my point of view at least, Rust didnt addressed the same sweet spot as Swift does.
Theres also some good things about Swift right in the corner, that is support to C++ bindings and a more fine-grained control of memory.
Once the memory ownership changes, than we will also be able to consider Swift for the same things as C, C++, Rust and Zig can right now.
Also i would say that dinamic calls while embedding script languages and function builders are very strong points that the language is becoming more powerful with each release.
Also some things like binary stability that Swift have that Rust doesnt are thing to take into account for, giving there are a lot of cases were shipping just the binaries and know they will still work is something very important for projects that cant afford to be open source.
I would consider to use Rust whenever C++ would also fit, but if i can use Swift i would not consider using Rust, because at least for me is a much better language to code.
I think people from the Rust community dont need to fear, because Rust have a strong community right now, and in that particular topic, is Swift that need to catch up and shake up this feeling of being a "apple owned language".
So i dont think they are aiming for the same thing, and therefore they dont need to be compared in a us vs. them basis, giving you can code on both, and i think it could be great if you do it.
Theres a false adage that you need to pick just one language, and having used a lot of languages and platforms over the years, im pretty happy now that i know that such thing doesnt exist.
You are better picking from 2 to 3 languages and use them according the goals of what you are building.
For me, my three languages are: C++, Swift and Python.
C++ for hardcore stuff, Swift for everything that a language like Java or C# could be considered and Python for the more relaxed (and now also expert) stuff.
You can replace Python with Ruby, Lua, etc.. replace Swift with C#, Kotlin, Java, Go, Scala, etc.. and replace C++ with Rust, Zig or C.
But if you mix the families, i say you will have a hard time using Python or C++ in the wrong places.
And this rule is also valid for Rust unfortunately.
* Note: i know this is subjective and a lot of people would find it more beautiful than Swift instead. Its ok and even good that we dont all have the same tastes.
It's shocking how mismanaged the SDK development at Apple is.
Knowing why Apple is doing this is important to understand why this will never happen.
Apparently the feature they are using is function builders (1) and its already working on the current versions of Swift. So at least now, nothing is preventing other people to try to replicate in a open source manner those features.
By the way, there are some projects on Github that already implements the same functionalities.
Don't wait for Apple to open source this kind of stuff, because one way to enforce lock in, is through API. And Apple is far away from being a benevolent big other as some people might naively assume.
1 - https://www.swiftbysundell.com/articles/the-swift-51-feature...
That is, "So at least now, nothing is preventing other people to try to replicate in a open source manner those features." was always the intent
Similar to rust implementing magic features and APIs, and macros, in nightly, before the API is verified and the implementation is ready.
In which case, you'd expect all of SwiftUI to be eventually possible by anyone else.
Function builders are still not a public feature, and therefore subject to breaking revisions without warning.
edit: and most of the useful additions are tied with iOS14 (lazy lists), so even if we were able to bump our min support to iOS13 it would be _years_ before we could do 14.
iOS 14 Adoption Surpasses 25% Across iPhone and iPad Five Days After Release
https://old.reddit.com/r/apple/comments/ix3gve/ios_14_adopti...
How long does it usually take on Android?
And the number of people still on 12 is significant.
It matters in the current context. Developers have a much easier time targeting the latest and hottest on iOS, compared to the only other alternative.
> And the number of people still on 12 is significant.
Not for long if 14 is already 25% in less than a week, and most users upgrade to the latest versions soon enough.
Nobody was doing comparisons either. But for this topic shouldn't we be comparing to windows programming tools too? And those generally get to update their language runtimes all on their own, without waiting for the OS at all.
> Not for long if 14 is already 25% in less than a week
I don't understand that logic. I didn't say 13, I said 12. The release of 14 isn't going to suddenly get a significant number of people off 12.
The number of users on 12 is going to drop over time but 12 is locked in as the final version for multiple percent of iphone owners in the US. It could be two more years before most companies are comfortable breaking compatibility with that to get some coding conveniences.
As mentioned above this is not true. On Android developers can ship the latest and greatest to devices 4-5 years old because the first party libraries are distributed in such a way to enable that.
SwiftUI/Combine are bundled with OS versions.
So, just like Android?
Nominally open, but closed source and proprietary APIs needed for modern apps are installed with the Play Store ?
https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
It's half the functionality that makes an Android device work for an unsophisticated user. To the point that people have to write shims just to get basic apps to run without it.
And the amount of functionality Google has moved into GPS has only grown over the years mind you, from things like Doze and its interaction with GPS, to installation processes that hook into it for verification...
If Android didn't have Google Play Services, it wouldn't be anything more than what Linux on smartphones is... a toy for geeks, nothing competitive with offerings like the iPhone.
SwiftUI is just a closed source framework. What's so confusing here? We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would we of Apple?
> On the other, I'm not entirely sure what the point of this effort is for?!
To develop using Swift on Windows. It's not terribly difficult to imagine that people might enjoy using their preferred language on other platforms — you mentioned Rust, after all, and that's on practically everything.
I think the confusion you have is not understanding the boundaries between Swift (the open language) and SwiftUI (the closed framework) — which, honestly, given the names, I can completely understand.
.NET is fully open-source now and it is developed in the open. And not just the BCL, but also platform UI/UX libraries like [WinForms](https://github.com/dotnet/winforms) and WPF.
(Yeah I was taken aback too: if you told myself from 10-15 years ago that WinForms would be open-sourced under the MIT license I'd think you were mad - or that Microsoft went out of business after the Year of the Linux Desktop really happened and open-sourcing everything was their swansong).
WPF, unlike WinForms, is ostensibly fully separate from Win32 and so should be possible to port it to non-Windows platforms.
1. WPF is now MIT-licensed.
2. Unlike WinForms, the bulk of WPF is managed-code, not a thin-wrapper over Win32.
Therefore anyone can now port WPF to Linux, macOS, etc - and they only need to port the "PresentationCore" part of WPF (i.e. the native parts that expose Direct3D drawing surfaces to WPF).
SwiftUI (or even UIKit/AppKit) are not the point of Swift.
Same way Windows Forms or QT are not the point of C++.
So there's that...
And how easy/worthwhile is it to use Rust for building GUI applications or games on Windows?
DirectX is closed source too, and I don’t even know what UI framework Microsoft is currently championing.
Some examples of this IMHO include:
- While Swift itself is open-source, "Foundation" (which is something of a stdlib of Swift and provides many key pieces of functionality) is not open source - at least on macOS. There is a reimplementation of Foundation for Linux which is open source but, surprise, surprise, the two sometimes have different behaviour...
- Swift releases are weirdly coupled to XCode releases, a closed-source IDE. Moreover, while technically possible, most people on macOS don't install Swift on its own, but always through XCode, and the two are quite tightly coupled (you can technically change the toolchain, but it's quite an opaque setting IMHO). This leads to a lot of "I updated XCode and now the code is not working anymore" issues, especially with more junior developers.
- Tooling outside of XCode (itself not the greatest of IDE of all times...) is extremely ... limited. For example, XCTest's (the test framework's) console output is almost unreadable and there are actually (half-abandoned) third-party tools that try to parse it and format it nicely (while introducing tons of weird bugs), something that test frameworks for other languages can just do for free. The package manager has, I think, one maintainer, and is so underpowered that most iOS developers don't really use it yet (despite it now being a couple of years old). And in terms of editor/IDE support there is now technically a LSP implementation, but last I tried, I couldn't even manage to set it up properly.
- There is no clear roadmap or even mission statement for Swift. Many other languages try to be clear about where they're headed and also what kinds of things they don't want to support, but Swift development is this weird mixture between a) a "community process" that often just leads to very different parties bringing their own very special concepts, syntax sugar, etc. into the language development without there seeming to be any overarching idea of where this all is headed, and b) some things just seemingly being implemented because it's useful for some shiny Apple feature ("function builders" which is mainly meant to support SwiftUI and which many people have been very skeptical about). Meanwhile long-standing proposals like properly fixing generics ("Generics Manifesto") are being pushed back indefinitely. It seems to me sometimes that Swift developers are willing to let the community bikeshed on trivial matters (e.g. syntax sugar), but when it comes to more important, long-term concerns (should we implement function builders or rather invest in some more generally reusable macro-like / code generation feature), are being unilaterally decided without really consulting the community.
Which parts of the generics manifesto are "properly fixing generics" in your opinion?
Also, there are some annoying restrictions around existentials, and documentation of Generics and other advanced type machinery could be a lot better in general.
Slightly OT: I wish people wouldn’t put such large license headers in source code. I just don’t see the point, and it’s often longer than the actual source!
There's an ongoing effort to fix this:
https://www.linuxfoundation.org/blog/2018/08/solving-license...
I thought WPF or WinRT or UWP was supposed to have replaced Win32 by now.
[0] - https://docs.microsoft.com/en-us/windows/apps/desktop/
[0] https://github.com/apple/swift/blob/master/docs/CppInteroper...
The C ABI is stable. Any (normal) C compiler and a bunch of compilers of other languages can produce blobs which can be linked with each other, and by extension with C++ code with extern "C" declarations.
Apple had their own problems with this (Carbon vs Cocoa) but that legacy has been shaken off.
If both platforms had to handle such migrations, I guess it's only fair to say that Windows' solution would be much more difficult given how committed Microsoft is to maintaining backwards compatibility.
Cocoa was not only older (the API comes from NextStep), it was also always marketed as being the "Native" API from day one [1]. Carbon was a secondary API marketed by them as a way of having "applications that also run on previous versions of the Mac OS (8.1 or later)" [2]. Carbon apps were uglier, clunkier and harder to write/maintain than Cocoa.
Now that I remember it: Back in the early 2000s Cocoa was so much better that they had to write iTunes (or was it Finder?) in Carbon to convince developers that Carbon was able to handle real world apps.
The problem with Carbon is that companies like Adobe, Autodesk and Microsoft overstayed their welcome and dragged their feet for almost 10 years instead of porting to Cocoa like Apple recommended in conferences. To convince them to port, Apple deprecated Carbon it in 2007 and removed it 12 years later in 2019.
[1] http://web.archive.org/web/20010617021453/http://developer.a...
[2] http://web.archive.org/web/20010620032754/http://developer.a...
I don't know much about the history of Finder in this regard, unfortunately. It of course existed from System 1.0 in 1984, but how much of Mac OS X 10.0's Finder was a complete rewrite and how much was ported from Classic Finder vs NeXTStep is something I have no idea about. It certainly had UX that came from NeXTStep (the column browser, for instance).
It was for Finder. During one of the WWDCs or MacWorlds (I don't recall which), Jobs specifically mentioned that Finder was written in Carbon as a way to show that Apple eats its own dog food. It was the big demonstration that Carbon wasn't some second-rate API … although, of course, it was.
Dogfooding as a concept isn't Apple-specific but it's definitely a meme in Apple circles — especially when Apple is detected as specifically not eating its own dog food!
- On old 90s hardware, Carbon could be faster (due to the C API)
- Apple didn't invent AppKit or Objective-C. That technology was inherited from NeXT and from what I understand there was push-back both within Apple and from the Mac developer community about adopting a language with an unusual syntax that nobody used.
Apple tried to transition Objective-C to a modern C++ style syntax, and failed.
Apple tried to get developers to use Java with AppKit (hence, the name Cocoa) and failed.
Apple tried to get developers to adopt garbage collection, and failed.
In the end, they didn't need to do any of that. Mac developers eventually became quite enthusiastic about Objective-C and AppKit and it quickly because the one true way to write Mac apps.
However, it took many years for Cocoa and AppKit to become fully formed. Up until 2009 and OS X 10.6, there were still many things that couldn't be done in Cocoa and required the Carbon APIs, mostly related to the Mac-specific features of the file system, like persistent file references, icons, metadata, etc.
For example, if you want to implement a UI for copying a file, you're going to want to display a progress bar and have the ability to cancel the operation. Up until OS X 10.6, that simply couldn't be done with Cocoa (NSFileManager, NSURL, etc.). You had to use gnarly Carbon APIs.
(Actually, it still can't be done with NSFileManager, but Apple added that ability to the Darwin file system APIs.)
That's why the Finder was initially implemented in Carbon.
And little bits if Carbon still live on in the modern 64-bit Mac world. If you want to implement global Hot Keys in your app you have to use the Carbon API and convert the Carbon key-codes to their AppKit equivalents.
Windows Forms and the native API share most of their controls' look and feel while WPF is a free-form application framework that allows you to ignore all UI standards if you desire to. I can't remember the last time I've seen a WPF application though, I think it's either dead or dying already.
UWP is the new API Microsoft really wants everyone to use. It comes preloaded with the "native" Windows 10 feel with their new design and is intended to be distributed through the MS app store (though you can install packages manually with some effort as a developer).
It's what new applications aiming to be Windows native probably should be using in my opinion, but most developers seem to stick to the native API or its wrappers. That means there's barely any UWP applications in use by most people, which means they aren't used to the UWP style, which means they find UWP apps weird, which means there's barely any UWP apps, etc., etc., etc.
https://microsoft.github.io/microsoft-ui-xaml/about.html
> WinUI 3 is the next version of the WinUI framework, shipping later this year. It dramatically expands WinUI into a full UX framework, making WinUI available for all types of Windows apps – from Win32 to UWP – for use as the UI layer.
In Windows there are totally different widget look and feels supported...
Button: https://github.com/dotnet/winforms/blob/master/src/System.Wi... / https://referencesource.microsoft.com/#System.Windows.Forms/...
Toolstrip (also base for menu): https://github.com/dotnet/winforms/blob/master/src/System.Wi... / https://referencesource.microsoft.com/#System.Windows.Forms/...
But that's how we do custom controls in Win32. You can get very far with only common controls, but as soon as you need something more complicated you have to draw it yourself. Just because they're using C# doesn't mean it's not the same API or is not native controls.
WPF on the other hand is completely different, internally it only uses native calls to get the canvas where everything will be drawn and to handle input/accessibility (plus a few other things).
Great to see it getting more support outside of the Apple domain.
Doing this in Javascript(Node) instead, is very cognitively taxing for me. Mental models are different, so I need to “cool down” and start thinking in the other language when switching between app dev / back end.
Swift is so nice That i would rather do everything in it anyway but not having to switch mental models is the real reason.
Edit: looking at the docs again theres an official upgrade guide now so thats a step int he right direction, I'll take a closer look when I get a chance.
What other backend language doesn't allow you to recover from errors? It is my understanding that even Haskell allows you to catch "error".
I developed a Swift server-side app (not with Vapor, but with Kitura - but the point still stands) for two years and this was one of the biggest issues, and despite ongoing discussions, it just has never been fixed.
Before, the lack of a good cross-platform story kept me away. Now, I think this gives me an excuse to play around with Swift.
1. version/dependency management is a bit of a pain. Every time there's a major language update I have to do surgery on my larger swift projects
2. ARC-based memory managements has some serious pitfalls in terms of worst-case performance characteristics.
But in terms of syntax and general philosophy, I have never found a language more pleasant to work with than Swift
It seems like Windows already has a glut of similar tools; if you wanted to make a real impact with a fairly new language, which Swift is, with massive corporate backing, which Swift has, the one would think Linux would be a far more opportune destination for an effort like this.
Windows on the other side were started as a community effort of only one brave fellow. That later was even hired by Apple as far as i know.
I guess this is why this is much splashy than the Linux support. It was more of a community thing and less of a corporate thing as the Linux support was.
EDIT: but kotlin MPP is my long term hope. Once they iron out the kinks (e.g. ios coroutines)
Plus, it’s running JS off thread. Performance has been fantastic. I rewrote recently an app in SwiftUI - the React Native app was faster and easier to write. Which was a surprise to me because I like the SwiftUI components more, but in the end the far superior hot reloading and far better dev tools, along with the much better flexibility (less time “getting the code/types to run”) meant I was moving about 5-10x faster.
Finally, we are sharing almost 100% of code across native and web. We built a component kit designed to use react-native-web and that handles just a few edge cases, and the net result is quite awesome. We do obviously have it designed to look different when mobile, but it’s the exact same as the web responsive mobile. The web version adapts nicely based on screen size as well.
So unlike Flutter you’re not having to deliver a massive web bundle with tons of incompatibilities and perf issues. And unlike any other language you’re fully cross platform.
I ran it for the first time the other day on Android just to test if it worked and it did first try, no code change necessary. I’ve definitely changed my opinion - React is not just viable, but preferred to me, even if I could theoretically move as fast with a native app in each language.
My issue with JS isn't the fact that its on/off the main thread, its that it is _necessarily async_ due to the bridge. That is _really_ limiting to design around.
Thats why Xamarin is in many ways the best of both worlds for mobile dev. If WASM/client-side-blazor take off then it can also target web.
For async issues, the canonical example I can think of is state restoration for when an app/activity is reaped by the system. These are synchronous platform APIs and so your options are very limited on how you plan to support them. Another example would be doing any sort of IO/background processing in the JS context that happens to return during interaction/animation that is also in the JS context.
I think they've improved quite a bit on animations, the Animated library has worked well for me with PanResponder, I was able to get a pretty complex bottom drawer interaction working (much like Apple Maps) where you need to handle bubbling events with multiple nested scrollable areas and dragging that inits only when scrolled to top, etc, all came together very smoothly. In SwiftUI it was a similar API, but far more work to get to behave and in the end I was doing some hacky stuff to get it finally fully behaving. Granted, SwiftUI is early stage, so perhaps in a year or so it will also have figured all this out.
As for testing, we've tested on a $100 two year old Android device with success, but nothing truly old.
[0] https://github.com/react-native-community/discussions-and-pr...
More news tomorrow, but see, for example: https://www.windowslatest.com/2020/09/21/google-flutter-uwp-...
(Disclosure: if it's not obvious, I'm on the Flutter team.)
They released a custom swift toolchain to target android.
Unfortunately there doesn’t seem to be a lot of interest from the swift core team, because i couldn’t find any official info on the state of android compilation (what part of the stdlib works, what doesn’t, and how to interop from java /kotlin to something compiled with swift).
There are some aspects where Swift is nicer in theory (e.g. Swift enums beat Kotlin sealed classes in terms of ergonomics and, while unnecessary for 99% of projects, we had some genuine use case for custom operators, working on a maths product). But other than those, it seems to be that Kotlin is the superior language in almost every respect. It seems to have none of the major flaws that Swift has, and the tooling is great, which is the exact opposite of my experience with Swift.
Still, you never know, it might manage to do it by fluke!
Another benefit of a community-driven language as aposed to a corporate-controlled one.
Rust began as a project in 2010, Windows 7 was released in 2009.
And right now, that is C++, JS, Rust and .NET. Not more not less.
Moving from Linux to Apple development has been a shock: All the gate keeping to keep me out of their hardware - after a month I still cannot reliably put my code on iOS - not for technical reasons but for license reasons.
Swift really suffers for coming from this environment. IMO leave it alone unless you have to develop for Apple hardware - and if you have to develop for Apple hardware - that is a business problem and you need to solve it.
If I were a Swift developer focused on Linux or Windows, though, it'd be a whole different story. The author of the linked blog post is a member of the Swift core team, and did most of the work to bring Swift to Windows himself, but outside of him, I don't really know anyone particularly focused on it.
(I've also made a very decent living for 15 years developing almost exclusively for Apple platforms, so I disagree with your last paragraph too, but that's another thing altogether.)
And it seems that they believe that the "outside" world cares about what is inside Apple's walled garden.
Truth is, for non-Apple people: Swift => Apple => no thanks. It is easier to see an Apple programmer excited about .Net than a Windows programmer paying attention to Swift.
FYI -- You may want to take your head out of your ass.
For example write code in Swift, compile to X, compile to Kotlin. Voila, I have cross platform code, just need to write some cross platform libraries that wrap UI, networking, etc for each platform.
Elements compiler [0] seems to do just that. Does anyone have experience using it in production? Why is this not being adopted as a viable cross platform solution?
I'd be curious to know why that is, given that once you have a few languages working, adding more on, intuitively (I have no experience in this) wouldn't be too difficult, given how many features the languages share?
In Elements we spent a lot of time on getting it right, and I think we have most edge cases covered for user code. The way generics are used in the Swift runtime library seems impossible to map perfectly on top of the concept of generics as C# has them though.
The « low level language » is actually LLVM intermediate language, and LLVM already support building for all the major targets.
For JVM and .NET/CLR based languages this is pretty easy and common.
> just need to write some cross platform libraries that wrap UI, networking, etc for each platform.
Congratulations, you've invented the JVM.
Poor Apple, budget cuts have been hit really hard.
They are trying to push Swift for Tensorflow [1], so proper upstream cross-platform capability would probably be important to them.
That's lost in the TensorFlow team budget.
Now contrast this with Java or .NET where the large majority of the development comes from the corporations themselves.
That's how open source is supposed to work, isn't it? Somebody wants a thing, they develop it, release it, and everybody improves on it?
They have to prioritize resources and Windows should be way down near the bottom of the list. It’s easy to say Apple has nearly infinite amounts of resources, but that never true in the software business. Someone has to manage the project, hire/manage teams, make decisions on goals, objectives, and they have to be managed by someone in engineering leadership, etc.
The simple answer is that focus is better spent on more important distractions.
Hence pjmlp wrote: "Poor Apple, budget cuts have been hit really hard". I think that's entirely fair.
Apple's resource is not infinite, but it's certainly more than enough to port Swift to Windows. Hence pjmlp says it shows "how important this is to Apple", especially in comparison to Java (Oracle) or .NET (Microsoft). I tend to agree.
As for why, Microsoft apparently has enough money to port Java to Apple Silicon.
https://appleinsider.com/articles/20/09/22/microsoft-contrib...