Blog

A user installs Rabby on their iPhone and Android phone to manage the same Ethereum wallet across devices. Both installations show the same balance, both can initiate transactions, and both display transaction previews before signing. Yet beneath that identical interface lies a fundamentally different relationship with the operating system. iOS confines Rabby to a strict sandbox with limited file access, no direct network snooping capability, and mandatory app store review. Android grants deeper system access, allows more flexible data storage patterns, and permits sideloading. Neither approach is automatically more secure, because mobile wallet security depends on what each operating system prevents, what it allows, and what the wallet application itself must protect.

The practical question is not which platform is inherently safer. It is what specific protections each operating system enforces, what permissions Rabby actually requests, how those permissions map to the wallet’s functionality, and what attack surface remains despite those constraints. A user who understands the difference between iOS sandbox limitations and Android’s permission model can make a more informed decision about device placement, backup strategy, and which sensitive operations belong on which platform.

iOS sandbox as a custody boundary

Apple’s sandbox is a process-level isolation mechanism that prevents applications from accessing files, network traffic, camera, microphone, or other device resources without explicit user permission. Rabby running inside that sandbox cannot directly read the file system beyond its allocated container, cannot inspect network packets belonging to other applications, and cannot silently activate the camera or microphone. These constraints are not features the wallet implements; they are enforced by the operating system itself.

The recovery phrase stored in Rabby’s iOS app lives in an encrypted container that only Rabby can decrypt. The operating system does not have a master key that allows Apple, a rogue process, or a compromised application to read that container without the wallet unlocking it. If a user has enabled device encryption and a strong passcode, the vault is further protected by the Secure Enclave, a dedicated cryptographic coprocessor that enforces rate limiting on incorrect unlock attempts. This is substantially different from Android, where system-level malware with elevated privileges might, in certain attack scenarios, traverse the file system and extract stored secrets if adequate encryption is not in place.

However, the iOS sandbox also imposes constraints that Rabby must work around. The wallet cannot directly access an iOS keychain as readily as it might on a desktop application, cannot easily spawn background tasks for continuous monitoring, and cannot maintain persistent network connections in the traditional sense. These limitations are why Rabby’s iOS app relies on Apple’s notification infrastructure and scheduled background activity to check balance changes rather than maintaining an open socket. The user experience consequence is that balance updates may be delayed compared to a desktop application or a browser extension, which operates with fewer sandbox restrictions.

The sandbox model also means that Rabby cannot install additional system-level security monitoring or conduct integrity checks on the operating system itself. If iOS is compromised at the kernel level—a scenario that requires either a zero-day vulnerability or a physical jailbreak—the sandbox is irrelevant. The wallet remains isolated from other user applications, but it is not isolated from a fully compromised device. Users who consider nation-state-level adversaries a realistic threat may conclude that the iOS sandbox provides protection against ordinary theft or casual malware, but not against a device that has been seized and exploited at a deep level.

Android’s permission model and what users actually grant

Android does not isolate applications by default in the same way that iOS does. Instead, it uses an explicit permission system. When Rabby is installed on Android, the system may present a list of requested permissions during installation or the first use. These typically include internet access, reading external storage, and potentially access to device identifiers. The user explicitly grants or denies each permission, and Android then enforces those grants at runtime.

Rabby’s Android app requests internet access because it must connect to Ethereum nodes and various blockchain services to fetch account data, broadcast transactions, and simulate transaction execution. It may request external storage access to facilitate wallet exports or backup imports, though modern Android versions increasingly discourage direct file system access in favor of scoped storage. Location permission is typically not required for Rabby’s core functionality, though it may be requested if the app provides region-specific features or error reporting.

The critical distinction is that Android permissions are not a sandbox. They are a label system that the operating system enforces through SELinux policies and runtime permission checks. A malicious application installed on the same Android device as Rabby cannot, by default, read Rabby’s data directory even if both are granted internet access. However, if a user grants a malicious application permission to read external storage, and if that malicious app then exploits a vulnerability to gain system-level access, the attacker might eventually reach Rabby’s stored data if that data is not encrypted or if the encryption keys are accessible.

The permission model also means that Rabby must actively defend against certain attacks that the operating system does not prevent. On iOS, the system prevents another app from hooking into Rabby’s touch events or displaying a fake unlock screen on top of it. On Android, Rabby must implement its own checks to detect when another application has drawn overlays on the screen, which could be used in a phishing attack. This is why Rabby displays warnings when overlay-capable applications are detected; the wallet is compensating for a permission model that is more permissive than iOS’s default isolation.

Private key storage and encryption differences

