I find it frustrating that react-native applications are allowed live-update their application at ru...

# multiplatform

[spierce7]

I find it frustrating that react-native applications are allowed live-update their application at runtime on mobile. Has anyone found a way to do this with Compose Multiplatform?

[mbonnin]

I guess the closest is https://github.com/cashapp/zipline?

[Stefan Oltmann]

I assume to compensate this we have the Preview feature.
For me it’s still so slow that I am faster restarting the app and navigate to the view.
But maybe that will change some day.

[jw]

Yep we do this with Redwood + Zipline

[jw]

It's also a fantastic development experience

[spierce7]

@jw What method are you using, and how is google / apple ok with it?

[spierce7]

Nevermind. Looking into zipline now.

[jw]

We use a JS engine (sorta, we actually ship a JS-like bytecode), same as React Native with Hermes

[spierce7]

I actually talked to you about this at the first Kotlin conf and you mentioned you were using something like dukt to do this for network requests.

[spierce7]

or rather, sharing code between platforms using js

[jw]

Duktape, yes. Zipline is the successor/supplanter.

[jw]

Duktape is a JS engine. Zipline is an abstraction on why you use a JS engine, and you never see JS. It binds Kotlin on both sides of the VM and transparently allows calls in both directions.

[spierce7]

So how many layers of your code base are you able to update on the fly?

[jw]

Different parts at different layers. For our Compose usage, we're updating presenters which talk to networking and database layers below and emit platform-agnostic representations of views to be bound to the native UI. We also have updated the native app's navigation framework to allow destinations specified only by a URL to dynamically ship entire new screens without an app update

[spierce7]

You mentioned js-like bytecode. That's QuickJS bytecode?

[jw]

Yes, for now. Eventually we'll switch to a WASM engine and WASM

[spierce7]

That will indeed be nice

[spierce7]

the problem seems to me that you can only really do this with the middle portions of your app. Any sort of database access, you'd have to come backout of zipline, but that's not the end of the world. Making HTTP requests inside of zipline and forgoing a database would allow you to ship most of your app in this fashion

[spierce7]

I wonder if it's reasonably possible to abstract the UI into it, so that your entire app was just a zipline service(s), and you only came out to access external platform services.

[jw]

now you're getting it

[jw]

and we could call it: Firefox!

[spierce7]

lol

[spierce7]

I can't tell if you are being serious

[jw]

¯\_(ツ)_/¯

[jw]

the entire premise of what we're doing it to steal the web's best features because the idiots at Apple and Google refuse to honor the web

[jw]

native apps are stupid. they have no technical limitation as opposed to a web app except through restrictions imposed by the surrounding host operating system

[jw]

maybe one day WASM will help tear that down. until then, we're doing this.

[spierce7]

that's actually what I was wondering, concerning wasm

[spierce7]

So in the implementation of what you are discussing, this is one of the reasons you are pushing into redwood instead of moving towards the more standard compose multiplatform?

[jw]

we have existing native apps which are gigantic. we don't want a split-brain problem with components implemented twice. native UI tends to be the best UI, so we try and use that as much as possible. it doesn't preclude sharing the rendering layer, but it's not an immediate goal.

[spierce7]

I'm wondering if Redwood would effectively allow you to asyncronously communicate via the UI, and effectively you could ship app updates via zipline unless you added a new UI component that altered native code

[jw]

that is what we're doing. as of friday we have two versions in the wild that we can now target and update with either an update to an existing screen or by pushing an entirely new screen the clients have never seen. the only restriction is that you have to use the UI components of the least-supported version.

[spierce7]

oh wow, and that's all possible via redwood and zipline then?

[spierce7]

so when is redwood going to be ready for me to use and consider? 😛

[spierce7]

You've kind of got my mind reeling here. I'm questioning a few assumptions I had made about redwood. Does redwood integrate with zipline by default? Is the entire point to be able to run the composable ui logic in JS and then somehow rendering it in the native UI?

[jw]

Redwood itself is only the Compose targeting a design system representation of a multiplatform UI toolkit. This would be an app whose presenters are written in Compose (not Compose UI) but targeting the native UI toolkit and whose Kotlin was compiled to the intrinsic execution mechanism of that target platform (Android bytecode, LLVM IR, JS).

