Native or cross-platform for a business app?

Cross-platform, unless something specific forces otherwise. The things that force native are concrete and short to check: sustained background work, deep use of a device capability that moves faster than the wrappers do, a design that has to feel exactly like the platform rather than merely good, or a regulated requirement that names a platform keystore. If none of those apply, two native codebases buy you very little and commit you to maintaining both.

What does an app for the Israeli market have to support that others do not?

Right-to-left layout as a first-class case rather than a late flip, which means mirrored navigation, correct behaviour for mixed Hebrew and Latin strings, and numbers and dates that stay left-to-right inside right-to-left text. Local payment and identity rails, which are not the same set as in Europe or the United States. And an interface that is legible to users who switch language mid-session, because many do.

Why do app projects cost more than the quote?

Because the quote prices the build and the cost is the maintenance. An app that ships is a standing commitment: two operating systems revise their requirements on their own schedule, certificates expire, store policies change, and an app that stops being updated eventually stops being installable. A proposal that does not name who does that work, and on what cadence, has not quoted the project.

How do you evaluate an app development company in Israel?

Ask to see an app they built that is still in the stores and still being updated, and ask who holds the developer accounts. The second question is the important one: if the agency owns the store listing and the signing identity, you do not own your app, whatever the contract says about intellectual property. Ask also what the release process looks like, because an app released by hand from one laptop has a single point of failure you will meet eventually.

Does the team need to be in Israel?

For the engineering, no. For the Hebrew interface, effectively yes, or at least someone native must sign off on it, because right-to-left errors read as carelessness to local users and are invisible to teams that do not use the language. Local presence also helps when the app has to touch Israeli payment or identity services, where the documentation is often in Hebrew and the support conversation certainly is.

Mobile app development in Israel

How to choose between native and cross-platform on grounds that hold up, what the local market adds to the requirements, and the commitment that decides the real cost after launch.

In short

Choose cross-platform by default and let a specific, nameable requirement push you to native. For the Israeli market, treat right-to-left as a design constraint rather than a translation task, because retrofitting it is more expensive than building with it. And read every proposal as two numbers: the build, which is quoted, and the maintenance commitment, which is usually not. An app that ships is a subscription you have taken out on your own behalf.

The stack decision, on grounds you can check

The honest version of this decision is short. Start from cross-platform; go native only for a reason you can state in one sentence.

If this is true	Choose	Why
The app does sustained work in the background: tracking, continuous recording, long synchronisation	Native	Background execution is where the two operating systems differ most and where cross-platform wrappers are furthest behind. This is the clearest native case there is
You depend heavily on a hardware capability that is still evolving: camera pipelines, on-device models, sensors, wearables	Native	These move faster than the wrappers that abstract them, so you would be waiting for someone else's release to use a feature you need
A regulator or a security review names platform-specific key storage or attestation	Native	Not a technical argument but a compliance one, and it is not worth arguing
Forms, lists, dashboards, orders, bookings, business process in your pocket	Cross-platform	One codebase, one test suite, one release process. Two native teams would deliver the same screens twice and disagree on behaviour in a way users notice
The app is mostly content with light interaction, and discovery matters more than device integration	Web first	A page is found by search and needs no installation. Many apps are built because an app was requested, not because installation serves the user. This is worth asking out loud

The last row is the one that saves the most money and is asked the least often. If nothing in your product needs the device, you may be funding a distribution channel with a lower conversion rate than the one you already have.

What the Israeli market adds

Right-to-left is structural

A Hebrew interface is not a translated English one. Navigation mirrors, back means the other direction, progress runs the other way, and icons that imply direction have to be flipped while icons that depict objects must not be. Numbers, dates, currency and Latin product names stay left-to-right inside right-to-left text, and getting that wrong produces strings that are technically present and practically unreadable.

The cost difference is entirely about timing. Designed in from the start, it is a constraint. Added after the layout is settled, it is a rebuild of every screen, and it tends to be discovered when the Hebrew content arrives, which is late.

A test worth running before you accept delivery. Put a Hebrew sentence containing a Latin brand name and a number into every field that accepts text, then screenshot each screen in both languages. Mixed-direction strings are where layout bugs live, and they do not appear with single-language sample data.

Local rails, not generic ones

Payment, identity and messaging in Israel run through a different set of providers than the defaults in most tutorials and most offshore estimates. Each one is an integration with its own documentation, often in Hebrew, and its own test environment with its own idea of what a test transaction is. Budgeting these as "payment integration, one line" is where mobile estimates most reliably break.

Users switch language mid-session

A single user may read Hebrew, work in English and receive content in Russian. Treat the language as a property of the person and of each message, rather than of the device, and make sure a missing translation is visible as missing rather than silently filled with another language. Hebrew text inside an English screen looks like it almost works, which is how it reaches production.

The number that is missing from most quotes

The build is the smaller commitment. After release, the app is on a treadmill that nobody controls:

Two operating systems revise their requirements on their own schedule, and an app that does not keep up eventually fails review or stops being installable.
Signing certificates and provisioning expire. When they expire unattended, you cannot ship a fix during the incident that made you want to.
Store policies change, particularly around privacy declarations, and a listing that is out of compliance can be pulled without a code change on your side.
Devices and screen sizes arrive. Layouts that were fine stop being fine.

So read the proposal for three answers: who performs the periodic update work, on what cadence, and what the arrangement is when nothing is wrong. A maintenance line that only covers bug fixing does not cover any of the above, because none of them is a bug.

Evaluating a company, in four questions

Show me an app you built that is still in the stores and still being updated. Not a portfolio screenshot. The update history is the evidence, and it is public.
Who holds the developer accounts and the signing identity? If the agency does, you do not control your own releases regardless of what the contract says about ownership. Transfer is possible and should happen at the start, not at the end.
How is a release produced? A build from one person's laptop is a single point of failure. You will meet it during an urgent fix.
Who signs off the Hebrew? Name the person. Right-to-left errors are invisible to a team that does not use the language and immediately visible to your users.

How I work on this

Practice since 2004, work on AI systems since 2023, projects for clients in fourteen countries. I am an independent architect rather than an app studio, which matters here mostly because "this should be a web page, not an app" is an answer I am free to give and a studio is not.

What a review produces: the native-or-cross decision with the reason written down, the list of local integrations with their real test constraints, the maintenance commitment as an explicit ongoing obligation rather than a footnote, and the account and signing arrangement settled before any code exists.

Where to start

Tell me what the app does when the phone is in a pocket and the screen is off. That single answer settles the native-or-cross question faster than a feature list, because it is the question the two platforms answer differently.

Get in touch | Related: integrations, ERP development, DevOps services

SLAtech LTD