Skip to content
Farhad Nazir

Flutter mobile apps for Android and iOS, built and shipped

I build mobile apps in Flutter, one Dart codebase for Android and iOS, together with the server they depend on. That covers sign-in, payments, chat, calls, push notifications, offline storage and the store submissions at the end.

Apps I have built or rebuilt and released include Estasher, an Arabic-first marketplace for engineering consultations in Saudi Arabia that I took over and rebuilt and that is live on the App Store and Google Play, Asaan Optics for optical shops on Google Play, and GeoPrints, a private travel journal on Google Play that keeps all of its data on the phone. I was also the main developer of the Flutter app for KAYANAK's customers and marketers.

What the service includes

  • Android and iOS from one codebase

    One Flutter project that produces native builds for both stores, so every change ships to both platforms.

  • Backend and API

    A server for identity, payments, files and push notifications, or integration with your existing API. For Estasher I wrote a new PHP and MySQL API that the app now runs on.

  • Offline-first storage

    Local databases such as SQLite, Isar and Hive, plus sync queues, so the app keeps working on a weak connection.

  • Chat and calls

    In-app chat with voice notes and file sharing, and voice and video calls with native ringing on Android, as built for Estasher.

  • Arabic and English

    Arabic-first layouts, Arabic fonts and right-to-left support, with light and dark themes.

  • Device features

    Camera, barcode and QR scanning, on-device text recognition, location, local notifications and home-screen widgets.

  • Store release and compliance

    App Store and Google Play listings, automated builds, in-app account deletion and the privacy details the stores review.

Problems it solves

Two codebases for two platforms
Separate Android and iOS apps double the work for every change. Flutter keeps one codebase while still producing a native build for each store.
An app that stops when the network drops
Shop counters and people on the move often have weak connections. Local storage and sync queues let them keep working and catch up later.
Taking over an app that is not ready for launch
Projects sometimes arrive half-built. On Estasher I replaced the backend, rebuilt sign-in, payments, uploads, notifications and calls, and redesigned the app before the client's launch date.
Payments decided by the phone
If the app decides that an order is paid, that decision can be manipulated. Payments are verified on the server, and only the server marks an order as paid.
Store rejections and release friction
Store reviews check privacy, permissions and account deletion. I build those in from the start and automate builds so releases become routine.

How I approach it

I keep trust on the server. The phone handles the interface and local data, while the server owns identity, money and anything that has to be verified. On Estasher the app writes bookings under strict database rules, and only the server API can mark an order paid or a commission settled.

I design for the connection the user actually has. Asaan Optics queues every write with an idempotency key, so sales made offline sync later without duplicates. GeoPrints has no server at all: its location timeline lives in an on-device Isar database and leaves the phone only when the user exports it.

Release work is part of the job. I set up automated builds with GitHub Actions and fastlane, so Estasher's iOS builds reach TestFlight without a manual step, and I handle store listings, permissions and account deletion so reviews go smoothly.

Technologies I use for this

  • Flutter
  • Dart
  • Android
  • iOS
  • Firebase
  • SQLite
  • PHP
  • MySQL
  • Laravel
  • Node.js

Typical stages

  1. Stage 1

    Scope and user flows

    Who uses the app, the main journeys for each role and what the first store release must include.

  2. Stage 2

    Backend and data design

    What lives on the phone, what lives on the server, and how sign-in, payments and notifications work.

  3. Stage 3

    Design and build

    Screens built on a shared design system, tested on real Android and iOS devices as features arrive.

  4. Stage 4

    Store preparation

    Listings, screenshots, privacy details, permissions and test builds through TestFlight and Google Play testing tracks.

  5. Stage 5

    Release and updates

    Submission under your developer accounts, then regular updates based on feedback and crash reports.

Related work

Estasher store graphic reading 'Engineering experts, verified' beside two phones showing the engineers home screen and an Arabic chat

Engineering consultation marketplace app

Estasher

A bilingual iOS and Android marketplace where clients in Saudi Arabia book consultations and request offers from verified engineers and engineering offices.

  • Mobile app
  • SaaS product
  • Business system
  • Web application
Asaan Optics Desktop Stock Control Center showing stock value at cost and retail, potential profit, stock by category, last 30 days of sales and low-stock alerts

Optical shop management SaaS

Asaan Optics

Optical shop software for Android and Windows: prescriptions, counter sales, stock and staff shifts on one shared shop account.

  • SaaS product
  • Mobile app
  • Desktop app
  • Business system
GeoPrints Google Play feature graphic with the app icon and three phone screens: Today's Journal, Map Explorer and History calendar

Private location journal for Android

GeoPrints

An Android travel diary that automatically logs your stays, routes and photos, with all location history kept on your phone.

  • Mobile app

Frequently asked questions

Does Farhad develop Flutter mobile applications?

Yes. Flutter is Farhad's main tool for mobile apps. His Flutter work includes Estasher, live on the App Store and Google Play, Asaan Optics on Google Play, and GeoPrints, a privacy-first travel journal for Android.

Can you build both Android and iOS apps?

Yes, from one Flutter codebase. Estasher is published on both the App Store and Google Play, and its iOS builds are sent to TestFlight automatically from CI.

Can the app support Arabic and right-to-left layouts?

Yes. Estasher is Arabic-first, with Arabic and English, an Arabic typeface and light and dark themes. Asaan Optics ships in nine languages including Arabic, and Arab Expat, an app still in development, supports English, Arabic and Urdu with right-to-left layouts.

Will you also build the backend?

Usually, yes. Most apps need a server for sign-in, payments, files and notifications. I have written app backends in PHP, Laravel and Node.js, and I can also connect the app to an API you already have.

Can you take over an existing app?

Yes. I took over Estasher in October 2026, replaced its backend, rebuilt the core features and redesigned the app before the client's launch date. I start with a review of the code, accounts and infrastructure so we know what to keep and what to replace.

Do you publish the app to the stores?

Yes. I prepare the listings, permissions, privacy details and account deletion, then submit to Google Play and the App Store under your developer accounts. Review times are set by Apple and Google, so I plan releases around them.

Have a software idea or a business process that needs a proper system?

Tell me what you are trying to fix. I will reply with honest questions, a practical plan and a realistic estimate.