Develop Reference

C++ vs native implementation of iOS/android

I'm developing an app for iOS and android that identifies songs. We have a matching engine in c++ that works well, but my question is about the rest of the app. We have a user interface design that allows the user to record, match and save, as well as share, edit, and see their recordings.
I'm not a coder - just a designer- and I'm getting conflicting advice about how to implement. One person wants to do the majority of the interface in c++ with just a thin native GUI skin, while the other says we should write in native IOS (swift) and Android and only have the engine in c++. The argument for c++ is it will be a single code base to maintain - it would include doing the sharing, storing history, displaying sonograms, etc. The argument against is that in fact it will not be easier to maintain, and will also create a lot of problems making calls, for example, between the interface and the sharing module.
Hope this is clear - it's a very hard thing for me to assess as ignorant as I am! Any advice would be greatly appreciated.

In my opinion, the way to go is to write the GUI the way it was meant to be. Native iOS/Android will yield a much better user experience and will allow you to use the platform latest and greatest way of implementing a UI.
Also, I am assuming that the engine will probably not be developped by the same people that develop the GUI itself, so the argument that it would be simpler to have a single code base doesn't really make sense.
Another solution could be to use Xamarin, so that you can consolidate iOS and Android development, while still having a common C++ engine.
Edit: Typo

How are your experiences with NativeScript?

Does anyone have experience with NativeScript and can compare it to developing native apps, especially for Android?
I have read all these articles:
FIRST THOUGHTS ON NATIVESCRIPT
SECOND THOUGHTS ON NATIVESCRIPT
Introduction to Native Script – Is It Worth Your Time?
My Experience Developing with Telerik NativeScript
I know especially three of them may be outdated. But I want to ask all of you developers:
How is your experience with NativeScript?
Are there any Android-Components you cannot use? Which are these ones?
Is styling really so limited?
Do apps really look so different at runtime as in the mockup as in the pictures of the first article referenced above?
Does loading of native Android objects into JavaScript Code always work correctly?
Does NativeScript generate Java-Code for Android-Platform out of the NativeScript code I write?
Is it possible to modifiy this code if I want to use some native-only features? What if I want to make UI changes then? Do I have to regenerate the code and do I miss my native extensions then?

Very glad to see that you are evaluating NativeScript to eventually use it in present and future projects.
I'll try to condense answers to a few of the questions into one, as they really are mostly related.
Skipped.*
That depends on what has already been exposed through a custom view/plugin or module. The core-modules that every NativeScript app comes with contains the most basic of wrappers for both Android and iOS under a common API. There are plugins (nativescript npm modules) that provide additional wrappers on native android views (nativescript-telerik-ui for one, nativescript-carousel), most of which are created by the NS community.
As RexSplode mentioned before me - it's mostly the platform that imposes certain limitations. NS uses CSS to declare style, but you can also access the native components and manage their style and appearance programatically if what you need isn't readily available out of the box.
First I'd like to note that the first 3 articles you've linked are over a year old now, and trust me, NativeScript has evolved a lot since then. With all the available components (remember the npm modules I mentioned earlier?) there's a good chance that you will get a close to 1:1 similarity to a well-styled native Android mockup.
At build time metadata is generated for the Android/Java public API used in the project. When the JavaScript Engine (V8) fires up, that metadata is loaded into memory, prototype chains are constructed, and callbacks are attached, so that when you call new android.widget.Button(); in your JavaScript code, the proper virtual machine instructions will be called, and a native button will be created. Static methods are accessed similarly, check out the official docs to get a better understanding of how it all works.https://docs.nativescript.org/runtimes/android/advanced-topics/execution-flow
and 7., and a cont. of 2. Java code, or rather compiled Java code is generated whenever you wish to extend a native Android class that isn't available already in a module or in the native Framework. Extending classes is very similar to how you would do it in Java - you extend a class, and create new implementations of interfaces. That means that you won't have to open Android Studio to create a new class, build it into a native plugin and then add it to your project, since you can do it all in your NativeScript code using JavaScript/TypeScript. https://docs.nativescript.org/runtimes/android/generator/extend-class-interface
Disclaimer: I am on the NativeScript Engineering team

I investigated the Native Script a little and my colleague at work writes an app with it, so I can offer you a bit of information that I have.
1. skipped
There are limited amount of components you can use with native script out of the box. However, if you have a native-java developer who can write a wrapper for you - you can use everything.
It is limited to the platform you are using. Android itself has a lot of style limitations which cannot be easily overwhelmed.
don't know
It works a little different. Your JS object, or rather widgets are translated to java code. So with the items from the box - yes, they are okey. If you write a wrapper for your custom component, then all is up to you.
Yes it does.
No, the code is generated, how are you going to modify it? Changes will be undone on the next build. However, you can write a native module for your application and use any features you want. It is like defining an interface, which you can use in JS code afterwards.

