Swift has this weird sort of ecosystem where Apple builds much of the platform in a very secret (most of the roadmap isn't shared), closed-source variant for its own OS. Then it has this open source version, with a very public compiler (roadmap IS shared) that allows cross platform toolchains like this one to exist.
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?!
> 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?!
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.
> 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?
.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).
WinForms is just a wrapper around Win32 API - which is closed, and so won't run on other platforms. So in many ways very similar to Apple's position on Swift and SwiftUI
Yes, but even-so it's now far easier to make an alternative WinForms implementation for non-Windows platforms. Mono had their own workable WinForms implementation a while ago (which was a clean-room implementation, IIRC), but now that isn't necessary.
WPF, unlike WinForms, is ostensibly fully separate from Win32 and so should be possible to port it to non-Windows platforms.
I wrote a project about a decade ago that used WPF and was disappointed to hear later that Mono wouldn’t be implementing a clone. They actually recommended Silverlight if one wanted cross-platform WPF. But WPF is just so much better than WinForms IMO, and Silverlight was on its way out then.
But they don't need to reimplement it entirely from scratch or as a clean-room implementation because:
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).
> I call it out as weird because take SwiftUI for example
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.)
SwiftUI could not have be written for the public version of Swift. Instead, the Swift language has been changed to have SwiftUI's desired syntax. That level of symbiosis is not "just" a UI framework.
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.
>SwiftUI could not have be written for the public version of Swift. Instead, the Swift language has been changed to have SwiftUI's desired syntax. That level of symbiosis is not "just" a UI framework.
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.
Objective-C was already like that since NeXT exists, stuff like protocols did not exist originally in the version that NeXT licensed from Brad Cox's employer.
And then later modified by complaints and feedback by the community. SwiftUI is still in its early stages but its earliest releases changed quite a bit. Some of the documentation still hasn't been updated to reflect those changes.
It looks similar to what happened with dot.net / mono, where Microsoft kept pushing tools and UI libraries for Windows and the ecosystem outside Windows stagnated or played an impossible catch up
SwiftUI being closed source is a huge issue for developers. Apple behaves as if every user is immediately on the latest version but the reality is the _lucky_ developers support one major version back. SwiftUI is broken in completely different ways for each minor release of iOS 13 and none of the fixes in 14 are possible to use in 13.
It's shocking how mismanaged the SDK development at Apple is.
Yea SwiftUI being tied to the iOS runtime was an incredibly bad decision IMO. WWDC the last couple years has been mostly useless because it's all about SwiftUI, and basically none of Apple's major app partners can use it yet since we are stuck supporting iOS11/12.
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.
SwiftUI is an attempt to stop the spread of people coding for things like React and instead focus in a Apple only SDK so they accomplish their goals of developer lock in.
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.
If you look at it benevolently, then it seems like they tried to force out the API they wanted, and made it publicly available to verify, and then worked backwards to implement it in the compiler properly
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] 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.
Function builders are still not a public feature, and therefore subject to breaking revisions without warning.
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.
> 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.
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.
My point is that Apple's weird choices like SwiftUI being tied to internal versions of the standard libraries creates mixed messaging. It's only general purpose enough that on Mac/iOS you get Apple's version of the standard libraries. On other platforms you use an open source version of the standard libraries as the community sees fit to implement the API.
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.
In practice I don't think it's that confusing. You have a large standard library which is available everywhere, and then you have a set of proprietary API's which are only available on Apple platforms.
Is the situation that different from C# and windows API's?
Exactly, and most of the proprietary libraries and frameworks in Swift are in the exact same situation. They are mostly wrappers around macOS and iOS libs and UIKit/AppKit
What about DirectX? And what’s the most common framework for Windows GUI apps anyway?
> 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.
Why would Apple want to write a completely new cross platform UI library, cloning the Mac OS desktop UI and give it away, or give away the Mac UI directly? How does that serve their interests?
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.
I speculated when it first came out that internally they have a port for either Windows or Android or both, if for no other reason than to discover any architectural limitations that would preclude such a thing. But I also think it's very unlikely that SwiftUI will ever be released for any non-Apple platforms.
They already have a port of some of the core platform GUI elements to windows. It's used in the Windows version of iTunes. It's probably quite minimal though.
>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?!
SwiftUI (or even UIKit/AppKit) are not the point of Swift.
Same way Windows Forms or QT are not the point of C++.
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.
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.
> Swift has this weird sort of ecosystem where Apple builds much of the platform in a very secret (most of the roadmap isn't shared), closed-source variant for its own OS. Then it has this open source version
So, just like Android?
Nominally open, but closed source and proprietary APIs needed for modern apps are installed with the Play Store ?
No, sorry if this sounds rough, but it's a 'not even wrong' comparison - the UI component code for Android is open and in the 95% case, _not_ tied to an OS version. What you're referring to as closed source and proprietary APIs is the idea that APIs backed by a Google service (ex. GPS coordinates -> address) are shimmed out and require a plugin from the vendor - and ex. Google's version of this API is _not_ open source, and the open source version of Pixel excludes non-Google elements (such as the date + weather widget not having weather)
>Play Services is a closed source app owned by Google and licensed as part of the Google Apps package. Any feature you see move from "normal" Android to Google Play Services is also moving from open source to closed source. This app pulls off the neat trick of not only enticing users with exclusive, closed source features, but locking in third-party developers with Google's proprietary APIs as well.
Yeah, the language you quoted is histrionical and responsible for innumerable mistaken impressions, including me, until last year. If you skim the headings you'll see it's things that'd more or less be 'obviously' proprietary - headings include Google Maps API, in app purchases, Play Games saving/scores...
As someone who's spent just as much time (if not more) developing for embedded Android devices without Google Play Services as developing for "traditional" ones, you're making a meaningless distinction.
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.
> 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.
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.
Swift manages to be technically open-source while not really being true to the idea of open-source. To me, it always seems as if somebody at Apple saw that companies like Microsoft going open source was good publicity and decided that they should do it now too, without really understanding what "open source" means.
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.
At the very least extensions of structural types, which I believe requires also variadic generics. Tuples are completely broken in Swift due to the fact that they're not Equatable - you can compare single tuples, since == is implemented for them, but you can't compare arrays of tuples. This makes some kinds of tests incredibly awkward to write and had lead my team to move away from tuples to nominal types a number of times.
Also, there are some annoying restrictions around existentials, and documentation of Generics and other advanced type machinery could be a lot better in general.
I can't think of a good business reason why they would want to open source SwiftUI. If I want to stay on Windows and develop an app using SwiftUI, why would I bother developing for the Mac?
There's nearly always advantages to being the owner of the complete stack, even if developed in the open and allowing other backends. Making sure that every piece matches your vision without little weird API impedance mismatches for a library being used in many places is a massive win. Nobody expects SwiftUI on Apple to be crippled by a decision, even if it would make SwiftUI on Windows and Linux better.
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.
Giving in the end you are comparing, for me at least Rust is more in the family of languages like C++.
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.
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!
I haven't done Windows development in over 10 years, but I really wasn't expecting to see what appears to be a stripped down implementation of AppKit wrapped around the old Win32 APIs, like it's 1999. (Nor Hungarian Notation).
I thought WPF or WinRT or UWP was supposed to have replaced Win32 by now.
I don't do any desktop development or use Windows much for that matter, but it looks like as of today, there are at least 4 ways [0] to build Windows desktop apps. No wonder the UX feels far less consistent and enjoyable than macOS.
Microsoft wanted to take developers in a direction they didn't want to go. They seemed to have realized their mistake and trying to unify this mess. In the recent past, you wouldn't find WPF and Windows Forms mentioned in the same article as UWP.
Apple had their own problems with this (Carbon vs Cocoa) but that legacy has been shaken off.
That's interesting, did not know about the carbon to cocoa move, couldn't afford anything Apple back then :)
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.
When comparing Carbon and Cocoa, only a fool would choose to write an app in Carbon. But initially there were a few problems:
- 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.
Both iTunes and Finder were at least partly Carbon for a long time. I'm not so sure convincing developers was the reason for that, though. iTunes 1.0 was Mac OS 9 only, and didn't even run on Mac OS X. It was a continuation of SoundJam MP, a third-party Mac app that predated the release of Mac OS X. So, really, iTunes was ported forward to Mac OS X using the same process Apple expected developers of existing Classic Mac apps to use, but that probably wasn't a decision (solely) made for developer relations reasons.
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).
> I'm not so sure convincing developers was the reason for that, though.
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!
For a language compiling to native instructions, there's really only the C(++) API. UWP is barely used in my experience and WPF/Windows Forms are basically exclusive to the dotnet framework.
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.
> 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.
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.
A lot of Windows Forms is non-Win32 controls with custom drawing, by the way. Especially things like menus, toolbars, etc. So a lot of Windows Forms controls are basically as native as WPF controls (just a lot harder to work with imho).
Are you sure? The source is available for both Core and old .NET and to me they all seem to be Win32 controls with some customization... unless I'm missing something. AFAIK WPF uses DirectX for rendering, so it's a bit different (it's more like Flutter... or a game engine).
Okay, perhaps my wording was off. Yes, they're Win32 controls in that sense, but many (most?) of the newer controls are no longer mere wrappers around something that exists in Win32, but rather implement all functionality in managed code, both behavior and drawing.
True and what’s more, Microsoft recently deprecated a load of Wi 32 native controls like Menubar and Toolbar where they now want you to migrate to the managed code / styled MenuStrip and ToolStrip.
> no longer mere wrappers around something that exists in Win32, but rather implement all functionality in managed code, both behavior and drawing
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).
I always heard it was a dumpster fire, but you've upped the ante by calling it a toxic waste site. Nice. I don't think I have heard a more appropriate description.
I really like Swift. Recently I've been using it as my "main" language in developing a macOS user interface for my MSc research project, and it has literally made developing fun!
Great to see it getting more support outside of the Apple domain.
I wrote some swift maybe 4 or 5 years ago when I was doing mobile app stuff and had access to a Mac. I remember finding the language pretty enjoyable, but considered its xplat potential questionable. At the time, I believe it did run on linux and people were touting it as a solid platform for building server side applications. I dont think that was ever realized though.
The docs are very incomplete and common third party dependencies are missing. I know it’s a chicken and egg type situation but vapor is not an appealing option for backend unless you really want/need to use Swift.
I was going use it only if there there was an official Firebase support to do things the way they are done on iOS. What I want is to have a server app that communicates with with Firebase services to do certain tasks.
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.
I find swift to be the most enjoyable and productive language I’ve used so can relate to you there, for me personally vapor seemed a long way off though. Maybe you could try Go? Kotlin is also very nice.
Swift has no concept of fault tolerance. If you by mistake make an illegal array access, multiply two numbers that are too big or overflow your stack (which is limited to ridiculous 512KB on secondary threads), your app crashes and that's that. Apart from a horrible user experience (you don't even get a "nice" customised 500 error page, just a "Gateway timeout" or similar), your app is now offline for everyone.
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.
Community and ecosystem mostly. Maybe it's changed a lot since version 3 but I don't see much uptake. I had enough issues that a rewrite of my API in Typescript was faster than upgrading to 4 when it came out.
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.
I’m betting once async/await lands in Swift it’s usefulness as a server-side language will greatly increase. You can check on GitHub the work on a async/await by people like Doug Gregor has begun. Very exciting.
The docs are incomplete because they just recently released version 4. Version 3's docs are much more fleshed out– v4's will get better now that the changes have actually landed.
This is really cool. I have been watching Swift with interest mainly because it is an answer to the question: How would a bunch of C++ experts (for example Doug Gregor and David Abrahams) design a language if they could do it all over again?
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.
To abuse an old meme: "...yes, but does it run on Linux..."
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.
Swift had Linux support almost right on the beginning. I think that even Apple are supporting this effort.
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.
It has been running on Linux since the first day it was made available as an open source project. It specifically targeted the current and current-1 versions of Ubuntu, but now it also targets Fedora Core and a few other distros contain official packages for it.
Presumably "windows" was a typo, and you meant Linux instead, but to be clear, official support for Swift on native (ie. not WSL) Windows is new in this release, and is largely the work of Saleem Abdulrasool who wrote the linked blog post.
Swift alone would be nice, but implementations of UIKit and/or SwiftUI for Android would be even better. SwiftUI in particular makes a lot of sense as a cross-platform UI framework, since its appearance and behavior adapts to the platform it's running on instead of trying to shoehorn in a single look and feel everywhere.
Flutter doesn't use native controls/frameworks under the hood, so it generally falls into the category of "trying to shoehorn in a single look and feel everywhere".
Not necessarily bad either - some companies may want distinct experience in their app across all platforms l. Any UI is fine as long as it is fast and efficient.
Yes, precisely. It has a "Cupertino" theme that kind of mimics the iOS look and feel, but it misses the mark and will always be behind the curve a least a release or two in matching the OS.
I think Kotlin is ahead enough in this area that it'll win. Plus it's much easier to compile Kotlin to native and use that from Swift than to use native from Java/Kotlin
Yeah it just reached alpha. I’m using Kotlin to power a side project on iOS with a SwiftUI view layer. I’ve yet to actually implement the Android version though.
We’re looking to rewrite a legacy C++ shared component that had become unmaintainable and are considering Kotlin native, mostly because it will be easier to hire for a mobile component written in one of the four primary mobile languages. How is your experience using it on iOS?
Overall really good, I picked it up pre alpha and haven’t needed to change that part of the codebase too much since then so can’t tell you how much has improved, it was stable enough for me even then. It’s extremely flexible and doesn’t require you to buy in completely, I’d recommend trying out a small framework first to see how it could work for your team. It suffers from the various early adopter type issues, not many third party packages etc but the jet brains docs and tutorials are pretty good, compile time also isn’t the fastest yet but they’re working on it. Kotlin’s async model can tale a bit to wrap your head around if you’re new to it too. Interfacing with the host platform is also pretty painless compared to the react native or flutter process.
Readdle apparently built spark (their client mail app) using a single swift core module compiled to all platforms, including android.
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).
Flutter is probably the best candidate. It's a shame Google is giving priority to Flutter for Web instead of desktop though. As discussed previously here on HN, Flutter for Web will always result in bloated web apps as they are reimplementing everything through canvas (eg: text editing, layouts, styling, etc).
Quick note here: we're investing in both pretty heavily. Google has a fair amount of pedigree on the web, so it's highly attractive to us to have web support, but we're paying close attention to the attention that desktop is receiving and are accordingly putting resources on it.
Ehh, kotlin MPP isn't far enough along for me yet. I'm biased against JS-based approaches. Xamarin is the best current option in my (very biased) opinion
EDIT: but kotlin MPP is my long term hope. Once they iron out the kinks (e.g. ios coroutines)
I was skeptical of React native especially having tried it a few years ago, but new versions are incredibly nice.
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.
Yeah my one time getting into react native was not good. Ran into several show stopping bugs with the build tooling basically immediately. Hot reload is absolutely a killer feature though and I wish I could have stuck with it for that alone.
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.
Are you doing the heavy lifting on the native side? I haven't used react native for a while so I don't know the facilities it offers, but my understanding was navigation/animation were not really solved yet. I would also be curious about what devices you are validating the interactions on. Is it a wide range, or mostly newer models?
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.
Ah yea I haven't run into the state restoration thing. Fabric[0] is fairly exciting though, and seems like it will have a sync API.
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.
I was working on a server-side project written in Swift (not my language choice) for 2 years before switching to my current company where I mostly write Kotlin.
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.
It's great to see more languages supported across more operating systems, though outside of iOS app development I am exceedingly dubious of the usefulness of Swift.
so swift is going cross platform, what would be the final size of executable and how much ram would it take to run as compared to electron? Can we say there's a slight possibility that devs would prefer swift over electron for desktop apps?
I'd be surprised if it could. Mainstream support for Windows 7 ended years ago, extended support ended this year. If the Swift community (or more accurately, the one guy in charge of the Windows port) bothers to support executables running on a deprecated version of Windows, that would come as a mighty surprise to me.
Still, you never know, it might manage to do it by fluke!
Not to turn this into a contest but Rust officially supports windows 7. In fact I believe Rust fully supported windows XP too until very recently when they decreased platform support to supported-but-unbuilt-and-untested.
Another benefit of a community-driven language as aposed to a corporate-controlled one.
Or more likely because Rust was developed to support Windows 7 before it was deprecated; Swift never targeted Windows 7. Swift was open sourced in 2015, the year when Windows 7's mainstream support ended; at that time, Swift only targeted Mac OS X and Ubuntu.
Rust began as a project in 2010, Windows 7 was released in 2009.
I think GP's comment is fair. The portability of Rust is of a completely different order of magnitude than Swift. I mean, people have actually gotten it running on Windows 98 SE. And on Windows, Rust has access to a rich winapi surface, nice COM wrappers (including semi-official support through Microsoft's com-rs), a WinRT projection. Not to mention that crates basically just work. Maybe it isn't a first-class supported language for Windows just yet, but it's starting to feel pretty close.
This Rust/WinRT translation is the key for Windows maturity now. C translation is the everywhere basic but Windows support is achieved with eh WinRT translation.
And right now, that is C++, JS, Rust and .NET. Not more not less.
Win7 Extended Security Update (ESU) is active until 2023. Besides, Win7 market share is still almost 1/3 of desktop OS market - most of the devs who target Windows wouldn't want to drop Win7.
I have been using Swift for a month, so I am a beginner. It has some modern features, but it is lacking any real sense of community and feels very incomplete. Its threading and IPC models are clunky and its network code makes XMLHttp
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.
As part of the Swift community (and the Objective-C and Mac/iOS community for years before that), I disagree that there's no community around Swift. I think the problem is that it's still very Apple platforms focused. If you're an iOS developer, you'll find a big community, and one that has been focused on Swift specifically for the past 6 years (to the point that there are complaints about that, e.g. https://twitter.com/phughes/status/1307024158275112965). There are many conferences every year (well, until this year), plenty of people on Twitter, blogs, multiple community Slack teams, etc. Just in my local area (metro area of ~2 million) we have a 750 person strong, very active Slack team for iOS/Mac/Swift development, and two separate monthly in-person meetup groups (again, before COVID).
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.)
It seems that there is some "community" of people not employed by Apple around the development of Swift.
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.
I'm not sure why that has to be the case. For example, C# found a home outside of the Microsoft ecosystem inside of the Unity game SDK. That was a result of the initial grass-roots Mono [1] project. There was the same handwringing when Mono started and as it started to gain traction. Nowadays I think most people consider it to be a viable cross-platform language. I see no reason Swift can't go this way as well.
I'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose.
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'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose.
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.
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?
Sort of. I can't comment on Kotlin, but Swift is a different beast though. Swift's generics are very different from say c#, java or even c++ templates, especially when you mix them with protocol associated types, which are also sort of, but not exactly generics.
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.
I have the impression that « finding cross platform librairies » for every types of I/O is actually a very very painful step, judging by the time it takes to get the swift stdlib work across all platform.
The « low level language » is actually LLVM intermediate language, and LLVM already support building for all the major targets.
> For the ones interested in working on core tooling, there is plenty of work to be done to improve the debugger and to improve the Windows support in the Swift Package Manager. We invite you to check out the Swift Bug Tracker for the current issues and to send patches to the GitHub repositories.
Poor Apple, budget cuts have been hit really hard.
Not really. Google hired LLVM and Swift dude for ML stuff. LLVM and Swift dude decided that although Google already had some LLVM, it still needed more Swift, and for ML specifically. This must have struck probably the majority of people in ML who are not him as slightly bizarre (notable exception: Jeremy Howard). Now he's left. I would be truly amazed if Swift for ML goes anywhere.
It looks more like between 3 and 5 devs, who probably came on at the same time as Lattner. It's roughly the same as the Java interface for TF has, and much smaller than the microcontroller TFLite team.
Nah, just re-asserting how "important" this is to Apple and Google, better let others do the work for free, while aspiring to be future employees, or not.
I think pjmlp is saying that Apple should be the one to improve the debugger and to improve the Windows support in the Swift Package Manager, rather than soliciting contributions.
And yet they didn't solicit anything. Posts on the Swift forums show that Saleem, known as compnerd, took on the task of porting to Windows himself, completely unprovoked — when he began to have something to show, the Swift developer community began to rally around him.
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?
What I was trying to say is why should Apple port Swift to Windows?
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.
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?!