No offense but it sounds like you don't make even remotely complex apps if you think very little needs to be native. When you make more complicated software you'll realize native really is the only way to go.
I can't imagine what correlation there could possibly be between "complexity" and the need for native code.
Indeed, the more complex the less attractive native becomes. Complexity means more code. I want as much code as possible to be in the highest-level language with the greatest specificity to the task at hand. Java/Swift are seldom that!
I had a revelation early in my career. I ported an application from mainframe Fortran to IBM PC Fortran. (Watcom, actually). It's an application that does variation simulation analysis (VSA). 35 years later, BTW, it still lives - it's now called Siemens Team Center Visualization VSA. The manufacturer of your car(s) disk drives, any commercial aircraft you've flow on - probably used it to model assembly variations.
One of the difficulties at the time was that mechanical engineers had to model assemblies in Fortran. It was difficult, the code was hard to read, it took a 1/2 hour compile/link cycle to try out a model. I designed a language specific to creating variation models. It had primitive types for e.g. points, lines, planes, fixtures, assemblies. Way more intuitive than Fortran arrays!
I implemented a compiler for the language. Instead of producing machine code, the compiler produced a bytecode. The bytecode was INTERPRETED. The interpreter was written in FORTRAN, fergoshsakes! Now an engineer could try-out a model in just a few seconds. But how ever was that going to perform well?!
Very well, it turns out. Almost all of the time was spent in statistical and matrix functions, written in Fortran. And Fortran was (and still is) pretty darn good at that kind of stuff. The time spent in the interpreter running loops, if statements, etc. was peanuts in comparison. We hired a mathematician to clean-up the Fortran library code - fixing the bugs, using heuristics instead of the classic algorithms that had been used by the university professor who originally wrote the application. A very tiny bit of code was re-written in assembly language.
At the start of the project, there had been little hope of getting the PC version to perform as well as mainframe. In fact, it wound-up beating the mainframe version by hundreds of percent. It enabled a revolution in manufacturing and was quickly adopted by the big-3 auto makers, airframe makers, etc. The FA-18 E/F was modeled head-tail in this language as part of the effort to fix the problems with that airframe.
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA379633
(5.2 Variability Control)
VSA modeling enabled the first use of HOLES (instead of slots - and costly manual alignment) to assemble car hoods to bodies. (Corvette, BTW). (Today, though, models are defined interactively on a graphics screen. I don't know if the language I designed is still used, but I do know that at least a few years ago, the graphical definition of models still produced source code in the language I designed.)
Point being? Performance has nothing to do with what language is used to create an application. It has to do with correct and well-performing algorithms, and the APPROPRIATE use of languages for the task at hand. I almost ALWAYS use a mix of languages, and every one of my hybrid apps has some amount of native code - which I keep at a minimum because it has to be re-written for each platform.
I learned early on that good performance comes from understanding where the application spends it's time - identifying the bottlenecks and dealing with them. A language as low-level as Swift or Java or Objective-C is rarely needed for the bulk of the code in application development.
I suppose it was a lucky happenstance that the purpose of that particular application was, in fact, to identify a sort of "bottleneck" in the design of mechanical assemblies, and I saw how the product was being applied. How much do you think your car would cost if every machining operation were done with the utmost of precision, regardless of need? The key is identifying WHICH operations require HOW MUCH precision in order to avoid rejects. The same approach can and should be applied to software design. WHICH bits of code require a low-level language, require native APIs, etc. to meet performance goals? A blanket application of the use of expensive, low-level tools and APIs is just fool-hardy and excessively costly. No matter what Apple tells you.
---
Some input from OP on just what he considers "the most simple app" would be helpful. And whether it needs to run on both iOS and Android. We've already heard from him a hint that he feels that native may be too complicated for his tastes. With some specific input, we can give more specific advice.
I think perhaps we've misunderstood his intention a bit. I think by "most simple app" he wants a small example to see what is involved. Something more than a "hello, world", but not that much more.
Still, it is useful to know what sort of app(s) he intendeds to eventually create, and for what platform(s).