Best approaches to migrating to an application interface?

[charlieforward9]

I have a web app built with react and deckgl that I would like to turn into a mobile app over the coming months.

Ideally, the transition should be smooth, but I know that is not how the world works. Are there any suggestions I should look at for the best way to preparing myself for the challenges of migrating this web-based solution into an application interface?

Thank you!

[ibgreen]

Are there any suggestions [for] migrating this web-based solution into an application interface?

Not quite sure what you mean with that. There is no native mobile API for deck.gl.

If you wanted to do use deck.gl in a mobile app, you will likely have to run your deck.gl web app in something like an iOS WebView and whatever the counterpart is on Android.

It is possible to communicate between the JS code in the WebView and the surrounding mobile application code, on iOS this would likely be Swift. There is a very old example of this in https://github.com/UnfoldedInc/ios-showcase/tree/master/UnfoldedShowcase/View. Unfortunately deck.gl maintainers won't be able to help you with this, but perhaps the community can be of assistance.

[charlieforward9]

@ibgreen Thank you.

We currently use deck.gl and hubble.gl in our platform and are planning to expand our use as our feature set evolves.

I’m trying to scope the challenges of running deck/hubble.gl within a mobile SDK context—whether through a hybrid framework like React Native / Expo / Ionic or similar. I realize this likely implies WebView embedding, and I'm wondering if there are known limitations or guidance for:

• Performance
• Interactivity
• Accessibility
• Export or recording support in hubble.gl

Ultimately, I'm trying to plan a migration path that avoids major rework later. Any insights, pitfalls, or references would be greatly appreciated.

RFC: @chrisgervang
CC: @ManuelCortes23

[chrisgervang]

To evaluate Hubble.gl support we can break it down into its 3 main features: animation, playback, and recording. The first two don't have any known limitations, but recording is limited by available memory and browser APIs.

My recommendation is to try the live examples on the website like https://hubble.gl/examples/website/quick-start

Mobile browsers have good support for photo encoding, but can run out of memory when buffering a lot of frames. And they have limited support for video encoding (desktop browsers only added official APIs in the last year or so).

I've only ever tried it on Mobile Safari on iOS 18:

• Playback works on all examples
• PNG, JPEG, and GIF encoders work but most examples run out of memory and crash before they finish. "Quick Start" works 100%. The others are shown to work by interrupting the rendering before they run out of memory - you'll at least get to see the frames you captured.
• WEBM isn't supported in iOS. Apple appears to be in a format war on this one.

WebCodecs API isn't fully supported in iOS yet, but it's our best hope for the future - some demos already work on my phone. So, while an MP4 encoder isn't shipped by Hubble today, we'd gladly accept a PR that brings something like this mp4muxer in.