Mobile app development in Athens: what to build and what to skip

The technology argument about mobile — React Native against native Swift and Kotlin — is usually conducted as though every company were building for a hundred million users. In a market of ten million people, the arithmetic is different, and it is the arithmetic rather than the engineering that should decide.

Two native codebases means two teams, or one team context-switching between two languages, two toolchains and two sets of platform conventions. Every feature is specified once, built twice, tested twice and shipped twice, and the second build is the one that quietly falls behind. For a product whose Greek audience might be fifty thousand people, that structure has to earn a doubled maintenance cost out of a market that cannot pay for it. Occasionally it does. Usually it does not, and the honest recommendation is one codebase.

So React Native, with Expo for the build and release tooling, is our default — and it is worth being precise about what that shares and what it deliberately does not. Shared: the TypeScript types that describe every API response, the validation schemas, the API client, the business rules, the design tokens, and the entire test suite around all of it. Not shared, on purpose: the navigation idiom, the modal presentation, the back gesture, the haptics and the typography scale, because an iOS user and an Android user have each learned a different set of expectations and an app that ignores them feels foreign in a way people cannot articulate but can definitely feel.

Native still wins outright in a short list of cases, and pretending otherwise is how agencies get themselves into trouble in month five. Sustained background location — a courier or fleet app running all day — is a native problem, because the battery and the permission model punish anything less than platform-idiomatic implementation. Heavy real-time graphics, AR, or custom rendering that must hold a frame budget of sixteen milliseconds. Deep integration with a platform SDK that ships no bridge. Serious Bluetooth or peripheral work. If the product is one of those, build native and pay for it; if it is not, one codebase is a strategic advantage rather than a compromise.

The third answer, which we give more often than clients expect, is not to build an app at all. If the product is content, a loyalty card or a form people complete twice a year, an installable progressive web app delivers most of it for a fraction of the cost and none of the store overhead. We would rather say that in the first meeting than discover it together in the retention report.

The local considerations are real and they are mostly not technical. Payment: Greek users expect instalments and increasingly expect a wallet, which means Viva Wallet or Everypay SDKs and Apple Pay and Google Pay wired properly rather than as an afterthought. Invoicing: a business customer will want a τιμολόγιο with a VAT number, and if the app sells anything, that flows into myDATA. Identity: gov.gr and the wallet-held ID have changed what verification can look like for products that need it, and that is a genuinely Greek advantage worth using.

And the store listing, which is a search surface most Greek publishers leave in English. App Store and Play Store metadata localised into Greek — title, subtitle, keyword field, description, screenshots with Greek interface — is the cheapest acquisition work available to a Greek app and it is skipped almost universally. It costs a day. It is the difference between appearing when somebody searches in the language they think in and not appearing at all.

The last decision is organisational. The team that builds the app should be the team that built the platform behind it, or at minimum should share the API design with them. Every miserable app project we have been called in to rescue has the same root cause: a mobile team consuming an API written for a website, discovering in week three that it returns a rendered page's worth of data, and negotiating changes with a back-end team that has other priorities. One team, one API, two front ends. That is the arrangement that ships.