Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Integrating Zig and SwiftUI

mitchellh.com

Post reply on HN
Print view View original

11–20 of 58 posts

Re: Integrating Zig and SwiftUI

#11

Post by turdprincess »

WhereIsTheTruth wrote: post #4

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 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…

The downside of this kind of strategy is that for an engineer to work on it, they need to be proficient in iOS, Android, and zig/c/c++. It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.

Another issue is maintenance and debugging - even something trivial like not being able to set breakpoints in the shared code can be a significant slowdown to an engineer. Not to mention the extra wrapping layers your native code needs to smooth out the interactions between the shared and native layers.

For sure there are settings where it makes sense to take this approach, especially if code is shared across more than two platforms. But just for iOS and Android I wouldn’t necessarily say it’s a more efficient solution.

Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another?

Re: Integrating Zig and SwiftUI

#12

Post by parhamn »

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.

Re: Integrating Zig and SwiftUI

#13

Post by benatkin »

FpUser wrote: post #7
WhereIsTheTruth wrote: post #4

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 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…

>"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 wi…

"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.

Re: Integrating Zig and SwiftUI

#14

Post by wudangmonk »

WhereIsTheTruth wrote: post #4

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 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…

React native and all these similar DSLs always seemed like a bad idea to me. I can forgive it on the web as you have no other choice than to use the 3 broken pillars which is html, css, and js and build your sand castles on top of that.

I wonder though, was the development of swift UI influenced by the abundance of react developers or is this what peak UI development looks like?. In the history of GUI applications does react represent the best we have managed to come up with?. I've used it as to me it kinda sucks but I have never worked on the UI side of anything except for small web frontends

I always just assumed that in the 40+ years there were some better UI libraries but apparently not?.

Re: Integrating Zig and SwiftUI

#15

Post by andrekandre »

turdprincess wrote: post #11
WhereIsTheTruth wrote: post #4

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 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…

The downside of this kind of strategy is that for an engineer to work on it, they need to be proficient in iOS, Android, and zig/c/c++. It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack. Another issue is maintenance and debugging - even something trivial like not being able to set breakpoints in the shared code can be a significant slowdown to an engineer. Not to me…

  > Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another?
this is one of the biggest downsides

the other big one is the code → write → test → deploy scenario is extremely slow to the point of extreme frustration (at least for kotlin multiplatform anyways) with these kinds of tools

Re: Integrating Zig and SwiftUI

#16

Post by mitchellh »

parhamn wrote: post #12

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.

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.

Re: Integrating Zig and SwiftUI

#17

Post by parhamn »

mitchellh wrote: post #16
parhamn wrote: post #12

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.

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, reque…

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.

Re: Integrating Zig and SwiftUI

#18

Post by deergomoo »

wudangmonk wrote: post #14
WhereIsTheTruth wrote: post #4

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 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…

React native and all these similar DSLs always seemed like a bad idea to me. I can forgive it on the web as you have no other choice than to use the 3 broken pillars which is html, css, and js and build your sand castles on top of that. I wonder though, was the development of swift UI influenced by the abundance of react developers or is this what peak UI development looks like?. In the history of GUI applications do…

The main benefit of declarative UI frameworks is that they remove the need to manually reconcile changes in state with changes in the representation of that state (with the caveat that it often becomes difficult to do so if the DSL doesn’t cover the behaviour you want).

UIs inherently have a hell of a lot of state that is constantly in flux, so it can become very difficult to manage those transitions correctly and efficiently. By providing a description of how an interface should look given some program state, the developer only need be concerned with the flow of data, and the framework can automatically create and apply the delta to update the UI in the most efficient way. For example, there’s no possibility to forget to re-enable a button in that rarely-used code path, because the “enabled” state is derived from the rest of your app state and any changes to that automatically cascade downwards.

I’m not saying these things are a silver bullet (and I don’t even really do much UI stuff anymore), but when my job involved frontend web stuff, moving from jQuery to Vue was both an unbelievable jump in both productivity and a massive decrease in UI bugs (and LoC!).

Re: Integrating Zig and SwiftUI

#19

Post by bestinterest »

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-4e0ec9...

Re: Integrating Zig and SwiftUI

#20

Post by madeofpalk »

wudangmonk wrote: post #14
WhereIsTheTruth wrote: post #4

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 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…

React native and all these similar DSLs always seemed like a bad idea to me. I can forgive it on the web as you have no other choice than to use the 3 broken pillars which is html, css, and js and build your sand castles on top of that. I wonder though, was the development of swift UI influenced by the abundance of react developers or is this what peak UI development looks like?. In the history of GUI applications do…

> In the history of GUI applications does react represent the best we have managed to come up with

tl;dr, yes.

Ignore the DSL syntax of React (or SwiftUI or whatever), and understand that React's model is that UI is a function of state. In my experience, being able to declare how your application should look given it's current state (and just let the engine figure out how to get there) is a significantly more productive.

This works very well with React on the Web because the primitives there are pretty basic, and there's a well understood way to break out back down to the imperative DOM APIs. Others (SwiftUI, WinUI XAML from my experience) haven't quite seem to have gotten the mix right yet, so you have a harder time once you need to do more complicated things.

SwiftUI (like React Web) has some really neat benefits from this - views can be serialized down and rendered without your application running. This is how lock+home screen widgets, and watch complications work - the app is intermittently asked to provide snapshots at certain points in time, which the OS serializes and shows later. This is easily possible with SwiftUI because it fundamentally is data.

Post reply on HN