[DIS] Pocket Node for iOS: a self-custody CKB light client for Apple and Identity/Signer for CCC web apps

Link to VOT page:

https://dao.ckb.community/landing?method=share&thread=76502&refer_id=51416

Summary

Pocket Node is a self-custody CKB wallet that runs a full Rust light client on the device with no gateway server: the phone verifies the chain itself, holds keys locally, and builds and broadcasts transactions peer to peer. Over the last grant we shipped all four Android milestones, and the app is live at v1.8.

This proposal brings the same wallet to iOS: iPhone, . There is no self-custody CKB light-client wallet on iOS today, so this closes a real gap in CKB’s mobile reach.

This proposal also makes Pocket Node usable by the wider ecosystem: we adds an in-app dApp browser with CCC-compatible signer, so CCC-enabled websites such as the iCKB app and other ecosystem dapps can use Pocket Node for identity and signatures. This follows the direction of the discussion in issues Pocket Node #430, Quantum Purse #119, and Neuron #3438, and it is a capability the Android app does not have today.

Project introduction

Pocket Node is already live and in daily use on Android, so it needs little introduction here. In short, it is a self-custody CKB wallet that puts a real node in the user’s pocket: the phone verifies the chain itself and holds the keys, with no server in the middle, so the wallet keeps working on its own even if our infrastructure disappears.

Across the Android grant, we delivered mainnet readiness and hardware-backed security, full Nervos DAO integration on device, multi-wallet with HD sub-accounts, transaction export, an address book, and a public launch, plus a large amount of reliability and security hardening driven by real user reports. The complete milestone-to-release mapping is in our grant completion report.

Team and roles

Jr ( @Jnr6 ) is the lead developer and sole builder. Senior mobile engineer with several years of professional mobile experience, previously leading mobile teams, and a CKB community member. Jr designed, built, and shipped Pocket Node on Android end to end across all four milestones. The iOS build is the same one-person effort. The Android delivery record is the evidence that this scope is achievable solo on the stated milestones.

Current status

  1. What carries over: the protocol logic, the DAO math, the sync-mode model, the threat model, the UX and copy. These are designed and proven on Android, so this is not a from-scratch product.

  2. What has to be built: the entire SwiftUI application,lifecycle/background behaviour,Apple key management with Keychain and Secure Enclave, the UniFFI integration,platform testing, and the CCC signer, which doens’t exist.

  3. What has to be rewritten: the CKB Java SDK is for JVM. Replacing it with multiplatform cryptography without breaking android.

Technical approach

One Rust core, one shared core, two native shells.

  • Light client: the existing Rust light client, compiled for iOS and exposed to Swift through a UniFFI bridge. Same engine as Android, same P2P verification, same on-device storage.
  • Shared core: the wallet’s business logic, including transaction building and signing, is shared between both apps rather than rewritten, so the security-critical code lives in one place, is written once, and will be audited once. The parts that are currently Android-specific are moved onto cross-platform equivalents as part of this work.
  • iOS shell: I set out from the beginning to give a great mobile experience, so we will build a native SwiftUI app for the UI with hardware-backed key storage that mirrors the Android security design and Face ID or Touch ID with a PIN fallback.
  • Platforms: iPhone.
  • CCC identity and signer: an in-app dApp browser with an injected CCC-compatible signer. CCC-enabled websites get identity and signatures only; the embedded light client stays internal to the wallet, and keys never leave the device. Every signature goes through a wallet-rendered approval screen that decodes the transaction before the user confirms.

Key benefits for CKB

  • Fills the mobile ecosystem gap. iOS users currently have no self-custody, server-free CKB light-client wallet. This is not another entry in a saturated category; it is the first of its kind on the platform.
  • Extends CKB’s reach to the Apple user base with a wallet that already exists and works on Android. The large-screen layout work will also be implemented on the Android app alongside the iOS, bringing proper tablet support with it.
  • Reinforces ecosystem resilience. Core functions, including Nervos DAO deposits and withdrawals, run on-device against the embedded light client, with no reliance on a hosted frontend.
  • Opens CKB dApps to mobile. The final milestone makes Pocket Node an identity and signer for CCC-enabled websites through an in-app dApp browser, so ecosystem dApps such as iCKB and other dApps become usable from the wallet,dApps keep their own light client, Pocket Node provides identity and signatures.

