Mobile Software
Systems
We build custom iOS and Android apps for your business, from customer apps to field team and dealer ordering apps. We choose the technology with clear reasoning, set up the backend and admin panel, and publish the app under store accounts opened in your name.
Same screen, two different routes
Native development means separate code for iOS and Android; cross-platform runs one codebase on both. Watch the screen being built both ways.
↳ Switch the approach; as lines are written, the screen builds on both phones.
iOS · Swift
NavigationStack {OrderCard(order)List(items) { Row($0) }Toggle(title, isOn: $on)
Android · Kotlin
Scaffold(topBar = { TopAppBar() }) {OrderCard(order)LazyColumn { items(items) }Switch(checked = on)
iOS
Android
- Two codebases, two teams or twice the workload
- Direct access to platform APIs and the newest features
- Strong choice for heavy graphics, camera or hardware work
Native development
Swift for iOS, Kotlin for Android. The choice for apps that rely heavily on device features such as the camera, Bluetooth or background location.
Cross-platform: React Native / Flutter
iOS and Android apps from a single codebase. For most business apps, this reduces the development and maintenance workload.
Backend and admin panel
The API the app pulls data from, user management and a web panel where you update content. It can connect to your existing ERP, CRM or website.
Notifications
Push notifications via Apple (APNs) and Firebase (FCM): order status, appointment reminders, campaign announcements by user group.
Offline mode
For field teams: filling in forms, adding photos and saving records without internet, then syncing with the server under conflict rules once a connection returns.
Payments
Payment providers such as iyzico/PayTR for physical goods and services; App Store and Google Play in-app purchases for digital content and subscriptions, as store rules require.
Sign-in and account management
Sign-in with email, phone (SMS code), Google and Apple. As store rules require, users can also delete their account from within the app.
Analytics and crash reporting
Tools such as Firebase Analytics and Crashlytics show which screens are used and why the app closed on which device.
Security and KVKK
Token-based sessions, encrypted storage of sensitive data on the device, HTTPS; correctly completed App Store privacy labels and Google Play data safety form, in line with KVKK (Turkey's Personal Data Protection Law).
Native, cross-platform or web app
The right technology depends on what the app will do, the budget and the long-term maintenance plan.
React Native / Flutter
For most business appsFrameworks that produce both iOS and Android apps from one codebase.
Pros
- Lower development and maintenance workload
- New releases on both platforms at once
- Sufficient performance for business apps
Watch out for
- Some device features may need native modules
- Libraries in use must be kept up to date
Best suited for
Most ordering, booking, field form, dealer and internal apps.
Which app does which job
Customer app
Restaurant orders, hotel and clinic bookings, loyalty cards, campaign notifications. A good fit for things customers do again and again; for one-off information, a website is usually enough.
Publishing on the App Store and Google Play
Getting an app into the stores properly takes time, just like building it. We put these steps into the project timeline from the start.
Apple Developer Program (annual fee; a company account requires a D-U-N-S number) and Google Play Console (one-time registration fee). Accounts are opened in your company's name and we're added as team members. Newly opened personal Google Play accounts must run a closed test before release, so we recommend an organization account.
What drives budget and timeline
Toggle the factors; each one adds a layer to the app. No figures, just how the work grows.
- Core app
- Number of screens and roles
- Backend needs
How a mobile app
is developed
Scope and technology choice
First-release features, user roles and the systems to connect to are defined; the native vs. cross-platform decision is made with clear reasoning.
Design and prototype
Flows and screens are designed and approved with a prototype you can try on your phone.
Development and test builds
The app and backend are built in stages; interim builds are distributed to your team via TestFlight and Google Play testing tracks.
Store release and maintenance
Store listings and privacy declarations are prepared and the review process is handled; after launch, we monitor crashes and ship version updates.
Work planned alongside the app
Frequently Asked
Questions
For most business apps (ordering, booking, field forms, dealer apps), a single React Native or Flutter codebase delivers enough performance and makes maintenance easier. If you need heavy graphics, advanced camera/AR, continuous background location or deep hardware integration, native development may be the better choice. We write the decision and our reasoning into the scope document.
Your company's. The Apple Developer Program has an annual fee and a company account requires a D-U-N-S number; Google Play Console is opened with a one-time registration fee. The app is published under your account and we're added as team members. That way, even if you change teams in the future, the app and your users stay with you.
Yes, rejections are especially common in Apple's review. Typical reasons: no working demo account provided for review, a missing privacy policy, no option to delete the account, unfinished features, or an app that looks like a copy of the website. We go through these points with a checklist before release, and if a rejection comes, we fix the issue based on the reason given and resubmit.
For physical goods and services (food orders, appointments, products), payment providers such as iyzico and PayTR can be used. For digital content, memberships or subscriptions, the stores require their own in-app purchase systems and commissions. We'll assess together which applies to you based on your business model.
Depending on your needs. If you have an existing system and API, the app connects to it. If not, we also build the server side and a web-based admin panel for user, content and order management; the server account is again opened in your name.
How the source code is delivered and the usage rights are set out clearly in the contract. We recommend that code developed specifically for the project is delivered at the end into a repository you own (e.g. GitHub, GitLab).
Apple and Google release new operating system versions every year, and after a certain date the stores require a new SDK/target API level; apps that aren't updated may stop being shown to new users. Library updates, bug fixes and user feedback also need regular work. That's why we plan maintenance as part of the project budget.
It depends on the number of screens and roles, whether a backend is needed, the integrations and the store review process. We generally recommend releasing a first version with the core features, then adding the remaining features in later releases based on user feedback. A stage-by-stage timeline is included in the proposal.