Product & platform
Mobile engineering
iOS and Android, cross-platform or native, with the release machinery built early rather than discovered the week before launch. Offline behaviour, permissions and store review are design constraints, not afterthoughts.
- React Native & Expo
- Native Swift & Kotlin
- Offline-first sync
- Push & deep linking
- App store release pipelines
- On-device inference
What we build
- Cross-platform applications
- One codebase for iOS and Android where the product does not need two.
- Native modules
- Platform code where the device capability or the performance genuinely requires it.
- Offline-first data layer
- Local state, queued writes and conflict resolution designed before the first screen.
- Release pipelines
- Signed builds, staged rollout, over-the-air updates and crash reporting from day one.
- On-device AI features
- Quantised models running locally where latency or privacy rules out a round trip.
Problems this solves
- Problem
- The app is unusable on a poor connection, which is where it is mostly used.
- Approach
- Design the offline path first — local writes, a queue, and explicit conflict resolution — rather than treating it as an error state.
- Outcome
- The app keeps working through a tunnel and reconciles when the signal returns.
- Problem
- Each release is a manual, anxious event.
- Approach
- Automate signing, versioning, staged rollout and over-the-air updates, with crash and adoption reporting attached.
- Outcome
- Shipping becomes routine, and a bad build can be pulled back in minutes.
- Problem
- A store review rejects the app late and the launch date moves.
- Approach
- Review the permission, privacy-label and account-deletion requirements during Design, and submit a build early.
- Outcome
- Review becomes a scheduled step rather than a risk to the launch.
How we approach it
Discover
We ask what happens with no signal, because the answer changes the architecture. Offline behaviour, permissions and store review are constraints you design around, not surprises for the last fortnight.
Design
The sync model is designed first — what is authoritative, what is cached, and what happens when both changed. Everything on screen depends on getting that right.
Engineer
A signed build on a real device in week one, on the release pipeline that will still be in use at launch. Internal tracks exist before there is anything to put in them.
Evaluate & harden
Tested on old devices and bad networks, not the newest phone on office wi-fi. Crash-free sessions and cold-start time are budgets, and review guidelines are checked before submission.
Launch & operate
Staged rollout, crash reporting and a rollback that has been used at least once. The cadence is set so a fix takes days, which is what makes a review queue survivable.
What we build it with
The offline mutation queue. The id is the idempotency key, so a retry after a dead tunnel cannot write the same record twice.
/** Mutations survive the tunnel. The UI never waits for a network. */
import NetInfo from "@react-native-community/netinfo";
type Mutation = { id: string; path: string; body: unknown };
const queue = new PersistentQueue<Mutation>("mutations");
export async function enqueue(path: string, body: unknown) {
await queue.push({ id: crypto.randomUUID(), path, body });
void flush();
}
async function flush() {
const { isConnected } = await NetInfo.fetch();
if (!isConnected) return;
for (const mutation of await queue.peekAll()) {
try {
// The id is the idempotency key, so a retry after a
// timeout cannot create the same record twice.
await api.post(mutation.path, mutation.body, {
headers: { "Idempotency-Key": mutation.id },
});
await queue.remove(mutation.id);
} catch {
await queue.backoff(mutation.id);
}
}
}Languages
- Swift
- Kotlin
ML & computer vision
- ONNX Runtime
Frontend & mobile
- React Native
- Expo
- Flutter
- SwiftUI
Observability & evaluation
- Sentry
Questions we get asked
React Native or native?
React Native or Expo when the product is mostly screens, data and forms, which is most products — one codebase and one team. Native when the app leans on the device: sustained camera work, background audio, tight platform integration. We make that call with you, with the trade-offs written down.
Can you take over an existing app?
Yes. We start with a build, a read and a dependency and crash audit, then tell you what is worth keeping. Most inherited apps need the release pipeline and the data layer fixed before anything user-facing is worth doing.
Do you handle store submission?
Yes — signing, provisioning, store listings, privacy labels, staged rollout and the review correspondence. We submit an early build deliberately, so that review is a known quantity well before the launch date.
Can AI features run on the device?
Where it makes sense. Quantised models via ONNX Runtime or the platform's own inference stack keep data local and remove the round trip; larger models stay server-side. We measure the accuracy and battery cost before deciding.
Tell us what you are trying to ship.
A first call is 30 minutes and costs nothing. Bring the problem rather than a spec — the useful part is usually working out whether this is the right shape of solution at all.
contact@algologix.coWe reply within 24 hours.