Scroll through Nigerian tech Twitter and you would think everyone is on an iPhone. Walk through an actual market in Alaba or Computer Village and the picture looks different. Android dominates the Nigerian smartphone market by a wide margin, across a huge range of prices and specifications. When a client comes to us wanting to reach ordinary Nigerian users at scale, not just a wealthy niche, the mobile strategy almost always starts with Android, and that single decision quietly shapes everything downstream.
Android in Nigeria means real fragmentation, not a footnote in a slide deck
"Support Android" sounds simple until you see the actual spread of devices our users carry: different screen sizes, different amounts of RAM, different Android versions, some phones with barely any free storage left. Building Android first forces us to confront that fragmentation honestly from day one, instead of discovering it later through a wave of confusing bug reports. We maintain a real device lab with a mix of budget and mid range phones, because a simulator on a developer's machine will never tell you the whole truth about how an app actually performs in someone's pocket.
We optimise for install size before we optimise for features
On a phone with limited storage, every megabyte an app requests is a small negotiation with the user. Do they delete old photos, or do they delete your app. We take that negotiation seriously from the architecture stage, trimming unused dependencies, compressing assets aggressively, and loading heavier features only when a user actually needs them rather than bundling everything into the initial install. A lean app is not just good engineering hygiene here, it is a genuine reason people keep an app instead of uninstalling it during their next storage clearout.
"On a budget Android phone, storage is not unlimited shelf space, it is a small room somebody is constantly rearranging. Respect that."
Offline-first is not a nice extra, it is the default assumption
Building Android first, for this market, means designing for intermittent connectivity as the normal condition, not the exception. Data gets cached locally so key screens still show something useful when the network briefly disappears. Actions the user takes while offline get queued and synced properly once connectivity returns, instead of silently failing. This mindset shift, treating a stable connection as a bonus rather than a guarantee, changes decisions throughout the entire build, not just in one settings screen somewhere.
Flutter is what makes this sequencing affordable
None of this Android-first thinking would be practical if it meant maintaining two completely separate codebases. Most of our mobile work is built in Flutter and Dart, one codebase that ships to Android and iOS from the same source, which is what lets us validate hard on Android first without quietly falling behind on iOS while we do it. For specific client requirements, an existing React Native codebase we are inheriting, a JavaScript-heavy team on the client side, we will reach for React Native instead. The framework serves the strategy, never the other way round.
iOS still matters, it just does not lead
None of this means we ignore iOS. Diaspora users, enterprise clients, and a genuinely significant segment of the Nigerian market use iPhones, and a serious product needs to serve them well too. What changes is sequencing. We validate the core experience against Android's harder constraints first, because a product that works well there tends to work beautifully on iOS afterward, while the reverse is rarely true. Building for the toughest conditions first, and letting the easier platform benefit from those lessons, has consistently given us stronger, more resilient products on both sides.