Android and iOS apps, built in Lahore and released to both stores

Zoftaa is a small mobile app development company in Pakistan, based in Lahore and fully remote. We build Android and iOS apps, usually from one Flutter codebase with native Swift or Kotlin where a feature needs it, and we take them through signing, store review and release. The engineers on your first call are the ones who write the code.

What we build

A project runs from the first screen to a live store listing and can cover:

• The app for Android and iOS, phones first, tablets when your users need them.
• The backend: sign-in, a database, file storage, push notifications and a web admin panel for your staff.
• Payments: subscriptions and in-app purchases through both stores, or ads if the app is free to use.
• AI features such as chat or summaries, called through your own backend so API keys never ship inside the app (see AI chatbots and LLM features).
• Analytics and crash reports, set up before launch.
• The store release: listings, privacy forms, review and a staged rollout.

Three examples of scope. They are illustrations, not past projects:

• A booking app for a salon or a tutoring centre: customers pick a slot and get a reminder, staff see the day in an admin panel.
• A delivery app for a logistics team: drivers log each drop with a photo, and the app works without signal and syncs later.
• A subscription content app with a free tier, a paywall and restore purchases.

Who it's for

This is for founders, product managers and small business owners in the US, the UK, Europe and the Gulf who want a small team abroad, a fixed plan and progress they can see every week.

It also fits teams whose app is already built, by a freelancer who moved on or with an AI app builder, and now has to pass store review. And it fits Pakistani businesses looking for an app development company in Lahore: shops, restaurants, schools and logistics firms get the same written plan and handover as anyone else.

Still testing the idea? See MVP development for a smaller first version.

How a project runs

1. Scope call. One call to understand the problem and check that we're the right team. Come with three answers: who will use the app, the one job it must do well, and any deadline.
2. Fixed written plan. Before any code: milestones, price and dates in writing, plus the screens and features, what is out of scope, and which store and cloud accounts are needed.
3. Weekly builds you can try. Every week there's a version to install on your own phone, through TestFlight on iPhone and a Google Play testing track on Android, so changes stay small and cheap.
4. Release and handover. We take the app through store review and a staged rollout, then hand over the code, accounts and keys with documentation: how to build the app, ship an update and run each service.

Launch and store setup for an app you already have

Launch and store setup is our app store submission service for an app that already exists, whoever built it. We handle signing, store listings, review and release on the App Store and Google Play.

• Signing: Android upload keys and Play App Signing, iOS certificates and provisioning profiles, all handed back to you.
• Listings and forms: descriptions, screenshots and the privacy policy link, Google Play's Data safety and content rating forms, and Apple's privacy details and age rating.
• Current rules (checked 1 November 2026): since 31 August 2026, new apps and updates on Google Play must target Android 16, API level 36 (target API requirements). If users can create an account, both stores require a way to delete it inside the app, and Google also wants a web link for deletion requests (Google Play, Apple guideline 5.1.1(v)).
• Review and release: answering reviewers, fixing what they flag, then a staged rollout to a small share of users first.

Review is where many first releases stall. Apple rejected 2,093,244 of the 9,100,620 submissions it reviewed in 2025, about 23% (App Store Transparency Report 2025), and says that on average over 40% of unresolved issues fall under guideline 2.1, App Completeness: crashes, placeholder content and incomplete information (App Review).

Lessons from apps we've shipped to Google Play:

• Google Sign-In can work in the builds you install yourself and fail in the copy users get from Play. Google re-signs your app with its own key, so you "must register the Google-held app signing key fingerprint with your API providers" (Play App Signing). The upload key on your laptop isn't enough. We add Google's fingerprint to Firebase before the first build goes out on a Play testing track.
• The Data safety form has to cover what the SDKs do. Google says the form must include data collected through third-party SDKs, and only a service provider processing data on your instructions is exempt from counting as sharing (Data safety). In our apps with ads, the ads SDK's data is declared as shared as well as collected. We fill the form from the code, and the privacy policy names the same services.
• Reviewers need a way in. Google Play asks you to "provide all required details to enable access to your app" when it sits behind a login (App access), and Apple asks for "demo account info (and turn on your back-end service!)" (guideline 2.1). We give reviewers a working demo account, or a guest mode that opens every feature, and keep the backend running during review.
• The listing must describe the build in review. We write it from the build itself and leave the roadmap out. A listing that names features or content the live app doesn't have gets flagged.

If your app is a website inside an app shell, Apple expects "features, content, and UI that elevate it beyond a repackaged website" (guideline 4.2). We'll tell you on the scope call if it needs native features first.

What you own

You own the code, the store accounts and the cloud accounts from day one:

• The code sits in a Git repository in your account, and we push to it as we work.
• Your Google Play Console and Apple Developer Program accounts are in your name, with us invited as users, so the app is published under your name.
• Firebase, Supabase or AWS projects are created in your account, and the bills go to you.
• The Android upload key, Apple certificates and API keys are handed over with a note on where each one is used, plus documentation another team could pick up.