Deliverables and milestones

Full parity with Android v1.8 (or whatever version the android version is then), plus the CCC signer, delivered across five monthly milestones. The most important work will be done first, so any possible bugs will be caught as we go on.

Milestone 1: Shared core, iOS bridge, app skeleton

  • Stand up the Multiplatform module and begin moving business logic into shared code without breaking the shipping Android app.
  • Replace the CKB Java SDK with multiplatform cryptography; port molecule encoding and address handling to shared code.
  • Build the Rust light client for iOS and wire the UniFFI bridge: init, start, stop, and a working query callable from Swift.
  • SwiftUI app skeleton with navigation, theme, and the light client running on device.
  • Acceptance: the iOS app builds, embeds the light client, and completes a testnet query end to end, while the shared core still compiles for Android unchanged.

Milestone 2: Keys, security, onboarding, receive

  • iOS key storage in Keychain with Secure Enclave access control, mirroring the Android hardware-binding threat model.
  • Face ID and Touch ID with a PIN fallback and lockout.
  • BIP39 generation and import, backup and verification flow, onboarding in SwiftUI.
  • Receive screen with address and QR.
  • Acceptance: create and import a wallet on a real device, keys hardware-protected, biometric unlock working, and a real testnet receive address shown.

Milestone 3: Send, sync, and activity (the usable wallet)

  • Sync engine and sync-mode model wired through the shared core.
  • Send flow with cell selection, fee, on-device build and sign, and broadcast; SwiftUI send screen with validation.
  • Activity history with pagination; QR scanner.
  • Acceptance: a real mainnet send and receive complete on device, history and sync work, and the first TestFlight beta is live.

Milestone 4: Nervos DAO, multi-wallet, and feature parity

  • Nervos DAO deposit, withdraw (both phases), and compensation tracking, reusing the shared DAO logic.
  • Multi-wallet create, switch, rename, delete, and HD sub-accounts from one mnemonic.
  • Background catch-up via the iOS background task scheduler, with notifications, on the foreground-first model described above.
  • Address book, CSV export, settings parity, and localization parity (English, Spanish, Russian, Chinese).
  • Acceptance: a DAO deposit and withdraw complete on mainnet, multiple wallets and sub-accounts work, and a feature-complete parity TestFlight beta is out, including the address book and localization.

Milestone 5: App Store launch and CCC identity and signer

  • App Store submission, review, and production launch.
  • CCC identity and signer, following the direction in Pocket Node #430, Quantum Purse #119, and Neuron #3438: dApps keep their own light client, and the wallet provides identity and signatures.
  • In-app dApp browser with an injected CCC-compatible signer: connect, signTransaction, and signMessage, with per-origin consent and wallet/account selection, since Pocket Node is multi-wallet.
  • Signature approval screen that decodes the transaction inside the wallet, resolves inputs through the light client’s proof-checked fetch to verify amounts and the exact fee, and shows what leaves the user’s cells and where the outputs go, gated by Face ID, Touch ID, or PIN. Keys never leave the device.
  • The signing and decoding core lives in the shared module, so the Android app gains the same capability on its normal release cadence (delivered there as a fast follow, not payment-gated here).
  • Acceptance: the app is live on the App Store for iPhone and iPad with full Android parity (or whatever version Android is on by then), and a real transaction on a live CCC-enabled dApp (for example the iCKB web app) is connected, decoded, approved, and signed end to end inside Pocket Node on iOS, with the signature returned to the dApp and the transaction confirmed on chain.The App Store review and the signer are independent workstreams within this milestone: if Apple’s final approval is still pending at month end due to review queue timing alone, sign-off proceeds on the submitted build plus the completed signer, with the listing going live as soon as Apple clears it.

Budget breakdown

Total: $15,000 USD, payable in CKB, over five months.

Payment When Amount Share
Commencement Kickoff $2,500 16.7%
Milestone 1 Month 1 $2,500 16.7%
Milestone 2 Month 2 $2,500 16.7%
Milestone 3 Month 3 $2,500 16.7%
Milestone 4 Month 4 $2,500 16.7%
Milestone 5 Month 5 $2,500 16.7%