React Native & Android?

I'm contemplating on using React Native for a new web app. Is it possible to ship both iOS and Android apps using it?
I know that it's on the roadmap, but it's unclear to me whether it's going to be a separate open-source project (e.g., React Android vs React Native), or just one (e.g., React Native).

TLDR: Most likely you can. But it depends on your use cases.
You can aim for about 80~99+% code reuse (depending on how much Android/iOS native views/modules you use eg. Do you have custom graphics code or low-level TCP networking code; Those can only be done in native code; And expose as API to your JS code. The amount of the platform-specific JS code is actually minimal. Plus you can also use platform check like if (Platform.OS === 'android'){} to solve that) of code reuse, which is pretty nice. Dropbox and other companies have done similar projects: using c++ to build a 'shared' component between iOS and Android project, while implementing most of the UI code in native iOS(Objective-c or swift) and Android(java). But now you are doing C++ with Java and Objective-C or Swift, more language to master, more complexity and more brain juice went down the drain. And it probably took some super tough gymnastic move to make different native code work in both iOS and Android, plus debugging...
React Native just makes it a lot easier to write almost everything in JavaScript. But there is a catch, only about 80% of the JS code could be shared. In the foreseeable future, you still need to write 'platform-specific' JS code for Android and iOS versions.
That's why FB said they aim for 'Learn once, code anywhere' instead of 'run' everywhere.
But it's still very nice other than code reuse(80+% code reuse is still a big improvement comparing to maintaining 2 entirely different versions: Android and iOS ya?)
Cmd +R to refresh the app is a GREAT boost for development speed. Waiting for a big project to compile just makes you felt you were dying inside.
Declarative UI you get for free, because of using React. This is another great plus! As you don't need to 'dig' into your specific UI code that often anymore. Data changed? Just 'flush' it and UI just update accordingly. No brain juice wasted.
I just ported my not so complicated Android React Native App to iOS. And it took me 3 days. The request for and iOS version for the App came as a rather abrupt and unplanned move. So could definitely be even faster had I built the Android with a plan for iOS too. Huge win:)
Another great benefit is able to do hot code push without going through the hellish 1 week app store review process. So no more, "YAY, our app is approved. Let's release. Oh Shiiit. Critical bug and our app keeps crashing(that's gonna keep happening for at least a week before your fix is live). And you have to beg Apple to speed up the process". This is possible because the major part of the code base would be written in JS and with tools like AppHub or CodePush, you could almost instantly deploy code to your users. This is conditionally allowed by Apple.
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code, and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Lastly, as an open-source project, project longevity tends to be a concern. Not an issue for React Native. Internally used by(FB Ads Manager) and backed by FB(a dozen FB Engineers?) by Facebook, with close to 500 contributors and 25k Stars, React Native is full of life. Seeing is believing :) (https://github.com/facebook/react-native)
EDIT 1
I realized that I am apparently a bit biased and only talked about the good stuff about React Native. So do checkout https://productpains.com/product/react-native/ and Github issues to have a full picture. It's definitely not silver bullet. That being said, it satisfies most of my use case and I couldn't see me use native iOS or Android anytime soon.
EDIT 2
The Facebook F8 conference app released by Facebook (duh..) is 100% open source and they have a really nice tutorial to show you how you could have both iOS and Android native experience(90% as good as native ?), and at the same time, achieved 85% code re-use. check it out --> https://makeitopen.com
EDIT 3
You may also want to checkout Flutter and its pros & cons :)

It doesn't make sense to have a single codebase if you want a truly native experience. At the moment we have things like NavigatorIOS in React Native which provides an iOS-style UI for navigating between app screens, but if we were to just start using that on Android it wouldn't feel like a true Android app.
Therefore I'd expect to see a NavigatorAndroid component or similar when the time comes, and the same for various other components that behave differently between the platforms.
One benefit that you would get is that any application logic - maybe a store, or your backend interactions - could be written in a JavaScript file and then included by both iOS and Android.
So while you won't get that write-once run-everywhere developer experience from React Native I would expect to see a solution that gives first-class UI on both platforms while encouraging as much reuse as possible. I personally also hope to see strong build tools to help develop and ship on multiple platforms.

React Native for Android has just been released, Android folder will be creating along side with iOS folder upon creating a new project.

Just another tip as NavigatorIOS was mentioned. Facebook are not really maintaining the code for NavigatorIOS. Instead they are focusing on Navigator.

