Mobile App Development: Android and iOS App Developer

What does mobile app development with me cover?

It covers four things, delivered by one person: the app for both stores, the API behind it, the admin panel your staff use and the publishing work. The quote prices each one separately. How a project runs day to day is explained on how I work.

What mobile apps are you building now?

I am currently building Android and iOS apps for Marmaids LLC, where I work as a freelance developer. For the same company I have built the API the apps talk to, a CRM and a WHMCS module, so the apps, the back office and the billing system share one set of data. The work is ongoing. The apps are the client's, so I do not publish their screens or internals here.

What does cross-platform mean, and when is a native app the better choice?

Cross-platform means one codebase produces both the Android app and the iPhone app, instead of two apps written separately. Flutter (Google's toolkit, written in Dart) draws its own interface. React Native (from Meta, written in JavaScript or TypeScript) drives the platform's own interface components. Both end up as real apps installed from the stores, not websites in a wrapper.

Some features stay native even in a cross-platform app. Home-screen widgets, an Apple Watch companion and similar system extensions are written in Swift or Kotlin and attached to the shared code, and I quote them as separate items. If the whole product leans on them, I say so before you commit.

Why does an app need a backend and an admin panel?

Because the app on the phone is only the screen. Accounts, orders, prices and rules live on a server that both platforms share. That backend and its admin panel are often as much work as the app, and a quote that leaves them out will grow later.

I build the API in Laravel or NestJS, the same tools I use for SaaS products. Two decisions go in on the first day:

• Versioned routes. Paths start with /api/v1, because old app versions stay on customers' phones for months and must keep working. A minimum-version check lets the server tell an outdated app to update.
• Token login. The app keeps a revocable token in the phone's secure storage (Keychain on iOS, Keystore on Android), never a password.

The admin panel lets staff look up a customer, edit content, refund an order and send notifications without calling a developer. Where the business already runs on a CRM, the API reads from it instead of keeping a second copy of every record.

How do push notifications work on Android and iOS?

Your server hands each message to Google's or Apple's delivery service, which passes it to the phone. On Android that service is Firebase Cloud Messaging (FCM). On iOS it is Apple Push Notification service (APNs), usually reached through FCM with an APNs key file (.p8) from your Apple developer account.

The user has to agree first: iOS asks for permission, and recent Android versions do too through POST_NOTIFICATIONS, so some users never receive a push. Every phone also has a device token that changes over time, so the backend stores tokens per user and removes dead ones. I ask for permission after a first order, not on the opening screen.

Do I have to use in-app purchase, or can I take payments with Stripe or Razorpay?

That depends on what you sell, and the stores decide, not the developer. As a general rule, digital goods used inside the app, such as subscriptions, premium features or downloadable content, go through Apple's and Google's own in-app purchase systems. Physical goods and services used outside the app, such as products you ship, rides, hotel stays or tickets, are paid through an ordinary processor like Stripe or Razorpay.

• Both stores keep a commission on in-app purchases, which belongs in your pricing.
• For in-app purchases, the backend confirms each transaction with Apple or Google, server to server, and follows their renewal and refund notifications before it grants or removes access.
• For Stripe or Razorpay, a paid order is confirmed by the provider's signed webhook event, not by the screen the customer returns to.

The rules have exceptions by country and by app category, and they change. I check the current store guidelines for your case during scoping and write the result into the quote.

What do Apple and Google need before an app can be published?

They need a developer account in your name, a signed build, a complete store listing and honest privacy answers, and then they review the app. I prepare this checklist with you:

1. Developer accounts. You enroll in the Apple Developer Program and register a Google Play Console account as the legal owner. Company enrollment involves identity checks and a D-U-N-S number, which can take days, so start early.
2. App identifier. A bundle ID and application ID such as com.yourcompany.app. It cannot be changed after release.
3. Signed builds. An Android App Bundle (.aab) for Google Play and an iOS build compiled with Xcode on a Mac.
4. Privacy details. A public privacy policy URL, Apple's App Privacy answers, Google's Data safety form, and a purpose text for every permission, for example NSCameraUsageDescription in Info.plist.
5. Reviewer access and account deletion. A demo login for the reviewer, and a way for users to delete their account if the app lets them create one.
6. Test release. TestFlight on iOS and a testing track on Google Play. Google may ask a new personal account to run a closed test before it grants production access.

Who owns the code, the store accounts and the signing keys?

You do. You open the Apple and Google developer accounts in your name or your company's, and I work inside them as an invited user whose access you can remove. I do not publish client apps under my own account, because whoever holds the account controls the app, its updates and its income.

At handover you receive the source repository, the Android upload keystore with its passwords, the Firebase project, the API credentials and written release steps. Rights to the custom code are spelled out in the quote before work begins.

Which apps will I not build?

I decline apps that copy someone else's product or that are designed to get around store rules.

• Clones of another company's app: its name, screens, icons or content.
• Apps that hide their real function from reviewers, or that collect contacts, location or messages without telling the user why.
• Fake reviews, paid ratings or bought installs.
• A website wrapped in a web view and submitted as an app. Apple tends to reject these, and a good mobile site does the job better. See business website development.

I also do not promise approval dates, download numbers or a position in store search. Apple, Google and your own marketing decide those.

How do I hire an app developer for my project?

The first step is the free scoping call, which takes about 30 minutes. The written quote follows within one business day, as a fixed price per scope or at $55 to $65 per hour while the size is still unknown. Bring three things: who the app is for, the three screens they will use most, and how you expect to be paid. When you are ready, send me the brief.