Akande Simpa
Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

The Nigerian market context

Android commands over 80% of the Nigerian mobile market. Most of your users are on Android devices, many running older OS versions on budget hardware with delayed or absent security patches. iOS users are a smaller but typically higher-value segment. This distribution has direct security implications: your Android app will face a wider range of device configurations, OS versions, and hostile environments than your iOS app.

Both platforms need hardening. But the nature and priority of hardening differs significantly. Here is a technical comparison of the security primitives that matter for fintech apps, from our experience running mobile pentests across both platforms.

Credential storage: Keychain vs KeyStore

iOS Keychain

Hardware-backed (Secure Enclave on devices with it). Data encrypted at rest with device-specific keys. Access control includes biometric binding (kSecAccessControlBiometryCurrentSet). Items are isolated per app unless shared via Keychain Access Groups. Encrypted backups protect Keychain items (with kSecAttrAccessibleWhenUnlocked).

Android KeyStore

Hardware-backed on devices with a Trusted Execution Environment (TEE) or Strongbox. Supports setUserAuthenticationRequired(true) for biometric binding. More configuration complexity: developers must manage key aliases, cipher specifications, and authentication validity durations. Not all devices have hardware backing—software fallback exists.

Fintech implication: Both are adequate for production credential storage when used correctly. The iOS Keychain is simpler to use securely. Android KeyStore requires more deliberate configuration but is equally secure on hardware-backed devices. The risk on Android is the fragmentation: some older or budget devices lack hardware backing, meaning keys are stored in software-encrypted containers that are weaker against rooted-device attacks.

Network security defaults

iOS: App Transport Security (ATS)

ATS enforces TLS 1.2+ for all connections by default. Cleartext HTTP is blocked unless explicitly allowed via NSAppTransportSecurity exceptions in Info.plist. Apple's App Review rejects apps with blanket ATS exceptions without justification. This is a strong default that catches insecure configurations before they ship.

Android: Network Security Config

Android's network_security_config.xml provides similar capabilities but is not enforced by default on older API levels. Apps targeting Android 9 (API 28)+ disable cleartext traffic by default, but many Nigerian fintech apps still target lower API levels for device compatibility. Certificate pinning requires explicit configuration on both platforms.

Fintech implication: iOS has the security advantage here. ATS is enforced by the platform and the App Store review process. Android requires developers to create and properly configure the network security config—and we frequently find it missing or misconfigured in Nigerian fintech apps. Always create a restrictive network_security_config.xml that disables cleartext, pins certificates, and restricts trusted CAs.

Code signing and distribution

iOS: mandatory code signing

Every iOS app must be signed with an Apple-issued certificate. Apps can only be installed through the App Store (or TestFlight for testing, enterprise certificates for internal distribution). The App Store review process checks for policy violations. Sideloading is extremely restricted. This makes distributing modified or repackaged apps very difficult.

Android: flexible signing, easier sideloading

Android apps are signed by the developer's own key. APKs can be sideloaded from any source—third-party stores, direct downloads, WhatsApp file sharing. An attacker can decompile an APK, modify it (adding malware, removing security checks), re-sign it with their own key, and distribute the modified version. This is a significant attack vector in Nigeria where sideloaded APKs are common.

Nigerian Context

Repackaged fintech apps on third-party stores

We have observed modified versions of Nigerian fintech apps on third-party APK sites—apps with identical branding but with additional code injected for credential harvesting. These repackaged apps exploit the trust users have in the brand. Android's open distribution model makes this possible. Implement Play Integrity API attestation to detect when your app is running a modified binary, and educate users to install only from Google Play.

Jailbreak vs root detection

Both platforms support compromised-device detection, but the techniques and effectiveness differ:

Root detection (Android)

Check for: su binary in PATH, Magisk presence, SELinux in permissive mode, test keys in system properties, and the ability to execute root commands. Use Google's Play Integrity API for attestation. Challenges: Magisk can hide root from detection (MagiskHide/Shamiko), making root detection an ongoing arms race. Multiple detection methods improve resilience.

Jailbreak detection (iOS)

Check for: Cydia or Sileo app presence, ability to write outside the app sandbox, forked file system paths (/Applications/Cydia.app), and dynamic library injection. Challenges: modern jailbreaks like rootless jailbreaks modify fewer system paths, making detection harder. Combine multiple checks and test against current jailbreak tools.

Fintech implication: Root/jailbreak detection should restrict sensitive operations (fund transfers, profile changes) rather than completely blocking the app. Alert the backend when a compromised device is detected so server-side risk scoring can adjust. Never rely solely on device integrity checks—they can be bypassed. Server-side enforcement of all business rules is the true defence.

Platform-specific attack surfaces

Android-specific risks

Overlay attacks via SYSTEM_ALERT_WINDOW, accessibility service abuse, intent interception from exported components, APK sideloading and repackaging, delayed security patches on budget devices, and clipboard monitoring.

iOS-specific risks

Keychain sharing misconfigurations, URL scheme hijacking (before Universal Links), enterprise certificate abuse for sideloading, Objective-C runtime method swizzling, and pasteboard data leakage to other apps in the same pasteboard namespace.

Shipping on both platforms? Our mobile pentest covers Android and iOS with platform-specific attack scenarios tailored to fintech applications.

Book a Cross-Platform Pentest

Practical recommendations for CTOs

Do not treat both platforms identically. Your Android app needs more defensive hardening because of the open ecosystem. Specifically:

Both platforms can be made secure for financial applications. Neither is secure by default. The difference is in where you invest your hardening effort and which platform-specific attacks you defend against. Use the mobile app pentest checklist as your starting framework for both.

Related reading

Blog: Certificate Pinning Guide · Securing Flutter & React Native Apps · Reverse Engineering Android Apps

Guides: Mobile App Pentest Nigeria · OWASP for Fintech · Fintech Security Checklist

Services: Penetration Testing · Authentication Security · Secure Architecture Review

Frequently asked questions

{faqs.map((faq) => (
{faq.q}

{faq.a}

))}