If an Android upload key is lost, Google lets you request a reset from inside Play Console (Play App Signing). An app in someone else's developer account is harder to get back: on Google Play it moves only when that account sends a transfer request to yours (app transfers).

Stack and tools

The written plan names the stack and the reason for each choice.

• Cross-platform: Flutter is our default for Android and iOS from one codebase (what some agencies call a hybrid app); how we build with Flutter explains when it fits. React Native when your team already works in React.
• Native: Kotlin on Android and Swift on iOS for the parts that need the platform directly. In our own builds, a video editor needed Kotlin and Android's Media3 library. Low-latency audio for a playable keyboard didn't: it stayed in Flutter on the flutter_soloud package.
• Backend: Firebase (sign-in, Firestore, Remote Config, Crashlytics) or Supabase on PostgreSQL. Custom APIs in Node.js, or Python with FastAPI, hosted on AWS or Cloudflare, with Docker where it helps.
• Admin panels in React or Next.js. A web product of its own belongs with web development.
• RevenueCat for subscriptions, AdMob for ads, and the OpenAI and Claude APIs for AI, called from the backend.

Timelines

These are the ranges we plan around; your written plan gives real dates.

What moves the dates:

• Scope: screens and user roles. A customer app plus a staff app is two apps.
• Backend: building on an existing API is quicker than writing one.
• Integrations: payment providers, maps and other third-party APIs each add testing time.
• Design: finished designs save time; if we design the screens, the plan includes it.
• Decisions: a week waiting for feedback adds a week to the plan.
• Accounts: an organisation account needs a D-U-N-S number on both stores. Apple says to allow up to 5 business days to get the number and up to 2 more before you can enrol (Apple D-U-N-S help).

On Google Play, personal accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in for 14 days in a row before applying for production, and that review "usually takes seven days or less" (Google Play testing requirements). That's at least three weeks from the first closed test build to a public listing. Apple is quicker: it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 (App Review). Both checked 1 November 2026.

Working with us from abroad

Outsourcing app development to Pakistan means a time difference. Pakistan Standard Time is UTC+5 all year, with no daylight saving (Pakistan Standard Time). Our hours are Monday to Friday, 10am to 7pm PKT, which is 05:00 to 14:00 UTC. Against a 9am to 5pm day:

For US clients we also take calls from 6pm to 10pm PKT (13:00 to 17:00 UTC), Monday to Friday. In New York that's 8am to 12pm in winter (EST) and 9am to 1pm in summer (EDT). In San Francisco it's 5am to 9am in winter (PST) and 6am to 10am in summer (PDT), so West Coast calls come early in your day.

Wherever you are, you get a build to try and a call each week, with written updates in between. Email or WhatsApp us and we usually reply within one business day. The work runs under a separate written agreement setting out scope, price and terms, as our terms say.

When we're not the right fit

• Games built on Unity or Unreal. We don't work in game engines.
• A large team, fast. We stay small on purpose; if you need ten engineers next month, we're the wrong size.
• Formal certifications. We hold no security or compliance certifications; if your procurement requires one, choose a vendor that does.
• Night and weekend cover. We work Monday to Friday, 10am to 7pm PKT.
• When a website would do. If users open it once a month and never need push notifications or the camera, a mobile-friendly web app may be cheaper. We'll say so on the call.

Frequently asked questions

How much does a developer account cost from Pakistan?

Google Play charges a one-time US$25 registration fee, paid by credit or debit card. Google says it "does not accept prepaid cards" and that "card acceptance varies by location" (Google Play), so check that your card works for international online payments first. Pakistan is a supported location for developer and merchant registration, and developers there are paid in USD or EUR (supported locations). The Apple Developer Program is 99 USD per membership year; Apple says prices may vary by region and are shown in local currency when you enrol (Apple enrolment). Fees checked 1 November 2026.

Whose name does the app go out under?

Yours. On an Apple individual account, your legal name is shown as the seller (Apple enrolment). To show a company name, Apple needs a legal entity with a D-U-N-S number and does not accept "DBAs, fictitious business names, trade names, or branches". Google Play also requires a D-U-N-S number for an organisation account, and getting one is free (Google Play). If your company isn't registered yet, we'll go through the choices on the scope call.

How much will my app cost?

We don't publish a price list, because the same brief can be a 6 week build or a 16 week one depending on the backend, payments and user roles. After the scope call you get a fixed price and dates in writing, before any code.

Can you take over an app someone else started?

Yes, if you can give us the source code and access to the store accounts. We build the app from the repository and read the code first; then the written plan says what we'd keep, what we'd fix and what it costs.

What happens after launch?

You have the code, keys and documentation, so any team can carry on. If you want us to keep shipping updates, the product retainer keeps the same engineers on your app every month. Plan for updates either way: store rules change, and Google Play raised its required target API level again on 31 August 2026.

Tell us about your app on the contact page. A few lines is enough: what it should do, who uses it and any deadline. An engineer will reply, usually within one business day.