App Development Agencies in Istanbul: Stores, Locale, Billing

The Dotted and Dotless I Will Break Your Build

Start here because it costs teams real money every year. Turkish has two separate letters that look like the Latin i: one with a dot and one without, each with its own upper case form. When a device is set to the Turkish locale, the platform's case conversion functions follow that rule, so converting an ordinary machine string to upper or lower case no longer produces what the rest of your code expects. Header names, file extensions, media types, protocol tokens, feature flag keys and case-insensitive comparisons all start failing, and only on devices set to this locale, which is why the bug reaches production.

The fix is a discipline rather than a patch: use invariant, culture-independent case conversion for anything a machine reads, and locale-aware conversion only for text a person reads. Ask every candidate development team about this directly. A team that has shipped here will recognise the problem immediately and tell you where it bit them; a team that looks puzzled has not.

Two related details belong in the same conversation. Sorting follows a local alphabetical order that places several letters where a default comparator does not expect them, so lists of names and cities come out wrong unless you use a locale-aware collator. And search needs to be diacritic-tolerant in both directions, because people type without accents and expect accented results back.

Three App Stores, Not Two

The Android picture here includes a third meaningful channel. A substantial installed base of handsets ships without the Google services layer and distributes software through the manufacturer's own store, which means an app built on Google messaging, maps, location and sign-in will not run on those devices at all. In many markets you can ignore that segment. Here it is large enough that ignoring it is a decision rather than an oversight.

Plan for it structurally. Put push notifications, maps, location and social sign-in behind interfaces with more than one implementation, keep a build variant that has no dependency on the Google layer, and test it on real hardware rather than assuming a fallback path works. Publishing to the third store is a separate submission with its own review queue and its own listing assets, so your release process needs to handle version drift when one channel clears review and another does not.

Sideloading of installer packages is also more common here than in most markets, which is worth knowing for two reasons: your analytics will show installs you cannot attribute, and unofficial repackaged copies of popular apps circulate, so integrity checks and certificate pinning are worth the effort for anything handling money.

Installments, Local Gateways and Card Routing

Paying in monthly installments is the default expectation for anything beyond a small purchase, and it is not something your checkout can approximate. The number of installments available, and whether they carry interest, depend on the issuing bank and the card product, which your system determines by looking up the card's leading digits against a table before it can display options. Show the wrong plans and the transaction fails at the bank; show none and the customer abandons.

That lookup is one reason local payment gateways are used rather than a generic international processor. They carry the bank relationships, the installment tables, the local fraud rules and the authentication flow, and they speak to the domestic card scheme that runs alongside the international ones and that some cards belong to exclusively. Cardholder authentication is routine rather than optional here, so design the flow around a redirect and a return, with your order state driven by the gateway callback.

Digital goods are governed by store policy instead, so decide early which of your products count as digital goods and price them knowing the platform commission applies. Mixing the two in one product is normal, but the flows, the reconciliation and the refund rules are different and should be designed as separate paths.

Public Sign-In, Identity Numbers and Message Delivery

The national identity number is requested in many flows and has a checksum, so validate it properly rather than accepting any digit string, and be explicit about why you are collecting it. For services touching government, the national electronic government gateway is the expected authentication route and gives a verified identity without you handling documents. Mobile electronic signature and qualified electronic signature are also in everyday use and can replace scanned paperwork in contract flows.

One-time codes by text message deserve engineering attention rather than being treated as solved. Delivery runs through local aggregators, sender identifiers must be registered before they can be used, and throughput and delivery rates differ noticeably between operators and between times of day. Build in a fallback channel, instrument delivery and read rates, and do not let account recovery depend on a single route.

Data Protection, Registration Duties and Where Data Lives

The national data protection law has its own structure, its own definition of explicit consent, and an obligation for many data controllers to register with a central registry before processing. That registration is an administrative duty with deadlines and penalties, and foreign companies operating here are not automatically outside it. Establish who the controller is, whether registration applies, and who maintains the entry, before launch rather than after a complaint.

Cross-border transfer is the second issue. Moving personal data outside the country is restricted and requires a lawful mechanism, so a default architecture that ships everything to a foreign cloud region needs a documented basis. Payments and financial services face stricter treatment still: institutions in that space are subject to rules requiring that relevant systems and data remain in country, which affects your hosting choice, your disaster recovery design and your choice of managed services. Ask the question before you pick a region, because retrofitting it is a rebuild.

Pricing an App When the Currency Moves

Store price tiers are set in local currency, and the currency has moved substantially and unpredictably. A price that made sense when you launched can drift a long way from your intended position within months, so treat price as something you review on a schedule rather than set once. Subscriptions add friction because raising the price of an existing subscription triggers platform-specific consent and notification rules, and a badly handled increase produces cancellations and one-star reviews at the same time.

Practical approach: choose a review cadence and put it in someone's calendar, prefer consumable and one-off pricing where the product allows it, and if you sell to businesses outside store billing, quote in a stable currency with a stated validity period. The same volatility affects your development contract, so agree the invoicing currency, the quote validity and what happens if the project pauses.

Publishing and Release Discipline From Istanbul

Keep the store accounts in your own organisation and add your supplier as a member. An app published under a development agency's account leaves the agency holding the listing, the ratings, the analytics and the ability to ship, and unwinding it later means a new listing and lost reviews. Hold the upload and signing keys yourself with an escrowed copy, and write the handover obligation into the contract.

Ship through staged rollout with a defined halt criterion and a rehearsed rollback, and segment crash and performance monitoring by device model, operating system version and distribution channel, since the build without the Google services layer is a genuinely different artefact. Build a server-driven minimum version check early, because users on mid-tier devices with limited storage postpone updates for a long time and you will be supporting old clients longer than your roadmap assumes. Localise the listing in proper Turkish rather than a machine translation, with screenshots showing local payment options and installment counts, since those are what a browsing user is looking for.

How to Shortlist a Mobile App Company in Istanbul

Ask for artefacts, not for a portfolio tour. Show me your installment checkout and how you determine available plans. Show me a build that runs without the Google services layer. Tell me how you handle locale-sensitive case conversion. Show me crash data from a live product segmented by device model, and tell me about your last rollback.

Then run a small paid trial before the main award: one real flow, working end to end on a mid-tier handset, delivered into repositories and pipelines you own. The working day overlaps almost entirely with European clients and gives a useful morning window for the Gulf, so a daily review call is realistic and worth using during the trial. Where the brief extends past engineering, verify those claims separately rather than accepting a bundle: compare with local engineering firms for backend and integration work, interface design specialists for product design, and local search specialists for the companion site.

Verified profiles, client feedback and portfolios for mobile app companies in every market are on Edvido, in-app motion work is listed with local animation studios, and you can send one brief to a shortlist so every proposal answers the same scope.