Good point. A better argument against the interpreted approach is that interpreted languages to a larger degree tend to be rather dynamic. With a platform like iOS where release cycles are fairly lengthy(not that this is really Warranted IMO) a static language is much more sensible. It's obviously a lot better to find as many bugs as possible before shipping and I would argue that this is much easier in stricter static languages. Frontend javascript for example is fine being dynamic and interpreted because it's easy to hotfix issues
I don't see a reason why a modern language, static or dynamic, could not have both a compiler and an interpreter. Most Lisps have both, Haskell has both. Also, most interpreted languages actually have a compile phase before the actual interpreter.
I do agree with you on that any platform should have a staticly typed language as a first class citizen.
What would be the use case for the interpreted version? I would assume it would be usable for the development process, surely running interpreted code on devices would be a total waste if compiled code is available?
During development is probably the best use case I can think of. With editor integration an interpreter is a tremendous help when coding. At least Lisps, Ruby, Python and Haskell have this kind of "development environments' to a some degree. I think GHCI even doubles as a debugger.
