Apps for Android and iOS
Mobile Apps for Android and iPhone
Before anyone writes code for an app, you need answers to a few questions: one codebase or two, what happens without a signal, and who keeps it working when the next operating system arrives. Aarvya Corporation works through those with you first, tests the result on real handsets, and treats the updates after release as part of the same job.
The first decision
One Codebase or Two?
This choice shapes the cost, the upkeep and how closely the app can work with the phone itself. We settle it with you before any screens are drawn, and we will not choose the cheaper-looking route just to shorten a quotation.
Separate native apps suit you when
- The app relies heavily on the camera, sensors, background tasks or other device features
- It should look and behave exactly as people expect on each platform
- Smooth running on lower-end phones matters more to you than sharing code
- You only need one of the two platforms to begin with
Android work is written in Kotlin with the Android SDK and Jetpack. iOS work is written in Swift, using SwiftUI or UIKit depending on what the screens require.
One shared codebase suits you when
- Both stores need substantially the same product
- One team keeping a single codebase current is easier for you to fund over time
- Most screens are forms, lists and content rather than heavy device work
- You accept that a few features will still need a small native bridge
For this we use Flutter or React Native, picked to suit the project rather than out of habit.
Conditions to plan for
What Has Your App Got to Cope With?
Most of the effort in a mobile project goes into situations a demo never shows. These are the ones we plan for, and they are worth raising early in any conversation about an app.
A weak or missing signal
People open apps on trains, in basements and on patchy rural networks. We agree with you what each screen shows when a request stalls, retry sensibly, cache results that are safe to keep, and read every response into typed models so a server change breaks the build rather than someone's session.
The camera, location or notifications
Each device feature brings its own permission prompt and platform rules. We request a permission only when a feature actually needs it, and make sure the rest of the app carries on working if the person says no.
Accounts, data and a server behind it
Firebase is often enough for sign-in, stored data, files, notifications and crash reports. When a project outgrows it, we move to a Node.js service with its own database while the app keeps calling one documented interface, so the change is our concern rather than yours.
Older and cheaper handsets
Not everyone using your app will carry this year's flagship. We measure launch time, dropped frames, memory, network calls and battery drain on real phones, then fix what the numbers point to: work moved off the main thread, images sized properly, a smaller download.
Getting through store review
Signing keys, App Bundles, certificates, provisioning profiles, listings and staged rollouts are handled as part of delivery. The review decision belongs to Apple and Google, so we prepare each submission carefully against their published rules rather than promising a result.
Staying current once it is released
An app nobody looks after decays quietly: a new operating system arrives, a store rule changes, a dependency turns out to be unsafe. We keep the project building and releasing, respond to what crash reports show, and gather improvements into planned updates.
Technology
Which Tools Go Into an App?
The list is narrowed for every project. These are what mobile work usually needs, together with the services that commonly sit behind an app.
- On the deviceThe native languages and SDKs for each platform, plus the two cross-platform frameworks we use.
- Kotlin
- Java
- Android SDK
- Jetpack
- Swift
- SwiftUI
- Flutter
- React Native
- Behind the appInterfaces built on Node.js, and Firebase where a managed backend keeps the project simpler to run.
- Node.js
- REST APIs
- Firebase
Delivery
How Does an App Get From Brief to the Store?
Mobile projects pass through the same stages as everything else we build. The platform decision is made at the start, and the store release and the updates after it are treated as part of the work rather than an afterthought.
- 01
Questions First
Before anything is estimated, we find out who will use the software, what they do today and what has to be different afterwards. The answers are written up for you to correct, and the estimate is built on that document.
- 02
Working Software, Early
You see real screens in small, regular instalments instead of one large reveal at the end. Each instalment is tested on ordinary devices and slow connections before you are asked to review it.
- 03
After Release
Once it is live you receive the code, the account access and notes that explain how it fits together. We remain available for fixes and for whatever you decide to add next.
Before you brief anyone
What Should Your App Do First?
Tell us what the app is for, which stores it needs to reach and what it has to connect to. We will reply with the questions that matter most, followed by an outline detailed enough to budget for.