iOS developers can add Hinkal to Swift applications through Swift Package Manager. Android developers can add it to Kotlin applications through Maven Central. Both SDKs are built from the same Hinkal core. There is no JavaScript bridge and no hidden WebView running inside the application.

What changed

Teams working on mobile apps have already been able to use Hinkal through @hinkal/react-native.

That package contains the JavaScript libraries and supporting components needed to run Hinkal inside a React Native application. It remains supported and is still the easiest option for teams already building with React Native. Native Swift and Kotlin applications, however, previously had to add a JavaScript environment that the rest of the application did not need. The new mobile SDKs remove that requirement.

Developers now call Hinkal directly through ordinary Swift or Kotlin methods. The native Hinkal library handles the privacy proofs, private balance records and transaction processing behind the scenes.

One core across both platforms

The iOS and Android SDKs are built from the same Go codebase using gomobile. On iOS, the code is provided as a prebuilt Hinkal.xcframework. Swift Package Manager downloads and verifies the framework automatically. On Android, it is provided as an .aar package and published through Maven Central as: io.hinkal:hinkal-android

Because both SDKs use the same core, they support the same privacy proofs, network protocol, operations and behaviour.

The private key remains in the wallet

The Hinkal SDK does not store or access the user’s private key. Instead, the application connects its existing wallet through a signer interface. The SDK can then ask the wallet to:

• Return the user’s address
• Return the current blockchain
• Sign a message
• Sign and send a transaction
• Switch networks

The wallet performs these actions, while the private key stays in the wallet or device keychain. The iOS interface is called MobileHostWalletProtocol. On Android, it is called HostWallet. Separate signer interfaces are also available for Solana and Tron. These networks are not currently live on Hinkal, so developers can prepare their integrations but should not yet make Solana or Tron functionality available to users. When a wallet connects, the user signs a message to create a Hinkal session. That session can then be used for multiple operations without requiring a new connection each time.

What developers can build

Once the wallet is connected, developers can add the following functionality to their mobile applications.

Private deposits

Users can move tokens from their public wallet into a private Hinkal balance. The transaction is signed and sent through the application’s existing wallet. The user therefore needs the token balance, enough native tokens for network fees and, for ERC-20 tokens, the required token approval.

Private transfers

Users can send funds from their private balance to another Hinkal user.

The sender, recipient and amount are not published on the blockchain.

The recipient provides a Hinkal private address, which the application can retrieve and verify before submitting the transfer.

Withdrawals

Users can withdraw funds from their private balance to any public wallet address.

The withdrawal is processed through a Hinkal relayer, so the user does not need to sign another public blockchain transaction. The relayer fee can be quoted before the withdrawal is submitted.

Private swaps

Users can exchange one token for another without leaving their private balance.

Pricing is provided through aggregated decentralised exchange liquidity.

Private cross-chain transfers

Users can move private funds from one supported blockchain to another.

The transfer remains private on both the source and destination networks, and developers can define the allowed slippage.

Deposits for another user

An application can deposit funds directly into another Hinkal user’s private balance.

Public payments to multiple recipients

The SDK also supports payments that start and finish with public wallet addresses.

An application can send from one public wallet to several public addresses through a single request. The recipients do not need a Hinkal account or private address, and they do not need to change how they receive funds.

This is particularly useful for payment applications, payroll tools and payout products that need to pay several existing wallet addresses.

Balance reads and batching

Private balances can be read separately for each token.

Applications can use cached balance information for normal interface updates and request a fresh scan after an operation that moves funds.

Tokens, recipients and amounts are passed as lists. This allows one request to process several tokens, payments or recipients instead of requiring a separate call for each one.

Compliance on mobile

The compliance controls are the same across Hinkal’s web and mobile products.

Deposits are screened through Chainalysis KYT before funds enter the private balance.

Moving the integration into a native mobile application does not change these screening requirements.

Integration requirements

iOS

Developers add the GitHub package URL in Xcode, import Hinkal, implement the signer interface, create a client and connect the user’s wallet.

Requirements:

• iOS 16 or later
• Swift 5.7 or later
• Xcode 15 or later

Package: github.com/Hinkal-Protocol/hinkal-sdk

Because the framework is generated using gomobile, iOS errors are returned through an NSError parameter rather than normal Swift throws.

The documentation includes a helper that converts these errors into the standard Swift try pattern.

Android

Developers add one Gradle dependency, import the Hinkal mobile library, implement HostWallet, create a client and connect.

Requirements:

• Android minSdk 21
• arm64-v8a
• x86_64

Package: io.hinkal:hinkal-android

Android methods use ordinary exceptions and can be handled with a standard try/catch block.

Handling errors safely

SDK errors currently use written messages rather than a fixed list of error codes.

We recommend separating them into three categories:

• Errors that require user action
• Temporary errors that can be retried
• Serious errors that should stop the operation

Balance reads can be retried with a delay.

Operations that move funds should never be automatically retried without first checking the user’s latest balance and transaction state. This prevents an application from accidentally submitting the same financial action twice.

Why native mobile support matters

Payment products are increasingly used on mobile devices.

Privacy cannot be limited to a website or desktop interface. It needs to be available inside the application where users already hold wallets, approve transactions and manage their money.

The new Hinkal SDKs make private balances and payments a normal mobile dependency, written in the same language as the rest of the application and connected to the wallet the user already trusts.

Quickstart, guides and full API reference -->