Application architecture
Structure that survives past the first release and more than one developer.
Services
Mobile App Development
We know the release process because we ship and operate our own mobile applications.
We develop iOS and Android applications and work through the parts that come with actually releasing them.
That includes application architecture, APIs, authentication, deep linking, analytics, attribution, push notifications, store submissions, releases, and production support.
Most of the difficulty in mobile is not writing the app. It is store review, release management, attribution that reconciles, deep links that resolve, and supporting a version of your software that is now on someone else phone.
Problems this solves
You may recognise some of these.
- A submission keeps getting rejected and nobody knows why
- Deep links open the store instead of the screen they should
- Install numbers do not match what the ad platform reports
- A bug is live and the fix is stuck behind a review queue
- The app works for the team and breaks for real users on older devices
What we do
The work itself
APIs and authentication
The backend the app depends on, built alongside it rather than assumed.
Deep linking and attribution
Links that land on the right screen, and install data that reconciles.
Store submission and releases
Review, listings, staged rollouts and the process around them.
Production support
Crash reporting, monitoring, and a route to shipping a fix quickly.
Process
How an engagement runs
Define the first release
What ships, and what deliberately waits.
Build the app and its backend together
The API is part of the product, not a dependency you hope exists.
Instrument before launch
Analytics, attribution and crash reporting on day one, not after the first campaign.
Get through review
Store requirements are a design constraint, and treating them as one saves weeks.
Operate the release
Staged rollouts, monitoring, and fixes that can actually be shipped.
Technology
What we typically build this on
The technology is chosen around the project. The business problem comes first.
- React Native
- TypeScript
- Django
- Node.js
- PostgreSQL
- Firebase
- BigQuery
Questions
Things people ask before starting
- Do you build native or cross platform?
- It depends on the product. Cross platform suits most business and consumer applications. Some products genuinely need native, and that is a scoping conversation rather than a default.
- Can you take over an app someone else built?
- Often, yes. The first step is reading the code and the release setup and telling you honestly what state it is in.
- Do you handle store submission?
- Yes. We ship and operate our own applications, so review, listings, deep linking and attribution are part of the work rather than someone else problem.
Related services
Often part of the same engagement
Tell us what you are trying to build
Tell us about the business, the problem, what you have today, and what you want to accomplish. If we are not the right team, we will tell you.