I'm working on a hardware product for which the business logic is written in Swift.
I'm looking for options for building an interface. So far I've narrowed it down to:
TokamakUI (a SwiftUI clone) with a LVGL backend, which I've started to implement
SwiftCrossUI (again, with LVGL support)
Wrapping LVGL in Swift and using that directly (also have started doing that here)
Using Flutter for the UI (with Sony's embedded embedder) and building native Swift support for Flutter channels to glue the business logic (as the Darwin implementation is written in ObjC)
Develop in SwiftUI and have the customer BYiOSD ;) I'd prefer to avoid this though.
Does anyone have any further thoughts or experience in this area? I've paused my work on the LVGL wrapper/backend because, I'm not really sure I want to be in the UI framework business.
In the list I know only SwiftUI but I can't see how you can use that on a third party embedded touchscreen device. What OS do you have there? Maybe you can use a web app as a frontend?
BYiOSD is a pun on Bring Your Own Device (BYOD) ;) There are products like the Avid Dock where the haptic controllers are paired with a tablet purchased by the end-user but that's not commercially viable for my product.
SwiftUI workalikes such as Tokamak and SwiftCrossUI run fine on Linux and, with a suitable backend that doesn't require X11, should be fine on embedded. (Hence exploring a LVGL backend – LVGL is a lightweight graphics library with a tiny memory footprint, I imagine a lot smaller than the Swift standard library!) However, adding LVGL support isn't trivial, although the ease of development using a declarative UI framework may make up for it. (But then, I could just use Flutter.)
There must be numerous benefits to this approach (perhaps a much cheaper hardware that won't require touch screen in this case, cheaper / quicker development / more straightforward updates, especially if it is web UI). But this is of course up to you as you know your product better.
I wouldn't necessarily fight for declarative UI though... Nicer and easier to program, yes, but more CPU intensive and if you have a readily available non declarative option to choose from I'd go for it. Exactly ditto for the programming language itself.
Sounds like an interesting project ahead of you, good luck.
Really good comments, thank you. Yes, I think I have a bit of a “when all you have is a hammer everything looks like a nail”, I love programming in Swift but maybe it’s not always the right tool for the job. I’m fairly confident I’ll be able to find a touchscreen platform with enough grunt though. And yes, avoiding touchscreen entirely is also something worth exploring. Hardware button presses could integrate with (Open)Combine or AsyncChannel quite nicely :)
I bet you can save on buttons as well (other than the power button) - just send appropriate BTLE actions from the BYOD device. OTOH you'd need BT(LE) or WiFi support, win some lose some. Out of curiosity, what's the thing doing?
It’s a personal monitor mixer, just a hobby project for now :) For musicians to adjust their own balances whilst recording. Audio delivered over IP, so a single Ethernet port for power, audio and control.
In the end I've decided on Flutter with the Sony embedded embedder, as it's well engineered and the SwiftUI clones, whilst promising, still have a way to go to be feature-complete.
FlutterSwift is a native Swift implementation of Flutter channels (using async/await and Codable) which I am going to use to glue Swift business logic to Flutter UI.