iOS development

Is anyone working on getting the SAFE network on the iOS platform?

I’d like to get involved and help with any existing effort.

15 Likes

@krishna one for you I think.

3 Likes

Hi Thomas,

What would be the ideal tools that you typically use?

There’s a safe_app_csharp library.
Do you use Xamarin?
Is Objective C more ideal for iOS dev?

5 Likes

Ultimately I want a React Native bridge module that exposes SAFE network APIs on both Android and iOS so that I can develop apps for both platforms in React Native.

The first step would be to expose these APIs natively on each platform: Java bindings on Android, Objective-C bindings on iOS.

Following the forums, I realize work on Java bindings for Android are in progress, but I have not read anything about native Objective-C bindings.

I could help with getting these bindings working on iOS and creating the React Native bridge for both Android and iOS.

12 Likes

Sounds like a valid concern.

Although SAFE network itself uses crypto currency, its solution is quite different from blockchain and the apps themselves do not necessarily mine.

It might be worth developing some simple app and trying to get it published to test the waters.

11 Likes

That would be correct. Java bindings are ongoing. As for Obj-C, they aren’t being worked on. So the C libs exposed by safe_client_libs would be where its at to begin work for a native Obj-C layer.

The xamarin layer should already allow us to test this with mini projects to confirm validity there. Certainly would be an interesting find :+1:

Just to confirm, do these React bindings not have the option to go via a C layer directly? cos thats what the dotnet APIs currently do preventing the need for a bridge in Obj-C/Java for them. Just wondering if that was even an option for the React layer.

Where can I find these C libs exposed by safe_client_libs? I’d like to give that a try. I found some info how to use Rust static libs in iOS here: Building and Deploying a Rust library on iOS

It sounds like native iOS can hit the C layer directly, which is good. From there to expose these APIs to React Native Javascript, a bridge is needed: https://medium.com/@FizzyInTheHall/writing-a-react-native-bridge-library-bce5b90ea6d0

1 Like

hmm C API docs I’d normally just lookup from the rust crate docs: safe_app - Rust

If you want to see how these are bound for PInvoke from dotnet: https://github.com/maidsafe/safe_app_csharp/blob/master/SafeApp.AppBindings/AppBindings.cs and https://github.com/maidsafe/safe_app_csharp/blob/master/SafeApp.AppBindings/AppBindings.Manual.cs would show the safe_app layer bindings.

[DllImport(DllName, EntryPoint = "is_mock_build")]
private static extern bool IsMockBuildNative();

Entry point would be the c fn. DllName for iOS would be a special keyword used by dotnet to trigger the static linking for AoT requirements from iOS. So it might have some similarities with the React stuff too in some way.

As for building the C libs for mobile: https://github.com/maidsafe/safe_client_libs/blob/master/scripts/package.rs should help build the mobile arch C libs if you’re familiar with cargo-script. so then it’d just require having the essential cross targets setup locally on the build machine and building via this as a helper. I think this also generates corresponding C headers if required. I havent checked them recently tho.

If you want to skip ^^ and just get the C static libs from the s3 bucket those gets deployed too as part of CI:

Mock: https://s3.eu-west-2.amazonaws.com/safe-client-libs/safe_app-mock-6be5558-ios.zip
Non-Mock: https://s3.eu-west-2.amazonaws.com/safe-client-libs/safe_app-6be5558-ios.zip

6be5558 in that url just refers to the commit from safe_client_libs these libs are from. I just picked it from the current commit the dotnet projects seem to depend from master.

These iOS c libs are also universal libs(well to two archs). so the static libs in the archive are fat libs for ARM64, x64.

Hope that helps :slight_smile:

4 Likes

Unfortunately I’m not familiar with Rust and its toolset, but I’ll start figuring it out. Thanks for all the info!

1 Like

Ah not a problem. You can try not having to “deal with rust” :slight_smile: , if you just go with downloading the static libs and merely use the docs for the C APIs. That might still be a bit tricky for the API docs, one cheat you could try is just do a grep in safe_client_libs/safe_app for extern "C" that’d filter out all the C API methods :slight_smile: if that helps or check the dotnet bindings which should mirror that list too.

Do shout out if you get stuck ofc and I’m sure the guys @nbaksalyar / @marcin can try and help with the C APIs.

3 Likes

I’ve managed to build safe_authenticator static libs on my MacBook.

After installing rust and pulling down safe_client_libs, I ran:

scripts/build-all
scripts/package.rs --name safe_authenticator

Looks like that resulted in building libsafe_authenticator for x86_64-apple-darwin architecture:

toms-MacBook-Pro:safe_client_libs tom$ cd target/
toms-MacBook-Pro:target tom$ find . -name "*.a"
./x86_64-apple-darwin/release/deps/libsafe_authenticator.a
./x86_64-apple-darwin/release/libsafe_authenticator.a
...

How do I build/package for other architectures like “ios-arm64”?

it has help instructions if you run it such as cargo script scripts/package.rs -- --help which should get you:

safe_client_libs packaging tool

USAGE:
    package [FLAGS] [OPTIONS] --name <NAME>

FLAGS:
    -b, --bindings    Generates bindings package
    -c, --commit      Uses commit hash instead of version string in the package name
    -l, --lib         Generates library package
    -m, --mock        Generates mock version of the library
    -h, --help        Prints help information
    -V, --version     Prints version information

OPTIONS:
    -a, --arch <ARCH>              Target platform and architecture [values: linux-x86, linux-x64, osx-x86, osx-x64,
                                   win-x86, win-x64, android-armeabiv7a, android-x86, ios-arm64, ios-x86_64, ios]
    -d, --dest <DEST>              Destination directory (uses current dir by default)
    -n, --name <NAME>              Name of the crate to package [values: safe_app, safe_authenticator]
    -t, --toolchain <TOOLCHAIN>    Path to the toolchain (for cross-compilation)

also side note, try building safe_app and not safe_authenticator as thats not essentially something the apps should be packaged with. Another side note: you do need to have cross platform rust targets setup for this, or go with the prebuilt libs to skip this part ofc.

1 Like

They recently allowed KINIT a blockchain app where you can earn and spend KIN the native currency.

The first to my knowledge.

1 Like

Interesting… no authenticator? I have yet to take a look at the Xamarin mobile app to see how it works, but I assumed there would be a need for the authenticator just like in Peruse. Or is there already an authenticator app somewhere that I should be using?

Yeh the authenticator is not really intended to be replicated per lang but be agonistic(to keep credentials secure … ofc being open source doesn’t restrict anything but isn’t something that’ll be a goto compared to app bindings which very much are expected to exist in as many languages to help devs build their apps ofc). The browser just happens to contain it in desktop right now and in mobile there is a detached auth repo that currently is with Xamarin to cater to android and iOS but be compatible with apps in respective platforms regardless of the app prog lang. it’d just use the native url scheme for auth info exchange in both mobile platforms similar to the desktop ipc between the browser and apps written in any other lang for desktop. That’s currently what safe_app_java would be showcasing similar to safe_app_csharp and safe_app_nodejs.

Ofc the app repo built with mock flag also bundles mock auth functionality to help it be tested without the production authenticator and a testnetwork and so on but that mock is packaged as part of the safe_app c lib itself.

3 Likes