Android apps are interpreted rather than compiled. Does this make them slower than iOS apps at runtime?
Java isn't interpreted on Android. Android apps are compiled to bytecode by the developer. Bytecode is a compact representation of the program: smaller than the source code written by the programmer, but still not directly executable by the CPU. Some optimizations, such as dead code removal, can be made at this stage.
When you load the app on a device, the Dalvik JVM compiles the bytecode to native executable code, just as it's about to run. This is just-in-time compilation. It causes a brief slow-down while the program waits to be compiled, but after that there's no performance overhead, because the code has been compiled to native executable code.
There are some performance advantages to doing it this way instead of compiling up-front on the developer's computer. The app can be compiled for the particular CPU on the phone, taking advantage of its hardware features and using its performance characteristics. For example, it can use hardware floating-point operations if the CPU supports it. In addition, a clever JIT compiler (admittedly, Dalvik is not quite this clever) can monitor the way the program runs, and perform optimizations based on the way the program is used in real use. It might recompile the code with better branch hinting once it has seen which options are turned on and off in your environment, on your phone. An up-front compiler doesn't have this information to use.
Dalvik uses the Dalvik cache and other techniques to mitigate the drawbacks of JIT compilation. The new JVM for Android L and later, ART, replaces the JIT entirely with an ahead-of-time compiler. This compiles the bytecode to native executable code when the app is installed, to get most of the advantages of JIT without the delay loading the app.
Don't forget that Android apps don't entirely consist of Java. Developers have the NDK to write all or part of their apps in C or C++, for performance-critical parts of the app, especially for games. Special-purpose interfaces like OpenGL and Renderscript let programmers take advantage of special hardware like the GPU and SIMD coprocessor for some kinds of computation.
So really, there's no simple answer to your question. Using JIT instead of up-front compilation makes some things faster, some things slower. It's just one part of the overall performance of the OS.
Since this is a broad question, here's a broad answer.
"Are iOS apps faster than android apps since android apps are interpreted?"
First off iOS apps are not "faster than" android apps.
Secondly, regarding the issue "Android apps are Interpreted." This is something you'd say about computing, like "15 years ago": as you can see from the discussion above, the situation is much more complicated today; entirely new technologies have come to the fore. The concept "compiled is faster than interpreted!" was relevant comparing, you know, perl to machine code 20 years ago; things have moved on so much that issue can not be really clearly applied to "iOS V Android" today.
Thirdly, there are other issues in mobile programming that totally swamp such considerations. Just one example on the ground, mobile programmers knock themselves out over handling large scrolling lists of images, lazy loading, and similar issues. How the two OSs, and the various popular libraries, handles these critical issues often swamps other issues.
Fourthly, just one more overwhelming issue on mobiles is the issues of the graphics chipset and the various complicated relationships of that to software, OpenGL, and so on. For example, Apple is coming out with a system they calL "Metal" in relation to these problems, and Android is coming out with their own "thingy" in this field. These issues around the graphics pipeline are tremendously important to how apps "feel" in your hand.
The very short answer to your question is "compiled V. interpreted" is basically an out-of-date discussion point you know?
(Also, I don't particularly find a Note3 "slower" than an iPhone. Also, some of this is pure artefact - there does exist inexpensive Android phones: there simply aren't low performance iPhones made, so some people may have incorrect ideas from this.)
Android only executes native machine codes and not VM bytecodes.
Codes are compiled to byte-code by software developer (apk files)
During app installation, the byte-codes are converted to native machine codes for a specific CPU. This leads to longer installation and larger execution files but faster runs.
Because interpreted apps does not means that they are always slow. Sometimes they are more powerful and dynamic as compared to compiled one. As all codes in compiled app are compiled once & output is kept in form of libraries or executables, while in interprated language, once can randomly change the sequence of execution. So i can say, it depends of developer to developer and there way of programming.
However, Java (Android's programming language) is not interpreted but is JIT compiled. That means that Android programs compile just before you run them, giving reasonably similar performance to iOS' Objective C.
More recently, Android's ART framework pre-compiles the apps, so they are run in the same way as iOS apps. In other words, the next version of Android will presumably be just as fast as iOS.
Programming languages generally fall into one of two categories: Compiled or Interpreted. With a compiled language, code you enter is reduced to a set of machine-specific instructions before being saved as an executable file. With interpreted languages, the code is saved in the same format that you entered. Compiled programs generally run faster than interpreted ones because interpreted programs must be reduced to machine instructions at runtime. However, with an interpreted language you can do things that cannot be done in a compiled language. For example, interpreted programs can modify themselves by adding or changing functions at runtime. It is also usually easier to develop applications in an interpreted environment because you don't have to recompile your application each time you want to test a small section.