8 ms·

Integrating Zig and SwiftUI

165 points by ingve 3y ago

conradev 3y ago
Rust also works quite well from Swift, in the same way The key to a nice developer experience is making the build from source flow as easy/integrated as possible I use a build script in Xcode to build a Rust static library automatically when building an app. This is the latest version in a project I am helping with: https://github.com/hackclub/burrow/blob/main/Apple/NetworkExtension/libburrow/build-rust.sh https://github.com/hackclub/burrow/blob/main/Apple/NetworkEx... It would be cool to write a similar adapter but to run build.zig!
- synergy20 3y ago
  the key to 90% programmer is though, zig seems to be 100 times easier to master. to me, use zig for c,use rust for c++
Arathorn 3y ago
this is also how the Element X rewrite of the Element Matrix client works - although with Rust rather than Zig. We had to add async support to uniffi for a good experience from Swift (and Kotlin) tho! https://youtu.be/eUPJ9zFV5IE?t=1280 https://youtu.be/eUPJ9zFV5IE?t=1280 has some deets.
WhereIsTheTruth 3y ago
SwiftUI shines because you get to write Swift code and embrace the DSL You'll never be able to write that kind of code with Zig, or C or C++, it's impossible: https://github.com/amosgyamfi/open-swiftui-animations https://github.com/amosgyamfi/open-swiftui-animations So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application, and that does look interesting, so you could write your crossplatform app logic in Zig, and only use Swift the UI That's the advantage that should be advertised, Kotlin tried with Kotlin-Native, seems like a good strategy
- nusaru 3y ago
  Second paragraph in OP: > One approach to building a native GUI for a cross-platform application is to write all of the business logic in a cross-platform language (C, Rust, Zig, etc.) and then write the platform-specific GUI code. This is the approach I take with my my terminal emulator and it works really well. As of the current date writing this post, 93% of my repository is business logic in Zig and C, and 4% is macOS-specific GUI code in Swift.
- benatkin 3y ago
  Are you suggesting that Zig never lets you just think about the problem? That's some terrible preoccupation with an idealized concept of a DSL. The swift code examples look kinda slick but it isn't a different paradigm any more than JSX is for building HTML. It seems like a form of The Bipolar Lisp Programmer. https://www.marktarver.com/bipolar.html https://www.marktarver.com/bipolar.html > Lisp is like wielding an air gun with power and precision. Those Swift examples you show are very exciting, but it's best not to get carried away. It's the same as those that say that vim is terrible because it's modal and don't believe that vim programmers can think about the problem while they're typing because their brain is distracted with switching between modes.
- FpUser 3y ago
  >"So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application" I've heard that BS from MS reps when they visited our company sometime in 90s. They were telling us how we should have monkeys drawing forms in VB and gurus making main code in C/C++. Then I showed them Delphi. You had to see how sour their faces turned. >"You'll never be able to write that kind of code with Zig, or C or C++" Your statement looks totally wrong. Looking at code seems like simple "fluent" notation that is quite possible in languages you mentioned.
  - deleted 3y ago
    [deleted]
  - benatkin 3y ago
    "you could write your crossplatform app logic in Zig, and only use Swift the UI" The UI glue code would be nothing special, and not improved by Swift vs Java. The UI would be designed in a design tool. I like open source, so perhaps Penpot.
