An app that works on the phones your users own, not just the one on your desk

No team can test every phone, so the first decision is which ones. We build a matrix from your audience, not from the newest releases. If you already have analytics, we read the top devices and OS versions from it. If you are launching, we use public market data for Saudi Arabia, where Android and iOS both carry large shares and mid-range Android phones are common.

A good matrix mixes recent flagship phones, a few older or budget models, at least one small screen, one tablet where relevant, and the oldest OS versions you promise to support. Each row costs testing time, so we trade breadth against depth openly. Typical coverage is 8 to 12 devices for a first release.

We combine real devices with emulators. Emulators are fast for early checks and layout at many screen sizes. Real devices are essential for camera, location, biometrics, push notifications, performance and anything touching hardware. The decision you own is the minimum supported OS version, which affects both testing cost and the share of users you reach.

Beyond the happy path, mobile has failure modes that web does not. A phone call arrives mid-payment. The user switches apps and returns an hour later. Permissions are denied, then granted. The device rotates. Storage is full. Battery saver throttles background work. We script these interruptions deliberately, because customers create them constantly.

Network behavior gets its own pass. We throttle to slow mobile speeds, drop the connection mid-request and go offline to check what the user sees and whether data survives. The worst bugs here are silent: a duplicate order after a retry, or a payment taken but never confirmed in the app.

Install and upgrade paths matter too. We test fresh installs, upgrades from earlier versions with saved data, and reinstalls. Many crashes appear only when old local data meets a new version. Push notifications are checked for delivery, correct deep links and permission prompts on both platforms. Accessibility checks cover text scaling, contrast and screen reader labels, which store reviewers and users both notice.

Arabic quality is a competitive point in Saudi Arabia. We test mirrored layouts, navigation direction, Arabic keyboard behavior, numerals, Hijri and Gregorian dates, and mixed Arabic and English strings such as product names inside an Arabic sentence. We also check that long Arabic text does not overflow buttons and that the keyboard never hides the field.

Payment flows are tested end to end in your gateway's sandbox: mada, Apple Pay, cards and any installment provider. We cover declined cards, timeouts, 3-D Secure steps, cancelled payments and returning from the bank app. Where the app handles personal data we check consent screens and data handling against the Saudi Personal Data Protection Law.

Finally we review store readiness. Apple and Google publish review guidelines covering privacy disclosures, permission explanations, account deletion, in-app purchase rules and metadata. We check your build and listing against them before submission. A typical engagement is 2 to 3 weeks for a first release, with shorter regression cycles on later updates.