Interesting detail about Square that I learnt on Twitter shortly after SwiftUI was launched...
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.
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+".
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.
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.
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.
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).
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 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.
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.
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.
”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.
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.
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.
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.
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."
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 :)
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.
The account was fine but the posts weren't making it past a software filter. We've marked the account legit so this won't happen again. In the meantime, the killed comments were all vouched for by users, which is great!
Hey @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 :)
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 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.
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.