Expo (and react-native) apps use native (android and ios) ui components to render the apps ui, like any native android or ios app would. Therefore they can be considered as native apps.
However your app logic is executed within a javascript thread an will communicate with the native threads (through the react-native bridge) to modify the native ui components. Since the bridge is completely asynchronous this should not affect the native ui performance of your application. If you want to understand the communication between js and native code it may be a good start to read this guide.
2- create react native app --> no need to compile the native code !!
With expo there is no need to compile native code, as expo already includes a "ready to use build" of react-native along with several other common react-native libraries. In an expo app this will be used together with your javascript bundle which than communicates through the react-native bridge with the already present native part.
They are basically just abusing the fact that you can inject different javascript bundles into a prebuilt react-native app. (as long as you are using only accessing a subset of the native functionality of that prebuilt app)
Note that Appcenters codepush uses the same functionality and their setup integration actually delivers a nice example how different javascript bundles can be loaded without touching the native part:
in ios AppDelegate.m this line is changed:
original react-native js-bundle loading which always resolves a static bundle
return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
js-bundle loading with codepush which can resolve to different js-bunldes
return [CodePush bundleURL];
Link to full codepush ios integration guide