I build native, and I will tell you when cross-platform is fine.
A senior native developer's straight assessment of when Flutter or React Native costs you and when a shared codebase is reasonable, so the decision fits your product. Day rate: €500 or $600.
It would be easy to say native always wins, but that is not true. Cross-platform frameworks like Flutter and React Native are reasonable for a lot of standard apps: forms, lists, CRUD, content that does not lean on platform-specific media or hardware. Sylvain's interest is in your product shipping well, so the recommendation is based on what you are building rather than on selling more native days.
The strain shows up in specific places: video playback and DRM, where you fight the bridge to reach AVPlayer and ExoPlayer; TV platforms, where Flutter and React Native have weak support; deep native API access; app binary size; and debugging that crosses the JavaScript or Dart bridge into native code. Keeping up with each new OS release is also slower when you depend on a framework to expose new APIs. If your product lives in these areas, native usually wins on time and quality.
If the app is mostly screens of data, the team already knows React or Dart, and there is no heavy media, hardware, or TV requirement, a shared codebase can genuinely save money and ship faster. The compromise is acceptable when the hard parts of your product are not the parts a framework struggles with. Sylvain will say so plainly when that is the situation, even though he is not the one who would build it.
The right choice comes from the product, not from a trend. Sylvain looks at your core features, your team, your platform targets, and your maintenance horizon, then gives a recommendation you can act on. When native is the answer, he builds it in Swift, SwiftUI, and Kotlin. When it is not, he tells you, so you do not pay for native where it adds nothing.
The same flat day rate of €500 or $600, remote. An honest assessment is usually a small number of days, and it can save you far more than that by avoiding the wrong architecture.
Yes. I review existing native or cross-platform apps, tell you what is healthy and what is not, and can take over native iOS or Android work. I read the code before forming an opinion.
Yes. If your product is a good fit for Flutter or React Native, I will say so, even though native is what I build. A wrong recommendation costs you more than one honest conversation.
Video, DRM, offline downloads, and TV platforms lean heavily on platform-specific APIs like AVPlayer, FairPlay, and the Apple TV focus engine. Reaching those through a cross-platform bridge is where most of the pain and quality loss shows up.
My hands-on building is native: Swift, SwiftUI, and Kotlin. I understand the cross-platform frameworks well enough to advise on the tradeoff, but my delivery is native code on each platform.
A description of your core features, your platform targets (iOS, Android, TV, web), your team's existing skills, and how long you expect to maintain the app. With that I can give a clear, product-based recommendation.
Send the product context, target platform, repository state, and timing. I will tell you quickly if I can help.