Does the choice of iOS language affect agency quotes and long-term maintenance costs?

Have you nailed down exactly what the app is going to do? Will it involve Bluetooth barcode scanning, background real-time GPS tracking, or complex camera animations? If it's just standard database operations like product listings, order confirmations, and push notifications, paying that 110.000 TL difference for native might not be worth it. But if there's heavy hardware integration, cross-platform will end up costing you a lot more down the road.

We had a similar ordering app built last year. We paid 180.000 TL and went cross-platform, and the first year was smooth. But after an OS update, the camera barcode scanner module broke. The agency told us the open-source library we used wasn't being updated anymore and they'd have to rewrite the module from scratch, asking for an extra 45.000 TL. More than half of what we initially saved evaporated on a single bug fix.

The whole "it must be native to be solid" mindset in the market is a bit overblown. Nowadays, even banking and major e-commerce apps run plenty of their screens on cross-platform or web-based interfaces. What matters more than the language the agency uses is how senior the team is in that language. A native app built on bad architecture will rack up far more maintenance costs than a well-architected cross-platform one.

Technically speaking, the real thing you need to watch out for is dependency management. In cross-platform languages, there is a bridge layer between the app's core and the operating system. This layer can cause lag or delays with every major OS update. Ask the agency how many third-party plugins they'll be using beyond standard package managers. The more external plugins there are, the more your future update costs will multiply.

Clauses you should definitely get into the specs before sitting down with the agency: 1) Verification that the source code adheres to clean architecture standards and contains comprehensive in-code documentation. 2) A requirement that the programming language and framework be on an up-to-date, long-term support (LTS) release. 3) A full list of licenses and versions for all third-party libraries upon project delivery. 4) A step-by-step setup guide so another team can spin up the project if the agency stops providing support.

we were in the exact same boat. when we looked for freelance devs later on, we realized most hybrid devs are pretty new to the market and only half-know both platforms but once things blew up we had no choice but to rebuild natively. if the budget allows and you're only targeting ios, going clean native from day one gives you total peace of mind.

When evaluating proposals, you shouldn't treat the scope of the maintenance and support contract as secondary to the tech stack. Regardless of the language used, having a solid SLA clause and locking in a fixed monthly maintenance fee will protect your company against developer turnover or OS version bumps. Also, make sure to explicitly include full, unconditional transfer of code ownership in the contract.

Two years ago, we took the cheap route for a similar wholesale app. We figured, hey, it's just a simple catalog and order screen. The agency finished and delivered the work, and eight months later they went out of business. We took the code to another developer. The guy opened up the project and said it was built on an obsolete, unsupported version of a framework, and that starting from scratch would be cheaper than trying to fix it. That's when we learned you have to question the long-term sustainability, not just the language.

Correct. Access credentials should be opened in the company's name, not personal accounts.

Solutions that work at a small scale collapse when you grow; I learned this late. If you post the result here, it will help others too.

Thanks, that was the answer I was looking for. When we decide without measuring, we always end up in the same place.

Hope this helps.

you're right.

You're right. In legacy systems, the most expensive thing is unknown dependencies.

Proven by experience.

Let me clarify the technical side. When you try to change everything at once, nothing settles.

Most time waste accumulates in tasks waiting for approval. If I were you, I'd go this route.

could you elabrate on that? just because everyone does it doesn't mean it's right.

good luck with that.

Could you elaborate on that? The cheapest quote is usually the least thought-out one.

This is my opinion, I'm not claiming it's absolute truth.

Let me speak from the other side; Im on the supplier side. Everyone rushing into ios app language gets stuck at the same point.

I'm also curious if anyone does it differently.

I have no experience with ios app language, so I'm asking. Trying to do this alone is the most expensive way.

There's one point I'm curious about. Implementing a change request process doesn't slow things down, it speeds them up.

This is my opinion, I'm not claiming it's absolute truth.