Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift on Windows

swift.org

Post reply on HN
Print view View original

121–130 of 209 posts

Re: Swift on Windows

#121

Post by zapzupnz »

jarjoura wrote: post #37

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…

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

Re: Swift on Windows

#122

Post by zapzupnz »

mpweiher wrote: post #96
jmull wrote: post #67

Earlier quoted context omitted.

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

But SwiftUI required some pretty major language changes, which were thus also done in secret and added to the language as a fait-accompli.

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.

Re: Swift on Windows

#123

Post by anoncareer0212 »

GeekyBear wrote: post #115
anoncareer0212 wrote: post #113

Earlier quoted context omitted.

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 sour…

>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. https://arstechni…

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

Re: Swift on Windows

#124

Post by zapzupnz »

ash_gti wrote: post #83
valuearb wrote: post #79

Earlier quoted context omitted.

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.

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.

And given their swift (pun intended) release schedule and fast user uptake of major releases, this is usually not too much of a hassle.

Re: Swift on Windows

#125

Post by zapzupnz »

jabofh wrote: post #26

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.

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.

Re: Swift on Windows

#126

Post by zapzupnz »

zerr wrote: post #74

The toolchain requires Win10 - but can a resulting executable be deployed on Win7?

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!

Re: Swift on Windows

#128

Post by zapzupnz »

sanxiyn wrote: post #116
valuearb wrote: post #81

Earlier quoted context omitted.

Are you saying Apple should ban open source projects based on the Swift code base?

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?

Re: Swift on Windows

#129

Post by zapzupnz »

armadsen wrote: post #93
ratww wrote: post #60

Earlier quoted context omitted.

Carbon/Cocoa wasn't really a "transition" per se. 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 remembe…

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…

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

Re: Swift on Windows

#130

Post by cercatrova »

jmull wrote: post #72
JamesSwift wrote: post #21

Earlier quoted context omitted.

If thats what you are after then flutter is available today

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

It enables a lot more customization and complex effects precisely because it draws every pixel itself.
Post reply on HN