4 ms·
Platform independence isn't really a big deal. Apple managed this just fine with fat binaries, and you could have an analogous system on Android without problem
by grey-area 12y ago
Platform independence isn't really a big deal. Apple managed this just fine with fat binaries, and you could have an analogous system on Android without problems and a build chain that automatically cross-compiled (easy in golang). Developers wouldn't even have to notice. The size of binaries is often a small part of the total size of the app - resources tend to take up much more room.
The real problem would be porting all the current APIs. If Google actually decided to do this though it would be a good opportunity to clean up the current APIs and provide a new version free from legacy cruft. So it is doable, but a fair amount of work to provide UI bindings etc.
The obstacles are more political and monetary than technical.
- hrjet 12y agoApple controls and chooses the hardware targets by itself. Android is open and the potential number of hardware targets is limitless. It's not just about the size of the binaries; the app and the programmer should ideally be agnostic of the hardware. On an open-platform with closed-source applications, the least awkward way to do this is to push the native translation to the run-time.
- grey-area 12y agoIn practice, is the number of hardware targets larger than two or three? I doubt it would be a problem for google to certify hardware targets.
- tormeh 12y agoBut here's the kicker: The number of targets is a variable. Google would have to force developers to recompile for each new ISA. New ISAs keep getting added, many of them ARM ISAs that are not mutually compatible.