There are properties that work on one platform only, either because they can inherently only be supported on that platform or because they haven't been implemented on the other platforms yet. All of these are annotated with @platform in JS docs and have a small badge next to them on the website. See e.g. Image.
There are known cases where the API between iOS and Android could be made more consistent:
<SwitchAndroid> and <SwitchIOS> are very similar and should be unified to a single <Switch> component<AndroidViewPager> (to be open sourced soon) and <ScrollView pagingEnabled={true}> on iOS do a similar thing. We might want to unify them to <ViewPager>.alert() needs Android support (once the Dialogs module is open sourced)LinkingIOS and IntentAndroid (to be open sourced) closer togetherActivityIndicator could render a native spinning indicator on both platforms (currenty this is done using ActivityIndicatorIOS on iOS and ProgressBarAndroid on Android)ProgressBar could render a horizontal progress bar on both platforms (currently only supported on iOS via ProgressViewIOS)There is currently no easy way of publishing custom native modules on Android. Smooth work flow for contributors is important and this will be looked at very closely after the initial Open Source release. Of course the aim will be to streamline and optimize the process between iOS and Android as much as possible.
There is a noted difference in the handling of Views with an opacity of 0 between iOS and Android. While iOS will allow these views to be clicked through and the View below will receive the touch input, for Android the touch will be blocked. This can be demonstrated in this example where it will only be possible to click the touchable on iOS.
There are properties that work on one platform only, either because they can inherently only be supported on that platform or because they haven't been implemented on the other platforms yet. All of these are annotated with @platform in JS docs and have a small badge next to them on the website. See e.g. Image.
There are known cases where the API between iOS and Android could be made more consistent:
<SwitchAndroid> and <SwitchIOS> are very similar and should be unified to a single <Switch> component.<AndroidViewPager> (to be open sourced soon) and <ScrollView pagingEnabled={true}> on iOS do a similar thing. We might want to unify them to <ViewPager>.alert() needs Android support (once the Dialogs module is open sourced)LinkingIOS and IntentAndroid (to be open sourced) closer together.ActivityIndicator could render a native spinning indicator on both platforms (currenty this is done using ActivityIndicatorIOS on iOS and ProgressBarAndroid on Android).ProgressBar could render a horizontal progress bar on both platforms (currently only supported on iOS via ProgressViewIOS).There is currently no easy way of publishing custom native modules on Android. Smooth work flow for contributors is important and this will be looked at very closely after the initial Open Source release. Of course the aim will be to streamline and optimize the process between iOS and Android as much as possible.
There is a noted difference in the handling of Views with an opacity of 0 between iOS and Android. While iOS will allow these views to be clicked through and the View below will receive the touch input, for Android the touch will be blocked. This can be demonstrated in this example where it will only be possible to click the touchable on iOS.