8 ms·

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 it

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 itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! Apple being Apple, each revision of SwiftUI is now glued to a singular release of a major revision of the OS. Instead, if Apple decided to built SwiftUI entirely in the open, then the foundational APIs that are closed-source would have to co-exist with the open source versions in order to work. This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries. 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?!

dsabanin 6y ago
This is a good example of the point for this effort: https://sparkmailapp.com/blog/swift-windows https://sparkmailapp.com/blog/swift-windows
- jarjoura 6y ago
  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.
  - criddell 6y ago
    > 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.
    - jmnicolas 6y ago
      Sorry to disappoint but : > 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
skohan 6y ago
> 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.
- deleted 6y ago
  [deleted]
- jarjoura 6y ago
  My point is that Apple's weird choices like SwiftUI being tied to internal versions of the standard libraries creates mixed messaging. It's only general purpose enough that on Mac/iOS you get Apple's version of the standard libraries. On other platforms you use an open source version of the standard libraries as the community sees fit to implement the API. Bugs in Apple's internal variant are tied to OS releases, whereas bugs in the open source variant are tied to someone getting around to fixing it. If Apple went all in on open source like Rust, or all in on proprietary/closed, then it would have more consistent messaging about what the language is for.
  - skohan 6y ago
    In practice I don't think it's that confusing. You have a large standard library which is available everywhere, and then you have a set of proprietary API's which are only available on Apple platforms. Is the situation that different from C# and windows API's?
    - jarjoura 6y ago
      .Net 5 and C# 9.0 are very much 100% open all the way down to the core. https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn (c#) https://github.com/dotnet/winforms https://github.com/dotnet/winforms (UI) https://github.com/dotnet/wpf https://github.com/dotnet/wpf (UI) https://github.com/dotnet/core https://github.com/dotnet/core (Foundation) I don't consider the Win32 API itself part of .NET or C# as they've existed long before either.
atarian 6y ago
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?
- monocasa 6y ago
  There's nearly always advantages to being the owner of the complete stack, even if developed in the open and allowing other backends. Making sure that every piece matches your vision without little weird API impedance mismatches for a library being used in many places is a massive win. Nobody expects SwiftUI on Apple to be crippled by a decision, even if it would make SwiftUI on Windows and Linux better. That's one of the reasons AMD pushed Mantle, then pushed Vulkan and DX12 and dropped Mantle. The shape of the API better fits their model for driver development than OpenGL or DX prior to 11, and they're happy for their competitors to help build an ecosystem that works better on their products than the alternatives at the time. IMO, this is the best model for library/API development if you can pull it off.
- myko 6y ago
  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.
- setr 6y ago
  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)
ash_gti 6y ago
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 compiler changes.
- valuearb 6y ago
  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.
  - ash_gti 6y ago
    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.
    - zapzupnz 6y ago
      And given their swift (pun intended) release schedule and fast user uptake of major releases, this is usually not too much of a hassle.
    - valuearb 6y ago
      Thanks!
simonh 6y ago
Why would Apple want to write a completely new cross platform UI library, cloning the Mac OS desktop UI and give it away, or give away the Mac UI directly? How does that serve their interests? The main purpose seems to be to enable developing back end server code in the same language and using the same service APIs as the client code on mobile and desktop.
- saagarjha 6y ago
  SwiftUI is designed such that a port to another platform would not be as awful as a clone of the Mac UI.
  - raphlinus 6y ago
    I speculated when it first came out that internally they have a port for either Windows or Android or both, if for no other reason than to discover any architectural limitations that would preclude such a thing. But I also think it's very unlikely that SwiftUI will ever be released for any non-Apple platforms.
    - simonh 6y ago
      They already have a port of some of the core platform GUI elements to windows. It's used in the Windows version of iTunes. It's probably quite minimal though.
jmull 6y ago
> 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.)
- mpweiher 6y ago
  But SwiftUI required some pretty major language changes, which were thus also done in secret and added to the language as a fait-accompli.
  - zapzupnz 6y ago
    And then later modified by complaints and feedback by the community. SwiftUI is still in its early stages but its earliest releases changed quite a bit. Some of the documentation still hasn't been updated to reflect those changes.
- riquito 6y ago
  It looks similar to what happened with dot.net / mono, where Microsoft kept pushing tools and UI libraries for Windows and the ecosystem outside Windows stagnated or played an impossible catch up
- pornel 6y ago
  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.
  - coldtea 6y ago
    >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.
