S/06 · Services
Mobile & desktop apps
In every pocket, on every desk, in every browser.
Native and cross-platform apps for iOS, Android, macOS, Windows and Linux, plus browser extensions. Offline-first, in sync with your API, and published to every store your users shop in.
- Platforms
- iOS, Android, macOS, Windows, Linux
- Also
- Browser extensions
- Built
- Offline-first, synced
- 01
Your users live on their phones and your service doesn’t.
- 02
Field teams lose work every time the connection drops.
- 03
You need a desktop tool that talks to local hardware.
- 04
A browser extension would put you exactly where your users already are.
- D/01
Native or cross-platform
We choose the stack from what the app has to do and who will maintain it, one requirement at a time. Native code where the app needs deep access to the device, one shared codebase where it saves you building everything twice, and the reasons written down so the choice can be revisited.
Included
- A written stack decision, requirement by requirement
- A clickable prototype on real phones
- Shared code where it helps, native modules where it does not
- An estimate of what each option costs to maintain
docs/stack-decision.md Requirement Choice Reason Booking list, works offline Flutter One codebase, SQLite on both Bluetooth receipt printer Native module Only the platform SDKs support it Home-screen widget Native Needs WidgetKit and Glance Desktop app for reception Tauri Small installer, reuses the web UI Two developers in-house Flutter One language to maintain - D/02
Offline-first sync
The app reads and writes to a database on the device, so it keeps working in a basement or on a train. Changes queue up and sync when the connection returns, and when two people edit the same record, clear rules decide what wins and nothing is silently lost.
Included
- A local database with the data each user needs
- A queue of changes that survives restarts
- Conflict rules agreed with you, and logged
- Tests that cut the network mid-sync
docs/sync.mmd - D/03
Push & real-time
Your backend sends an event, and the right people hear about it: a push notification when the app is closed, a live update when it is open. We handle expired tokens, quiet hours and retries, so notifications arrive once, on time, and only when they are useful.
Included
- Push through APNs and Firebase Cloud Messaging
- Live updates over WebSockets while the app is open
- Notification preferences each user controls
- Delivery logs, so you can see what arrived
notify · production $ notify tail --env production
✓ 10:02:11 booking.confirmed → APNs delivered 84 ms
✓ 10:02:11 booking.confirmed → FCM delivered 112 ms
✓ 10:02:14 slot.freed → ws 412 live clients
! 10:02:19 FCM token expired · device d_7f3a removed
✓ 10:30:00 reminder.24h → 38 devices, 38 delivered
- D/04
Desktop apps
Desktop apps for the jobs a browser cannot do well: talking to a printer or a card reader, working with local files, staying open all day at a reception desk. Every release is signed, installs like any other program, and updates itself without a visit from IT.
Included
- Signed and notarized installers for each system
- Auto-updates, with a way to roll back
- Access to local hardware and files where needed
- A build pipeline that produces every platform at once
release/v2.4.0/ - release/
- v2.4.0/
- ClinicDesk-2.4.0-arm64.dmgmacOS · notarized
- ClinicDesk-2.4.0-x64.dmgmacOS · Intel
- ClinicDesk-2.4.0-x64-setup.exeWindows · signed
- ClinicDesk-2.4.0-x64.msiWindows · managed
- clinicdesk_2.4.0_amd64.debDebian, Ubuntu
- ClinicDesk-2.4.0.AppImageany Linux
- latest.jsonupdate manifest
- CHANGELOG.mdwhat changed
- D/05
Browser extensions
An extension puts your service inside the browser your users already have open. We build it once on the WebExtensions standard, ask only for the permissions it truly needs, and take it through each store’s review, which is where most extensions get stuck.
Included
- One codebase for every major browser
- Minimal permissions, explained in the listing
- Store listings, screenshots and privacy details
- Updates published to every store together
extension · store status · v1.3.0 - Chrome Web Storelive
- Firefox Add-onslive
- Microsoft Edge Add-onsin review · day 2
- Safari, through the App Storein review
- Opera add-onslive
- Permissions limited to storage and example.comminimal
- D/06
Store releases
We prepare the listings, sign the builds and take each release through store review. New versions roll out to a small share of users first, and we watch crash reports before releasing to everyone, so a bad build reaches a few people instead of all of them.
Included
- Store listings, screenshots and release notes
- Signing keys kept under your accounts
- Staged roll-outs with crash monitoring
- A release checklist your team can repeat
release · 2.4.0 Day 1
Builds signed and uploaded
→ App Store Connect and Play Console
Day 2
Internal testing
→ TestFlight and the Play internal track
Day 3
Store review
→ approved on both stores
Day 4
Staged roll-out
→ 10% of users, 99.8% crash-free
Day 7
Full release
→ every user, with release notes
- 01
Choose the stack
Native, cross-platform or web — picked for your users and your team, not for fashion.
- 02
Prototype
Clickable flows on real devices before full production starts.
- 03
Build & test
Automated tests and device testing across the screens your users actually have.
- 04
Release & update
Store submissions, staged roll-outs and crash reporting from day one.
A first release usually takes ten to sixteen weeks, depending on the platforms and how much has to work offline. You hold a working build on your own phone from the first weeks, and get a new one every week after that.
- Weeks 1–2
Requirements and the stack decision, then a clickable prototype on real devices.
- Weeks 3–4
The foundations: sign-in, the local database, sync and the build pipeline.
- Weeks 5–11
The features, screen by screen, with a test build in your hands every week.
- Weeks 12–14
Testing on the devices your users have, store listings and beta testers.
- Weeks 15–16
Store review and a staged roll-out, watching crash reports before going to everyone.
The source code
Every app and extension in your repository, with instructions to build it from scratch.
Store accounts and signing keys
Published under your developer accounts, with the keys stored where your team can reach them.
Design files and the prototype
Every screen and flow, ready for the next feature or a new platform.
A build and release pipeline
One command, or one click, to build, sign and upload a new version.
Crash reporting and analytics
Dashboards for crashes, versions in use and key flows, under your own accounts.
A check after the first release
We review crash rates, store ratings and reviews a few weeks in, and fix what turned up.
- Swift / SwiftUI
- Kotlin / Compose
- Flutter
- React Native
- Tauri
- Electron
- WebExtensions
- SQLite
Native or cross-platform?
It depends on what the app does. We recommend one after the consultation and explain why.
Which stores can you publish to?
The App Store, Google Play, Microsoft Store, Flathub and the browser add-on stores, plus regional stores your users rely on.
Who maintains the app after launch?
We can, or we hand it over with documentation and a build pipeline your team can run.
How long until it is in the stores?
Ten to sixteen weeks for most first releases. Store review usually adds a few days, so we plan for it from the start.
Will the app and the store accounts be ours?
Yes. The app is published under your developer accounts and the signing keys are yours. We work inside your accounts as invited members, and step out when you want us to.
Tell us what you are building.
Every project starts with a consultation: you bring the idea and everything you know, we turn it into a design you can build on.
Book a consultation