Trying to understand if `WASM` binaries can be downloaded dynamically in runtime, loaded onto `andro...

# webassembly

[Jishin Dev [JD]]

Trying to understand if WASM binaries can be downloaded dynamically in runtime, loaded onto android/iOS/web platforms to be able to do OTA updates to our SDKs.
• Has anyone explored this already?
• Any pointers/tips to know if its actually worth a shot?
• Is this even a good idea? 😅
• Does GooglePlay/AppStore flag such SDKs (that use dynamically downloaded code)?
Idea is to stop having the client to upgrade the SDK and make releases every now and then for minor changes, bug fixes or feature upgrades..

[jessel]

I don’t think anyone has directly explored this for WASM at this point, but your use-case sounds very similar to the goal of Cashapp’s Zipline library, which uses Kotlin/JS and intends to explore WASM in the future

[Jishin Dev [JD]]

Sweet! Thanks @jessel 🙌

[CLOVIS]

As an aside, I'm not sure who your clients are and what their requirements are, but I believe a lot of people would consider this a deal breaker. I'm never using a SDK that does this.

[Jishin Dev [JD]]

Interesting. Can you help us understand your exact concern here @CLOVIS? Is it security? Performance? Dynamic code execution? Something else? Or all of them and more? 😄

[CLOVIS]

All of them, and reproductibility. If it worked yesterday one way, and I myself didn't change anything, it should behave exactly the same way.

[CLOVIS]

It's already difficult enough to find where bugs come from when using a lot of libraries, if I discover one of them just changes over time without control, I'm removing it.

[Jishin Dev [JD]]

I'm sure versioning would be able to solve for the last one. No? The changes pushed dynamically should no way impact API I/O.

[CLOVIS]

What kind of changes are you thinking about?

[CLOVIS]

Anything that is user-visible cannot change without my control.

[CLOVIS]

If a bug existed when I released a version, I want the bug to still exist two years later when I checkout that version.

[Jishin Dev [JD]]

Nothing user-visible or breaking, unless there's a bug.
Everything non-visible.

If a bug existed when I released a version, I want the bug to still exist two years later when I checkout that version.

Yes this is exactly what we're trying to solve for. This is not something we want. 😄

[CLOVIS]

Then you don't need anything complicated. You can just publish new versions to Central or anything else. Like everyone else does.

[Jishin Dev [JD]]

Just like how it works for patches done to web libraries.

[CLOVIS]

If a bug existed when I released a version, I want the bug to still exist two years later when I checkout that version.

This is, by definition, incompatible with OTA updates.

[Jishin Dev [JD]]

Then you don't need anything complicated. You can just publish new versions to Central or anything else. Like everyone else does.

The clients will still need to update once we push to central. Which is another hurdle to jump. Which will be avoided with this.

[Jishin Dev [JD]]

Yes, but unless the OTA has anything breaking, for the case at hand, I think this approach works is what I was saying.

[CLOVIS]

Do you have an example of something you can change that is not user-visible, and does not impact the behavior of the app in any way?

[CLOVIS]

I don't believe that exists.

[Jishin Dev [JD]]

There are many but let me give you one - Analytics.

[CLOVIS]

Which part of analytics? Fixing a bug in your data collection is visible. Changing the way you do requests has performance impacts that are user-visible.

[CLOVIS]

I guess the only change you can do, is editing the name of a measurement. I'm not trusting anyone (including myself) to have the discipline necessary to never make any other change, given the power.

[CLOVIS]

What happens when your servers are down? All apps of all users of the SDK breaks?

[Jishin Dev [JD]]

Fixing a bug in your data collection is visible.

I would hope it is visible. That is the point. 😄

Changing the way you do requests has performance impacts that are user-visible.

If changes have gone through QA and proper testing, the impact to ux(if any) would be insignificant compared to the other intense operations that happen within the SDK in parallel. At least this is not the concern we have for this use case but you're right, maybe something that can be considered for other projects where it's a priority.

What happens when your servers are down? All apps of all users of the SDK breaks?

Well that would be bad. So, we workaround by shipping a version with the SDK package. This also takes care of the initial load scenario where the client app doesn't have to wait for anything to be downloaded. May be wrong but I think zipline already takes care of this.