Earlier quoted context omitted.
Yeah it just reached alpha. I’m using Kotlin to power a side project on iOS with a SwiftUI view layer. I’ve yet to actually implement the Android version though.
We’re looking to rewrite a legacy C++ shared component that had become unmaintainable and are considering Kotlin native, mostly because it will be easier to hire for a mobile component written in one of the four primary mobile languages. How is your experience using it on iOS?
Swift on Windows
161–170 of 209 posts
Re: Swift on Windows
#162Earlier quoted context omitted.
WinForms is just a wrapper around Win32 API - which is closed, and so won't run on other platforms. So in many ways very similar to Apple's position on Swift and SwiftUI
Yes, but even-so it's now far easier to make an alternative WinForms implementation for non-Windows platforms. Mono had their own workable WinForms implementation a while ago (which was a clean-room implementation, IIRC), but now that isn't necessary. WPF, unlike WinForms, is ostensibly fully separate from Win32 and so should be possible to port it to non-Windows platforms.
Re: Swift on Windows
#163Re: Swift on Windows
#164Earlier quoted context omitted.
Sounds a bit like developing in Haxe: https://haxe.org
Haxe seems to have no Swift or Kotlin support :( I'd be curious to know why that is, given that once you have a few languages working, adding more on, intuitively (I have no experience in this) wouldn't be too difficult, given how many features the languages share?
In Elements we spent a lot of time on getting it right, and I think we have most edge cases covered for user code. The way generics are used in the Swift runtime library seems impossible to map perfectly on top of the concept of generics as C# has them though.
Re: Swift on Windows
#165Earlier quoted context omitted.
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.
> After an extensive discussion, we ended up with Electron as the front-end part of future Spark for Windows.
Apparently they use a Swift plugin for Nodejs
Re: Swift on Windows
#166Earlier 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/
For a language compiling to native instructions, there's really only the C(++) API. UWP is barely used in my experience and WPF/Windows Forms are basically exclusive to the dotnet framework. 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 W…
Re: Swift on Windows
#167Earlier quoted context omitted.
Yes, but even-so it's now far easier to make an alternative WinForms implementation for non-Windows platforms. Mono had their own workable WinForms implementation a while ago (which was a clean-room implementation, IIRC), but now that isn't necessary. WPF, unlike WinForms, is ostensibly fully separate from Win32 and so should be possible to port it to non-Windows platforms.
Mono reimplemented WinForms from scratch, and any port of WPF would also have to be a from scratch reimplementation. Same for SwiftUI.
1. WPF is now MIT-licensed.
2. Unlike WinForms, the bulk of WPF is managed-code, not a thin-wrapper over Win32.
Therefore anyone can now port WPF to Linux, macOS, etc - and they only need to port the "PresentationCore" part of WPF (i.e. the native parts that expose Direct3D drawing surfaces to WPF).
Re: Swift on Windows
#168I'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…
For JVM and .NET/CLR based languages this is pretty easy and common.
> just need to write some cross platform libraries that wrap UI, networking, etc for each platform.
Congratulations, you've invented the JVM.
Re: Swift on Windows
#169Swift 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'm not entirely sure what the point of this effort is for?! I'm not quite sure I understand your point. Are you saying Swift has no value outside of SwiftUI? It's a pretty nice general purpose language.
Re: Swift on Windows
#170Earlier 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