There's a module in Redwood called Treehouse, which is Redwood running on Zipline. Here an indirection is placed between what we call Redwood Compose and Redwood Widget which allows all operations to be serialized across the Zipline bridge (the Redwood Protocol).

[spierce7]

this is amazing. Animations would be very complicated with redwood, I'd imagine.

Not critiquing, but trying to understand, why take this approach instead of just rendering to a canvas from js code? Are using the native widgets under the hood that important?

[jw]

The current plan is to send animations as either semantic "çross-fade" or equations (alpha from 0f to 1f for 2s) and have them run 100% host-side.

[jw]

I think using the native widgets has tons of advantages and makes the project feasible to build by two or three people instead of like 50

[spierce7]

Not going to make the same mistake as react-native? 😛 That makes sense. Animations would have to be simple then I'd imagine

[jw]

The system is not meant to replace 100% of UI in our app where you have a really rich UX. And ultimately you can choose the level of abstraction of your widget set so usually complex animations can be encapsulated entirely at the UI-layer hidden by a normal property change

[spierce7]

I think using the native widgets has tons of advantages and makes the project feasible to build by two or three people instead of like 50

Wouldn't you just re-use compose ui to make it as easy as possible?

[jw]

maybe in 5 years once Compose UI works on iOS and the web

[spierce7]

Anyways, this is amazing

[jw]

also doing so would immediately alienate our entire iOS and web teams and the project would become like a trojan horse they have to fight. some still fight, but many have since learned Kotlin and Compose and are contributing because they still get to design delightful UI and the host services.

[spierce7]

Super valid point.

[Joel Denke]

Follow up question, what is needed today to Apple and Google allowing this? I mean update stuff without go through their app stores? A lot less has been triggering deny upload updates I mean. Where is the line?

[xiaobailong24]

https://github.com/cashapp/redwood/issues/1305
My mind about Redwood.

[jw]

Apple and Google need to provide "installable" JS web pages, which both mostly do, but they need to go farther and elevate them to intrinsically behave like native apps rather than requiring a wrapper shipped in the app stores (which both allow) or the awkward PWA experience. Safari actually made huge leaps in the latest iOS and MacOS here. Things like persisted JIT and AOT code caches need added so cold start experience is fast. Exposing platform-specific APIs into the WASM and/or JS runtime which is not a replacement for the standards process, but not everything must be standardized across vendors. The web is already built on progressive enhancement, after all. It doesn't need to be 100% of the capability, but also why isn't it 100% of the capability? Like a lot of things the limiting factor here is rarely the underlying technology itself.

[jw]

Just having the web and native apps skate towards each other slowly would be better than the current status quo of each company forcing them to be parallel worlds

[Joel Denke]

@jw Wow that explains a lot. I think iOS 1 was web only if I am not mistaken. Wasnt Palm OS and Samsung old WAPP store being web as well. Like before iOS and Android was distributed "app" stores.
So to align techniques they need to replace their own app stores. I guess Cydia not an option.
Do you think WASM and such will help us skate towards?
I have a wish large tech companies would co op more. Just a little leap of co op would be amazing.
I guess it would be hard making JS or Kotlin make this leap for 100% performance for everyone?

[jw]

WASM is a requirement. JS simply is not a language or a bytecode format for other languages that can peak anywhere near native performance. It's had tens of thousands of person-years thrown at it and those people have done herculean things, but ultimately it's a terrible language for what we need today.

[spierce7]

The world you are describing, is one that I'm pretty sure apple would reject. They are so exclusive, I feel like they want people to make explicitly designed products for their system. They don't want sharing.

That being said, I'm shocked they allow react-native to do as much as it does, and ship a javascripe engine for apps to interact with.

[Joel Denke]

@spierce7 Yeah a lot of shocking things when some small minor things get rejected. Dont get me started on payments 🤣 Apple do a lot of open source, but maybe only one direction?
I dont mind unique design and products. But why cant we share programming languages or core engines at least. Mac using Unix kind a, and Android Linux. Not entirely but kind a. They have a lot in common.
Would be nice compete at products and not software frameworks and patents.