oscargrouch 6y ago
Giving in the end you are comparing, for me at least Rust is more in the family of languages like C++. Very powerful, fast and close to the metal, but with uglier* syntax and not as productive as the next family of languages. Which are: Java, C# and Swift (unlike C++ and Rust) for me are pointing into solving a very hot spot of programming, with the balance of power, being more pleasant to program in and feeling more productive. Your code will be almost as fast as a C++ program, but you dont need to feel (that much) miserable writing stuff into it. (And i say this as someone that likes C++, but knows its not the most productive and pleasant experience) It remedy some pain points of programming, that in my point of view at least, Rust didnt addressed the same sweet spot as Swift does. Theres also some good things about Swift right in the corner, that is support to C++ bindings and a more fine-grained control of memory. Once the memory ownership changes, than we will also be able to consider Swift for the same things as C, C++, Rust and Zig can right now. Also i would say that dinamic calls while embedding script languages and function builders are very strong points that the language is becoming more powerful with each release. Also some things like binary stability that Swift have that Rust doesnt are thing to take into account for, giving there are a lot of cases were shipping just the binaries and know they will still work is something very important for projects that cant afford to be open source. I would consider to use Rust whenever C++ would also fit, but if i can use Swift i would not consider using Rust, because at least for me is a much better language to code. I think people from the Rust community dont need to fear, because Rust have a strong community right now, and in that particular topic, is Swift that need to catch up and shake up this feeling of being a "apple owned language". So i dont think they are aiming for the same thing, and therefore they dont need to be compared in a us vs. them basis, giving you can code on both, and i think it could be great if you do it. Theres a false adage that you need to pick just one language, and having used a lot of languages and platforms over the years, im pretty happy now that i know that such thing doesnt exist. You are better picking from 2 to 3 languages and use them according the goals of what you are building. For me, my three languages are: C++, Swift and Python. C++ for hardcore stuff, Swift for everything that a language like Java or C# could be considered and Python for the more relaxed (and now also expert) stuff. You can replace Python with Ruby, Lua, etc.. replace Swift with C#, Kotlin, Java, Go, Scala, etc.. and replace C++ with Rust, Zig or C. But if you mix the families, i say you will have a hard time using Python or C++ in the wrong places. And this rule is also valid for Rust unfortunately. * Note: i know this is subjective and a lot of people would find it more beautiful than Swift instead. Its ok and even good that we dont all have the same tastes.
myko 6y ago
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.
- oscargrouch 6y ago
  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-features-that-power-swiftuis-api/ https://www.swiftbysundell.com/articles/the-swift-51-feature...
  - setr 6y ago
    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.
  - wool_gather 6y ago
    > function builders [are] 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. Function builders are still not a public feature, and therefore subject to breaking revisions without warning.
deleted 6y ago
[deleted]
GeekyBear 6y ago
> 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 ?
- anoncareer0212 6y ago
  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)
  - GeekyBear 6y ago
    >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-android-controlling-open-source-by-any-means-necessary/4/ https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
    - anoncareer0212 6y ago
      Yeah, the language you quoted is histrionical and responsible for innumerable mistaken impressions, including me, until last year. If you skim the headings you'll see it's things that'd more or less be 'obviously' proprietary - headings include Google Maps API, in app purchases, Play Games saving/scores...