Part of the initial payment funds the physical device required to start development on iOS and the Apple Developer Program enrolment.

Out of scope and future funding

Named here so the roadmap is clear and this proposal stays honest about its boundaries:

  • A single combined external security audit once both the Android and iOS codebases are complete, so one engagement covers both platforms and the shared core together. This is deliberately not funded in this grant; it belongs after iOS reaches parity.
  • Quantum-resistant lock support: After getting mobile platform parity, exploring how to allow users to choose what lock to use when signing their transaction (I don’t know what shape this will take yet, but proper research will be done and communicated in due time).
  • A cross-wallet CCC signer standard and cross-device transport. This proposal ships Pocket Node’s own in-app CCC signer (Milestone 5). Letting a desktop dApp talk to the phone wallet, and standardizing one signer protocol across wallets, needs agreement on transport and session security with the other wallet teams. Per the direction in the linked community discussions, dApps keep their own light client and wallets provide identity and signatures. I will pursue the standard as dedicated follow-on work together with Quantum Purse, Neuron, and the CCC maintainers. Hanseen has a plan to build this standard later.
  • Deeper ecosystem integrations, connecting Pocket Node natively to other CKB projects and protocols as they mature, such as native iCKB rendering beyond the CCC dApp compatibility delivered here, Fiber, and other community tech being built.
  • Fiat on-ramp and off-ramp, if and when it fits the self-custody model (I’m being optimistic here).

Risk and mitigation

  • Timeline. Full parity plus the signer, solo, in five months is ambitious. Mitigation: the riskiest structural work (shared-core extraction and the Rust bridge) is in Milestone 1, so slippage is visible at the first milestone; feature parity completes in Milestone 4, leaving the final month focused on the launch and the signer; and those two are independent workstreams within Milestone 5, so a slow Apple review cannot stall the signer, nor the reverse.
  • Remote signing surface. A website asking a wallet to sign is the most sensitive new surface in this proposal. Mitigation: the funded slice is the in-app browser only, so there is no relay, no network transport; the wallet decodes and displays every transaction itself before signing; signing stays behind biometric or PIN; and this surface is explicitly part of the future combined security audit.
  • App Store review. Self-custody wallets are permitted, but review can be strict. Mitigation: clear self-custody framing with no on-ramp or off-ramp claims, correct encryption-compliance declaration, and time budgeted for a review round or two in Milestone 5.
  • Background sync. iOS cannot sync a light client continuously in the background. Mitigation: a foreground-first model with best-effort background catch-up, communicated honestly in the app, consistent with how the Android background-sync work already sets expectations.
  • Shared-core extraction touching Android. Moving logic into a shared module affects a shipping app. Mitigation: extract incrementally with the Android build kept green at every step, verified before each milestone sign-off.

Open source and distribution

The iOS app is MIT licensed and open source from the start of Milestone 1, in the same public repository, with tagged releases per milestone, matching the Android commitment. iOS distribution is through the App Store and TestFlight, but the full source and tagged releases remain public, and builds are reproducible from source where the toolchain allows.

Closing

Pocket Node proved on Android that a phone can be its own CKB node. iOS is the natural next step: the same self-custody, server-free experience for the large share of users the ecosystem cannot reach today. I welcome the community’s feedback and questions.

Also, if you’re wondering why the android app isn’t on the playstore yet, it’s largely due to the fact that, I had to upload it under an organization account, which requires some process/paper-work from my end, it took some time but it’s now under review from google.

34 Likes

This is amazing, but will be a lot of work, due to the strict nature of IOS

3 Likes

The payment request is way too high. You’ve already been paid for the Android version. And you’ve already done most of the work. Besides, the sum seems arbitrary—and what project comes next after this? I do know people who use Apple, but I don’t consider them typical Nervos adopters. That’s just my opinion, though; many people have to use Apple devices for their work. Is there any interest in Apple here?

I’d also like to note that I find the implementation of iCKB questionable. Similarly, other solutions might want an implementation as well. I don’t think a project (with few users) like iCKB should be mixed in with this.

I also find the dApp browser to be a departure from the original core idea of having a “Flight Node in your pocket.” With DAO, sending and receiving transactions, sync… I think you’ve strayed from what it used to be.

