Native or cross-platform
Native or cross-platform: the comparison comes before the decision.
Native or cross-platform, the call rests on three criteria: hardware access, maintenance budget, time to market. We weigh all three before choosing.
Native or cross-platform: three criteria, not a preference
Hardware access: bluetooth, badge reading, demanding camera work, sensors. Maintenance budget: one codebase or two, over five years. Time to market: one launch or two.
We put all three in writing, with a cost for each route. The decision is yours, made on numbers rather than on the technical fashion of the season.
What cross-platform does well, and less well
It covers form screens, lists, maps and notifications perfectly well, which is most of what a business app consists of.
It shows its limits on heavy image processing, 3D and uncommon system integrations. In those cases native stays simpler to hold over time.
Pricing is handled subject by subject, with a short form and a written answer: Quote for an Android and iOS app. And to judge on evidence, we show what we run ourselves: our four in-house products.
DX-13
Common questions about native and cross-platform
Which cross-platform technology do you use?
The choice depends on the project and on what your team could take over. We favour something you will find on the Tunisian market rather than a rare stack that would tie you to us.
Is cross-platform slower?
On a business app the difference is rarely noticeable. It becomes noticeable with complex animation or heavy processing. We measure instead of ruling on principle.
Can we move to native later?
Yes, but it is an interface rewrite. What survives is the API and the business rules, provided they were not written inside the app itself.
Reference DX-13
Put a price on it
A short scoping round, a fixed price, a schedule. Tell us the outcome you want, not the solution you picture.