zapzupnz 6y ago
> I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why SwiftUI itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! SwiftUI is just a closed source framework. What's so confusing here? We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would we of Apple? > On the other, I'm not entirely sure what the point of this effort is for?! To develop using Swift on Windows. It's not terribly difficult to imagine that people might enjoy using their preferred language on other platforms — you mentioned Rust, after all, and that's on practically everything. I think the confusion you have is not understanding the boundaries between Swift (the open language) and SwiftUI (the closed framework) — which, honestly, given the names, I can completely understand.
- DaiPlusPlus 6y ago
  > We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would we of Apple? .NET is fully open-source now and it is developed in the open. And not just the BCL, but also platform UI/UX libraries like [WinForms](https://github.com/dotnet/winforms https://github.com/dotnet/winforms) and WPF. (Yeah I was taken aback too: if you told myself from 10-15 years ago that WinForms would be open-sourced under the MIT license I'd think you were mad - or that Microsoft went out of business after the Year of the Linux Desktop really happened and open-sourcing everything was their swansong).
  - pkphilip 6y ago
    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
    - DaiPlusPlus 6y ago
      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.
coldtea 6y ago
>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...
Razengan 6y ago
> This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries. And how easy/worthwhile is it to use Rust for building GUI applications or games on Windows? DirectX is closed source too, and I don’t even know what UI framework Microsoft is currently championing.
Tainnor 6y ago
Swift manages to be technically open-source while not really being true to the idea of open-source. To me, it always seems as if somebody at Apple saw that companies like Microsoft going open source was good publicity and decided that they should do it now too, without really understanding what "open source" means. Some examples of this IMHO include: - While Swift itself is open-source, "Foundation" (which is something of a stdlib of Swift and provides many key pieces of functionality) is not open source - at least on macOS. There is a reimplementation of Foundation for Linux which is open source but, surprise, surprise, the two sometimes have different behaviour... - Swift releases are weirdly coupled to XCode releases, a closed-source IDE. Moreover, while technically possible, most people on macOS don't install Swift on its own, but always through XCode, and the two are quite tightly coupled (you can technically change the toolchain, but it's quite an opaque setting IMHO). This leads to a lot of "I updated XCode and now the code is not working anymore" issues, especially with more junior developers. - Tooling outside of XCode (itself not the greatest of IDE of all times...) is extremely ... limited. For example, XCTest's (the test framework's) console output is almost unreadable and there are actually (half-abandoned) third-party tools that try to parse it and format it nicely (while introducing tons of weird bugs), something that test frameworks for other languages can just do for free. The package manager has, I think, one maintainer, and is so underpowered that most iOS developers don't really use it yet (despite it now being a couple of years old). And in terms of editor/IDE support there is now technically a LSP implementation, but last I tried, I couldn't even manage to set it up properly. - There is no clear roadmap or even mission statement for Swift. Many other languages try to be clear about where they're headed and also what kinds of things they don't want to support, but Swift development is this weird mixture between a) a "community process" that often just leads to very different parties bringing their own very special concepts, syntax sugar, etc. into the language development without there seeming to be any overarching idea of where this all is headed, and b) some things just seemingly being implemented because it's useful for some shiny Apple feature ("function builders" which is mainly meant to support SwiftUI and which many people have been very skeptical about). Meanwhile long-standing proposals like properly fixing generics ("Generics Manifesto") are being pushed back indefinitely. It seems to me sometimes that Swift developers are willing to let the community bikeshed on trivial matters (e.g. syntax sugar), but when it comes to more important, long-term concerns (should we implement function builders or rather invest in some more generally reusable macro-like / code generation feature), are being unilaterally decided without really consulting the community.

dsabanin 6y ago

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

jarjoura 6y ago
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.
- criddell 6y ago
  > 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.
  - jmnicolas 6y ago
    Sorry to disappoint but : > 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

skohan 6y ago

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

deleted 6y ago
[deleted]
jarjoura 6y ago
My point is that Apple's weird choices like SwiftUI being tied to internal versions of the standard libraries creates mixed messaging. It's only general purpose enough that on Mac/iOS you get Apple's version of the standard libraries. On other platforms you use an open source version of the standard libraries as the community sees fit to implement the API. Bugs in Apple's internal variant are tied to OS releases, whereas bugs in the open source variant are tied to someone getting around to fixing it. If Apple went all in on open source like Rust, or all in on proprietary/closed, then it would have more consistent messaging about what the language is for.
- skohan 6y ago
  In practice I don't think it's that confusing. You have a large standard library which is available everywhere, and then you have a set of proprietary API's which are only available on Apple platforms. Is the situation that different from C# and windows API's?
  - jarjoura 6y ago
    .Net 5 and C# 9.0 are very much 100% open all the way down to the core. https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn (c#) https://github.com/dotnet/winforms https://github.com/dotnet/winforms (UI) https://github.com/dotnet/wpf https://github.com/dotnet/wpf (UI) https://github.com/dotnet/core https://github.com/dotnet/core (Foundation) I don't consider the Win32 API itself part of .NET or C# as they've existed long before either.

atarian 6y ago

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?

monocasa 6y ago
There's nearly always advantages to being the owner of the complete stack, even if developed in the open and allowing other backends. Making sure that every piece matches your vision without little weird API impedance mismatches for a library being used in many places is a massive win. Nobody expects SwiftUI on Apple to be crippled by a decision, even if it would make SwiftUI on Windows and Linux better. That's one of the reasons AMD pushed Mantle, then pushed Vulkan and DX12 and dropped Mantle. The shape of the API better fits their model for driver development than OpenGL or DX prior to 11, and they're happy for their competitors to help build an ecosystem that works better on their products than the alternatives at the time. IMO, this is the best model for library/API development if you can pull it off.
myko 6y ago
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.
setr 6y ago
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)

