I've updated the SwiftCrossUI repository to publish its docs to GitHub Pages via the deploy-pages GitHub action instead of writing them to the gh-pages branch.
The repository used to take 2.5 minutes to clone on my home WiFi, and after deleting the gh-pages branch it now takes under 2 seconds 🎉
Development has been a little bit quiet since v0.2.1 (around 2 weeks ago) because I've been focussing more on Swift Bundler, in particular getting it ready for its v3.0.0 release, and improving Windows support.
SwiftCrossUI v0.3.0 brings a few SwiftUI feature parity improvements, some bug fixes, and perhaps most notably for users, a huge amount of documentation improvements by Kaleb Ascevich.
github.com/moreSwift/sw...
I've just released SwiftCrossUI v0.2.0 (two and a half years after v0.1.0), and I'm aiming to begin making regular releases now that I'm focusing on SwiftCrossUI full time.
492 commits, 127 PRs, and 77k changed lines.
github.com/moreSwift/sw...
If you'd like to try it out, follow the Swift Android getting started guide, then use the command in the screenshot to build SwiftCrossUI's CounterExample (on the android_support branch); www.swift.org/documentatio...
Swift Bundler can now automatically locate compatible Swift Android SDK + Swift toolchain pairs on the user's behalf. It also supports automatically installing and launching apps on Android devices and emulators.
If you know anyone who might be interested in the project, I'd love if you could share the video with them!
The Ladybird browser project has inspired me to begin making regular SwiftCrossUI development update videos. The first one is up on YouTube now and covers the last two months of SwiftCrossUI development. Let me know what you think! youtu.be/HgRO7eIHkyE
The talk is 10 minutes long, and covers the basics of SwiftCrossUI, Swift Bundler, hot reloading, and Mia’s Swift Data alternative called Amethyst Vein.
One of SwiftCrossUI’s amazing contributors, Mia Koring, recently presented a lightning talk about SwiftCrossUI at the Swift Pre-FOSDEM Community Event. Go check out the recording on YouTube if you missed it! youtu.be/EC9qVCYBVyk?...
Wrote it in Swift (rather than my usual Python for scripting) with as many libraries as I wanted, and it was relatively enjoyable! The annoying part was using an oddly structured library for interacting with the GitHub API (which was missing bindings for the Actions part of the GitHub API).
Made a small utility for checking in on my repositories at a glance. It solves something that has bothered me for a while, which is that GitHub doesn't display a diff from the latest review to current changes (instead it shows which *files* changed since the last review but diffs against the base).
I've been working on Android support for Swift Bundler this past week or so, and it can now bundle SwiftCrossUI applications into Android APKs fully automatically 🎉
To finish off basic Android support, I still have to implement Android device/emulator discovery and automatic APK running.
As SwiftCrossUI and Swift Bundler have grown, it’s become clear that they deserve to live under their own org.
For that reason, I’ve created the moreSwift org and transferred SwiftCrossUI and Swift from my personal account to the org.
“Create your next app with moreSwift” 😉
github.com/moreSwift
They should also make it easier for people to port existing native apps to SwiftCrossUI by incrementally replacing native view implementations with cross-platform SwiftCrossUI implementations. FooHostingView implementations will also be very useful in that space, and are planned.
These interoperability features will be great for allowing developers to hack together features that SwiftCrossUI doesn't have yet, which will be useful even once SwiftCrossUI is more mature (just look at SwiftUI).
The first example shows off the new `inspect(_:)` family of modifiers, by using the one for Text to reimplement the textSelectionEnabled modifier. And the second shows off the new …Representable family of protocols.
I've just merged a bunch of native interoperability features into SwiftCrossUI; namely native widget inspection modifiers, and …Representable protocols similar to NS/UIViewRepresentable from SwiftUI; github.com/stackotter/s...
Any ideas what exactly the NSLayoutManager.limitsLayoutForSuspiciousContents does? I feel like it probably attempts to filter out content that looks like it could be trying to trigger memory corruption bugs in the text engine?
developer.apple.com/documentatio...
I feel like Google slightly misinterpreted the sentiment of my search query...
I've merged my SwiftCrossUI layout performance PR, and I've updated the PR description with a detailed write-up of the optimisations that it contains in case anyone is interested: github.com/stackotter/s...
Exactly! And we get good API consistency guarantees that we wouldn’t get if we instead wrote each view (e.g. Text) once for each platform, like I believe Tokamak does.
There's a bit of boilerplate atm, but once I have another unit test using DummyBackend I'll abstract that out (no use abstracting from one example).
I also just used DummyBackend to make SwiftCrossUI’s first proper cross platform UI-related unit test: github.com/stackotter/s...
The test reproduces an issue where my new ScrollView impl didn’t notify the underlying scroll widget of changes to scroll bar presence when processing layout updates.
The benchmarks that I've been using to measure my layout system optimisation progress use DummyBackend to simulate basically everything involved in handling a view update other than the backend-specific part of displaying the results on screen. Great for a wholistic view of performance!
A great thing about SwiftCrossUI's backend-based architecture, is that it was relatively easy to implement a DummyBackend specifically made for cross platform unit testing and layout performance benchmarks.
Dependency tracking affects window resizing performance a great deal because you can be sure that none of the content has changed, and thus can reuse basically any useful previous computations. I want to add state dependency tracking to SwiftCrossUI, but for now am focusing on the layout algorithm.
I did some quick testing against SwiftUI, and it appears that for my benchmarks, SwiftCrossUI's initial layout speed (when SwiftUI isn't caching results) is within a factor of 2 of SwiftUI. The advantage that SwiftUI still has is that it can cache across updates due to state dependency tracking.
I've been working on a whole heap of performance improvements for SwiftCrossUI's layout system over the past two weeks, and they're almost ready to merge.
One of my benchmarks is 68x faster, and an app that I've been testing against is now 28x faster at window resizing.
github.com/stackotter/s...
