Supported Wallets - NEAR Connect iOS

NEAR Connect iOS supports all wallets in the near-connect manifest, providing seamless integration with the full NEAR wallet ecosystem.

Wallet Compatibility

All wallets supported by the underlying @hot-labs/near-connect JavaScript library work out of the box—no additional configuration needed.

Wallet	Type	Status	Notes
HOT Wallet	Native app (Telegram)	Tested	Deeplinks to Telegram app
Intear Wallet	Web app	Tested	Opens in-app browser
MyNearWallet	Web app	Tested	Opens in-app browser
Meteor Wallet	Web app	Tested	Opens in-app browser

New wallets added to the near-connect manifest automatically become available without requiring updates to your app or the NEAR Connect iOS library.

Wallet Types

Web Wallets

Web-based wallets are hosted web applications that handle authentication and transaction signing in a browser environment. How they work:

When the user selects a web wallet from the selector, near-connect calls window.open() to create a popup
NEAR Connect iOS intercepts this and creates a new WKWebView popup
The popup loads the wallet’s web interface
After authentication or transaction approval, the wallet redirects back to the bridge page with result data
The popup is automatically closed and removed

Implementation:

func webView(
    _ webView: WKWebView,
    createWebViewWith configuration: WKWebViewConfiguration,
    for navigationAction: WKNavigationAction,
    windowFeatures: WKWindowFeatures
) -> WKWebView? {
    // Override the data store to enable cookies (required by Cloudflare-protected wallets)
    configuration.websiteDataStore = .default()
    
    let popup = WKWebView(frame: webView.bounds, configuration: configuration)
    popup.navigationDelegate = self
    popup.uiDelegate = self
    popup.backgroundColor = .systemBackground
    popup.customUserAgent = "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) ..."
    
    manager.bridgeWebView.addSubview(popup)
    popupWebViews.append(popup)
    return popup
}

Advantages:

No app installation required
Works immediately on any device
Wallet updates don’t require app updates
Universal compatibility across platforms

Considerations:

Requires internet connection
May be subject to Cloudflare or other web protections
User must trust the in-app browser environment

Native App Wallets

Native app wallets are standalone iOS (or cross-platform) applications installed on the user’s device. How they work:

