If I understand it correctly it seems a bit orthogonal thing to binary diffs.
Slicing will prepare an app bundle per target from source app bundle.
Bitcode will be compiled to target spec.
On-demand resources are self-explanatory.
In Android AFAIK you have to do all those things by yourself. With this difference that you can't compile Java bytecode yourself and send it to the user. If you use NDK you have to do this. But I would argue that in most cases it does not result in major size differences. The biggest difference would be in case of app using lots of graphical assets that could be delivered with different DPI depending on device. However, as I said, AFAIK you can do this.
The bundle, the compiled binary and resources have to be somehow delivered to the user. The files probably in many cases would be delivered in compressed form. Either they will stay compressed and be decompressed on demand or be decompressed after download. Most probably it will be the former.
You can send whole data each time or give some kind of delta to whatever user has. In case of delta you can diff either compressed or uncompressed data. In case of former you will have the same issue as Google had with their bsdiff between APKs. In case of latter you will have to decompress the data and it would be a waste of space not to compress it again later. The results would be the same as what Google currently do.
If Apple would like to optimize the size of updates they would have to do the same (I don't know if they are not doing it already). To achieve this the data would have to be recompressed.
Slicing will prepare an app bundle per target from source app bundle.
Bitcode will be compiled to target spec.
On-demand resources are self-explanatory.
In Android AFAIK you have to do all those things by yourself. With this difference that you can't compile Java bytecode yourself and send it to the user. If you use NDK you have to do this. But I would argue that in most cases it does not result in major size differences. The biggest difference would be in case of app using lots of graphical assets that could be delivered with different DPI depending on device. However, as I said, AFAIK you can do this.
The bundle, the compiled binary and resources have to be somehow delivered to the user. The files probably in many cases would be delivered in compressed form. Either they will stay compressed and be decompressed on demand or be decompressed after download. Most probably it will be the former.
You can send whole data each time or give some kind of delta to whatever user has. In case of delta you can diff either compressed or uncompressed data. In case of former you will have the same issue as Google had with their bsdiff between APKs. In case of latter you will have to decompress the data and it would be a waste of space not to compress it again later. The results would be the same as what Google currently do.
If Apple would like to optimize the size of updates they would have to do the same (I don't know if they are not doing it already). To achieve this the data would have to be recompressed.