ellis0n 3y ago
Good job. Please add a few words about debugging.
parhamn 3y ago
How does the api and "bridge" look in this type of setup? I'm trying to wrap my head around which parts you'd keep in the cross-platform layer (and whether that layer might be very thin in many applications I've built). If the application is heavy in UI state, does this sort of thing still make sense? I can't imagine what hell bidirectional data binding would be in this setup.
- mitchellh 3y ago
  OP here. UI state lives in the GUI code. For a GUI toolkit like SwiftUI, that's quite important ergonomically. I'm unsure how to really describe how the "bridge" code looks. All GUI interaction code happens in Swift, and when buttons are pressed and so on, I call functions back into Zig, and so on. There are certain scenarios where my Zig code calls back into Swift (via function pointers provided). For example, requesting to quit the application. These are handled using NSNotificationCenter accordingly. As I stated in the post, my cross-platform layer is >90% of my lines of code, and this isn't a trivial program, so for my use case this is working great.
  - aatd86 3y ago
    Interesting. I am thinking of writing such bridge for ly use case using Wasm (Wazero) with Go. Hoping the perf impact of crossing the bridge will not be too high.
  - parhamn 3y ago
    The post is great, hope I didn't seem to be critiquing it! I liked the idea so much I wondered if theres a magic reactive layer with data bindings so I could use it in UI heavy cross platform apps.
bestinterest 3y ago
Noob question, What makes languages like Zig, Rust, C and C++ the best fit for cross platform applications over many garbage collected languages? Why is bringing the language runtime a problem? What does it mean to compile to a C-compatible library? EDIT: I decided to ChatGPT my question instead. https://chat.openai.com/share/9a5f9f7a-0f5d-4cf6-95fc-4e0ec957c669 https://chat.openai.com/share/9a5f9f7a-0f5d-4cf6-95fc-4e0ec9...
- dhab 3y ago
  Curious to know from experts in the above to see if ChatGPTs response is valid? Me as someone who knows nothing about either, looking at a nuanced response from ChatGPT, puts me at awe - esp. response to the question: "Say I called a bunch of goroutines when I was in the Add function of the example you gave, would this be a problem?"
  - deleted 3y ago
    [deleted]
  - alecthomas 3y ago
    As I responded in a sibling comment, this is the point where ChatGPT goes completely off the rails and starts fabricating responses. Temper your awe :)
- alecthomas 3y ago
  ChatGPT's responses start accurate then quickly go off the rails. The section from this point onwards is completely incorrect: > Say I called a bunch of goroutines when I was in the Add function of the example you gave, would this be a problem? The Go runtime is initialised once only in c-shared mode for the lifetime of the application - it would make no sense to do it on every function invocation, and be incredibly slow. So the answer to this section and the next one are just largely bogus. ie. this response > However, once you call a function via a C or Swift bridge, it becomes a synchronous operation and will block the calling thread until all goroutines have completed execution. Therefore, you would need to effectively manage the synchronization of these goroutines to avoid unnecessary blocking of the calling thread. And the response to this question: > You said in 4 the Go runtime may not keep running, does this mean that every invocation of the Add function has to spin up the whole Go runtime every time? Why cant it just stay alive inside the Swift process? Are completely incorrect.
felipefar 3y ago
Nice post! I'm not sure if the same result is applicable to most software projects. A console emulator doesn't need several types of GUI objects, while most other projects need to display and handle input for several different types of data. In most projects I've worked on, the proportion of GUI code to business code was different: I saw apprx. 70% GUI code to 30% business code. So a cross platform GUI layer saves a lot more development time.
- filleduchaos 3y ago
  Is 70% of the code actually GUI code, or is it business-and-platform-logic-coupled-to-GUI code?
  - felipefar 3y ago
    New kinds of widgets, composition of classic widgets, view models, event handling (selection state, drag and drop, user inputs), visuals, shortcuts and accessibility.
- 59nadir 3y ago
  > In most projects I've worked on, the proportion of GUI code to business code was different: I saw apprx. 70% GUI code to 30% business code. Is it just me or is this a sad indictment of GUI libraries/frameworks in general? I'm not saying that the majority of situations I've seen are different, but while looking at these percentages it's actually sad that they seem likely, especially when you consider the lack of control most modern GUI solutions afford you and how you constantly have to work around their bad design. We're paying a lot for very little in the modern GUI landscape.
dgellow 3y ago
IMHO that’s one of the main benefits of following the Model-View-ViewModel architecture pattern for GUIs. You can have all the models and viewmodels defined in a platform agnostic library, and your views are the only thing to implement in a platform specific way. The core library can be implemented in any language, you just need a way to call methods and setters when the user interacts, and handle update events to update the UI.
- skrebbel 3y ago
  This seems like a really good idea! But at second glance, won’t differences between the UI designs on different platforms require subtly different viewmodels for each platform? Not if you make the exqct same UI on each platform I bet, but if you do that, you might as well use something like Flutter or React Native and only code the whole thing once, no?
  - dgellow 3y ago
    Yes, there are differences between platforms, complicating the picture a bit. There is a bit of a trade off/judgement calls when deciding what needs to be in the core library and what to keep on the platform specific code. You can always wrap a shared view model with a more specific one if you have to account for a few differences, or just decide to keep a bit of logic in the view. If you have >80% of your viewmodels that can be shared between platforms, MVVM can be really useful (just my own rule of thumb). If you have more differences between platforms I guess you will want to try something else. Regarding Flutter, then yes I agree with you, their approach is different, it’s more adapted if you want to design a single UI that will be rendered the same on every platform, without relying on native controls.
