Swift tries to be two things: a language tailored towards high speed and memory efficiency, and a language that provides high level abstractions.
But most apps do not need to hit high levels of performance. You swipe and the code will transition between pages, and then the CPU sits there idly by until the user initiates another action. Most user interface code would be tolerable at 100ms, but Swift aims for 1ms. The slowest thing about our apps is usually data I/O, and that’s not something a language can even fix!
In some cases, there are genuine needs for certain code to be really fast. This falls into two general categories: games, and data algorithms. I’m not talking about games here, that’s a completely different beast. But for algorithms, they can be separated and isolated from the rest of the code base.
There are many popular React Native apps with many users. While it is true that they are slower than native apps, this also means that if Apple were to create their own version of this layer themselves and make it a blessed native way to develop, then they have much more opportunity to optimize it.
And how much easier would this make it for Apple to transition to a more modern approach to view handling. It’s true that ViewController, storyboards, and auto-layout were heading in the right direction, but it shouldn’t be the final destination. React, React Native, and Flutter all show us that developers crave a simpler and more intuitive way to build mobile apps. Now Apple needs to step up to the plate and take the initiative, or risk falling too far behind.