Justin helps dev and product teams navigate the waters of mobile app development and is an expert at integrating them into larger technical, customer, and business ecosystems.
To be concise, it solely depends on which framework suits your mobile app development needs.
Yes, and if your mobile app development needs are to leverage, maintain, and recruit for existing, complex native (Java/Kotlin/Swift/ObjC) apps, Kotlin Multiplatform is the best option. Rewriting with Flutter, RN, or Xamarin are expensive and risky options in that case. (Yes, it's possible, but you really need to put in the decision-making effort and commit to the implementation effort)
the real differences among the three frameworks based on the following parameters
I came to a similar conclusion that Flutter is better in several categories than RN and Xamarin. React Native's biggest con is that it relies so heavily on community libraries (as you mentioned) but Flutter also relies on community libraries. Even native Android and iOS development include many community libraries (e.g. Alamofire and SQLDelight).
Flutter's rating on widgets, native functionality, and bugs/glitches will definitely be better on Android than iOS (or other Apple devices when/if support is added) because of the natural closeness of the Flutter and Android teams, and the natural distance of the Flutter and Apple teams. There have been, still are, and will continue to be many issues in the repo about cupertino widgets and feature-alignment on iOS. There are also issues with older/less-powerful Android devices.
Again, it comes down to what your mobile dev needs are. UI/UX that doesn't necessarily need to match platform expectations on each platform will be more suited to a solution that shares UI. Otherwise, native UIs will give the best experience (and keep up with first-class innovations from Android and iOS platform teams). Scale of app and engineer teams may mean sticking with current competency or a strong strategy to change that (it probably cost Facebook less to create HHVM than to train/hire non-PHP devs and rewrite all the things). A web shop moving into mobile may want RN or Flutter, a .NET shop may go with Xamarin. I've only seen one mature org making the move from native to Flutter, I've seen several move from RN to native, I'm expecting moves from Flutter to native in the future (especially with further adoption and improvements of SwiftUI and Jetpack Compose and my expectation that Flutter won't keep up with iOS). Kotlin Multiplatform is in a great position to hedge the risk inherent in platform changes (at the OS level and the UI level) by focusing on the business logic in the middle as well as some platform similarities that have very low risk of change (built on *nix, using sqllite, etc).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for sharing your research on this
Yes, and if your mobile app development needs are to leverage, maintain, and recruit for existing, complex native (Java/Kotlin/Swift/ObjC) apps, Kotlin Multiplatform is the best option. Rewriting with Flutter, RN, or Xamarin are expensive and risky options in that case. (Yes, it's possible, but you really need to put in the decision-making effort and commit to the implementation effort)
I came to a similar conclusion that Flutter is better in several categories than RN and Xamarin. React Native's biggest con is that it relies so heavily on community libraries (as you mentioned) but Flutter also relies on community libraries. Even native Android and iOS development include many community libraries (e.g. Alamofire and SQLDelight).
Flutter's rating on widgets, native functionality, and bugs/glitches will definitely be better on Android than iOS (or other Apple devices when/if support is added) because of the natural closeness of the Flutter and Android teams, and the natural distance of the Flutter and Apple teams. There have been, still are, and will continue to be many issues in the repo about cupertino widgets and feature-alignment on iOS. There are also issues with older/less-powerful Android devices.
Again, it comes down to what your mobile dev needs are. UI/UX that doesn't necessarily need to match platform expectations on each platform will be more suited to a solution that shares UI. Otherwise, native UIs will give the best experience (and keep up with first-class innovations from Android and iOS platform teams). Scale of app and engineer teams may mean sticking with current competency or a strong strategy to change that (it probably cost Facebook less to create HHVM than to train/hire non-PHP devs and rewrite all the things). A web shop moving into mobile may want RN or Flutter, a .NET shop may go with Xamarin. I've only seen one mature org making the move from native to Flutter, I've seen several move from RN to native, I'm expecting moves from Flutter to native in the future (especially with further adoption and improvements of SwiftUI and Jetpack Compose and my expectation that Flutter won't keep up with iOS). Kotlin Multiplatform is in a great position to hedge the risk inherent in platform changes (at the OS level and the UI level) by focusing on the business logic in the middle as well as some platform similarities that have very low risk of change (built on *nix, using sqllite, etc).