So that it can be used as a library by application, or as a background service (if that's possible on iOS).
I could tackle the technical part of this, but I don't have any iPhone, Mac or Apple device in general.
Let's get you some devices then. :computer:
I got parity compiling for and running on iOS – it was fairly straightforward because iOS is very similar to macOS. The changes I had to make were:
open(url: &str) function for target_os = "ios"malloc_usable_size)It would still need #4842 to be usable inside of an iOS app or extension (also light syncing needs some love in general).
@ratake nice work! it's true, we do need a library as well as better light sync. #8075 should address some of the syncing issues but beyond that we need stronger guarantees from the consensus layer.
could you submit a PR?
I've looked a bit into this issue today, as I had exceptionally access to a Mac.
The heapsize situation is quite problematic.
We should be able to replace it with the malloc_size_of crate of servo, but that means we have to propagate the change throughout the dependency tree.
EDIT: malloc_size_of pulls up half of the Servo ecosystem.
We also need cc-rs to pass a flag to the linker when building a library. Unfortunately, the rust-crypto crate still uses gcc-rs and doesn't seem to be maintained anymore. Hence the build fails.
Either we fork rust-crypto to use cc-rs, or we remove the rust-crypto dependency entirely. I would suggest the latter.
Closing issue due to its stale state.
Most helpful comment
I got parity compiling for and running on iOS – it was fairly straightforward because iOS is very similar to macOS. The changes I had to make were:
open(url: &str)function fortarget_os = "ios"malloc_usable_size)