OpenSwiftUI – An Open Source Re-Implementation of SwiftUI(github.com)
github.com
OpenSwiftUI – An Open Source Re-Implementation of SwiftUI
https://github.com/Cosmo/OpenSwiftUI
13 comments
Hm so those registers which you give your credit cards haven't had security fixes for 4 years and can probably be trivially taken over with wireless zero click attacks. :/
The opaque return types are, however, only available in Swift 5.1 and later, which means that the API will have to be different and not directly compatible with the Swift UI.
Not just Swift 5.1, but they also require iOS 13 because there's a rather unfortunate stdlib dependency. Technically they only need the dependency when crossing module boundaries, but they're restricting the feature completely anyway, I guess because they don't want to bother explaining "you can use 'some' on internal APIs but you can't use it on a public API without iOS 13+".
As long as Swift supports #ifdefs, I'm sure with some minor coding conventions, they could make it work.
bundling hardware like that is not uncommon. i’ve worked with three orgs that did this to one degree or another...and it was always a pain in the ass, in my experience.
Yeah it was an interesting constraint that I hadn't considered before but it makes a lot of sense.
Is it Blueprint[0] you're talking about? It doesn't seem to be a reimplementation.
[0] https://github.com/square/Blueprint
[0] https://github.com/square/Blueprint
To my understanding, no. I was referencing tweets from one of their iOS engineering leads during and after the SwiftUI announcement. He was specifically talking about doing an API compatible re-implementation for older iOS versions.
Benedikt Terhechte (from XING and the Contravariance podcast) has a similar project called AwfulUI[1] to bring some SwiftUI goodness on previous iOS releases. I don't think it's open source at the moment though.
[1]: http://contravariance.rocks/episodes/210_show_notes.html
[1]: http://contravariance.rocks/episodes/210_show_notes.html
Thanks for mentioning it! There's a plan of open sourcing it. It has different aims than OpenSwiftUI. It is just a back port so that SwiftUI-Like code can be used with iOS < 13. I hope to open source it very soon.
So many questions OP. I dove into the source and couldn't answer...
1. Does this use native rendering of the local OS? I.e. On Linux it uses GTK or QT?
2. Is this meant to be entirely OS Agnostic? Are you going to support Linux, Windows, Kitchen Sink, Etc?
3. Are you planning on seeing this through to the end and completing the library 100% or is this a proof on concept?
1. Does this use native rendering of the local OS? I.e. On Linux it uses GTK or QT?
2. Is this meant to be entirely OS Agnostic? Are you going to support Linux, Windows, Kitchen Sink, Etc?
3. Are you planning on seeing this through to the end and completing the library 100% or is this a proof on concept?
In the current state it draws into a pixel buffer array which you can then display on for example an epaper display connected to a Raspi or other embedded device.
1. No. Neither. It does all the drawing on its own. Right now even fonts.
2. I think he would like to make it platform agnostic that way (i.e. provide reusable parts), but no, not right now.
3. His primary goal is/was driving UIs on embedded devices and AFAIK wants to complete it at least for this task.
Disclaimer: In contact with @cosmo in some Slack, due to my SwiftWebUI project (which offloads a load of things to the browser, so his stuff is quite different / more complex in many ways).
1. No. Neither. It does all the drawing on its own. Right now even fonts.
2. I think he would like to make it platform agnostic that way (i.e. provide reusable parts), but no, not right now.
3. His primary goal is/was driving UIs on embedded devices and AFAIK wants to complete it at least for this task.
Disclaimer: In contact with @cosmo in some Slack, due to my SwiftWebUI project (which offloads a load of things to the browser, so his stuff is quite different / more complex in many ways).
I will be watching this. We can always use more better tools for making GUI on embedded. Especially ones that do their own rendering.
One of my plans is to play around with using and/or creating a custom flutter engine embedder like flutter-pi.
One of my plans is to play around with using and/or creating a custom flutter engine embedder like flutter-pi.
Interesting! I'm curious about this because I didn't see anything rendering to the pixel buffer array. Do you know where that code is? I tried looking for it.
I think this is just an API that must be connected to a graphical backend for each platform.
> The project's goal is to provide a platform-agnostic interface — without the generation of the graphical user interface.
> The rendering of graphical user interfaces can be implemented in platform specific (Linux, Windows, Embedded, …) projects.
> The project's goal is to provide a platform-agnostic interface — without the generation of the graphical user interface.
> The rendering of graphical user interfaces can be implemented in platform specific (Linux, Windows, Embedded, …) projects.
I sincerely wish this kind of project goes far. At best we'll finally escape apple's grip on UI and swift and their awful documentation and no OS support beyond apple, at worst it'll put some pressure for apple to open source the tech and have the community port it to android.
What do you mean by Apple's grip on Swift?
Apple has de-facto control of where the language is heading.
look at the discussion on swift forum when SwiftUI was announced. They added a huge batch of new features to the language with a huge proposal that got released with xcode eventhough it has never been discussed beforehand publicly (for obvious reasons).
Apple is clearly the main force behind Swift at the moment, which has some good sides (at least the language is evolving), but is pushing the tech toward a certain direction at the detriment of others (IMHO). Apple is mostly building frontend tech, and swift initial goal was to also be a great force for server-side tech (which means great cross-platform experience).
As an example, i don't think apple is ever going to release a server side framework, or a cross-platform GUI framework able to create android app. The only swift/android project i know on github (https://github.com/readdle/swift-android-toolchain) is using a swift fork to disable objective-c features that don't work well on other platform. That's telling.
Apple is clearly the main force behind Swift at the moment, which has some good sides (at least the language is evolving), but is pushing the tech toward a certain direction at the detriment of others (IMHO). Apple is mostly building frontend tech, and swift initial goal was to also be a great force for server-side tech (which means great cross-platform experience).
As an example, i don't think apple is ever going to release a server side framework, or a cross-platform GUI framework able to create android app. The only swift/android project i know on github (https://github.com/readdle/swift-android-toolchain) is using a swift fork to disable objective-c features that don't work well on other platform. That's telling.
”I don't think apple is ever going to release a server side framework”
I don’t think Apple releasing a server-side framework would help, as nobody would be using it.
Also, there is the Swift Server Work Group (https://swift.org/server/), where two out of six members have an Apple email address. They recently wrote a kind of “state of the union” that, in my view, shows progress is made towards using Swift on servers (https://swift.org/blog/sswg-update/)
As to a cross-platform GUI framework: I don’t see them doing that, just as I don’t see Microsoft or google doing that.
I don’t think Apple releasing a server-side framework would help, as nobody would be using it.
Also, there is the Swift Server Work Group (https://swift.org/server/), where two out of six members have an Apple email address. They recently wrote a kind of “state of the union” that, in my view, shows progress is made towards using Swift on servers (https://swift.org/blog/sswg-update/)
As to a cross-platform GUI framework: I don’t see them doing that, just as I don’t see Microsoft or google doing that.
As to a cross-platform GUI framework: I don’t see them doing that, just as I don’t see Microsoft or google doing that.
? Flutter and Xamarin already exist.
? Flutter and Xamarin already exist.
> I don’t think Apple releasing a server-side framework would help, as nobody would be using it.
Yeah.
I think something useful has a much better chance of coming out of the community than Apple. Let Apple focus on what they're good at and leave the server-side stuff to the people who breathe it every day.
Yeah.
I think something useful has a much better chance of coming out of the community than Apple. Let Apple focus on what they're good at and leave the server-side stuff to the people who breathe it every day.
> i don't think apple is ever going to release a server side framework
Maybe not, but there is this: https://github.com/apple/swift-nio
Maybe not, but there is this: https://github.com/apple/swift-nio
Yes, and then there's kitura and vapor which are trying to make it happen.
But look at what Lattner's concurrent manifesto aimed at two years ago : https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...
We still don't have async / await, and that was just step 1.
But look at what Lattner's concurrent manifesto aimed at two years ago : https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...
We still don't have async / await, and that was just step 1.
Well if you look at the "cross-platform" support compared to the other languages such as Go and Rust, Swift is quite poor at this: Apart from Linux, platforms such as Windows, FreeBSD, WASM, Haiku, etc are all unofficial ports which community members have to maintain but it is getting there, slowly.
In terms of the prospect of a cross-platform GUI, SwiftUI is taking a similar direction to Flutter and React Native. I see no other serious alternatives from the likes of Go or Rust at the moment. As far as Apple is concerned, they have total control of the direction of the language and they pick and choose which components to open-source.
In terms of the prospect of a cross-platform GUI, SwiftUI is taking a similar direction to Flutter and React Native. I see no other serious alternatives from the likes of Go or Rust at the moment. As far as Apple is concerned, they have total control of the direction of the language and they pick and choose which components to open-source.
My biggest concern about building a huge UI in Swift is that I can't take it anywhere off Apple's platforms. I'm not a fan of platform-specific languages or development paradigms, yet the portable options give up a lot in convenience. It would be great to have a best of both worlds scenario.
> The project's goal is to provide a platform-agnostic interface — without the generation of the graphical user interface.
As someone who is relatively ignorant about this kind of thing...what does that above quote ^ mean?
As someone who is relatively ignorant about this kind of thing...what does that above quote ^ mean?
It means that it implements the logic to determine what needs to be updated from one UI state to another UI state but it leaves the concrete implementation on how to create, delete, move, insert, and update UI interface elements to the users.
If I'm not mistaken I think the idea is something like React, provide an API to describe interfaces that can have different platform specific bindings written for them.
My fear is that when this is production ready already >80% of all iOS users will be on iOS 13
Which is a good thing! (author of this project here)
OpenSwiftUI is not meant to run on Apple devices. Quite the opposite :) The project is quite in the early stages but at some point, it should be possible to create graphical interfaces with GTK, Win32 Forms or even ASCII, but written in Swift.
"Learn once, apply anywhere."
Half the value of SwiftUI comes from Xcode's GUI builder. Does this plan to support that?
Well -- not exactly how someone would imagine. You can build your GUI in any iOS, macOS, etc application within Xcode and add your view as a target of another platform. It's maybe not the best solution, but one that works :)
Would be wonderful if you can document it in the README, I think a lot of people would love to be able to use the full power of Xcode.
I've found that SwiftUI is reasonably viable to use even without the GUI builder. I find myself hiding it most of the time, since the code usually tells me what I need.
So it is like flutter but in swift?
The author is in this thread but his/her account is dead.
https://news.ycombinator.com/user?id=maccosmo
https://news.ycombinator.com/user?id=maccosmo
What kind of weird coding style is this?
public let _content: ContentHey @DagAgren, author auf OpenSwiftUI:
Yeah, it's weird.
My plan is to stay as close to the SwiftUI API as possible.
However, I had to expose some private properties for the platform specific implementation like SwiftUIEmbedded and left the underscore to indicate that this property is not meant to be used by an application developer.
I don't like it either -- but that was the best I could come up with :)
I don't like it either -- but that was the best I could come up with :)
By looking at the source code i'm pretty sure it ended up on HN front page purely by accident. The author clearly is just working on some proof of concept and hacking stuff together.
(i do agree _ and public together don't make any kind of sense though)
(i do agree _ and public together don't make any kind of sense though)
It’d guess it’s an implementation detail that’s been marked as public for ease of use during development.
I applaud this effort. I really think the UI team that built SwiftUI at Apple really screwed up by
1. Making it tied to the OS. 2. Not building it in a way that its Open Source.
Yes I've read comments from Apple engineers that proclaim it relies on new features of UIKit/AppKit. Then, why not open source those UIKit/AppKit changes? Or, don't build the framework in such a tight-coupled way.
v1 should be about getting early adopters by allowing maximum platform reach and incrementally filling in the gaps.
So I'm hopeful this effort or any similar effort becomes the way forward for a lot of projects.
1. Making it tied to the OS. 2. Not building it in a way that its Open Source.
Yes I've read comments from Apple engineers that proclaim it relies on new features of UIKit/AppKit. Then, why not open source those UIKit/AppKit changes? Or, don't build the framework in such a tight-coupled way.
v1 should be about getting early adopters by allowing maximum platform reach and incrementally filling in the gaps.
So I'm hopeful this effort or any similar effort becomes the way forward for a lot of projects.
For any other project this is probably true, but Apple has never cared about any platform but their own.
Apple occasionally releases services for popular platforms that aren't theirs.
Square sold iPads with their software on as "appliances", so they can't deprecate them on a schedule like most software. For this reason the Square iOS codebase (which is a single codebase) must support back as far as iOS 9.
Because of this, they're considering an internal implementation of SwiftUI so that they can start using it now, rather than in ~5 years time. I wouldn't be surprised if they open sourced this if they do go ahead with it.