Swift for Blockchain

What is Swift

Swift is Apple's open source programming language for apps, services, and embedded code. It is described at swift.org as fast, expressive, and safe, with predictable memory management and compilation to native code. The language is developed in the open at github.com/swiftlang/swift and documented in The Swift Programming Language at docs.swift.org/swift-book.

Apple released Swift 6 on September 17, 2024. The Swift Evolution changelog tracks the line since: Swift 6.1 on March 31, 2025, Swift 6.2 on September 15, 2025, and Swift 6.3 on March 24, 2026. Each ships with Xcode and as a standalone toolchain for macOS, Linux, and Windows via swift.org/install.

Swift is not a native on chain smart contract language for Ethereum or Solana the way Solidity or Rust is. No major L1 runs Swift bytecode in consensus. You use Swift where Apple platforms meet blockchains: in iOS and macOS wallets, signing and key management, and in Swift clients that talk to nodes over JSON-RPC or gRPC.

If you are new to Swift, the official starting point is The Swift Programming Language and the Swift.org documentation. Everything below is verified against those sources plus the SDK READMEs listed at the end.

Who it is for

You should learn Swift for blockchain if you:

• Build iOS or macOS wallet apps. Every App Store wallet with native UI, biometrics, and Secure Enclave storage is a Swift app.
• Work on mobile-first onboarding. Embedded wallets, passkeys, and WalletConnect flows on iPhone are implemented in Swift with SwiftUI and Combine.
• Maintain a Swift codebase and need to add blockchain features without rewriting your app in React Native or Flutter.
• Want to use Apple's security hardware for key storage and device attestation on consumer devices.

You can likely skip Swift for now if you:

• Only write on chain contracts for EVM chains. Solidity and Vyper ship to the EVM. Swift helps you call those contracts from an app, not replace them.
• Only write Solana programs or Cosmos modules. Those are Rust and Go. You will still use Swift for the mobile client that calls them, but not for the program itself.
• Build backend indexers or data pipelines. TypeScript, Python, Go, and Rust have more blockchain indexing libraries.

How Swift works

The language itself

Swift is statically typed with type inference, optionals, closures, structs and classes, and protocol-oriented generics. Memory is managed by Automatic Reference Counting (ARC). Value types like structs copy on assignment, reference types like classes share ownership. This is different from garbage collected languages and from manual malloc and free in C.

Since Swift 5.5 the language includes structured concurrency with async and await, actors for isolated state, and Sendable checks. Swift 6 makes data race safety the default. The compiler refuses code that shares mutable state across concurrency domains without proper isolation. For wallet code that signs in the background while updating UI, this catches threading bugs before they ship.

Swift Package Manager is the integrated build tool. You create a package with swift package init, add a dependency in Package.swift, build with swift build, and test with swift test or the newer Swift Testing library introduced alongside Swift 6. On Apple platforms you usually build through Xcode, which bundles the Swift toolchain.

On security primitives, Apple ships CryptoKit on Apple platforms. It provides SHA256, P256, Curve25519, AES-GCM, and ChaChaPoly, plus Secure Enclave wrappers. Apple also publishes Swift Crypto at github.com/apple/swift-crypto, an open source implementation of much of CryptoKit based on BoringSSL for use on Linux and Windows. On Apple platforms Swift Crypto delegates to CryptoKit, so results match.

A key detail for blockchains: CryptoKit supports NIST P-256, P-384, P-521, and Curve25519, but not secp256k1, the curve Bitcoin and Ethereum use for ECDSA and BIP-340 Schnorr. If you need secp256k1 in Swift you use a separate library. Examples include P256K at github.com/21-DOT-DEV/swift-secp256k1, which wraps bitcoin-core libsecp256k1, and secp256k1 bindings used inside wallet SDKs.

How Swift talks to blockchains

Swift apps do not execute contracts on device as a validator does. They act as clients:

1. The app builds a transaction or a read call in Swift types.
2. It signs locally with a private key held in Keychain, Secure Enclave, or an MPC share.
3. It sends the signed payload to a node over JSON-RPC with URLSession, or via a typed SDK, and waits for a receipt or event.

That pattern repeats across every mature Swift SDK.

web3swift (web3swift-team/web3swift).

