Get the top HN stories in your inbox every day.
jarjoura
zapzupnz
> 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.
DaiPlusPlus
> 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).
pkphilip
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
tasogare
The opening of those libraries are really recent and they were not developed as open source.
jmull
> 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.)
pornel
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.
coldtea
>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.
pjmlp
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.
mpweiher
But SwiftUI required some pretty major language changes, which were thus also done in secret and added to the language as a fait-accompli.
zapzupnz
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.
riquito
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
myko
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.
trevor-e
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.
oscargrouch
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.
1 - https://www.swiftbysundell.com/articles/the-swift-51-feature...
setr
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.
wool_gather
> 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.
Razengan
> Apple behaves as if every user is immediately on the latest version
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?
myko
Irrelevant as Android devs could ship Jetpack Compose pre-alpha months ago to Android users on devices many years old
Dylan16807
Nobody was talking about Android.
And the number of people still on 12 is significant.
skohan
> I'm not entirely sure what the point of this effort is for?!
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.
jarjoura
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.
skohan
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?
undefined
undefined
simonh
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.
saagarjha
SwiftUI is designed such that a port to another platform would not be as awful as a clone of the Mac UI.
raphlinus
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.
coldtea
>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++.
So there's that...
dsabanin
This is a good example of the point for this effort:
jarjoura
Sure, I guess if they feel the open source versions of Swift's standard library are functional enough to release production quality software.
Keep in mind, the UI code will be completely custom for Windows though.
criddell
> 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.
ash_gti
SwiftUI isn't tied to the OS version.
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.
valuearb
Just curious, why can’t SwiftUI apps run on any iOS version prior to 13?
My clients app requires supporting iOS 11, but I’d love to start mixing in sone SwiftUI.
ash_gti
They didn't release the frameworks for those OSs.
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.
rudedogg
I didn’t know about the effort to be able to create GUIs on Windows. It looks like there are basic wrappers for a lot of controls too: https://github.com/compnerd/swift-win32/tree/ed4993f7cbb284a...
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!
geraldcombs
> Slightly OT: I wish people wouldn’t put such large license headers in source code.
There's an ongoing effort to fix this:
https://www.linuxfoundation.org/blog/2018/08/solving-license...
zerr
I hope wxSwift project will be resurrected.
thought_alarm
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.
chin7an
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.
[0] - https://docs.microsoft.com/en-us/windows/apps/desktop/
wvenable
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.
chin7an
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.
jeroenhd
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.
donor20
The push now for UWP is so misguided. I have no clue why they've decided to spend decades making apps jankier and weirder.
jmnicolas
UWP is so last year! We're all about WinUI now! ;)
thought_alarm
I suppose if Swift can only interoperate with C APIs, Win32 would be the only option.
ratww
Well, Swift uses LLVM, so it's possible to link it to C++ code with extern "C" declarations.
tomc1985
I hope WinForms never dies, it is the OG Windows "look" and much less amenable to all the web-app looking BS that permeates desktop apps today
ygra
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).
ratww
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).
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/...
xfer
WinRT/UWP is not a replacement for win32 because it's missing lots of OS apis, it's not just about the UI related apis.
fomine3
True but it's intended. Win32 is too useful so it makes some security problem.
ryanmarsh
Windows dev is a superfund site
dylan604
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.
LegitShady
A delinquent toxic waste site even
oseph
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.
non-entity
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.
mrtksn
Swift on a server is a think: https://vapor.codes
jamil7
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.
RcouF1uZ4gsC
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.
skohan
It's a really nice language. IMO the main limitations currently are:
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
melling
I’ve got a Swift Cookbook on GitHub. Some might find it helpful:
jabofh
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.
jeremymcanally
It already works on Linux (quite well, actually): https://swift.org/download/#releases
oscargrouch
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.
zapzupnz
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.
swebs
Yes, it had official Linux support since 2015.
sjm
There are already multiple Linux toolchains available, Windows is just catching up: https://swift.org/download/
skohan
It has run on windows for years. It's fairly limited in terms of distro support, but this is a stated goal for Swift 6.
armadsen
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.
skohan
Yes I did mean linux, thanks for the correction
Gys
Swift for Android would be a real milestone. There are not so many mainstream cross mobile development platforms.
kitsunesoba
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.
JamesSwift
If thats what you are after then flutter is available today
jmull
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".
Gys
Sorry, yes I meant to include SwiftUI (which I assume is to succeed UIKit).
wasyl
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
jamil7
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.
brantonb
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?
undefined
bsaul
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).
EvilEy3
Kotlin, Flutter, Any JS framework, QT, Xamarin.
pier25
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).
timsneath
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.
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.)
JamesSwift
Xamarin
akmarinov
Kotlin Native React Native
JamesSwift
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)
pjmlp
Xamarin, Qt, Flutter, Webviews
longstation
I hope one day they could bring the same (GUI support) to Linux.
Tainnor
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.
ww520
This is huge. This makes Swift a viable cross platform language, especially for non-gui apps.
baumatron
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.
Get the top HN stories in your inbox every day.
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?!