User selects a native wallet from the selector
near-connect generates a deep link URL (e.g., tg://, near://)
NEAR Connect iOS detects the custom URL scheme and opens it with UIApplication.shared.open()
The wallet app launches, shows its native UI, and processes the request
After approval, the wallet redirects back to your app or the web bridge with result data

Implementation:

private func shouldOpenExternally(_ url: URL) -> Bool {
    let scheme = url.scheme?.lowercased() ?? ""
    
    // Non-HTTP schemes open externally (custom deep links)
    if scheme != "http" && scheme != "https" {
        return true
    }
    
    // Known app-link domains that should open native apps
    let externalDomains = ["t.me", "telegram.me"]
    if let host = url.host?.lowercased(),
       externalDomains.contains(where: { host == $0 || host.hasSuffix(".\($0)") }) {
        return true
    }
    
    return false
}

When a custom scheme is detected:

if shouldOpenExternally(url) {
    UIApplication.shared.open(url)  // Launches native app
    return nil
}

Advantages:

Native iOS UI and performance
Can work offline (depending on wallet implementation)
Better integration with device security (biometrics, secure enclave)
More control over UX

Considerations:

User must have the wallet app installed
Deeplink URL schemes must be properly configured
App-to-app communication depends on URL callbacks

Native wallets like HOT (which runs in Telegram) provide the fastest, most seamless experience for users who already have the app installed.

Special Case: HOT Wallet (Telegram)

HOT Wallet is a NEAR wallet built into Telegram as a mini-app. It’s a hybrid approach:

Launched via deep link: https://t.me/... or tg://...
Runs in the Telegram app’s embedded browser
Leverages Telegram’s authentication and security
Returns to your app via callback URL

Flow:

Your App → near-connect selector → User picks HOT
  ↓
Deep link to t.me/hot_wallet
  ↓
Telegram app opens → HOT mini-app loads
  ↓
User approves transaction in Telegram
  ↓
HOT redirects back to bridge page
  ↓
Your app receives result

In code:

let externalDomains = ["t.me", "telegram.me"]
if let host = url.host?.lowercased(),
   externalDomains.contains(where: { host == $0 || host.hasSuffix(".\($0)") }) {
    UIApplication.shared.open(url)  // Opens Telegram
    return true
}

HOT Wallet requires the Telegram app to be installed. If it’s not, the deep link will fail silently or prompt the user to install Telegram from the App Store.

Connecting to Specific Wallets

You can programmatically connect to a specific wallet by ID:

// Connect to a specific wallet
walletManager.connect(walletId: "my-near-wallet")

Common wallet IDs:

"hot-wallet" - HOT Wallet (Telegram)
"my-near-wallet" - MyNearWallet
"meteor-wallet" - Meteor Wallet
"intear-wallet" - Intear Wallet

Use the wallet selector UI for the best user experience. Direct wallet connection is useful for apps that have an exclusive partnership with a specific wallet or want to provide quick-connect buttons.

Wallet Feature Support

Different wallets support different features. NEAR Connect iOS handles feature detection automatically via the near-connect library.

Common Features

All listed wallets support:

✅ Wallet connection - Basic account authentication
✅ NEAR transfers - Sending tokens to other accounts
✅ Smart contract calls - Invoking contract methods
✅ Transaction signing - Signing and broadcasting transactions

Optional Features

Feature	HOT	MyNearWallet	Meteor	Intear
NEP-413 Message Signing	✅	✅	✅	⚠️ Varies
Sign and connect (combined)	✅	⚠️ Varies	⚠️ Varies	⚠️ Varies
NEP-366 Delegate Actions	⚠️ Varies	⚠️ Varies	⚠️ Varies	⚠️ Varies

When a wallet doesn’t support an optional feature like connectAndSignMessage(), NEAR Connect iOS gracefully falls back to basic sign-in without the message signature.

Handling Fallbacks

The library automatically handles cases where a wallet doesn’t support advanced features:

Example: Connect and Sign Message

let result = try await walletManager.connectAndSignMessage(
    message: "Authenticate with MyApp",
    recipient: "myapp.near"
)

if let signedMessage = result.signedMessage {
    print("Wallet supports signInAndSignMessage: \(signedMessage)")
} else {
    print("Wallet only supports basic signIn, no message signature returned")
}

// Either way, result.account is populated
print("Connected account: \(result.account.accountId)")

In NEARWalletManager.handleEvent():

case .signedIn(let accountId, let publicKey, let walletId):
    let account = NEARAccount(accountId: accountId, publicKey: publicKey, walletId: walletId)
    currentAccount = account
    
    // If a signInAndSignMessage continuation is waiting but we got
    // a plain signIn event, still complete it (wallet doesn't support the feature)
    if let cont = signInAndSignMessageContinuation {
        let result = SignInWithMessageResult(
            account: account,
            signedMessage: nil  // No signature available
        )
        cont.resume(returning: result)
        signInAndSignMessageContinuation = nil
    }

Always check for nil on optional result fields and handle both the success and fallback cases in your app’s logic.

Network Support

All wallets support both mainnet and testnet. The network is configured when initializing the manager:

// Mainnet (default)
let walletManager = NEARWalletManager()
walletManager.network = .mainnet

// Testnet
let testnetManager = NEARWalletManager()
testnetManager.network = .testnet

The network setting affects:

Which wallet environments are shown in the selector
Which RPC endpoints are used for queries (rpc.mainnet.near.org vs rpc.testnet.near.org)
Where transactions are broadcast

Changing the network after accounts are connected will disconnect the current session, as wallet sessions are network-specific.

Session Persistence

Connected wallet sessions persist across app launches:

private func saveAccount(_ account: NEARAccount) {
    if let data = try? JSONEncoder().encode(account) {
        userDefaults.set(data, forKey: accountStorageKey)
    }
}

private func loadStoredAccount() {
    guard let data = userDefaults.data(forKey: accountStorageKey),
          let account = try? JSONDecoder().decode(NEARAccount.self, from: data) else {
        return
    }
    currentAccount = account
}

What’s stored:

✅ Account ID (e.g., "user.near")
✅ Public key (if provided by wallet)
✅ Wallet ID (which wallet was used)
❌ Private keys (always remain in the wallet)

NEAR Connect iOS is non-custodial. Your app never has access to private keys—all signing happens inside the wallet, whether web-based or native.

Disconnecting Wallets

Disconnecting works the same for all wallet types:

walletManager.disconnect()

This:

Calls window.nearDisconnect() in the JavaScript bridge
Clears the near-connect session state
Sets currentAccount to nil
Removes the stored account from UserDefaults

Disconnecting doesn’t revoke access keys on the NEAR blockchain—it only clears the local session. Users can revoke access keys from their wallet’s settings if needed.

Adding Custom Wallets

If you’re building a custom NEAR wallet or want to integrate a wallet not in the manifest, you can:

Submit to the near-connect manifest: Open a PR to near-connect-ios repository
Fork and modify: Clone the near-connect library and add your wallet to the manifest locally
Use direct connection: If your wallet follows NEAR wallet standards, use connect(walletId:) with your custom wallet ID

The library is designed to be extensible and automatically picks up new wallets added to the manifest.

Security Considerations

Web Wallets

Run in WKWebView with standard WebKit sandboxing
Use WKWebsiteDataStore.default() to enable cookies (required by some wallets)
Custom user agent to ensure compatibility: Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 ...)
HTTPS-only for production wallets (near-connect enforces this)

Native Wallets

Deep link validation ensures only registered URL schemes are opened
Callback URLs are verified by near-connect before processing
Private keys remain in the native app’s secure storage (Keychain, secure enclave, etc.)

Bridge Security

The persistent WebView only loads the bundle’s local HTML file
JavaScript is loaded from the official near-connect CDN with integrity checks
Message handlers only accept messages from the trusted bridge page
All wallet operations require user approval in the wallet UI

For production apps, always test wallet integration thoroughly on both mainnet and testnet, with both web and native wallet types.

Documentation Index

​Wallet Compatibility

​Wallet Types

​Web Wallets

​Native App Wallets

​Special Case: HOT Wallet (Telegram)

​Connecting to Specific Wallets

​Wallet Feature Support

​Common Features

​Optional Features

​Handling Fallbacks

​Example: Connect and Sign Message

​Network Support

​Session Persistence

​Disconnecting Wallets

​Adding Custom Wallets

​Security Considerations

​Web Wallets

​Native Wallets

​Bridge Security

Wallet Compatibility

Wallet Types

Web Wallets

Native App Wallets

Special Case: HOT Wallet (Telegram)

Connecting to Specific Wallets

Wallet Feature Support

Common Features

Optional Features

Handling Fallbacks

Example: Connect and Sign Message

Network Support

Session Persistence

Disconnecting Wallets

Adding Custom Wallets

Security Considerations

Web Wallets

Native Wallets

Bridge Security