Talk to the bench
Start a conversationUitbreidingsstraat 32, 1050 Elsene, Brussels-Capital Region, Belgium
Monday to Friday, 9:00 AM – 6:00 PM
Technology Stack
Frameworks matter less than people sometimes hope, but they are not irrelevant. The stack decides how fast you can ship, how much a change costs six months later, and whether the next developer can read the code. Here is what we reach for at Eclipse Holdings Group and, more usefully, when we reach for something else instead.
Expo handles the build, testing and shipping workflow around React Native, which removes a great deal of the native build friction that used to define mobile projects. It is our default for cross-platform mobile work, and it pairs cleanly with GitHub Actions and Fastlane in the release pipeline.
The practical benefit is pace: a functioning test build on a real phone early in the project, and fewer certificate problems at submission time.
When Expo is the pick
Choosing between them
Neither wins on principle. We write the decision down during scoping so it can be revisited with evidence rather than argued about. The ruled rows below are how we work through it, field by field.
A ruled ledger like this ships with every project file, so a new developer who joins in month eight reads the same reasoning the client approved in month one.
Tauri builds cross-platform desktop apps with a smaller binary and tighter resource use than the heavier Electron approach. It fits admin tools, utilities and internal applications where the interface is web technology and the footprint matters. If the app must run on modest hardware in a back office, that difference is noticeable in daily use.
Avalonia is the cross-platform desktop path for teams in a .NET environment, and it goes beyond Windows-only tooling. It suits business software and internal applications where the organisation's own developers will maintain the code later, since it follows patterns a .NET team already recognises. We pick it when the surrounding infrastructure makes .NET the natural home.
Windows
Native
macOS and Linux
From the same codebase
Backend choice
The two backends cover different futures. Firebase gets a first version into users' hands quickly; Supabase leaves the data layer open enough that your own team can grow into it. Which one fits depends less on the framework and more on who keeps the lights on in year two.
Layer
Firebase
Supabase
Data model
Document store, flexible during early changes.
SQL with a real schema and readable queries.
Who maintains it
Fine while the studio holds the wheel.
Comfortable when your team is in SQL already.
Auth and push
Authentication, analytics and push, ready on day one.
Auth plus app backend, with the data inspectable.
Best fit
MVP and early-stage product delivery.
Teams planning to hire in-house later.
Firebase is frequently the backend companion to Flutter or React Native projects. When the data model is straightforward and the priority is getting something into users' hands, it is often the shortest route. Supabase is built around a SQL database, which makes it attractive when a team wants a more open backend layer they can inspect and query directly.
After the first release
Three parts of the stack never show up in a pitch deck's first slide, and they decide whether the product survives its second year. They are standard equipment on our projects, not optional extras.
Firebase Test Lab runs your app on real devices in the cloud rather than emulators, across a spread of hardware and OS versions. That matters because device fragmentation is a practical risk, not a theoretical one. We run automated passes on the matrix and then use physical handsets for the things automation cannot judge.
Sentry tracks runtime errors and stability issues in production, which is the difference between knowing about a crash and hearing about it from an unhappy user weeks later. It records the stack trace, the device and the app version. For any application where reliability matters after launch, this is standard equipment rather than an optional extra.
Fastlane automates the build and release steps for mobile apps, including the parts of store submission that people forget. Combined with GitHub Actions, it produces repeatable deployment workflows where a release is a defined sequence. Manual release steps are where release friction lives, and removing them is one of the cheaper improvements available to a project.
Together they turn release from a nervous afternoon into a step in a sequence. That is what most of the stack is for.
Where this page sits
What we do with your answer
Send a paragraph: the platforms you need, the data you keep, who maintains the software once it is live, and the release date you are working back from. In return you get a short written recommendation on framework, backend and release tooling, and the reasons on one page — the same ruled format we use on a project.
The recommendation is free, and it is written for a decision-maker rather than a developer. If we think another studio's stack is a better fit for what you described, the answer says so.
