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

111–120 of 209 posts

Re: Swift on Windows

#111

Post by GeekyBear »

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…

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

Re: Swift on Windows

#112

Post by oscargrouch »

myko wrote: post #106
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…

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.

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

Re: Swift on Windows

#113

Post by anoncareer0212 »

GeekyBear wrote: post #111
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…

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

Re: Swift on Windows

#114

Post by [deleted] »

GeekyBear wrote: post #111
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…

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

[deleted]

Re: Swift on Windows

#115

Post by GeekyBear »

anoncareer0212 wrote: post #113
GeekyBear wrote: post #111

Earlier quoted context omitted.

> 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 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://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...

Re: Swift on Windows

#116

Post by sanxiyn »

valuearb wrote: post #81
pjmlp wrote: post #45

Earlier quoted context omitted.

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.

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.

Re: Swift on Windows

#117

Post by setr »

oscargrouch wrote: post #112
myko wrote: post #106

Earlier quoted context omitted.

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.

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

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.

Re: Swift on Windows

#119

Post by LegitShady »

dylan604 wrote: post #90
ryanmarsh wrote: post #19

Earlier quoted context omitted.

Windows dev is a superfund site

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.

A delinquent toxic waste site even

Re: Swift on Windows

#120

Post by setr »

atarian wrote: post #57
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 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?

It goes backwards too. If I like swift enough even though I'm on windows, I could also trivially include MacOS support (and possibly iOS)
Post reply on HN