App development that reaches the store, instead of getting stuck a week before it.
I'm Lior Zabari, a registered developer with both Apple and Google. It means I don't only write the app, I also submit it, handle rejections and know the places where it falls apart. iPhone, Android and web apps.
A reply from me personally, usually within the hour during Israel working hours.
Last updated:
I build you an app that runs on the customer's or the employee's phone and connects to what already exists in the business. I'm Lior Zabari, registered as a developer with both Apple and Google, so the store submission and handling rejections are part of my job and not your problem.
The rule I work by: first we check whether you need an app at all. For many businesses a good website is enough, and I say so even when it costs me work.
Do you even need an app?
That's the first question I ask, and the answer isn't always yes. The three ways to deliver a service on the phone look similar to the customer and are completely different in cost and maintenance.
| What we check | Responsive website | Web app (PWA) | Store app |
|---|---|---|---|
| Time to launch | Fastest | Medium | Longest, because of the approval process |
| Push notifications | Limited | Possible, with restrictions | Full, and this is usually the real reason for an app |
| Access to camera, location and files | Partial | Partial | Full |
| Offline work | No | Partial | Yes |
| Presence in the stores | None | None | Yes, and it's also a discovery channel |
| Ongoing maintenance | Lowest | Low | High: every OS update can break something |
What's in an app development project
A specification that starts from the process
Not from a list of screens but from the question of what the user came to do and how fast they can do it.
Screen design
Real screens before writing code, so changes happen while they're still cheap.
Development for both platforms
iPhone and Android from the same codebase, with adjustments where the systems really differ.
Connection to what you already have
A management system, payments, a calendar or inventory. An app that isn't connected is one more place to enter data.
Testing on real devices
Including old OS versions and small screens, where most things break.
Store submission
The developer accounts, store assets, privacy policy and forms. The second round with the review too, if needed.
How much does it cost to develop an app?
A real business app for iPhone and Android, with a backend and submission to both stores, costs in Israel in 2026 between 80,000 and 180,000 shekels (roughly $22,000 to $50,000). That's not my price, it's what the market charges, and the number repeats across several Israeli price lists published this year. Below it there's a real range for a simple app, and above it there are products that are already a company, not a project.
| What's being built | Market range | What it actually includes |
|---|---|---|
| Simple app | About ₪50,000 to ₪80,000 | A handful of screens, no complex logic, usually without its own backend |
| Full business app | About ₪80,000 to ₪180,000 | iPhone and Android, a backend, users, notifications and store submission |
| A product with real complexity | Hundreds of thousands of ₪ and up | Payments, real time, heavy integrations, a team that maintains it over time |
Native, cross-platform or no code at all
Everyone who sells development shows the three options and nobody says which one they would choose. This is my recommendation, and I depart from it only when there's a reason.
| Approach | When it's my choice | The price you pay for it |
|---|---|---|
| Cross-platform | My default for most business apps: one codebase for both stores | Edge cases that require separate code for each OS |
| Fully native | When the app leans heavily on hardware or on high performance | Double the cost and maintenance, because it's two projects |
| No-code or "vibe coding" | For a quick prototype meant to test an idea with users | Hits a ceiling fast and is hard to maintain when something breaks |
Want me to check whether you need an app at all?
The code and the accounts stay yours
Developer accounts in the business's name
I open the Apple and Google accounts in your business's name, not mine. With Apple, an organization account requires a D-U-N-S number registered to your company, and if there isn't one I explain what's needed to open it.
The code in your repository
With full history and documentation. The developer who continues after me gets a project they can step into, not a riddle.
Keys and secrets in order
Signing keys, certificates and permissions are documented and handed over. Losing a signing key is one of the needless pains in this field.
I'm available afterwards too
An app isn't a project that ends. The operating systems update once a year and something always needs adjusting.
From the first call to a version you can download
Fit call
What the user came to do, how many times a week, and what happens today without an app. At the end of the call I say whether you need an app or whether something cheaper will do the job.
The output: a straight answer, even when it's noSpecification and a first version on paper
The list of screens that really go into the first version and what gets deferred. This is where most of the money is saved, because a change in a document costs an hour and a change in code costs a week.
The output: an agreed scope and a final priceScreen design
Real screens you can click through before a line of code is written, so you see the product instead of imagining it.
The output: a clickable prototypeDevelopment in versions
You get an installable version every week or two, not at the end. That way a small fix happens while it's still small.
The output: a test version on your deviceTesting and store preparation
Real devices, small screens, old versions. In parallel we prepare the store assets, the privacy policy and the forms that Apple and Google require.
The output: a build ready for submissionSubmission, approval and launch
I submit from your accounts, answer the review if there are questions, and handle a rejection if one comes. This is the stage where most projects get stuck with people who haven't done it before.
The output: an app you can downloadWhat happens between "we're done developing" and "it's in the store"
This is the part no page in the field spells out, and it's exactly where timelines fall apart. The two stores work differently and both have stages that can't be skipped.
Developer accounts in the business's name
Opening an account with Apple and with Google, verifying the business's identity and signing the agreements. With Apple, business verification is usually the longest stage and depends on your company's documents, so it's worth starting early.
Store assets and declarations
Descriptions, screenshots in every size, an icon, an active privacy policy and a detailed declaration of what data is collected and why. An inaccurate declaration is a rejection reason in itself.
A beta version for real users
Limited distribution before the store, to catch crashes on devices we haven't tested. Google also requires a closed test before publishing to everyone for certain account types, and we check those terms against your account before committing to a timeline.
Apple's review
A person at Apple opens the app and checks it against the rules. If an account is needed to get in, we provide a test user, otherwise they get stuck and reject.
Google's review
A mix of automated and human review, with emphasis on permissions policy, the data-safety declaration and the age rating. A first version usually takes longer than a routine update.
Second round
A rejection isn't a disaster, it's part of the process. What matters is how fast you fix and resubmit, and knowing the wording they expect helps with that.
Questions about app development
How much does it cost to develop an app?
A business app for iPhone and Android with a backend and store submission costs, in Israel in 2026, between 80,000 and 180,000 shekels (roughly $22,000 to $50,000). A simple app can fall in the 50,000 to 80,000 range, and a complex product with payments and heavy integrations runs into the hundreds of thousands. The exact figure can only be given once we know which screens go into the first version.
How long does it take to develop an app?
A first version of a business app usually takes three to five months from specification to store, of which a few weeks go to store preparation and submission. Timelines break mainly for two reasons: additions that come in mid-way and answers that are delayed on your end.
Do I need an app, or is a website enough?
If you need notifications that reach the phone, access to the camera or location, or offline work, you need an app. If the goal is to be seen, contacted or booked, a good website will do it faster and at a lower cost.
Who owns the app and the store accounts?
The business. I open the developer accounts in your business's name, the code sits in your repository and the signing keys are handed over and documented. An organization account with Apple requires a D-U-N-S registration in the company's name, and that is something we sort out at the start. If you work with someone else tomorrow, there is nothing to recover.
What happens if the store rejects the app?
We fix and resubmit, and that's included. Nobody can guarantee approval, because the decision is Apple's and Google's. What can be done is to dramatically lower the chance of rejection: an app that is a wrapper around a website, permissions that aren't explained, a login screen that blocks everything, or a privacy statement that doesn't match. I go through that list before submission.
Do you build native or cross-platform?
My default is cross-platform, meaning one codebase that runs in both stores. It saves time and maintenance and suits most business apps. When the app leans heavily on hardware or performance, we move to native and say up front that it costs more.
Can an app be built with no-code tools?
Yes, and it's excellent for a prototype that tests an idea with users. The problem starts when you need something the tool doesn't support, or when something breaks and there's nobody to turn to. If the product is the core of the business, it's worth building it so it can be maintained.
What does it cost after launch?
Three things: developer account fees that Apple charges every year and a one-time payment to Google, hosting and backend by usage, and maintenance. The operating systems update every year and something always needs adjusting, even if you haven't touched the app.
You work alone. What happens if you're not available?
That's the real downside of working with one person. The answer is that the code, the accounts and the keys are yours from day one, that everything is documented, and that I give notice of vacations in advance. If you move to someone else tomorrow, they get a project they can step into.
Can the app connect to the systems we already have?
Yes, and that's usually what makes it useful. A management system, payments, a calendar, inventory or a CRM. If the system has an interface, we connect to it. If it doesn't, we build a small layer that mediates. An app that isn't connected is one more place where data has to be entered by hand.
When I say no
When a website does the job
If there are no notifications, no hardware and no frequent repeat use, an app will cost more and bring less.
When there's nobody to maintain it
An app needs updating even when nothing in it changes. Without maintenance it stops reaching new users on new devices, and that happens within about two years.
When the goal is only to be in the store
Presence in the store isn't a strategy. If there's no reason for anyone to install, the installs won't come.
When everything is needed at once
I build a lean first version that works. Anyone who insists on twenty screens at launch gets a launch that doesn't happen.
Related
Tell me what the app is supposed to do
No specification needed. One sentence about what the user came to do is enough to start a conversation.
Prefer to talk? +972 52-877-5515