ash_gti 6y ago

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

valuearb 6y ago
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.
- ash_gti 6y ago
  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.
  - zapzupnz 6y ago
    And given their swift (pun intended) release schedule and fast user uptake of major releases, this is usually not too much of a hassle.
  - valuearb 6y ago
    Thanks!

simonh 6y ago

Why would Apple want to write a completely new cross platform UI library, cloning the Mac OS desktop UI and give it away, or give away the Mac UI directly? How does that serve their interests? The main purpose seems to be to enable developing back end server code in the same language and using the same service APIs as the client code on mobile and desktop.

saagarjha 6y ago
SwiftUI is designed such that a port to another platform would not be as awful as a clone of the Mac UI.
- raphlinus 6y ago
  I speculated when it first came out that internally they have a port for either Windows or Android or both, if for no other reason than to discover any architectural limitations that would preclude such a thing. But I also think it's very unlikely that SwiftUI will ever be released for any non-Apple platforms.
  - simonh 6y ago
    They already have a port of some of the core platform GUI elements to windows. It's used in the Windows version of iTunes. It's probably quite minimal though.

jmull 6y ago

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

mpweiher 6y ago
But SwiftUI required some pretty major language changes, which were thus also done in secret and added to the language as a fait-accompli.
- zapzupnz 6y ago
  And then later modified by complaints and feedback by the community. SwiftUI is still in its early stages but its earliest releases changed quite a bit. Some of the documentation still hasn't been updated to reflect those changes.
riquito 6y ago
It looks similar to what happened with dot.net / mono, where Microsoft kept pushing tools and UI libraries for Windows and the ecosystem outside Windows stagnated or played an impossible catch up
pornel 6y ago
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.
- coldtea 6y ago
  >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.

oscargrouch 6y ago

Giving in the end you are comparing, for me at least Rust is more in the family of languages like C++. Very powerful, fast and close to the metal, but with uglier* syntax and not as productive as the next family of languages. Which are: Java, C# and Swift (unlike C++ and Rust) for me are pointing into solving a very hot spot of programming, with the balance of power, being more pleasant to program in and feeling more productive. Your code will be almost as fast as a C++ program, but you dont need to feel (that much) miserable writing stuff into it. (And i say this as someone that likes C++, but knows its not the most productive and pleasant experience) It remedy some pain points of programming, that in my point of view at least, Rust didnt addressed the same sweet spot as Swift does. Theres also some good things about Swift right in the corner, that is support to C++ bindings and a more fine-grained control of memory. Once the memory ownership changes, than we will also be able to consider Swift for the same things as C, C++, Rust and Zig can right now. Also i would say that dinamic calls while embedding script languages and function builders are very strong points that the language is becoming more powerful with each release. Also some things like binary stability that Swift have that Rust doesnt are thing to take into account for, giving there are a lot of cases were shipping just the binaries and know they will still work is something very important for projects that cant afford to be open source. I would consider to use Rust whenever C++ would also fit, but if i can use Swift i would not consider using Rust, because at least for me is a much better language to code. I think people from the Rust community dont need to fear, because Rust have a strong community right now, and in that particular topic, is Swift that need to catch up and shake up this feeling of being a "apple owned language". So i dont think they are aiming for the same thing, and therefore they dont need to be compared in a us vs. them basis, giving you can code on both, and i think it could be great if you do it. Theres a false adage that you need to pick just one language, and having used a lot of languages and platforms over the years, im pretty happy now that i know that such thing doesnt exist. You are better picking from 2 to 3 languages and use them according the goals of what you are building. For me, my three languages are: C++, Swift and Python. C++ for hardcore stuff, Swift for everything that a language like Java or C# could be considered and Python for the more relaxed (and now also expert) stuff. You can replace Python with Ruby, Lua, etc.. replace Swift with C#, Kotlin, Java, Go, Scala, etc.. and replace C++ with Rust, Zig or C. But if you mix the families, i say you will have a hard time using Python or C++ in the wrong places. And this rule is also valid for Rust unfortunately. * Note: i know this is subjective and a lot of people would find it more beautiful than Swift instead. Its ok and even good that we dont all have the same tastes.

myko 6y ago

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.

