Blind index search methods

Figure out how Swift unit tests work and what type of tests we want to write for the SDK wrappers. We'll likely need to do an integration level test for most things unless there's a good way to mock out the underlying C calls somehow. This ticket should probably be done somewhere in the middle of the rest of the tickets so we have a good understanding of the repo layout. Written as a SPIKE because trying to do all the unit tests in a single ticket would take forever.

All post-init user API methods.

ironoxide-swift library does not support ironoxide-swig-bindings v0.14.7.
Please update this library for supporting ironoxide-swig-bindings v0.14.7.

Cleanup to support full options of policy caching config, method to clear the policy cache, etc.

Work on a sample iOS app and README that we can add to the Swift repo to show how to use the SDK. Probably just a simple todo app like we have for Android.

Also need to test this on an actual device.

Consuming latest ironoxide-cpp, user create, user verify, and device generate all need to use the new Jwt class.

Add integration tests for user SDK operations in the same vein as we have for ironoxide to exercise all of the SDK methods and verify their results.

We allow callers to specify HTTP timeout options in various places in ironoxide. All pre-init functions take an optional duration and the IronOxideConfig has a sdk_operation_timeout. Figure out how to pass those in from Swift.

See if we can get CI running on this repo in Github. Need to figure out a lot of pre-test stuff like the ironoxide binary, header files, etc.

Add integration tests for document SDK operations in the same vein as we have for ironoxide-java to exercise all of the SDK methods and verify their results.

if let ironJwt = Jwt(auth0IdToken) {
print(ironJwt)
}

This is showing error like this :

"'jwt' failed validation with the error 'JSON error: missing field pid at line 1 column 543'"

Should be able to run brew install libironoxide which places a staticly linked library for iOS (.a file) as well as a package config file.

There are various places within our Swift library where we're not feeing memory used within Rust correctly or completely, which will cause memory leaks in an application which uses our library. Places we've found so far:

• The Util.collectTo method copies memory when converting from Rust vectors to Swift arrays. We should free the underlying memory after copying
• When converting strings (Util.rustStringToSwift) from Rust to Swift, we're calling free methods on the underlying Rust types, but we aren't doing anything when we move data from Swift into Rust (Util.rustStringToSwift) which might also need work to free
• Look into this comment about strings going out of scope when passing them to Rust.

@giarc3

let jwt = Jwt(auth0token)

Getting below error for Social logins(facebook and google)

"'jwt' failed validation with the error 'JSON error: duplicate field sid at line 1 column 780'"

Originally posted by @BaiXiaoYan in #57 (comment)

Figure out the best way to implement the initialize_check_rotation method from IronOxide and how that works within Swift. Probably look at how we did it in Java.

All document methods, including the advanced/unmanaged methods.

Consuming the latest ironoxide-java, initialize_blind_index_search was moved from EncryptedBlindIndexSalt to IronOxide.

We need to match these changes and fix tests and imports.

Add a handful of integration tests for group operations in the same vein as the integration level tests that run in ironoxide-java.

These can mostly come from ironoxide, but need to make sense in Swift (use nil instead of None, use typical swift doc comment format, etc).

GitHub pages supports having a /docs folder in a projects tree to host docs for a project, e.g, https://ironcorelabs.github.io/ironoxide-swift/. Now that we have docs being generated via Jazzy, we should publish those on GitHub pages as it's as good a place as any to point to.

In order to keep them up to date without work, we should modify our GitHub actions build script to automatically update and commit them. Ideally we would do this when a tag is pushed since that will indicate a new version was released, but if that is too difficult then doing it on merge to master would also work.

userCreate
generateNewDevice
initialize (without policy or timeout configuration

The Swift project that we've done a PoC for so far is in a Swift application with view files, etc. We should instead move that over to a Swift library that we can build and (somehow) publish for other projects to depend on. XCode has the ability to create a new Library project, we should start there and see what we can do.

As part of this, we should also figure out how to do some initial unit tests in order to test and run this library.

We had found a number of issues with the memory model between the JVM and ironoxide that caused us to implement a number of changes so that the JVM didn't crash when developers re-used things they passed down to our SDK. We should do some of the same experiments with Swift to see if it has the same problems and what types of changes we need to implement to make sure the same doesn't happen there.

We need to deallocate the memory of our OpaquePointers when a Swift wrapping struct gets garbage collected. Unfortunately this cannot be done on structs as the deinit only exists on classes. So switch everything over to a class and add the deinit method and _delete call to clear the native struct.

Also, our wrapping structs all have accessor methods. It seems more Swift-like to have properties instead. Swift has evaluated properties but also can do lazy evaluation as well, so figure out the best way to make that work.

Add wrappers for all Group SDK methods. Also includes work to create/expose out Swift structs for the input/output types.

We want the Swift tests to be similar to ironoxide where we generate users on demand for tests to avoid conflicts between tests. This requires that we have a project/segment/assertion key setup and a JWT library to let us generate JWTs. This library seems like the best option for JWT generation.