bsaul 3y ago
this approach gets me really interested. What are the improvements i should expect in zig compared to C ? And how does zig stdlib compare to something like the go stdlib ( which to me remains the gold standard)
- kristoff_it 3y ago
  >What are the improvements i should expect in zig compared to C ? https://ziglang.org/learn/overview/ https://ziglang.org/learn/overview/ >And how does zig stdlib compare to something like the go stdlib the stdlib is still work in progress and not the current focus of development. right now things get added to it organically (ie things needed by the compiler itself, the toolchain, or as a proof of concept for other important functionality, like an event loop). as we move forward we will have a phase where we make a final decision on what should stay in, what should be improved, and and what should be cut. In the meantime you can quickly get a feel for what's in the stdlib by browsing the online docs: https://ziglang.org/documentation/master/std/ https://ziglang.org/documentation/master/std/
  - bsaul 3y ago
    i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?
    - Daimanta 3y ago
      According to https://ziglang.org/documentation/master/#Targets https://ziglang.org/documentation/master/#Targets the only fully supported targets are x86-64. This does not mean that the entire stdlib will only work on x86-64 but that specific functions that require information about the inner workings of an architecture is only guaranteed to work on x86-84. If you'd be interested in a hash function like CRC32 you can see in the source code that there is no dependency on arch specific functionality, which makes it likely that it will work fine on other (LE?) architectures. This is on a case-by-case basis at the moment though. The advice from the Zig community is to check the source code in case of doubt. I have always found the source to be accessible, so this hasn't been an issue for me.

165 points by ingve 3y ago

Rust also works quite well from Swift, in the same way The key to a nice developer experience is making the build from source flow as easy/integrated as possible I use a build script in Xcode to build a Rust static library automatically when building an app. This is the latest version in a project I am helping with: https://github.com/hackclub/burrow/blob/main/Apple/NetworkExtension/libburrow/build-rust.sh https://github.com/hackclub/burrow/blob/main/Apple/NetworkEx... It would be cool to write a similar adapter but to run build.zig!

synergy20 3y ago
the key to 90% programmer is though, zig seems to be 100 times easier to master. to me, use zig for c,use rust for c++

Arathorn 3y ago

this is also how the Element X rewrite of the Element Matrix client works - although with Rust rather than Zig. We had to add async support to uniffi for a good experience from Swift (and Kotlin) tho! https://youtu.be/eUPJ9zFV5IE?t=1280 https://youtu.be/eUPJ9zFV5IE?t=1280 has some deets.

WhereIsTheTruth 3y ago

SwiftUI shines because you get to write Swift code and embrace the DSL You'll never be able to write that kind of code with Zig, or C or C++, it's impossible: https://github.com/amosgyamfi/open-swiftui-animations https://github.com/amosgyamfi/open-swiftui-animations So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application, and that does look interesting, so you could write your crossplatform app logic in Zig, and only use Swift the UI That's the advantage that should be advertised, Kotlin tried with Kotlin-Native, seems like a good strategy