The most starred Swift Ethereum library, described as an iOS toolbelt for interaction with the Ethereum network. Features listed in the README include Swift implementation of web3.js functionality, interaction with a remote node via JSON RPC, local keystore management compatible with geth, smart contract ABI parsing and V2 decoding, ENS support, Infura support, TxPool parsing, event loops, middleware hooks for transaction workflow, and explicit standards support for BIP-32, BIP-39, BIP-44, EIP-20, EIP-155, EIP-2718, EIP-1559, and others plus RLP and Base58. Install via Swift Package Manager:

dependencies: [
    .package(url: "https://github.com/web3swift-team/web3swift.git", .upToNextMajor(from: "3.0.0"))
]

Requirements listed: iOS 13.0 or macOS 10.15, Xcode 12.5, Swift 5.5. You import web3swift and Web3Core, create a Web3 provider from an RPC URL, then use EthereumAddress, CodableTransaction, web3.eth.send, and contract.createReadOperation for calls. For local development the docs recommend Ganache running at 8546 for tests.**argentlabs/web3.swift.

A lighter Ethereum Swift API with support for smart contracts, ENS, and ERC20. Adds ERC721 helpers, BigInt and BigUInt via attaswift/BigInt, and optional ZKSync Era support. Install:

.package(url: "https://github.com/argentlabs/web3.swift", from: "1.1.0")

You provide an EthereumKeyStorage conformer for your key, create an EthereumHttpClient or EthereumWebSocketClient for RPC, then generate typed contract calls from an ABI.**EvmKit.Swift (horizontalsystems/EvmKit.Swift).

A native Swift toolkit for EVM chains used in Unstoppable Wallet. It handles account and transaction sync over HTTP or WebSocket, stores ETH balances and transactions locally, supports mnemonic, BIP39 seed, private key, or watch address restore, ENS, EIP-1559 gas with live updates, and RxSwift reactive APIs. It supports Ethereum, BNB Chain, Polygon, Arbitrum One, Optimism, and Avalanche C-Chain. Together with Eip20Kit, NftKit, UniswapKit, and OneInchKit it adds DeFi features without WalletConnect. ZKsync Era Swift SDK (zksync-sdk/zksync2-swift).

A web3swift-based SDK for ZKsync Era. It ports most web3swift APIs and adds ZKsync-specific fields for account abstraction and contract deployment. It exposes ZkSyncClient for chain queries and Wallet with WalletL1 and WalletL2 for deposits, withdrawals, and transfers. Minimums listed: iOS 13 and macOS 11. Aptos Swift SDK (aptos-labs/aptos-swift-sdk).

A type safe Swift 6 SDK targeting tier 2 P0 plus P1 compliance with aptos-sdk-specs v1.0.0. Minimums: iOS 17, macOS 14, watchOS 10, tvOS 17, Swift 6.0. It uses async and await with actor-based clients. AptosClient composes 15 domain APIs: general, account, transaction, view, coin, faucet, digitalAsset, fungibleAsset, ANS, staking, and more. It includes BIP-39 mnemonics with SLIP-0010 and BIP-32 HD derivation via Mnemonic.generate and Ed25519Account.fromMnemonic on path m/44'/637'/0'/0'/0'. Algorand Swift SDK (CorvidLabs/swift-algorand).

Modern Swift 6 SDK with async and await, type safe Address and MicroAlgos, PaymentTransaction, AlgodClient and IndexerClient actors, and support for iOS 15 plus macOS 11 plus tvOS 15 plus watchOS 8 plus visionOS 1 plus Linux. Concordium Swift SDK (Concordium/concordium-swift-sdk).

For iOS 16 plus macOS 10.15, focused on seed based identities, credential and account creation, transfer transactions with memo, and CIS-2 fungible tokens. It wraps Rust crypto via ConcordiumWalletCrypto exposed as a Swift package. Flow Wallet Kit (onflow/Flow-Wallet-Kit).

Includes SecureEnclaveKey using SecureEnclave.P256.Signing.PrivateKey with CryptoKit and KeychainAccess, plus SeedPhraseKey and PrivateKey variants. privateKey returns nil for Secure Enclave, by design, since the key is non exportable. Solana in Swift.

Two patterns appear: lightweight Solana clients like ZODs-Labs/swift-solana-kit which advertises Swift 6, Foundation, CryptoKit, URLSession, and no third party SDK dependencies in core targets, with minimums macOS 14 plus iOS 17 plus Swift 6 plus Xcode 16, and more complete embedded wallet stacks listed below. SpaceKit and Swift EVM.

