[mwcampbell]

Ah, yes, the tools involved with mobile development can be frustrating. FWIW, I generally skip the emulator/simulator and go straight to testing on the device. For iOS, you have to mess with Apple developer program membership, code signing, and provisioning profiles to run an app on the device. But for Android, just enable debugging on your device, connect via USB, and use adb.

About learning a "new syntax" for Xamarin, do you just mean that you don't know C#? Or are you talking about XAML? As I understand it, XAML is basically .NET's JSX, but with a sharper division between the declarative markup and the code (or "code behind" as it's called in the .NET world). Charles Petzold's book about Xamarin Forms does a good job of demystifying XAML.

I have mixed feelings about Xamarin versus React Native. On the one hand, React Native is fairly easy to integrate into an existing mobile app, and it integrates with each platform's native development tools (Xcode for iOS, Gradle for Android). That's not the case for Xamarin; in particular, on iOS, Xamarin uses its own AOT native code compiler based on LLVM. The next time that Apple puts out a new version of Xcode and, the same day, introduces a new requirement for app store submissions (for a new platform if not for iOS itself), Xamarin users are stuck until Xamarin scrambles to update its compiler.

On the other hand, with Xamarin, the resulting app is more native in ways that users can actually perceive, even when using Xamarin Forms. To take a simple example, React Native's (new) Button component doesn't actually use a UIButton on iOS or the equivalent on Android. So what happens when a future version of the platform changes the appearance of a button's border? Now React Native's hard-coded styles are out of date. A more complex example that's actually more relevant to me is React Native's ListView component. It doesn't use UITableView on iOS or the native ListView on Android. I don't know what this means for Android, but for iOS, the difference is noticeable, at least to blind people using an app with VoiceOver. Bring up the UIExplorer app on a device, turn on VoiceOver, and swipe through the screen. Notice that VoiceOver doesn't automatically scroll through the list; you have to do that manually with a three-finger swipe up. Contrast that with any native UITableView. My feeling is that React Native's developers will use native components in situations where they know they can't duplicate the native behavior, but if they think they can produce a cross-platform JS component that feels native enough, they will. Given the great momentum of React Native, which isn't likely to stop any time soon, I guess I should stop ranting and actually fix the problem, or at least the user-visible symptoms.

I haven't used either Xamarin or React Native for a real project yet. For my latest mobile project, I tried to take the Google Inbox approach, that is, writing non-UI code in cross-platform Java, then writing each platform's UI in that platform's native language. Then for iOS, I use Google's J2ObjC to compile the cross-platform Java into ObjC. But I'm not really happy with this approach. My guess is that all the best practices for writing an app this way are only known by the teams within Google that are doing it. There certainly isn't a strong community of developers outside of Google using this approach. And while cross-platform UI toolkits are criticized for being prone to the uncanny valley problem, my experience writing a desktop app with SWT suggests that you can go a long way with a cross-platform UI toolkit, as long as the toolkit is based on the highest-level native facilities that are applicable, and you can drop down to native when necessary. So I'm looking at cross-platform mobile development solutions that actually have strong developer communities behind them, and Xamarin and React Native are the top contenders.

This long-winded rant is the product of my last few weeks of thinking about cross-platform mobile development and surveying the landscape. Perhaps this thread wasn't the best place for it to finally burst out. Just know that it's a vexing problem even for someone who's been doing mobile development intermittently for a while (6 years for an iOS app, 3 years for the Android version).

Good luck with your mobile app.

[feech]

yea, cut me I bleed C# .. the transition to client libraries has been hard enough, but mobile has thrown me in a tizzy.

The straight up performance of Xamarin on my development machine was what through me. Getting it all setup and rolling and seeing the incredible amount of heavy lifting it took to get something rolling just turned me off completely.

I see what you mean about react-native, but from my perspective, the next-best-thing is a far enough second place finisher that I don't want to consider it. I still feel a native web based app running on all platforms is the ultimate best way to roll. We just need Apple to stop fighting it.