5 ms·

The one publicly known production use of bitcode was that it allowed them to recompile all existing armv7 watchOS apps as arm64_32, which made it so that the fi

The one publicly known production use of bitcode was that it allowed them to recompile all existing armv7 watchOS apps as arm64_32, which made it so that the first 64-bit apple watch could run existing apps. This required specifically designing arm64_32 (which is arm64 but with 32-bit pointers) to enable this, and isn't really a viable approach for anything other than this specific scenario where they knew that they'd be migrating to a specific new architecture in the future. Before the first 64-bit watch was announced they were very vague and hand-wavy about what bitcode was for because they had to keep the upcoming products a secret, and sort of implied that it'd be used for things which didn't actually make very much sense.

alerighi 4y ago
I think that here Android is a better ecosystem: you distribute your application as a bytecode, and then it's the phone itself to compile it to a real binary when you install it. This allow far greater compatibility with even very old versions of the OS or old applications in newer OS and simplifies the build process. Working in a company that builds both Android and iOS application I have to say that building iOS apps generates 10x the problems that you have with building Android applications, in terms of CI infrastructure, that means that Android you run gradlew and it works, provided you have the right JVM version installed, with XCode it's always a mess. Also for how it works the ecosystem with Android I'm not forced to upgrade, that means that if a project uses SDK X I can build it forever with that SDK and it will still work even on latest devices, with Apple you have to build with the latest toolchain if you want to execute on newer terminals. That makes Android far more suitable for b2b applications.
- arjvik 4y ago
  Until apps start adding native code via the NDK, then you need one binary per arch
  - pjmlp 4y ago
    Unless one is a game developer, otherwise using the NDK is an exercise in masochism. In any case, Intel devices used to have ARM emulators, and Android on ChromeOS still does it. https://developer.android.com/topic/arc/device-support#arm-translation https://developer.android.com/topic/arc/device-support#arm-t...
    - saagarjha 4y ago
      The NDK is important to applications looking to reuse native codebases.
      - pjmlp 4y ago
        While having the joy to manually write JNI wrappers to 90% of Android APIs, and fitting their build into CMake/Gradle scripts, or trying to fit building artifacts into AARs. It might be relevant, however Google's own documentation and tooling during the last decade is quite clear that one should stay out unless doing games.
        saagarjha 4y ago
        I’m not saying it doesn’t suck, but when has any developer listened to what the platform asks them to do?
- pjmlp 4y ago
  While I dislike the way Google has managed the whole Android Java story, the way they have doubled down on a managed environment for computing is great. Certainly not the first, yet it shows how it can look like when everyone is committed to make it happen, unlike what WinDev did during Longhorn project.

alerighi 4y ago

I think that here Android is a better ecosystem: you distribute your application as a bytecode, and then it's the phone itself to compile it to a real binary when you install it. This allow far greater compatibility with even very old versions of the OS or old applications in newer OS and simplifies the build process. Working in a company that builds both Android and iOS application I have to say that building iOS apps generates 10x the problems that you have with building Android applications, in terms of CI infrastructure, that means that Android you run gradlew and it works, provided you have the right JVM version installed, with XCode it's always a mess. Also for how it works the ecosystem with Android I'm not forced to upgrade, that means that if a project uses SDK X I can build it forever with that SDK and it will still work even on latest devices, with Apple you have to build with the latest toolchain if you want to execute on newer terminals. That makes Android far more suitable for b2b applications.

arjvik 4y ago
Until apps start adding native code via the NDK, then you need one binary per arch
- pjmlp 4y ago
  Unless one is a game developer, otherwise using the NDK is an exercise in masochism. In any case, Intel devices used to have ARM emulators, and Android on ChromeOS still does it. https://developer.android.com/topic/arc/device-support#arm-translation https://developer.android.com/topic/arc/device-support#arm-t...
  - saagarjha 4y ago
    The NDK is important to applications looking to reuse native codebases.
    - pjmlp 4y ago
      While having the joy to manually write JNI wrappers to 90% of Android APIs, and fitting their build into CMake/Gradle scripts, or trying to fit building artifacts into AARs. It might be relevant, however Google's own documentation and tooling during the last decade is quite clear that one should stay out unless doing games.
      - saagarjha 4y ago
        I’m not saying it doesn’t suck, but when has any developer listened to what the platform asks them to do?
pjmlp 4y ago
While I dislike the way Google has managed the whole Android Java story, the way they have doubled down on a managed environment for computing is great. Certainly not the first, yet it shows how it can look like when everyone is committed to make it happen, unlike what WinDev did during Longhorn project.