To get my support, you’ll mainly need to adjust the funding request. Maybe eight thousand, but why eighteen thousand? You’ve been involved in this topic for quite some time now. Yes, there might be some Apple users here—I don’t know—but I think it’s a good thing that the Pocket Node app can be ported to Apple, including for Tapplets.

7 Likes

Thanks knmo, I appreciate the read and pushback because you have been one of the few people that cared too look, interract and provided feedback. Let me take these honestly, because a couple are worth clearing up for anyone else following along.

On iCKB, this is the most important one, because I think it is a misunderstanding that changes your objection entirely. I am not building an iCKB integration. I am building a CCC signer: Pocket Node becomes a wallet that any CCC-enabled website(which alot of the dapps being built on ckb is) can use for identity and signatures. iCKB is simply an example of such a website. The exact same work makes every current and future CCC dApp usable, with zero per-project code. So your instinct that other solutions will want this too is right, but not totaly spot on: they all get it from one neutral piece, and no single project is favored. I named iCKB only because it is a live dApp I can test against and it was one of the very first feedback/pushback i got on the first proposal, i did also here and here .

On the dApp browser being a departure from a light node in your pocket, I would argue it is that same idea extended, not abandoned. The principle was always sovereignty: your node, your keys, no server in the middle. The signer keeps all of it. The dApp runs its own light client, Pocket Node keeps its embedded one internal, keys never leave the device, and every signature is decoded and approved on-device behind your biometric. A website cannot touch your node or your keys, it can only ask you to sign, and you see exactly what you are signing before you do. That is the pocket node principle applied to dApps rather than a move away from it. It is also exactly what the CCC maintainer and other builders asked Pocket Node for in issue #430 i suggest you read the issue details so you get a scope of what i mean .

6 Likes

The focus on extending Pocket Node to iOS while maintaining its self-custody architecture and light-client design would strengthen the CKB ecosystem and improve accessibility for a wider user base. Very insightful project

4 Likes

@knmo i didn’t want my response to be too long, so I’ll complete my response here,
on the amount, it’s similar to Android. There I built on a device I already owned, . On Apple I own nothing: before writing a line of code I have to buy devices to develop and test on, because Secure Enclave, Face ID, the camera, and background behaviour cannot be validated on a simulator. To match the Android figure exactly I would have to strip that device cost out and absorb the hardware myself. I’m also targetting three Apple platforms and a CCC signer the Android app does not have(I’ll have to build this into the android codebase too) while still maintaining the already existing code.

On what comes next, the roadmap is in the Out of Scope section (combined security audit, the cross-wallet signer standard with the other wallet teams, quantum-resistant locks). Happy to refine with feedback.

3 Likes

I just wanted to clarify that I was simply sharing my thoughts on the existing solution mentioned in the issue and did not ask Pocket Node to support CCC.

I have no further comment on the proposal. Thank you for your great work.

2 Likes

Hi @Hanssen That’s right, I got the wording wrong and i have corrected that. Thank you.

1 Like

Of the proposal, this is what I’m actually interested in :backhand_index_pointing_up:

Generally, being a DApp developer, I don’t see really enough value in creating new wallets who cannot interact with Web DApps.

Side Note: I personally don’t like the in-app browser approach, but as @Hanssen was noting it likely carries the least uncertainty.

If implemented safely and in a reusable way, this would set a great example for others to follow in our ecosystem!

Keep up the Great Work, Phroi

PS: linked Github issue spurred from this Telegram conversation which is a continuation of ideas expressed in the first proposal.

3 Likes

You’ve already been paid for the Android implementation. That initial work was worth significantly more than porting to Apple platforms is worth. There are several platforms—you say there are three, which I already consider a lot—and what about future device compatibility? Will other types additionally be added at some point? Is there even a need for Apple support, or will it end up being just a handful of people? It seems to me like you’re using a sledgehammer to crack a nut here. And if you’re just starting to buy Apple devices yourself, then you probably don’t have much experience with them yet. Problems or delays are more likely.

