Mobile app development is about much more than putting your website into an icon on a home screen. A good app opens instantly, keeps working on a weak signal, sends the right notification at the right moment, passes Apple and Google review on the first try and keeps running after the next iOS and Android release. Getting all of that right takes product thinking, solid frontend engineering and a backend designed for clients that can be offline, outdated or on the other side of the world.
Contents
At CodeWiz we build cross-platform apps with React Native and Flutter, native apps in Swift and Kotlin when the product calls for it, and the APIs, databases and infrastructure behind them. Because we are a full-stack team, the app, the backend and the deployment pipeline are designed together instead of being stitched together by three different vendors.
This service is for startups validating a product, companies that want a customer-facing app next to an existing web shop or platform, and teams that need an internal field app for staff, deliveries or inspections. If you already have an app that crashes, lags or keeps getting rejected in review, we can take it over, stabilise it and move it forward.
React Native & Flutter Apps: One Codebase for iOS and Android
Cross-platform frameworks let one team ship to both stores from a single codebase. For most business apps – catalogues, bookings, loyalty programmes, dashboards, marketplaces, field tools – this is the most cost-effective route, because features, bug fixes and tests are written once.
React Native with Expo
React Native renders real native UI components and is written in TypeScript, so web developers and existing React code can be reused. Since the New Architecture (Fabric renderer, TurboModules and JSI) became the default, the old bridge bottleneck is gone and native modules are faster to call. We build React Native apps on Expo, which gives us EAS Build for cloud builds and signing, EAS Submit for store uploads and EAS Update for over-the-air fixes to the JavaScript layer without waiting for a new store release.
Flutter
Flutter uses Dart and draws every pixel itself with its Impeller rendering engine. That makes the UI look identical on every device and makes heavily animated or custom-branded interfaces easy. Flutter is a strong choice when the design is far from the platform defaults, when you also want desktop or embedded targets, or when your team already knows Dart.
What you get
- A TypeScript or Dart codebase with a clear structure: navigation, state management (Zustand, TanStack Query, Riverpod or Bloc), API layer and design tokens.
- Platform-specific touches where they matter: native share sheets, haptics, biometric login, deep links and widgets.
- Automated tests (Jest, React Native Testing Library, Flutter widget tests, Maestro for end-to-end flows) running in CI.
- Crash reporting and performance monitoring with Sentry or Firebase Crashlytics from the first build.
Native iOS & Android Development With Swift and Kotlin
Native development means two codebases: Swift with SwiftUI on iOS and Kotlin with Jetpack Compose on Android. It costs more, but it is still the right answer in several situations:
- Deep hardware access: Bluetooth Low Energy devices, NFC, background location, camera pipelines, audio processing.
- Platform extensions such as Apple Watch apps, widgets, App Clips, CarPlay, Android Auto or Wear OS.
- Apps where every millisecond of startup time and every frame of animation matter.
- Products where the platform look and feel is a selling point and new OS features should be adopted on day one.
There is also a middle ground: Kotlin Multiplatform shares business logic between iOS and Android while keeping fully native UI, and an existing native app can embed React Native or Flutter screens for new features. We also write native modules for cross-platform apps when no library exists for a specific SDK or device.
Mobile App Development Options Compared
There is no universally best framework. The table below summarises the trade-offs we discuss with clients before writing any code:
| Approach | Language | Code sharing | Performance | Best for | Watch out for |
|---|---|---|---|---|---|
| React Native (Expo) | TypeScript | High, plus reuse of web logic | Near-native for typical business apps | Teams with React skills, apps that evolve quickly | Third-party native libraries vary in quality |
| Flutter | Dart | Very high, including UI | Near-native, smooth custom animations | Strongly branded UI, multiple targets | UI does not follow platform defaults automatically |
| Native (Swift, Kotlin) | Swift, Kotlin | None (two codebases) | Best possible | Hardware-heavy apps, platform extensions | Roughly double the effort for features and tests |
| Kotlin Multiplatform | Kotlin, Swift for iOS UI | Business logic shared | Native UI | Native teams that want less duplication | Smaller ecosystem, iOS tooling still maturing |
| Progressive Web App | JavaScript | Shared with the website | Good, limited device APIs | Content and simple tools without store presence | Limited background features, especially on iOS |
Our default recommendation for a new business app is React Native with Expo, unless the design, the hardware or your existing team points clearly in another direction.
App Store & Google Play Publishing Without Surprises
Many first-time app owners discover too late that publishing is a project of its own. We handle the whole process and set up the accounts in your company’s name, so you own the listing, the signing keys and the reviews.
Apple App Store
- An Apple Developer Program membership (99 USD per year) and, for companies, a D-U-N-S number for the organisation account.
- Privacy nutrition labels, a privacy manifest for apps and SDKs that use sensitive APIs, and in-app account deletion if users can create accounts.
- TestFlight beta testing, then review against the App Store Review Guidelines. Most reviews finish within a day or two; rejections usually concern missing login credentials for reviewers, incomplete features or digital goods sold outside in-app purchase.
Google Play
- A one-time 25 USD developer registration, identity verification and a completed Data safety form.
- New personal developer accounts must run a closed test with at least 12 testers for 14 days before production access; organisation accounts are exempt.
- Android App Bundles signed with Play App Signing, a target API level that Google raises every year, and staged rollouts that start at a small percentage of users.
Store listing and release management
We prepare screenshots for every required device size, keyword-aware descriptions (app store optimisation), localised listings and release notes. CI pushes builds through internal, beta and production tracks with Fastlane or EAS Submit.
Mobile Backends & APIs Designed for Apps
A mobile backend has requirements a website backend often does not. Old app versions stay installed for months, networks drop mid-request and every screen should load with as few round trips as possible. We build mobile backends in Laravel or Node.js on PostgreSQL or MySQL, with Redis for caching and queues.
- Versioned APIs: REST or GraphQL endpoints that stay backwards compatible, plus a minimum-version check that can ask users to update when an old build must be retired.
- Authentication: OAuth 2.0 with PKCE, short-lived access tokens and refresh tokens stored in the iOS Keychain or Android Keystore, plus Sign in with Apple and Google where it helps sign-up.
- Payloads shaped for screens: pagination, field selection and image resizing through a CDN, so a product list does not download desktop-sized photos.
- Protection: rate limiting, request validation and abuse detection – the same principles as in our guide to API rate limiting.
- Payments: Apple and Google in-app purchases for digital goods, and Stripe or PayPal for physical goods and services, following the same practices as our payment gateway integration work.
Firebase or Supabase can speed up an MVP, and we use them when they fit. With complex business rules, existing systems to integrate or strict data residency needs, a custom API is usually cheaper and more flexible over time.
Push Notifications & Offline Sync Users Can Rely On
Push notifications that people keep enabled
Every notification goes through Apple Push Notification service (APNs) on iOS or Firebase Cloud Messaging (FCM) on Android. iOS and, since Android 13, Android both require the user’s permission, so we ask at a meaningful moment instead of on first launch, and consider provisional notifications on iOS. A typical FCM HTTP v1 message carries both a visible notification and data for deep linking:
{
"message": {
"token": "DEVICE_TOKEN",
"notification": { "title": "Order shipped", "body": "Your order #1042 is on its way" },
"data": { "type": "order", "orderId": "1042" },
"android": { "priority": "high", "notification": { "channel_id": "orders" } },
"apns": { "payload": { "aps": { "sound": "default", "badge": 1 } } }
}
}On the backend we store device tokens per user and platform, remove invalid ones automatically, send through a queue so campaigns never block the API, and let users choose categories (orders, messages, promotions).
Offline-first data and sync
Offline support is a design decision, not a library you add at the end. We keep a local database on the device (SQLite through Expo SQLite, op-sqlite or Drift, WatermelonDB, Room or SwiftData) and treat the network as a way to synchronise rather than a requirement to show data. Changes go into an outbox and are sent with idempotency keys, so a retried request never creates duplicates:
async function flushOutbox() {
for (const job of await db.outbox.all()) {
const res = await fetch(`${API_URL}/sync`, {
method: "POST",
headers: { "Content-Type": "application/json", "Idempotency-Key": job.id },
body: JSON.stringify(job.payload),
});
if (res.ok) await db.outbox.remove(job.id);
else if (res.status === 409) await resolveConflict(job, await res.json());
else break;
}
}Conflicts are resolved with rules agreed with you: last write wins for simple fields, server-authoritative for prices and stock, or merge logic for collaborative data. Background sync runs through WorkManager on Android and BGTaskScheduler on iOS, and sync engines such as PowerSync are an option when the data model is large.
Mobile App Security
An app binary is in the hands of every user, including the curious ones. We follow the OWASP Mobile Application Security Verification Standard (MASVS) as a checklist:
- No API secrets in the app bundle – anything shipped in the binary can be extracted, so sensitive operations happen on the server.
- Tokens in secure storage, TLS everywhere and certificate pinning for high-risk apps such as finance or health.
- Play Integrity API and Apple App Attest to make automated abuse of your API harder.
- Obfuscation with R8 on Android, dependency scanning in CI and minimal permissions, each justified in the store listing.
Common Mobile App Mistakes We Fix
- Asking for notification, location and tracking permissions on first launch, before the user sees any value.
- APIs that break old app versions, so users who have not updated suddenly see errors.
- No crash reporting or analytics, so problems are discovered through one-star reviews.
- Signing keys and store accounts owned by a former freelancer instead of the company.
- Loading full-size images and unpaginated lists, which drains battery and mobile data.
- Testing only on the newest flagship phone, never on an older mid-range Android device.
What Drives the Cost of Mobile App Development
We estimate after a short discovery phase rather than quoting from a feature list alone. The main factors are:
- The number of screens, user roles and flows, and how custom the design is.
- Cross-platform or native, and whether tablets, watches or widgets are in scope.
- Whether a backend already exists or has to be built, and which systems (ERP, CRM, payment providers) must be integrated.
- Offline requirements and real-time features such as chat or live tracking.
- Security and compliance needs, and the level of ongoing maintenance after launch.
Apps are never really finished: Apple and Google ship major OS releases every year, and store requirements change with them. We plan maintenance from day one, and our approach to premium development without premium prices keeps it sustainable.
How We Work
- Discovery: we clarify the users, the core flows, the business goals and the systems the app must connect to, and recommend a framework.
- Design and prototype: wireframes and a clickable prototype that you can test on your own phone before development starts.
- Build: development in short iterations with regular TestFlight and Play internal builds, together with the backend and APIs.
- Test: automated tests, end-to-end flows with Maestro and manual testing on real iOS and Android devices, including older models.
- Launch: store listings, review submission and a staged rollout with crash and performance monitoring.
- Support: OS and SDK updates, store requirement changes, new features and over-the-air fixes where allowed.
Why CodeWiz
- App and backend in one team: we build the mobile app, the API, the database and the servers, so nothing gets lost between vendors.
- Honest technology choices: React Native, Flutter, native or even a PWA – we recommend what fits your product, not what we happen to prefer.
- Open-source first: Expo, Laravel, Node.js and PostgreSQL keep you free of lock-in, and you own all code, accounts and keys.
- Performance and security built in: the same team that tunes websites to 100/100 PageSpeed and hardens servers works on your app.
- Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally – read more about CodeWiz.
Frequently Asked Questions
How much does it cost to develop a mobile app?
It depends on the number of features, the design, the backend and the integrations. A focused MVP with a handful of core screens is a very different project from a marketplace with payments, chat and offline mode. We give you a clear estimate after discovery, broken down by feature, so you can decide what goes into the first release.
How long does it take to build an app?
A focused MVP usually takes a few months from discovery to store release, while larger products are delivered in phases. Store review itself is quick, but a new personal Google Play account adds the closed testing period.
Should I choose React Native or Flutter?
Both are mature and production-ready. React Native fits teams with JavaScript or React experience and apps that share logic with a web platform; Flutter fits highly customised, animation-rich interfaces. For most business apps either works well, and we explain the trade-offs for your specific case.
Do I need a native app or is a PWA enough?
If you need store presence, reliable push notifications on iOS, background tasks or device features like Bluetooth, a native or cross-platform app is the better choice. For content and simple tools, a progressive web app can be cheaper and faster to launch.
Who owns the app and the source code?
You do. We publish under your developer accounts, hand over the repository, signing keys and documentation, and you can continue with us or any other team.
Can you take over an existing app?
Yes. We start with a code and infrastructure audit, fix crashes and outdated dependencies, update the app to current store requirements and then continue with new features.
Ready to Build Your Mobile App?
Tell us what your app should do and who will use it, and we will propose the right technology, scope and timeline. Contact us to discuss your idea, or explore all of our development services.