Two experimental paths show Swift closer to execution. SpaceKit, presented at forums.swift.org in February 2025, is a Swift smart contract framework that compiles Swift to WebAssembly for SpaceVM chains, notably MultiversX, with BigUInt, Vector, Storage and Event abstractions and a SwiftVM test environment. Swift EVM, documented in June 2025, is a pure Swift Ethereum Virtual Machine that executes real Ethereum bytecode, tracks gas, and handles EIPs like EIP-2929 warm and cold access, with native Ethereum types H160, H256, and U256. Both remain community projects, not replacements for Solidity or Rust for production contracts today. Bitcoin in Swift.**swift-bitcoin at github.com/swift-bitcoin/swift-bitcoin builds a cross platform Bitcoin framework in data race safe Swift with modules BitcoinCrypto, BitcoinBase, BitcoinWallet, BitcoinBlockchain, BitcoinTransport, and BitcoinRPC. It depends on bitcoin-core libsecp256k1 and uses SwiftNIO for transport. The pichukov/swifty-kaspa SDK for Kaspa shows a similar pure Swift approach for Kaspa with BLAKE2b and BLAKE3, BIP-39 and BIP-32, and Secure Enclave wrapping.

Crypto and key storage on Apple devices

Three options dominate Swift wallet apps.

Keychain plus Secure Enclave. The device Keychain stores items with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and optional biometric gating. When available, keys live in the Secure Enclave, a hardware isolated coprocessor. On iOS this is accessed via SecureEnclave.P256.Signing.PrivateKey or via CryptoKit plus LocalAuthentication. The Enclave key is non exportable, so privateKey returns nil and signing happens inside hardware. The Flow Wallet Kit example makes this explicit. Swifty-Kaspa documents a production pattern: a P-256 envelope via ECIES with ephemeral P-256 plus HKDF-SHA256 plus AES-GCM around the seed, device bound, biometric gated, with a software wrapping fallback only for simulator builds.

Limit: the Enclave supports P-256 (secp256r1), not the secp256k1 curve that Ethereum and Bitcoin signatures require. That is why many teams do not store the secp256k1 private key directly in the Enclave. Instead they store a P-256 passkey in the Enclave that authorizes access to the secp256k1 key, or they use MPC.

Embedded wallets with MPC. SDKs like Coinbase CDP Swift (coinbase/cdp-swift), Dynamic Swift (dynamic.xyz), Crossmint (CrossmintSDK), and FabricBloc FabricKit ship a single Swift package that creates non custodial wallets secured by MPC. Para docs describe the common 2-of-2 design: one share on device protected by passkey and biometrics, one share in cloud HSMs in AWS or similar, with signing done via distributed key generation and the DKLS19 algorithm without ever assembling the full key. FabricKit notes that MPC shares live in the Secure Enclave when available. These SDKs expose actor based async APIs, e.g. Coinbase WalletsClient as an actor with start(), onAuthStateChange, and handleOAuthCode, and Dynamic via DynamicSDK.instance() with Combine publishers for authenticatedUserChanges.

Hardware wallets and WalletConnect. Swift apps also add hardware wallet bridges or WalletConnect to keep keys off device. The EvmKit and web3swift docs note Ledger style flows and watch account modes.

A practical check: EvmKit lists iOS 13 plus Swift 5.5, web3swift lists the same, while newer SDKs like Aptos and swift-solana-kit require Swift 6 and iOS 17 or macOS 14 because they use strict concurrency. Match your deployment target first.

Why teams choose Swift for blockchain

Where Swift helps most

• Native app quality. SwiftUI, UIKit, and Swift concurrency produce responsive wallet UIs with Face ID and Touch ID prompts, background sync, and efficient networking via URLSession. Users get a real iPhone app, not a web view.
• Security hardware access. Only Swift has first class access to Secure Enclave, Keychain, DeviceCheck, and Managed Device Attestation on iOS. If you need device bound keys or hardware attestation for compliance, Swift is the required path.
• Type safety and data race safety. Optionals, typed errors, and Swift 6 concurrency checks catch nil and race bugs that in wallet code can mean lost funds or stuck transactions. The compiler refuses many unsafe sharing patterns.
• Interop with C and C++. Swift calls C and C++ directly. That is how Swift Bitcoin links libsecp256k1, LMDB, and SwiftNIO without a separate foreign function layer.

Trade offs to know

