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

101–110 of 209 posts

Re: Swift on Windows

#101

Post by criddell »

jarjoura wrote: post #40
dsabanin wrote: post #39

Earlier quoted context omitted.

This is a good example of the point for this effort: https://sparkmailapp.com/blog/swift-windows

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.

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

Re: Swift on Windows

#102

Post by pornel »

jmull wrote: post #67
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 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.

Re: Swift on Windows

#103

Post by favorited »

jamil7 wrote: post #51
mrtksn wrote: post #43

Earlier quoted context omitted.

Swift on a server is a think: https://vapor.codes

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.

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.

Re: Swift on Windows

#104

Post by nwienert »

JamesSwift wrote: post #34
nwienert wrote: post #27

Earlier quoted context omitted.

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…

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

Actually curious how it’s limiting being async? I’m doing some intense animations and interaction so far with no trouble.

Re: Swift on Windows

#105

Post by xfer »

thought_alarm wrote: post #17

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.

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.

Re: Swift on Windows

#106

Post by myko »

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.

Re: Swift on Windows

#107

Post by fomine3 »

xfer wrote: post #105
thought_alarm wrote: post #17

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.

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.

True but it's intended. Win32 is too useful so it makes some security problem.

Re: Swift on Windows

#108

Post by myko »

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?

For folks developing for Apple platforms an open source SwiftUI would mean we could ship bug fixes to users who have not updated their OS.

Re: Swift on Windows

#109

Post by JamesSwift »

nwienert wrote: post #104
JamesSwift wrote: post #34

Earlier quoted context omitted.

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

Actually curious how it’s limiting being async? I’m doing some intense animations and interaction so far with no trouble.

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.

Re: Swift on Windows

#110

Post by [deleted] »

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…

[deleted]
Post reply on HN