We build mobile apps for iOS and Android. Alongside native development, we build cross-platform solutions with Flutter and KMM, and we handle the App Store and Google Play release process ourselves.
The most common mistake in mobile projects is picking the technology out of habit. There’s no rule that every app has to be cross-platform; by the same token, writing every app natively means unnecessary cost. The choice comes down to how much the app talks to the device hardware, what performance you expect and what your maintenance budget is.
Native or cross-platform?
| Approach | When it’s the right choice |
|---|---|
| Native (separate iOS + Android) | When hardware-level features such as the camera, sensors, Bluetooth and background processing carry most of the weight; when you need maximum performance and a platform-specific experience |
| Flutter | For interface-heavy apps that will offer the same experience on both platforms; when getting to market faster with a single codebase is the priority |
| KMM | When you want to share the business logic while keeping the interface native on each platform |
In the discovery call we explain this choice and the reasoning behind it — and we tell you openly what the decision means for cost and maintenance.
Technologies we use
On Android, current UI architectures such as Jetpack Compose; on iOS, the platform’s own modern toolset. Flutter and KMM when the project calls for cross-platform. For projects that need a backend, we build the API and data layer too — we don’t write the mobile app and leave everything behind it to someone else.
Process
- Discovery and analysis. User scenarios, the platform decision, technical requirements.
- Strategy and planning. Screen inventory, technology choice, timeline.
- Design and prototype. Interface designs and a clickable prototype; development starts once you approve them.
- Development and testing. Weekly progress reports and test builds you can run on your own device.
- Go-live and launch. Store accounts, app listing copy, the review process and release.
- Support and growth. Store policy changes, operating system updates and version maintenance.
How long does it take?
An app covering both iOS and Android takes 6-10 weeks on average. The main factors that set the timeline are the number of screens, backend and third-party integrations, and how much weight platform-specific features carry.
That doesn’t include store review time — App Store and Google Play review times vary and are outside our control. We discuss it as a separate item during planning.
Apps we’ve published
kitUP, Univerlist, Talkido, Word Notebook and KSerialPort are among our products live on the app stores. For the full list and our other projects, see our portfolio page.
Frequently asked questions
Whose name will the app store accounts be opened under?
Whose name the Apple Developer and Google Play accounts will be under is clearly written into the contract. We recommend settling this in the discovery call — it’s the deciding factor if you ever want to switch agencies.
Does the app need updates after it’s published?
Yes, and it isn’t optional. Apple and Google change their operating systems and store policies every year; apps that aren’t updated can be removed from the stores after a while. That’s why we recommend a maintenance agreement after handover.
Can I have just an iOS app or just an Android app built?
You can. If your target audience is concentrated on one platform, starting there and adding the other later is often a smarter use of your budget.
Can you take over development of our existing app?
We can. First we need access to the source code and a short technical review; depending on the state of the code, we tell you plainly whether continuing or rewriting will be cheaper.
Do you handle in-app purchases and payment integration?
Yes. Integrating in-app purchases and external payment providers can be included in the scope. Which method complies with store rules depends on your product; we talk it through during discovery.