Yes. We're running it in production with about 5m registered users.
Some things are a little behind iOS but catching up quickly. It's a good wagon to be on.

React Native is designed so that you can deploy to both iOS and Android. There is a caveat, of course.
React Native has supported iOS for much longer, coming to Android only recently. So, there are some differences in terms of what is supported on each platform.
For example, if you place borders on Text, they will show up on iOS, but not on Android. In order to overcome this, you need to place a View around the Text, and apply a border to that. Luckily, React Native makes it easy to integrate separate stylesheets for each platform (or even platform-specific styling on a single stylesheet).
Support for Android is continuously evolving, so it will only be a matter of time before React Native for Android is on par with iOS. Nevertheless, this shouldn't deter you. In my experience, it's a great way to quickly develop for both platforms, and it does save some headaches.

you don't need to maintenance separate code base for android & ios. Actually you can use same code base for build android & ios. I recommend to read the react-native documentation(according to react-native version you are using) before using any inbuilt component in your code.
Eg:- TextInput component onKeyPress function supports for ios only.
if ur are using external lib check these lib support for both ios and android.
Anyway you have to configure external lib separately(install) both android and ios.
hope this will helpful.

Trying to display Hello World character on android phone using native code

using stdout library it will maybe pass data to logcat or somewhere else which is not heading toward to display screen.
How can I manage to display what I want using native code with out passing dalvik...T_T

There may well be no officially supported way to do that. Android is fairly fundamentally based around java code running in the dalvik virtual machine.
It used to be your only option was to use jni between your own native and java code to pass the data through to the java-level Android display APIs.
In more recent versions, it is possible to write a so-called native activity where all of your code is C or C++. However, such an activity still runs in a process built around a dalvik virtual machine running platform-supplied java code, and calling into your code via jni.
There is an embedded Open GL native API which you could use to plot text, but it is quite likely that behind the scenes some jni is still involved, at the very least in the setup of the views.
Both the native activity and native use of open GL have examples in the ndk distribution.
I suppose you could also have you code interact via pipes or sockets with a different process which would display its output, but that's just moving the use of dalvik elsewhere.

Android NativeActivity

The Android NDK has just been significantly expanded to include support for writing android applications entirely in native C/C++ code. One can now capture input events on the keyboard and touch screen using native code, and also implement the application lifecycle in C/C++ using the new NativeActivity class.
Given all the expanded native capabilities, would it be worthwhile to completely bypass Java and write Android application in native code?

The NDK is not native per-se. It is to a large extent a JNI wrapper around the Android SDK. Using NativeActivity gives you a convenient way of dealing with certain app-life cycle events, and add your own native code on top. ALooper, AInputQueue etc. are all JNI wrappers of the Java SDK counterparts, some with additional code that is private and unaccessible for real apps.
When it comes to Android development, there's no such thing as writing an application entirely in native C++ - you will (in every real App case that I can think of) always need to use the Android API:s, which are to a huge extent pure Java. Wether you use these through wrappers provided by the NDK or wrappers that you create yourself doesn't really change this.
So, to answer your question: No, it wouldn't be worthwhile, because you would end up writing JNI wrappers for SDK calls instead of writing JNI wrappers to your own Java methods that do the same thing, with less code, simpler code and faster code. For example, showing a dialog using "pure c++", involves quite many JNI calls. Just calling a Java method through JNI that does the same thing will give you faster code (one JNI call), and, arguably, code that is easier to maintain.
To fully understand what you can do, you really must examine the Android source code. Start with native_app_glue.c, which is available in the NDK, then continue with the OS implementation of AActivity, ALooper, AInputQueue etc. Google Code Search is a great help in this. :-)
If it is easy to do in Java, and includes many calls, call a method through JNI that does it all, rather than writing all the extra code to do it with multiple JNI calls. Preserve as much of your existing C++ code as is reasonable.

Not if you are just making a standard application. The Java SDK is more complete than its Native counterpart right now so you would still be making things more difficult for yourself.
If you are not doing something that requires the NDK (read: real time performance sensitive) then stick with Java.

Just some food for thought but if you have an app on iOS and Android, some C/C++ code might be shareable. Obviously the iOS Obj-C and platform specific code wouldn't work elsewhere. (Ditto for the Android specific stuff). But you might be able have some shared code that's platform neutral.

If you can, stick with the java style apps until versions of Android supporting native activities constitute a significant fraction of the installed base.
For things that were hard to do before - particularly ports of existing code - this will probably be a big help.
It's not entirely clear yet what has changed vs. just writing your own thin java wrapper. For example, is there still a copy of the dalvik VM hanging around?