nusaru 3y ago
Second paragraph in OP: > One approach to building a native GUI for a cross-platform application is to write all of the business logic in a cross-platform language (C, Rust, Zig, etc.) and then write the platform-specific GUI code. This is the approach I take with my my terminal emulator and it works really well. As of the current date writing this post, 93% of my repository is business logic in Zig and C, and 4% is macOS-specific GUI code in Swift.
benatkin 3y ago
Are you suggesting that Zig never lets you just think about the problem? That's some terrible preoccupation with an idealized concept of a DSL. The swift code examples look kinda slick but it isn't a different paradigm any more than JSX is for building HTML. It seems like a form of The Bipolar Lisp Programmer. https://www.marktarver.com/bipolar.html https://www.marktarver.com/bipolar.html > Lisp is like wielding an air gun with power and precision. Those Swift examples you show are very exciting, but it's best not to get carried away. It's the same as those that say that vim is terrible because it's modal and don't believe that vim programmers can think about the problem while they're typing because their brain is distracted with switching between modes.
FpUser 3y ago
>"So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application" I've heard that BS from MS reps when they visited our company sometime in 90s. They were telling us how we should have monkeys drawing forms in VB and gurus making main code in C/C++. Then I showed them Delphi. You had to see how sour their faces turned. >"You'll never be able to write that kind of code with Zig, or C or C++" Your statement looks totally wrong. Looking at code seems like simple "fluent" notation that is quite possible in languages you mentioned.
- deleted 3y ago
  [deleted]
- benatkin 3y ago
  "you could write your crossplatform app logic in Zig, and only use Swift the UI" The UI glue code would be nothing special, and not improved by Swift vs Java. The UI would be designed in a design tool. I like open source, so perhaps Penpot.

ellis0n 3y ago

Good job. Please add a few words about debugging.

parhamn 3y ago

How does the api and "bridge" look in this type of setup? I'm trying to wrap my head around which parts you'd keep in the cross-platform layer (and whether that layer might be very thin in many applications I've built). If the application is heavy in UI state, does this sort of thing still make sense? I can't imagine what hell bidirectional data binding would be in this setup.

mitchellh 3y ago
OP here. UI state lives in the GUI code. For a GUI toolkit like SwiftUI, that's quite important ergonomically. I'm unsure how to really describe how the "bridge" code looks. All GUI interaction code happens in Swift, and when buttons are pressed and so on, I call functions back into Zig, and so on. There are certain scenarios where my Zig code calls back into Swift (via function pointers provided). For example, requesting to quit the application. These are handled using NSNotificationCenter accordingly. As I stated in the post, my cross-platform layer is >90% of my lines of code, and this isn't a trivial program, so for my use case this is working great.
- aatd86 3y ago
  Interesting. I am thinking of writing such bridge for ly use case using Wasm (Wazero) with Go. Hoping the perf impact of crossing the bridge will not be too high.
- parhamn 3y ago
  The post is great, hope I didn't seem to be critiquing it! I liked the idea so much I wondered if theres a magic reactive layer with data bindings so I could use it in UI heavy cross platform apps.

bestinterest 3y ago

Noob question, What makes languages like Zig, Rust, C and C++ the best fit for cross platform applications over many garbage collected languages? Why is bringing the language runtime a problem? What does it mean to compile to a C-compatible library? EDIT: I decided to ChatGPT my question instead. https://chat.openai.com/share/9a5f9f7a-0f5d-4cf6-95fc-4e0ec957c669 https://chat.openai.com/share/9a5f9f7a-0f5d-4cf6-95fc-4e0ec9...

dhab 3y ago
Curious to know from experts in the above to see if ChatGPTs response is valid? Me as someone who knows nothing about either, looking at a nuanced response from ChatGPT, puts me at awe - esp. response to the question: "Say I called a bunch of goroutines when I was in the Add function of the example you gave, would this be a problem?"
- deleted 3y ago
  [deleted]
- alecthomas 3y ago
  As I responded in a sibling comment, this is the point where ChatGPT goes completely off the rails and starts fabricating responses. Temper your awe :)
alecthomas 3y ago
ChatGPT's responses start accurate then quickly go off the rails. The section from this point onwards is completely incorrect: > Say I called a bunch of goroutines when I was in the Add function of the example you gave, would this be a problem? The Go runtime is initialised once only in c-shared mode for the lifetime of the application - it would make no sense to do it on every function invocation, and be incredibly slow. So the answer to this section and the next one are just largely bogus. ie. this response > However, once you call a function via a C or Swift bridge, it becomes a synchronous operation and will block the calling thread until all goroutines have completed execution. Therefore, you would need to effectively manage the synchronization of these goroutines to avoid unnecessary blocking of the calling thread. And the response to this question: > You said in 4 the Go runtime may not keep running, does this mean that every invocation of the Add function has to spin up the whole Go runtime every time? Why cant it just stay alive inside the Swift process? Are completely incorrect.