Both iOS and Android versions of Rabby encrypt the recovery phrase and private keys before storing them locally. iOS uses the Secure Enclave and the Data Protection framework, which ties encryption keys to the device passcode. The operating system enforces that the encrypted data cannot be accessed until the device is unlocked at least once after boot. This is enforced in hardware.

Android uses a combination of Android Keystore and device encryption. The Android Keystore API allows applications to generate and store keys in a way that they cannot be extracted, even by the application itself. However, the strength of this protection depends on whether the device has a hardware-backed keystore, which is common on modern Android phones but not guaranteed on all devices. Additionally, Android Keystore keys can be extracted if the user has granted certain permissions or if the device is running an older Android version with unpatched vulnerabilities.

The practical implication is that on a modern, fully patched iPhone with a strong passcode, the recovery phrase is protected by multiple layers that are very difficult to compromise without either the user’s cooperation or highly specialized forensic tools. On a modern, fully patched Android phone with hardware-backed keystore support, the protection is comparable, but the implementation details vary more widely across device manufacturers.

Neither platform automatically protects against a user who writes down the recovery phrase and stores it insecurely, forgets the device passcode, or enters it into a fake Rabby app downloaded from an unofficial source. The operating system’s technical protections are irrelevant if the user defeats them through poor operational security. This is why Rabby’s official installation through the legitimate app store, the official website, and careful verification of the application source remains essential on both platforms.

Network isolation and transaction broadcast

When Rabby initiates a transaction on iOS, the app opens a network connection through the normal iOS networking stack. Apple does not inspect the contents of that traffic in real time; instead, it enforces network privacy rules at the system level. If a user has enabled iCloud Private Relay, DNS queries may be routed through Apple’s servers. The wallet itself handles encryption of traffic to the blockchain node or RPC endpoint it is communicating with. iOS provides no mechanism for another app to intercept or eavesdrop on Rabby’s network traffic without either a system-level compromise or a rooted device.

On Android, the situation is more complex. If the device has administrative privileges granted to a security app, a VPN app, or a firewall, those applications can potentially observe Rabby’s network traffic in plaintext if the wallet is not using encrypted transport. Rabby therefore must rely on HTTPS and network encryption as a core control, not as an optional enhancement. This is not a weakness specific to Rabby; it is a consequence of Android’s more permissive permission model. The wallet cannot prevent a privileged system service from observing traffic, so it must ensure that the traffic itself is cryptographically protected.

Neither platform protects against blockchain network observation. When Rabby queries a node for the balance of an Ethereum address, the node operator can see that query and potentially infer that an IP address is interested in that address. If the user is using their ISP’s default DNS resolver, the DNS query itself may be visible. This is why users who want stronger privacy should consider using their own node, a privacy-focused RPC service, or running Rabby through a Tor connection or VPN. The mobile operating system’s networking model influences how practical these options are, but it does not make or break them.

Browser extension versus mobile app threat models

Rabby’s browser extension operates in a different threat environment than the mobile app. The extension runs inside a browser sandbox on a desktop or laptop, where the operating system typically grants more permissions and isolates less strictly than on mobile. A malicious website visited in the browser cannot directly read the extension’s storage because of cross-origin policies, but if the website tricks a user into approving a transaction in Rabby’s popup, the website has achieved its goal without needing to bypass the browser’s isolation.

The browser extension also benefits from the richness of the desktop operating system: it can display more detailed warnings, integrate with hardware wallets, and maintain longer-running connections to blockchain services. Users who want to learn more about the browser extension can find installation instructions here. The desktop environment is typically used for larger transactions or longer interaction sessions, while mobile apps are often used for quick checks and confirmations.

Mobile apps, by contrast, operate in a more restricted context where the user is more likely to be interrupted, the screen is smaller, and notifications may arrive during sensitive operations. The mobile threat model includes the possibility that the device will be lost, stolen, or accessed by someone with physical proximity. This is why Rabby’s iOS app benefits from the Secure Enclave’s PIN rate limiting, and why Rabby’s Android app should integrate with the device’s biometric authentication. The user should enable a lock screen, not rely solely on app-level protections, and understand that mobile devices are inherently more exposed to physical theft than a laptop kept in a secure location.

Jailbreak, rooting, and what “official” really means

An iOS device that has been jailbroken has had its sandbox intentionally compromised by the user or an attacker. Once jailbroken, iOS provides no more protection than a conventional operating system, and arguably less, because some of the security mechanisms are disabled to allow the jailbreak. A user who jailbreaks an iPhone should not trust that Rabby’s recovery phrase is protected by the Secure Enclave anymore.