[Stefan Oltmann]

Regarding Apple I consider having technologies like a JS engine risky. Maybe they are just not aware of that and don’t care today, but ban it tomorrow. Hard to predict what they are up to. I remember how all these Adobe Flash apps got suddenly banned because Apple did not want it anymore.

I like how my Kotlin code compiles to Objective-C and becomes indistinguishable for Apple from other Objective-C frameworks, so they can’t ban it suddenly.

[jw]

It's absolutely distinguishable in the same way the JS engine or WASM engine itself is distinguishable.

[Stefan Oltmann]

How does a XCFramework created by Kotlin/Native differ to a „real“ one?

[jw]

What is a "real" one?

[jw]

Kotlin does not compile to Objective-C it compiles to LLVM IR and produces Objective-C headers for Objective-C (and Swift) to call into that code.

[jw]

It has very unique markers such as its own garbage collector and standard library that make it trivial to target with automated rejection tools.

[Stefan Oltmann]

Something I wrote with XCode in Objective-C would be a „real“ one.

[Stefan Oltmann]

Yes, ok, you are right about the standard lib components of course.

[Joel Denke]

Isnt Swift using LLVM to objc as well in similar way? I guess without GCC though?

[jw]

Swift compiles to LLVM IR the same as Kotlin, yes.

[Stefan Oltmann]

So what Apple could not like is Kotlin stdlib and ban that. That’s more unlikely than they deciding that they won’t accept JS code anymore.

[jw]

But there's no JS code in the app. There's a JS engine. That JS engine could just as easily be written in Kotlin or Swift.

[Stefan Oltmann]

I see.

[jw]

It's code which interprets binary downloaded over HTTP. Is that my Kotlin multiplatform reading protobuf and conditionally populating some UI elements based on it? Or is that a WASM engine downloading WASM and running full-on logic?

[Joel Denke]

Can they even do that? I mean their own stuff from Google and Apple using these tech stacks. Would be hard ban lets say JS but use JS themselves.

[Stefan Oltmann]

Now I see your point, Jake.

[jw]

I'm just banking on never being as large as React Native

[jw]

Second place feels very comfortable!

[Joel Denke]

Also will be interesting if AI can write machine code directly, convert any code and run directly, WASM kind a but one level up. Then our high level languages made by humans for humans will be obsolete. But until then I like Redwood, CMP, KMP and such, solve what React Native didnt succeed. Will be interesting see if competes with Flutter.

[Stefan Oltmann]

Would be hard ban lets say JS but use JS themselves.

I think Apples apps can do a lot of things third parties are not allowed to. Because we can’t be trusted. 😉

[Joel Denke]

JS cant be trusted either (security flaw by design), see no difference :) But yeah SMS and email still exists 😘

[Stefan Oltmann]

Also will be interesting if AI can write machine code directly, convert any code and run directly, WASM kind a but one level up. Then our high level languages made by humans for humans will be obsolete.

No, they won’t. You just add a new abstraction where how you write the prompt for the AI becomes the next kind of programming language. As long as we don’t have mind readers there will always be programming languages of some kind.

[jw]

Are you referring to eval? Zipline does not enable eval support so there's no way to do anything but normal execution.

[Joel Denke]

Protecting memory in JS, is that possible? So many zero days exploits in v8 stopped counting long time ago. Perhaps possible isolate, but havent seen anyone succeed yet. Eval just one of them :)

[jw]

You are forbidden from JIT/AOT by Play Store and App Store terms of service so the engine is always an interpreter and no native memory access is available.

[jw]

Unless you are talking about flaws in the engine itself, but that's not JS's problem since any native code can have those bugs.

[Joel Denke]

Was thinking other apps installed attacking your js engine. Can happen OS level as well, but more common in browsers and JS if I understand correctly.
I think in most cases its easier targeting JS even though not necessarily JS itself being weakest link. Too easy interpretation stuff non type safe.

[jw]

Ultimately we aren't loading arbitrary code, though. It's our code, just within a VM rather than compiled natively.