When a product should be built natively for Apple

Some products are Apple products. They should feel like they were made for the phone they run on — the type, the motion, the way a screen yields to the next one. That is native iOS app development: Swift, Xcode, Apple’s own SDK. No translation layer.

At FLUIDS, Flutter is the default when a product needs to be real on iOS and Android from the first release. Swift is the answer when the product belongs on Apple. This note is how we decide — for Saudi and Gulf products, and for anyone asking the same question.

What native iOS in Swift means

A native iOS app is written in Swift and built in Xcode against Apple’s SDK. The current UI layer is SwiftUI. UIKit remains valid where a control still needs it. The two sit in one project. We do not declare UIKit dead.

The developer account is the client’s. TestFlight is how they open the real app while it is being made. The App Store listing ships under their name. Credentials stay theirs. Nothing is held hostage. What actually transfers is a separate note.

This is not a tutorial. Apple already wrote those. The useful question is when this stack is the right one, and when it is not.

When the product belongs on Apple

Native Swift is the right default when one or more of these is true. If none of them are, and Android is in the first release, Flutter is the correct Fluids answer.

The audience is Apple-only

The first release is iPhone — and perhaps iPad, Watch, or Vision — and Android is not a launch requirement. That is a real business in Saudi Arabia in a way it is not in many markets. Mobile operating systems in the Kingdom sit at roughly half iOS, half Android. An Apple-only product can be a product. It is still a decision, not a default.

The product needs day-one Apple APIs

App Intents and Siri, widgets, Live Activities, App Clips, HealthKit, ARKit, Core ML, Wallet, CarPlay, watchOS. Flutter waits on a plugin or a native module. If the product’s value is one of those surfaces, write it in Swift.

The work is close to the hardware

Camera pipelines, Bluetooth and IoT, precise background location. The OS gives you the APIs. A cross-platform layer gives you a subset, later.

The surface must be Apple-fluent

A reading surface that should feel like Books. A map that should feel like Maps. A health flow that should feel like Health. Typography, Dynamic Type, the system motion. This is not “native is prettier.” It is a product that has to belong on the phone.

The product will live on Apple’s release train

Each autumn the OS changes. Privacy prompts, design language, new system features. A native app adopts them without waiting for a plugin. If that yearly cadence is part of the product’s life, Swift is the quieter long-term path.

How we build a native iOS app

The engagement is the same one on the rest of the studio: frame, build, ship. We do not invent a second process for Apple.

• Frame — scope, users, and success in writing. A fixed quote. If the product does not need native, we say so before work begins.
• Build — SwiftUI-first. Weekly TestFlight. You review the real app, not a status report.
• Ship — App Store Connect under your developer account. Handover documentation. Credentials that belong to you.

The backend is still one backend. A Swift client talks to the same data as a React admin. Native does not mean isolated. It means the iOS surface is written in the language the platform is made in.

What SwiftUI and native performance are for

SwiftUI is for structure, state, and system behaviour — Dynamic Type, Dark Mode, accessibility, right-to-left layout. Instruments is for when something is actually slow: memory, energy, a scrolling list that hitching. We do not sell “native performance” as an adjective for a form.

Native performance matters for camera, maps under load, audio, and motion that has to match iOS. It does not matter as a slogan. We will not invent frame-rate numbers. We will not claim every screen is faster in Swift. The condition is the product, not the pitch.

Bilingual Arabic and English, built as RTL

A locale is not a string file. It is direction, type, numerals, dates, and voice. Apple’s Human Interface Guidelines are clear: system controls flip in an RTL locale if you use standard controls. Custom chrome does not. Carets usually mirror. Playback and media chrome usually do not. Mixed script — Arabic UI with English product names — is normal in the Gulf. It has to be tested, not assumed.

Aalim is the named example of Arabic script as the product, not as decoration: authentic Uthmani text, recitation, tafsir. The App Store listing for a Saudi storefront needs Arabic and English metadata, screenshots, and keywords that match the binary. Claiming Arabic and shipping English screenshots is how review fails. The two store checklists are their own note.

What App Store review actually requires

Apple publishes the figure: on average, 90% of submissions are reviewed in less than 24 hours. That is Apple’s number, not a promise. First submissions, medical apps, and anything with user-generated content sit in the slower tail. The practical failure mode is not “strict Apple.” It is guideline 2.1 — App Completeness. A crash, a placeholder, a missing demo account, a dead backend.

• A live backend and a demo login the reviewer can use.
• Screenshots of the app in use. Localized if you claim Arabic.
• Privacy policy and purpose strings that match what the app actually reads.
• Digital unlocks and subscriptions go through In-App Purchase.
• Physical goods and real-world services — a clinic visit, a store coupon — use Apple Pay or cards, not IAP.

That is the Apple half. The operating note — IPA and AAB, TestFlight versus Play closed testing, the Saudi storefront — is what it takes to ship to both stores.

Naqrah.app books real clinic visits in Oman. That is a real-world service. T-CODE publishes offers a shopper redeems in a store. Same rule. Jameyatek organizes a jam’iyya and does not transfer, process, or store money — that honesty is the product, and it is the thing review and a regulator both need to see stated plainly.

We do not guarantee approval. We submit a complete app, with a working backend, under your account.

What is different in Saudi Arabia and the Gulf

Users expect Arabic-first or true bilingual, not English with an Arabic afterthought. Apple Pay is ordinary. Digital goods still go through IAP. If the app stores personal data of people in the Kingdom, PDPL applies — privacy notices, a lawful basis, subject rights. We are not a law firm and we do not claim a certification. That constraint is its own note.

The Kingdom is funding and buying digital products in health, education, retail, and civic life. That is context. It is not a slogan we print on a slide.

Where Apple Intelligence fits — and where it does not

On-device models and App Intents are useful if the product is Apple-first and the user’s device language is one Apple supports. As of Apple’s own list in 2026, Arabic is not a supported Apple Intelligence language. We will not sell Writing Tools, notification summaries, or Siri App Intents “in Arabic.”

A product can still ship its own on-device model. A recitation check, a course assistant trained on one file, a verifier that never leaves the phone — those are yours. They are not Apple Intelligence. Keep the names straight.

The decision is the product’s

If you are deciding native versus Flutter for a Saudi or Gulf product, the fashion of the stack is the wrong input. The product is the input. Apple-only, hardware-close, or fluent with the system — Swift. Both stores, one team, one release — Flutter. The admin that runs either of them is a web surface on the same backend. That is a separate note.

See the shipped work, then write to us with what you want built.