3 ms·

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

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?

andrekandre 3y ago
> 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
jb1991 3y ago
> It’s somewhat uncommon to have engineers known just iOS This is very common in the iOS world. Not sure about other areas.
- JimDabell 3y ago
  Why did you break off mid-sentence? If you continue reading the rest of the sentence, you will see that they are saying the opposite of what you think they are: > It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.
  - jb1991 3y ago
    > If you continue reading the rest of the sentence who stops reading a sentence in the middle? I did not include Android or other stacks because I don't know about them (as I said, "not sure about other areas"). But for iOS it is not uncommon for developers to solely specialize in it, yet the comment claims it is uncommon. I wonder if you misread my comment or the one I replied to? Or perhaps the original comment is grammatically ambiguous.
    - ItsHarper 3y ago
      They were saying that it's uncommon for a single developer to specialize in both iOS and Android
    - turdprincess 3y ago
      My wording could have been better - I meant that it’s uncommon for engineers to know both iOS and Android at a deep level. Sharing code can let you share a lot of your logic, but you still need to understand the native host environment well, in fact maybe even deeper than normal since you are using unconventional approaches. So you need engineers that have this deep iOS experience, deep Android experience, and deep C++/rust experience. If you are a solo dev with this skillset then maybe it’s a good choice. But in a team / big company setting such an unconventional stack will always be a drag chute on your velocity in all stages of the project
kristoff_it 3y ago
> even something trivial like not being able to set breakpoints in the shared code I think your overall point still stands, but you can setup breakpoints in Zig and have the normal tooling work correctly with it.

andrekandre 3y ago

> 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

jb1991 3y ago

> It’s somewhat uncommon to have engineers known just iOS This is very common in the iOS world. Not sure about other areas.

JimDabell 3y ago
Why did you break off mid-sentence? If you continue reading the rest of the sentence, you will see that they are saying the opposite of what you think they are: > It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.
- jb1991 3y ago
  > If you continue reading the rest of the sentence who stops reading a sentence in the middle? I did not include Android or other stacks because I don't know about them (as I said, "not sure about other areas"). But for iOS it is not uncommon for developers to solely specialize in it, yet the comment claims it is uncommon. I wonder if you misread my comment or the one I replied to? Or perhaps the original comment is grammatically ambiguous.
  - ItsHarper 3y ago
    They were saying that it's uncommon for a single developer to specialize in both iOS and Android
  - turdprincess 3y ago
    My wording could have been better - I meant that it’s uncommon for engineers to know both iOS and Android at a deep level. Sharing code can let you share a lot of your logic, but you still need to understand the native host environment well, in fact maybe even deeper than normal since you are using unconventional approaches. So you need engineers that have this deep iOS experience, deep Android experience, and deep C++/rust experience. If you are a solo dev with this skillset then maybe it’s a good choice. But in a team / big company setting such an unconventional stack will always be a drag chute on your velocity in all stages of the project

kristoff_it 3y ago

> even something trivial like not being able to set breakpoints in the shared code I think your overall point still stands, but you can setup breakpoints in Zig and have the normal tooling work correctly with it.