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

141–150 of 209 posts

Re: Swift on Windows

#141

Post by coldtea »

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…

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

Re: Swift on Windows

#142

Post by coldtea »

pornel wrote: post #102
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.)

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…

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

Re: Swift on Windows

#143

Post by coldtea »

saagarjha wrote: post #139
chin7an wrote: post #20

Earlier quoted context omitted.

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/

On macOS there’s three: Cocoa, Catalyst and SwiftUI.

All map to more or less the same underlying libs and widgets, so there's no real difference...

In Windows there are totally different widget look and feels supported...

Re: Swift on Windows

#144

Post by valuearb »

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.

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.

Re: Swift on Windows

#145

Post by valuearb »

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.

Thanks!

Re: Swift on Windows

#146

Post by trevor-e »

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.

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.

Re: Swift on Windows

#147

Post by timsneath »

pier25 wrote: post #38
EvilEy3 wrote: post #9

Earlier quoted context omitted.

Kotlin, Flutter, Any JS framework, QT, Xamarin.

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.

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

Re: Swift on Windows

#148

Post by nwienert »

JamesSwift wrote: post #109
nwienert wrote: post #104

Earlier quoted context omitted.

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…

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.

[0] https://github.com/react-native-community/discussions-and-pr...

Re: Swift on Windows

#150

Post by AlphaSite »

cercatrova wrote: post #130
jmull wrote: post #72

Earlier quoted context omitted.

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.

Thats not necessarily to its benefit.
Post reply on HN