Earlier quoted context omitted.
I'm having trouble reading sarcasm. Are you joking? Or is there a complaint in there somewhere?
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.
Swift on Windows
81–90 of 209 posts
Re: Swift on Windows
#82Earlier quoted context omitted.
this is actually a community project, the guy behind all this (Saleem) isnt even at Apple, hes at Google.
Is it just a hobby project, or actually sponsored by Google? They are trying to push Swift for Tensorflow [1], so proper upstream cross-platform capability would probably be important to them. [1] https://www.tensorflow.org/swift
Re: Swift on Windows
#83Earlier quoted context omitted.
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 compi…
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.
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.
Re: Swift on Windows
#84Earlier quoted context omitted.
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).
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/... Toolstr…
Re: Swift on Windows
#85Earlier quoted context omitted.
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/... Toolstr…
Okay, perhaps my wording was off. Yes, they're Win32 controls in that sense, but many (most?) of the newer controls are no longer mere wrappers around something that exists in Win32, but rather implement all functionality in managed code, both behavior and drawing.
Re: Swift on Windows
#86I'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose. For example write code in Swift, compile to X, compile to Kotlin. Voila, I have cross platform code, just need to write some cross platform libraries that wrap UI, networking, etc for…
Re: Swift on Windows
#87Swift for Android would be a real milestone. There are not so many mainstream cross mobile development platforms.
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).
Re: Swift on Windows
#88I 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.
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/
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.
Re: Swift on Windows
#89I'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose. For example write code in Swift, compile to X, compile to Kotlin. Voila, I have cross platform code, just need to write some cross platform libraries that wrap UI, networking, etc for…
The « low level language » is actually LLVM intermediate language, and LLVM already support building for all the major targets.
Re: Swift on Windows
#90I 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.
Windows dev is a superfund site