• Not for on chain logic. Swift does not deploy to the EVM, Move VM, or SVM today except via experimental compilers like SpaceKit. Contracts still ship in Solidity, Vyper, Move, or Rust, and Swift apps call them.
• Curve mismatch in Enclave. Storing a secp256k1 key directly in the Enclave is not supported. You need the P-256 passkey plus MPC or HSM pattern, which adds infrastructure.
• Platform limits. Core targets for many Swift SDKs are Apple platforms only. Linux support is often planned but not ready. web3swift, Aptos, and swift-solana-kit each list different minimums, so you need to track which version your users run.
• **Smaller blockchain sample base.

Compared to TypeScript with viem and ethers or Rust with Anchor, Swift has fewer copy paste DeFi snippets. Docs assume iOS knowledge and you will often read EVM docs written for TypeScript first, then port to Swift.

Pros and cons for blockchain work

Pros

• Best path to App Store distribution. One language covers UI, networking, persistence, and signing with tooling Apple supports directly through Xcode and TestFlight.
• Hardware backed auth. Face ID, Touch ID, and Enclave gated signing provide hardware protection that pure software Keychain cannot.
• Modern concurrency. Actors and async sequences map well to RPC polling, WebSocket subscriptions, and transaction confirmation flows.
• **Package ecosystem that fits iOS.

Swift Package Manager, DocC, and Swift Testing match the iOS release train, with no bridge to Node. Cons

• Learning curve for blockchain specifics. You must learn both Swift concurrency and blockchain concepts like nonces, gas, ABI encoding, and reorg handling.
• Separate contract language still required. You will maintain Solidity or Rust for contracts plus Swift for the app. That is two toolchains, two test suites, and two audit surfaces.
• Dependency on Apple toolchain. Xcode, provisioning profiles, and App Store review add steps that web deploys do not have.
• Smaller hiring pool for protocol work. Most core protocol and smart contract roles list Solidity, Rust, Go, or Move first. Swift roles cluster at wallet teams, fintechs, and consumer dApps that ship on iOS.

How to get started

1. Install Swift the supported way

On macOS install Xcode from the App Store, then check:

swift --version
xcodebuild -version

For standalone toolchains on macOS, Linux, or Windows use swift.org/install or the swiftly version manager. Swift 6 is included in Xcode 16.3 and later. Keep the Swift version aligned with your SDK. Aptos Swift SDK and swift-solana-kit require Swift 6.0 and Xcode 16. For older EVM kits, Swift 5.5 plus Xcode 12.5 is enough.

Open local docs with open https://docs.swift.org/swift-book/ or dash docsets. The Swift book revision for Xcode 16.x tracks Swift 6 syntax.

2. Learn optionals, ARC, and actors before wallet code

Work through The Swift Programming Language chapters on basics, optionals, structures and classes, extensions, protocols, error handling, and concurrency. Practice these until they are automatic:

• Unwrap with if let and guard let. Try force unwrapping nil and read the runtime error.
• Value vs reference. Try mutating a struct copy vs a class instance.
• Actor isolation. Try sharing a mutable array across two Tasks without actor and fix it by moving state into an actor.

These exercises mirror real wallet bugs, like showing a stale balance due to a race between a WebSocket event and a UI read.

3. Pick one chain stack and wire a read call first

Option A: Ethereum with web3swift (most reusable for EVM)

mkdir MyWalletApp && cd MyWalletApp
swift package init --type executable
# Add .package(url: "https://github.com/web3swift-team/web3swift.git", .upToNextMajor(from: "3.0.0")) to Package.swift
swift build

In code, create a provider from an RPC URL, then read:

import web3swift
import Web3Core

let web3 = try await Web3.new(URL(string: "https://sepolia.infura.io/v3/YOUR_KEY")!)
let address = EthereumAddress("0xe22b8979739D724343bd002F9f432F5990879901")!
let balance = try await web3.eth.getBalance(for: address)
print(balance) // in wei

Add a contract read with web3.contract(Web3.Utils.erc20ABI, at: tokenAddress) and createReadOperation("balanceOf"). Keep keys in memory only for this first test.

Option B: ZKSync Era with zksync2-swift Follow the same Swift Package step, then use ZkSyncClient at https://sepolia.era.zksync.dev and WalletL2 for getBalance and transfer. Keep the same web3swift ABI for contracts.

Option C: Solana, Aptos, or Algorand with their Swift SDKs

• Solana: install swift-solana-kit and create a Kit product targeting iOS 17 or macOS 14, then use Kit, Rpc, and ProgramClientCore.
• Aptos: AptosClient(.testnet) then Ed25519Account.generate() and client.faucet.fundAccount.
• Algorand: AlgodClient plus IndexerClient with Address and MicroAlgos types.