oscargrouch 6y ago
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-features-that-power-swiftuis-api/ https://www.swiftbysundell.com/articles/the-swift-51-feature...
- setr 6y ago
  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.
- wool_gather 6y ago
  > function builders [are] 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. Function builders are still not a public feature, and therefore subject to breaking revisions without warning.

deleted 6y ago

[deleted]

GeekyBear 6y ago

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

anoncareer0212 6y ago
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)
- GeekyBear 6y ago
  >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-android-controlling-open-source-by-any-means-necessary/4/ https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
  - anoncareer0212 6y ago
    Yeah, the language you quoted is histrionical and responsible for innumerable mistaken impressions, including me, until last year. If you skim the headings you'll see it's things that'd more or less be 'obviously' proprietary - headings include Google Maps API, in app purchases, Play Games saving/scores...

zapzupnz 6y ago

> I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why SwiftUI itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! SwiftUI is just a closed source framework. What's so confusing here? We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would we of Apple? > On the other, I'm not entirely sure what the point of this effort is for?! To develop using Swift on Windows. It's not terribly difficult to imagine that people might enjoy using their preferred language on other platforms — you mentioned Rust, after all, and that's on practically everything. I think the confusion you have is not understanding the boundaries between Swift (the open language) and SwiftUI (the closed framework) — which, honestly, given the names, I can completely understand.

DaiPlusPlus 6y ago
> We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would we of Apple? .NET is fully open-source now and it is developed in the open. And not just the BCL, but also platform UI/UX libraries like [WinForms](https://github.com/dotnet/winforms https://github.com/dotnet/winforms) and WPF. (Yeah I was taken aback too: if you told myself from 10-15 years ago that WinForms would be open-sourced under the MIT license I'd think you were mad - or that Microsoft went out of business after the Year of the Linux Desktop really happened and open-sourcing everything was their swansong).
- pkphilip 6y ago
  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
  - DaiPlusPlus 6y ago
    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.

coldtea 6y ago

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

Razengan 6y ago

> This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries. And how easy/worthwhile is it to use Rust for building GUI applications or games on Windows? DirectX is closed source too, and I don’t even know what UI framework Microsoft is currently championing.

Tainnor 6y ago

Swift manages to be technically open-source while not really being true to the idea of open-source. To me, it always seems as if somebody at Apple saw that companies like Microsoft going open source was good publicity and decided that they should do it now too, without really understanding what "open source" means. Some examples of this IMHO include: - While Swift itself is open-source, "Foundation" (which is something of a stdlib of Swift and provides many key pieces of functionality) is not open source - at least on macOS. There is a reimplementation of Foundation for Linux which is open source but, surprise, surprise, the two sometimes have different behaviour... - Swift releases are weirdly coupled to XCode releases, a closed-source IDE. Moreover, while technically possible, most people on macOS don't install Swift on its own, but always through XCode, and the two are quite tightly coupled (you can technically change the toolchain, but it's quite an opaque setting IMHO). This leads to a lot of "I updated XCode and now the code is not working anymore" issues, especially with more junior developers. - Tooling outside of XCode (itself not the greatest of IDE of all times...) is extremely ... limited. For example, XCTest's (the test framework's) console output is almost unreadable and there are actually (half-abandoned) third-party tools that try to parse it and format it nicely (while introducing tons of weird bugs), something that test frameworks for other languages can just do for free. The package manager has, I think, one maintainer, and is so underpowered that most iOS developers don't really use it yet (despite it now being a couple of years old). And in terms of editor/IDE support there is now technically a LSP implementation, but last I tried, I couldn't even manage to set it up properly. - There is no clear roadmap or even mission statement for Swift. Many other languages try to be clear about where they're headed and also what kinds of things they don't want to support, but Swift development is this weird mixture between a) a "community process" that often just leads to very different parties bringing their own very special concepts, syntax sugar, etc. into the language development without there seeming to be any overarching idea of where this all is headed, and b) some things just seemingly being implemented because it's useful for some shiny Apple feature ("function builders" which is mainly meant to support SwiftUI and which many people have been very skeptical about). Meanwhile long-standing proposals like properly fixing generics ("Generics Manifesto") are being pushed back indefinitely. It seems to me sometimes that Swift developers are willing to let the community bikeshed on trivial matters (e.g. syntax sugar), but when it comes to more important, long-term concerns (should we implement function builders or rather invest in some more generally reusable macro-like / code generation feature), are being unilaterally decided without really consulting the community.