CraysAvocadough
Avocadough is not trying to become your Lightning node. It gives an iPhone a clean way to control a wallet you already connected through Nostr Wallet Connect.
An iPhone face for someone else's Lightning wallet
Avocadough is best understood as a wallet interface, not as a new wallet service that asks you to deposit money into a brand. The official site describes it as a Bitcoin Lightning app powered by Nostr Wallet Connect, and the open-source repository describes it as an iOS Lightning wallet through NWC. That wording is precise. The iPhone app gives you a native surface for a wallet that already exists somewhere else.
That makes Avocadough different from a Cashu wallet, a custodial Lightning account, a node dashboard or a social client with a zap button. The app does not start by asking you to create a timeline, follow people or publish posts. It starts by asking for an NWC connection. Once paired, it can show the balance and payment tools exposed by that connection. If the remote wallet says no to a method, Avocadough has to say no too.
This is the right mental model for testing the app. Avocadough is the steering wheel and dashboard. The funds, payment policy, fees, channel liquidity, custodial risk and uptime live with the connected wallet provider. The app can make that relationship feel clean on iOS, but it cannot turn every NWC backend into the same product.
The first secret is the pairing string
The heart of Avocadough is the NWC URI. In practice that usually arrives as a QR code or a string beginning with nostr+walletconnect. Inside that string are the pieces needed to talk to the wallet service: the wallet public key, at least one relay, a secret and sometimes a Lightning Address. The string is convenient because it lets a client connect quickly. It is dangerous for the same reason.
Avocadough's setup flow treats that URI as the real onboarding step. The app lets you scan a code with the camera or paste a manual string. It parses the URI through NostrKit, stores the secret, records the wallet public key and relay, and tries to initialize the NWC client. If parsing fails or the wallet cannot be reached, the setup stays in the error path instead of pretending the wallet is ready.
Handle that connection string as wallet authority. It is not a public Lightning Address. It is not a normal username. It is a capability that can authorize commands within the permissions granted by the wallet service. If you screenshot it, paste it into an untrusted page or keep it in cloud notes, you may be leaking the control plane for your payments.
What Avocadough stores on the phone
The code separates the sensitive secret from the rest of the connection record. The NWC secret is saved through SparrowTek's Vault package with an iOS Keychain configuration named for the NWC secret. The less sensitive connection metadata, such as wallet public key, relay and optional Lightning Address, is represented as a SwiftData model.
That split is a good iOS pattern. The Keychain is the right place for secrets that should not sit in ordinary app data. SwiftData is the right kind of local model layer for records the interface needs to reconstruct state, route the user past setup and show the connected wallet. Avocadough does not have to store a password or create a server-side account to remember that it has been paired.
The Settings screen makes this storage story visible in plain user terms. The destructive action says it will disconnect and clear data. Behind that button, the app routes through the wallet state and removes the local NWC connection. That is the button to use when a phone is changing hands, a connection has been over-permissioned or you simply want this iPhone to stop controlling that wallet.
Permissions shape the whole interface
Nostr Wallet Connect is useful because it does not have to be an all-or-nothing relationship. A wallet can expose only the methods it wants a client to use. Avocadough takes that seriously. After setup it asks the wallet for information and stores the returned method list as part of the local wallet model.
The visible app then checks those methods before opening money actions. If the wallet does not advertise balance access, tapping balance can show a permission error. If the connection does not include pay_invoice, the Send flow is blocked. If make_invoice is not available, the Receive invoice path is blocked. The interface is not inventing capabilities that the remote wallet refused to grant.
That is good for safety and good for diagnosis. If Avocadough feels limited after pairing, the next question is not only whether the app is broken. The better question is which permissions the NWC provider granted. A read-only connection, a receive-only connection and a full send-and-receive connection should not behave the same.
Balance, send, receive and recent activity
The main wallet screen is built around everyday Lightning actions. It can display the current balance in millisatoshis converted into a human view, offer Send and Receive buttons, show a recent activity section and refresh transaction data. The app also asks Block's public Bitcoin pricing endpoint for a current BTC price so fiat-adjacent displays can be calculated locally.
The NWC client methods underneath are familiar if you have used the protocol: get_info, get_balance, pay_invoice, make_invoice, lookup_invoice and list_transactions. Avocadough wraps those calls in its own wallet provider layer so the UI can call a common wallet manager rather than reaching into protocol details from every screen.
That provider design matters because the repository already has a broader wallet abstraction. The enum includes NWC and Cashu as wallet types, and there is a Cashu provider protocol with methods for mints and tokens. Today the default provider registration is NWC. The Cashu hooks read like an architectural opening, not a current promise that the shipped app is a full Cashu wallet.
Receiving depends on the connection you brought
Avocadough's receive flow has two modes. If the NWC URI included a lud16 Lightning Address, the receive screen can show that address and present a QR code for it. That is the smoother experience because the address can be reused by someone who wants to pay you without asking for a fresh invoice first.
If no Lightning Address is present, the app falls back to invoice creation. The make_invoice path asks the connected wallet to create a BOLT11 invoice for an amount and description, then looks the invoice up so the app can keep the payment hash with the local receive state. That extra lookup is a small implementation detail with a practical purpose: the UI wants both the invoice string and the payment hash.
The limitation is important. A reusable address shown in Avocadough is not invented by the iPhone. It comes from the connected wallet relationship. If your provider did not put lud16 into the NWC URI, Avocadough cannot magically publish a Lightning Address for you. It can still create invoices if make_invoice is permitted.
Sending is invoice first, with address support
The send screen accepts an invoice, a Lightning Address or LNURL-style input. Avocadough uses LightningDevKit's BOLT11 parser to detect invoice strings and sends invoice payments through the connected wallet's pay_invoice method. For address-style input, it moves through a details and review flow before submitting the payment.
Camera access is requested only when the user wants to scan a QR code. The SwiftUI send presenter checks the iOS camera authorization state, requests permission if needed and opens the QR scanner only when permission is available. That is the kind of small mobile detail that separates a real iPhone app from a protocol demo.
The most important send rule remains simple: Avocadough can only spend through the authority you gave it. If the NWC string is allowed to pay invoices, a successful pairing can become a spending device. If you only wanted the app to view or receive, create a limited NWC pairing at the wallet provider side before scanning it.
Transactions are a local mirror
Avocadough keeps local transaction models, but it is not the final ledger of the wallet. The app calls list_transactions through NWC, maps remote transaction data into SwiftData and stores fields such as payment hash, invoice, description, amount, fees, created time, expiry and settlement time. That local model lets the interface show recent activity without treating the remote backend as a dumb black box.
There are limits. The app's wrapper notes that some NostrKit list transaction parameters are not supported by the underlying call and are ignored. The transaction sync code also catches errors and returns instead of making every failed refresh into a user-facing crash. For a wallet interface, that is understandable. For a financial audit, it means you should check the source wallet if anything looks incomplete.
Read the activity list as a convenience layer. It helps you see what Avocadough recently observed through NWC. It is not a substitute for understanding the connected wallet's own records, its backup model, its fee policy or its transaction export story.
NostrKit, CoreNostr and the SparrowTek stack
Avocadough is also useful as a window into SparrowTek's Nostr tooling. The Swift package lock file shows NostrKit and CoreNostr coming from SparrowTek repositories, Vault for secret storage, LightningDevKit's Swift package for invoice parsing and Apple's Swift ASN.1 and Swift Crypto libraries. It is a native Swift stack, not a web wrapper with a wallet logo.
NostrKit does the heavy NWC work. The Avocadough app delegates URI parsing, wallet connection, encrypted command handling and wallet method calls to NostrKit's WalletConnectManager. CoreNostr sits lower in the stack, while Vault handles Keychain access. That division keeps the app code focused on pairing, screens, permissions and local state.
The repository requirements are modern: Xcode 16.2, macOS 15 and Swift 6. That matters if you are trying to build the app yourself. You should expect a current Apple development setup rather than an old sample project that can be compiled casually on any Mac.
The privacy policy is modest, not magical
Avocadough's privacy posture is straightforward. The official policy says the app does not create accounts. It also says server software may keep basic technical information such as IP addresses in temporary memory or logs, and that the app may collect aggregate anonymous statistics about feature usage to improve the app.
That is a modest claim, and modest claims are better than impossible ones. A wallet interface can avoid creating accounts and still touch external systems: the NWC relay, the wallet provider, Block's pricing endpoint, the official website, App Store distribution and whatever analytics are present in the app. Privacy depends on the whole path, not only on whether Avocadough has a login form.
Before using it with meaningful funds, think about what each party can see. The NWC relay can be part of the command path. The wallet provider knows the wallet. The pricing endpoint sees price requests. The App Store knows install metadata. Avocadough's own policy limits what the developer says it collects, but it does not erase the rest of the payment stack.
Background notifications have real iOS limits
The repository includes notes on wallet notifications, and those notes are more realistic than the usual instant-payment marketing. iOS does not let an ordinary app keep a persistent WebSocket connection alive in the background forever. That is a direct constraint for any NWC client that wants to receive live relay notifications after the phone is locked or the app is suspended.
The documented plan separates three layers: foreground or brief-background NWC notifications when the app is active enough, local notifications for events the app sees, and slower background refresh as a fallback. It also points out that reliable instant push would require a small server that subscribes to the NWC relay and sends APNs notifications.
That should shape expectations. Avocadough can be a pleasant iPhone wallet interface, but no iOS client can pretend the operating system does not exist. If instant receive alerts matter to you, test them under real lock-screen and background conditions, not only while the app is open on the desk.
Open source helps, but testing still matters
The public repository is one of Avocadough's strengths. You can read the wallet provider, setup flow, settings screen, transaction model, receive flow, send flow, price service and package dependencies. You can also see the support link, privacy policy text and attribution to NostrKit and Block's price API inside the app source.
Open source does not remove the need to test. It gives you a way to verify how the app intends to behave, but the shipped app is still a compiled iOS build, and the actual security of your setup also depends on the wallet provider, the relay, the permissions inside the NWC connection and your device hygiene.
A sensible first run is small and deliberate. Pair a low-value wallet, confirm the methods returned by the provider, check whether balance appears, create a tiny invoice, pay a tiny invoice, verify the source wallet's record, close and reopen the app, then disconnect and confirm that the connection is removed. That test teaches you more than a logo, a screenshot or a promise.
Where Avocadough fits in the NWC ecosystem
Avocadough belongs with wallet interfaces because it makes NWC usable from the phone. It does not try to solve relay policy, social discovery, long-form publishing or Nostr identity by itself. It focuses on the specific moment when a person has a wallet service somewhere and wants an iOS app to operate it cleanly.
That role is valuable. NWC only becomes friendly when normal users have good surfaces for pairing, viewing balance, receiving, paying and disconnecting. Avocadough gives that surface to Apple users while keeping the Nostr and Lightning mechanics out of the main line of the interface.
The tradeoff is that a good interface can make a dangerous connection feel harmless. NWC is powerful because it moves wallet commands through a portable protocol. Use that power intentionally. Pair the minimum permissions you need, keep the secret private, prefer providers you understand and treat the iPhone as one control device among several, not as the place where every risk disappears.
What to check before you rely on it
Start with the official links. Download Avocadough from the App Store link on avocadough.xyz or join the TestFlight from the official site. Avoid random builds and unsolicited pairing pages. A wallet interface that begins with a sensitive NWC string should not be installed from a source you cannot verify.
Then inspect the wallet side. Which provider created the NWC URI? Which methods are allowed? Is there a spending cap? Is the relay reliable? Can the connection be revoked from the provider? Does the wallet expose lud16 if you expect reusable receiving? Avocadough can only enforce what the connection and provider make available.
Finally, decide what the app is for. It is a strong fit for a small mobile NWC controller, a clean iPhone companion to a wallet service and a way to learn how NWC feels in a native app. It is not a reason to ignore wallet custody, backup, relay dependency, iOS background limits or the risk of leaking a live connection string.
Sources worth opening
Open the official website, App Store link, TestFlight link, GitHub repository, Swift wallet files, NWC documentation, NIP-47, LNURL documents and Apple's Keychain and SwiftData documentation together. Avocadough is easiest to understand when the polished iPhone surface is read beside the connection and storage code.
- Avocadough official website
- Avocadough App Store link from the official site
- Avocadough TestFlight link from the official site
- Avocadough privacy policy
- Avocadough support project page
- SparrowTek official website
- SparrowTek avocadough GitHub repository
- Avocadough README
- Avocadough notifications notes
- Avocadough NWC wrapper
- Avocadough NWC wallet provider
- Avocadough wallet provider abstraction
- Avocadough wallet manager
- Avocadough app state
- Avocadough setup presenter
- Avocadough setup state
- Avocadough sync config data
- Avocadough sync transaction data
- Avocadough wallet presenter
- Avocadough wallet state
- Avocadough receive presenter
- Avocadough receive state
- Avocadough send presenter
- Avocadough send state
- Avocadough settings presenter
- Avocadough settings state
- Avocadough wallet model
- Avocadough transaction model
- Avocadough NWC connection model
- Avocadough Block BTC price service
- Avocadough localization strings
- Avocadough Swift package lock
- SparrowTek NostrKit
- SparrowTek CoreNostr
- SparrowTek Vault
- LightningDevKit Swift package
- NWC official site
- NWC introduction
- NWC reference API overview
- NIP-47 Nostr Wallet Connect
- LNURL LUD-16 Lightning Address
- LNURL LUD-06 pay request base spec
- Apple Keychain Services documentation
- Apple SwiftData documentation
- Apple camera authorization documentation
- Apple background tasks documentation
- Block