Similarly, an Android device that has been rooted by a malicious actor or exploited through a vulnerability may have been modified so that applications run with elevated privileges. Rabby has no way to detect whether its own process is running in a compromised environment unless it explicitly checks for known indicators. This is another reason why Rabby’s use of overlay detection is important: it is compensating for the fact that an Android device is not guaranteed to be trustworthy.

The concept of “official” is important because it is the primary mechanism available to reduce the risk of installing a modified version of Rabby. The iOS App Store review process does not prevent all malicious apps, but it does introduce friction and accountability. An attacker who distributes a fake Rabby through the App Store risks detection and removal. On Android, the Google Play Store provides similar review, but Android also allows sideloading from third-party sources. A user who installs Rabby from an unknown APK file or a sketchy third-party store is accepting the risk that the app has been modified to steal recovery phrases.

Users should always install Rabby from the official app store for their device, verify that the publisher matches the legitimate developer, and cross-reference with the official website before entering any recovery phrase or creating a wallet. The browser extension should similarly be verified by checking the publisher and comparing the extension ID with what is listed on the official rabby.io domain.

Backup and recovery: the overlooked permission boundary

Both iOS and Android support cloud backups. iCloud backs up application data, including encrypted wallet data, unless the user explicitly opts out. Google Drive provides similar functionality on Android. These backups are encrypted by the cloud provider, but they do introduce a second custody point. If a user’s iCloud account is compromised, an attacker may be able to restore the wallet backup to a different device and access the funds if they can also bypass the device passcode.

Rabby’s recovery phrase, if written down and stored in cloud notes or a note-taking app that syncs across devices, introduces similar risk. A compromised cloud account or a credential theft attack could expose the recovery phrase. Users who want to minimize cloud exposure should store the recovery phrase on paper, in a physical safe, or in a dedicated offline storage method. Neither iOS nor Android can protect a user who stores the secret in an insecure location, but both operating systems do prevent Rabby itself from accidentally uploading the phrase to the cloud without explicit user action.

The Rabby iOS app respects iOS backup exclusion flags, which means the wallet can be configured to not back up sensitive data to iCloud. However, the wallet must still store something locally to recreate the account on a new device. This is why Rabby displays the recovery phrase during the initial setup: the user can choose to write it down or store it securely. If the user loses both the recovery phrase and the device, the wallet is unrecoverable. This is a security property, not a bug. The operating system’s inability to restore the wallet without the recovery phrase prevents an attacker from restoring a stolen wallet to a new device if they lack the recovery phrase.

Comparing threat models: which platform for which use case

iOS is preferable for users whose primary concern is protection against malware and casual theft. The sandbox prevents a malicious app from directly accessing the recovery phrase, and the Secure Enclave provides hardware-backed protection against brute-force attacks on the device passcode. A user who keeps their iPhone secure, uses a strong passcode, and does not jailbreak it can rely on the operating system to prevent many common attack vectors.

Android is preferable for users who require advanced features such as hardware wallet integration, who want to use alternative app stores or sideload applications, or who run a custom ROM with specific security properties. Android’s permission model requires more active vigilance: a user must be more careful about which permissions they grant, must verify that downloaded APK files are legitimate, and should understand that the operating system is less restrictive by default.

For most users, the choice between iOS and Android for Rabby should be based on which device they already own and which operating system they are most comfortable securing. A user who owns both should consider keeping high-value cryptocurrency on the iOS device, using the Android device for smaller transactions or testing, and storing the recovery phrase completely offline. A user who owns only one device should ensure it is fully patched, enable all available security features, and understand that the operating system’s protections are only effective if the device is not lost or physically compromised.

Future permission models and evolving attack surfaces

iOS continues to introduce stricter privacy controls. Recent versions have added app privacy reports, which show users which permissions each app has used. This transparency is valuable but does not change the fundamental isolation model. Rabby will continue to request internet access because it must communicate with the blockchain, and users should continue to grant that permission because the wallet cannot function without it.

Android is gradually moving toward stricter isolation through features such as hardware-backed keystore support, scoped storage, and Play Integrity API checks. As these features become more standard, the practical differences between Android and iOS are narrowing, though they are unlikely to disappear entirely. The fundamental difference—iOS enforces isolation by default, Android requires active permission management—will likely persist.

The most important evolution is likely to be attestation and verification mechanisms that allow users to confirm they are running unmodified, official versions of Rabby. Both Apple and Google have introduced mechanisms for this, though they are not yet widely integrated into wallet applications. As these tools mature, they will provide a technical foundation for verifying that the app installed on a device is legitimate, which is arguably more important than the operating system’s native permission model.