Smartphones are a good argument for both views IMHO. Native development (as in native machine code executables) on Android is still a terrible experience even though they had a decade to fix it. It's much better on Apple platforms, maybe because they actually cared about developer-experience and native code is a "first class citizen" there.
It goes beyond the different instruction set of course and most of the time this is indeed mostly irrelevant (unless you've arrived at processor-specific optimizations), but the "develop on the same platform you are running on" still has the least painful workflow IMHO.
I think the ARM-based Macs are inevitable, although it might be called "iPad Pro Developer Edition".
This is Jeff Atwood's argument: https://blog.codinghorror.com/the-tablet-turning-point/ ; Apple tablet performance at Javascript is now catching up to and exceeding desktop performance. Apple have also sunk a lot of money into developing their own processor line, and they have experience in force-migrating all their customers between architectures. At some point you might not be able to buy an Intel-based Apple laptop any more. Given the immense brand loyalty among web developers, they are likely to shrug and carry on .. and start demanding ARM servers with high Javascript performance.
I just wonder if Apple can design laptop chips that perform well (per watt) at 45W TDP or desktop chips at 2-3x that and with multiple sockets. If not, then what’s the point?
I won’t move to an ARM Mac, personally. I will move to Windows or Linux on x86 for all the reasons Linus gives and also for games. Sorry, but an ARM Mac may finally push me where crappy keyboards and useless anti-typist touch bars have not quite done.
Native (NDK) development on Android is hard on purpose, as means to increase the platform security and target multiple SOCs.
NDK level programming is explicitly only allowed for scenarios where ART JIT/AOT still isn't up to the job like Vulkan/real time audio/machine learning, or to integrate C and C++ from other platforms.
In fact, with each Android release, the NDK gets further clamped down.
I would like a better NDK experience, in view of iOS and UWP capabilities, on the other hand I do understand the security point of view.
Yeah, right, just like the PS3 was intentionally hard to develop for to keep away the rubble. That worked out really great (at least Sony did a complete 180 and made the PS4 SDK a great development environment).
As long as Android allows running native code via JNI, the security concerns are void anyway. If they are really concerned about security, they would fix their development tools (just like Apple did by integrating clang ASAN and UBSAN right into the Xcode UI).
One article is about enforcing the exvlusive use of public APIs. The rest is about hardening the C/C++ code of AOSP. I dobnot see any "clamping down" here. What am I missing?
Except they allow nearly everything for regular Android apps since libc lets you access nearly every syscall.
Nothing was meaningfully "clamped down" there. You can't directly syscall some obsolete syscalls anymore, and you can't syscall random numbers, but nearly any actual real syscall is still accessible and nothing indicates that it won't be.
As long as libc can do it so can you, since you & libc are in the same security domain. Or anything else that an NDK library can do in your process, you can go poke at that syscall, too.
It'd almost always be stupid to do that instead of going through the wrappers, but you technically can
This is mostly setgid/setuid, mount point and system clock related stuff. Except for syslog and chroit, I see no syscalls that you should be using in a user process anyway.
So technically, this is clamping down Android, but it seems like a pretty reasonable restriction and far from a heavy handed approach.
I bet Apple's experience moving from PowerPC to X86 gave them a leg up as well, and in both cases (PowerPC/X86, MacOS/iOS) they had the power to force developers to cross-develop to maintain access to their platform. Nobody is in a position to force server-side developers to switch to ARM.
From the other perspective too, Google clearly seemed to want the flexibility to change the details of Android architecture on a "whim", seeming to settle on the Linux kernel at the last minute and expecting to support both ARM and x86 and whatever else they felt they wanted. Google's focus on the JVM/Dalvik and making Native hard in Android seems quite intentional, forcing developers to cross-develop in a different way by obfuscating as much code as possible into a virtual machine that they could 100% control abstracted from underlying architecture and even kernel.
What do you think can be improved in Android? Unlike iOS, Android is actually running in diverse hardware. All iOS devices are Arm, where as Android will run on x86. That alone makes it more of a hassle.
The command line C/C++ toolchain is fine, at least now where this is basically reduced to clang and libc++.
The problem is basically everything else:
- The ever changing build systems. And every new "improvement" is actually worse than before (I think currently it is some weird mix of cmake and Gradle, unless they changed that yet again).
- Creating a complete APK from the native DLL outside Gradle and Android Studio is arcane magic. But both Android Studio and Gradle are extremely frustrating tools to use.
- The Java / C interop requires way to much boilerplate.
- Debugging native code is still hit and miss (it's improved with using Android Studio as a standalone debugger, but still too much work to setup).
- The Android SDK only works with an outdated JDK/JRE version, if the system has the latest Java version, it spews very obscure error messages during the install process, and nothing works afterward (if it needs a specific JDK version, why doesn't it embed the right version).
The Android NDK team should have a look at the emscripten SDK, which solves a much more exotic problem than combining C and Java. Emscripten has a compiler wrapper (emcc) which is called like the command line C compiler, but creates a complete HTML+WASM+JS "program". A lot of problems with the NDK and build system could be solved if it would provide a compiler wrapper like emcc which produces a complete APK (and not just a .so file) instead of relying on some obscure magic to do that (and all the command line tools which can do this outside gradle are "technically" deprecated).
...hrmpf, and now that I recalled all the problems with Android development I'm grumpy again, thanks ;)
MIPS support has been officially dropped but x86 is still very alive - mostly due to the emulator these days, though, but some Android TV hardware was using it for a while, too.
Native development sucking on android is mostly an android problem (and to some extent a Qualcomm problem since their smartphone SOCs don’t support anything else.)
It goes beyond the different instruction set of course and most of the time this is indeed mostly irrelevant (unless you've arrived at processor-specific optimizations), but the "develop on the same platform you are running on" still has the least painful workflow IMHO.
I wouldn't mind an ARM-based Mac though ;)