felipefar 3y ago

Nice post! I'm not sure if the same result is applicable to most software projects. A console emulator doesn't need several types of GUI objects, while most other projects need to display and handle input for several different types of data. In most projects I've worked on, the proportion of GUI code to business code was different: I saw apprx. 70% GUI code to 30% business code. So a cross platform GUI layer saves a lot more development time.

filleduchaos 3y ago
Is 70% of the code actually GUI code, or is it business-and-platform-logic-coupled-to-GUI code?
- felipefar 3y ago
  New kinds of widgets, composition of classic widgets, view models, event handling (selection state, drag and drop, user inputs), visuals, shortcuts and accessibility.
59nadir 3y ago
> In most projects I've worked on, the proportion of GUI code to business code was different: I saw apprx. 70% GUI code to 30% business code. Is it just me or is this a sad indictment of GUI libraries/frameworks in general? I'm not saying that the majority of situations I've seen are different, but while looking at these percentages it's actually sad that they seem likely, especially when you consider the lack of control most modern GUI solutions afford you and how you constantly have to work around their bad design. We're paying a lot for very little in the modern GUI landscape.

dgellow 3y ago

IMHO that’s one of the main benefits of following the Model-View-ViewModel architecture pattern for GUIs. You can have all the models and viewmodels defined in a platform agnostic library, and your views are the only thing to implement in a platform specific way. The core library can be implemented in any language, you just need a way to call methods and setters when the user interacts, and handle update events to update the UI.

skrebbel 3y ago
This seems like a really good idea! But at second glance, won’t differences between the UI designs on different platforms require subtly different viewmodels for each platform? Not if you make the exqct same UI on each platform I bet, but if you do that, you might as well use something like Flutter or React Native and only code the whole thing once, no?
- dgellow 3y ago
  Yes, there are differences between platforms, complicating the picture a bit. There is a bit of a trade off/judgement calls when deciding what needs to be in the core library and what to keep on the platform specific code. You can always wrap a shared view model with a more specific one if you have to account for a few differences, or just decide to keep a bit of logic in the view. If you have >80% of your viewmodels that can be shared between platforms, MVVM can be really useful (just my own rule of thumb). If you have more differences between platforms I guess you will want to try something else. Regarding Flutter, then yes I agree with you, their approach is different, it’s more adapted if you want to design a single UI that will be rendered the same on every platform, without relying on native controls.

bsaul 3y ago

this approach gets me really interested. What are the improvements i should expect in zig compared to C ? And how does zig stdlib compare to something like the go stdlib ( which to me remains the gold standard)

kristoff_it 3y ago
>What are the improvements i should expect in zig compared to C ? https://ziglang.org/learn/overview/ https://ziglang.org/learn/overview/ >And how does zig stdlib compare to something like the go stdlib the stdlib is still work in progress and not the current focus of development. right now things get added to it organically (ie things needed by the compiler itself, the toolchain, or as a proof of concept for other important functionality, like an event loop). as we move forward we will have a phase where we make a final decision on what should stay in, what should be improved, and and what should be cut. In the meantime you can quickly get a feel for what's in the stdlib by browsing the online docs: https://ziglang.org/documentation/master/std/ https://ziglang.org/documentation/master/std/
- bsaul 3y ago
  i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?
  - Daimanta 3y ago
    According to https://ziglang.org/documentation/master/#Targets https://ziglang.org/documentation/master/#Targets the only fully supported targets are x86-64. This does not mean that the entire stdlib will only work on x86-64 but that specific functions that require information about the inner workings of an architecture is only guaranteed to work on x86-84. If you'd be interested in a hash function like CRC32 you can see in the source code that there is no dependency on arch specific functionality, which makes it likely that it will work fine on other (LE?) architectures. This is on a case-by-case basis at the moment though. The advice from the Zig community is to check the source code in case of doubt. I have always found the source to be accessible, so this hasn't been an issue for me.