Start with testnet and a faucet before you touch mainnet funds.

4. Add secure storage and biometrics

• Store the mnemonic or private key seed with Keychain via KeychainAccess or KeychainStorage as shown in Flow Wallet Kit. Use kSecAttrAccessibleWhenUnlockedThisDeviceOnly and set kSecAccessControlBiometryAny when you need Face ID.
• For Enclave: create via SecureEnclave.P256.Signing.PrivateKey() and store the encrypted representation, not the raw private bytes. Remember to handle the non exportable case where privateKey returns nil.
• For embedded wallets with MPC: integrate Coinbase CDP Swift, Dynamic, Crossmint, or FabricKit rather than hand rolling key splitting. Create the client with WalletsClient(config: CDPCoreConfig(projectId: "your-project-id")), call start(), then sign via the SDK so shares never assemble on device.

Test on a real device, not only the simulator. The simulator has no Enclave and falls back to software wrapping, which the Swifty-Kaspa docs mark as not for production secrets.

5. Practice secure patterns

• Validate every address with checksum before sending. web3swift and argent web3.swift provide EthereumAddress with checksum support.
• Check chain id and replay protection. EIP-155 is listed as supported in web3swift.
• Estimate gas and handle EIP-1559 fields. EvmKit provides live EIP-1559 prices.
• Test reorgs and pending states via TxPool parsing support in web3swift.
• Never log a seed phrase or private key. Keep signing behind an actor so only one transaction mutates the nonce at a time.

FAQ

Can I write Ethereum smart contracts in Swift?

Not for deployment to Ethereum mainnet today. Mainnet runs EVM bytecode produced from Solidity, Vyper, or Yul. You can use Swift to build frontends, wallets, and indexers that call those contracts via ABI over JSON-RPC. Experimental paths compile Swift to WASM for SpaceVM chains via SpaceKit, or run EVM bytecode in Swift via Swift EVM, but those are not replacements for EVM deployment.

Why does Apple CryptoKit not sign Bitcoin or Ethereum transactions directly?

Because CryptoKit exposes NIST curves P-256, P-384, P-521, and Curve25519. Bitcoin and Ethereum require secp256k1 ECDSA and for some cases BIP-340 Schnorr. That is why Swift projects pull in libsecp256k1 via P256K or via the crypto module inside web3swift and Swift Bitcoin. The Enclave also only supports P-256, so Swift wallets that want hardware protection store a P-256 passkey in the Enclave that authorizes a secp256k1 MPC signing ceremony, as described in Para and FabricKit docs.

Do I need to know Objective-C to learn Swift?

No. Swift is presented in The Swift Programming Language as a standalone language with its own syntax and standard library. The book introduces variables, types, functions, and control flow without assuming Objective-C. Interop exists for calling C and C++ or existing Objective-C frameworks, but it is not required for new wallet apps.

Should I use web3swift or argent web3.swift?

Both are EVM Swift libraries. web3swift has broader feature coverage and more stars and forks, with geth compatible keystore, ABI V2, ENS, and TxPool support. argent web3.swift is lighter and pairs well with specific stack choices and ZKSync Era via zksync2-swift. Many apps start with web3swift for Ethereum mainnet and L2s, then add argent style helpers per contract.

Is Swift hard to learn for Web3?

Ownership and type discipline apply differently than in Rust. Swift optionals and actor isolation are the main hurdles if you come from JavaScript or Python. Many developers report two to four weeks until basic app flows feel comfortable and a few months until wallet state, keystore, and chain sync code feel straightforward. Pair Swift study with one chain SDK so you apply actors to RPC subscriptions right away.

What minimum Swift and OS versions do I need?

Check the SDK you target. web3swift and EvmKit list iOS 13 and Swift 5.5 plus Xcode 12.5. Aptos Swift SDK and swift-solana-kit require Swift 6, Xcode 16, and iOS 17 or macOS 14 due to strict concurrency. Concordium requires iOS 16. Align your Package.swift tools version and your Xcode before you add the dependency.

How does Swift compare to Kotlin for mobile Web3? Both build native wallets. Swift covers iOS and macOS with Secure Enclave and DeviceCheck, Kotlin covers Android with StrongBox and Key Attestation. Cross platform Web3 SDKs like Coinbase CDP, Dynamic, and wallet infra like EvmKit often ship both Swift and Kotlin packages with parallel APIs. If you target both stores, expect to maintain Swift and Kotlin clients that share the same RPC and backend.