You describe how potential dApps can be used equally by CCC signers, and that iCKB is just one prominent example. But even this prominent example has negligible usage. And how much of that negligible usage came from potential Apple users? This was just meant to spark some thought. An Apple user can install Neuron on their desktop or Bitcoin Light on their mobile device. I know that none of these are solutions comparable to PocketNode. But Apple users can certainly use CKB if they want to.

In my opinion, you should at least remove the dApp browser and any CCC-related features from your proposal. The PocketNode wallet could be as functionally and visually similar as possible to the Android version and be available only for the most popular Apple platform—presumably a fairly new one.

Don’t you think someone who has already worked extensively with Apple and already possesses the necessary knowledge and devices would be better suited for porting PocketNode?

I’m curious about Hanssen0’s idea for a peer-to-peer application connection.

I have reservations about integrations combining QuantumPurse, Neuron and PocketNode. These are separate projects, even though the developers probably share their knowledge and experience. Post-quantum-secure encryption will also become the default standard for transactions at Nervos in the medium term.

4 Likes

just want to share that this is taken out of context, the original is meant to communicate that secure practices seem to lead to downstream designs that uphold secure practices, while security compromises seem to lead to additional downstream security compromises. I don’t see it as applicable to one’s experience with development on one mobile platform versus another.

2 Likes

Thanks for the clarification; I wasn’t clear on that point—I was referring to integrating CCC into PocketNode. But it’s still great and important that the CCC exists.

2 Likes

I created the misunderstanding, when i used the word “Port” in the proposal, that created the idea of everything needed is already implemented and just need to be transfered over. while in reality, what i can transfer over is, the protocol logic(in rust), UI and UX, the DAO math and the sync-mode model; all these are already designed on android and i don’t have to reinvent the wheel, the rest of the work doesn’t exist on Pocket node and i have edited the proposal to indicate that.

The “several platform” is another misunderstanding created by my choice of word, there are two codebase, Android and iOS, everything else is under this two platform, if you’re are refering to the Ipad and native Mac OS includeed, that is not a separate codebase, the work from iOS trickles down and the bulk of the work for those two comes from form factor design work and separate QA and review cycle per target, same goes for the android platform too; which add to the work load and i will be removing them.

Not using an apple device is a personal choice, I have experienced both and i choose android as my daily driver(it gives me room for tinkering) and i use a macbook for work (testing the mac OS app is easy),owning a device doesn’t mean having building experience, plus you said problems and delay are more likely that statement itself is a guess, also that is what the milestone on the proposal is for, you don’t proceed if previous milestones are not cleared and the code is out in the open, anyone can compile and run it

I didn’t just come up with this or decided to build this on my own, this conversation has been ongoing for several months, both in my first proposal which i linked earlier. If you look at what is currently being built in the CKB ecosystem, a lot of it is web-based. Pocket Node being able to act as the identity/signing layer gives those applications a way to interact with the wallet without giving them access to the wallet’s internal light client or keys, also this is not about iCKB alone. and the other solution in the apple ecosystem in your own word are solutions not comparable to PocketNode

your concern here is that PN is swaying away from it original goal.Pocket Node still uses its own internal light client. That light client is not shared with the dApp. The keys stay on the device. A website cannot access either of them. It can only ask Pocket Node for identity or ask the user to sign something, and the user still sees and approves that inside Pocket Node.
So for me the principle is still the same: your node, your keys, no trusted server in the middle.

So I will remove native macOS and iPad support from this proposal, focus the funded Apple implementation on iPhone, and reduce the funding request accordingly.

I’ll update the proposal to reflect that.

5 Likes

I like Pocketnode and hope it’ll get even better than it already is. I’ll recommend PocketNode based on the results of the external audit.

3 Likes

Thank you @knmo you support is highly appreciated. you’re one of the users actually shaping how Pocket Node is being developed and that i don’t take for granted.

4 Likes

Hi everyone, voting is now live on metaforo

https://dao.ckb.community/landing?method=share&thread=76502&refer_id=51416

3 Likes

Hi everyone we have 3 days left to vote on Metaforo. don’t forget to show your support for pocket node.

https://dao.ckb.community/thread/vot-pocket-node-for-ios-a-self-custody-ckb-light-client-for-apple-and-identity-signer-for-ccc-web-apps-76502

3 Likes