Best way to upload/compress large videos on mobile native?

Mobile Beta
1

Hello,

For one of my Mobile Native Apps, I need to allow users to upload images, videos, and files, and retrieve them later.

Images and files are fine: some native plugins handle image compression well, and files rarely exceed 50MB so a size limit works.

The problem is with videos. They can grow extremely large very quickly. An iPhone 4K video of just a few seconds can exceed 50MB. Setting a hard size limit creates a terrible UX because most videos will exceed it, making the feature basically useless.

All native plugins I have tested struggle to upload files larger than 50MB, and even when they manage it, the upload takes too long.

I want to achieve the same experience as WhatsApp, messenger, or any chat app where videos of any size are automatically compressed on the client side before upload, resulting in a seamless UX.

I will not have a huge volume of video uploads, but the ones that do happen are critical, so I need to get this right. The concern is not about file size limits or Bubble storage costs, it is purely about the upload UX.

What direction should I take?

  • A native plugin that handles client-side video compression before upload?

  • A web plugin integrated via WebView?

  • A third-party storage/upload service ?

  • Any other approach?

Has anyone solved this cleanly inside a Bubble native app? Thanks for your help!

2

Why not try some external storage, e.g. Supabase buckets? In this way, you could avoid all the hardcoded solutions with some simple API calls to supabase.

3

It’s not about the server or costs for now, but everything that happens before that.

I’m just looking to be able to upload large videos without the app crashing or the upload taking multiple minutes.

4

Cloudflare Workers > Cloudflare D1 > Bubble Data API > Save To Bubble Database

This process avoids any timeouts from Bubble, solid performance, and you can add a compression api in your Cloudflare Worker for optimization. The speed is great.

I’ve used this process for large audio files (wavs, mp3), but haven’t tested this for mobile but will do soon.

5

For heavy files on mobile, the current best options will be working with a webview.
-using a 3rd party storage with a configured web page and backend workflows linked to the webview.
-or just the a good web plugin integrated via the web page linked to the Webview since you have no concern about Bubble storage costs.

The key for UX here will be to make sure the web page is designed exclusively for mobile and there’s a status checker/indicator say in their profile or uploads view to show if its still processing.. or the upload is done.

6

Thanks @saviorabrams and @AnkharaStudios for your suggestions.

The best UX solution I found so far is the S3 Dropzone plugin used inside a WebView. It handles multipart upload, which speeds things up a bit, and reduces crashes and timeouts on large files.

That said, it is far from ideal for a native app context:

  • You cannot pass files from a WebView to the native app layer via front-end, which makes seamless file management during forms very difficult

  • The overall integration feels hacky compared to a true native implementation, for such a basic feature as file uploads

  • When a video is selected from the iOS gallery from webview, Apple automatically converts it (from HEVC to H.264 I think) before handing it to the browser. This conversion alone (that does not really change the size of the file) adds roughly 25% to the total upload time and cannot be avoided or controlled.

  • That forces you to use third party external storage, which can be good, but can also be overkill and add unwanted complexity to your App.

My understanding so far: client-side video compression/resizing is useless in a WebView. It runs on the browser’s raw CPU via WebAssembly, which is so slow it takes longer than the upload itself. So compression in a WebView is a net negative for UX (total x2 or x3 longer than a raw upload). The same problem applies to web apps and browsers in general.

What chat apps like WhatsApp actually do seems to be:
client-side hardware compression > background upload > optional server-side transcoding.

The key word here is hardware. These apps use native iOS and Android APIs (AVFoundation, MediaCodec) that leverage the phone’s dedicated encoding chip, making compression very fast. They also use background uploads, which means the upload does not stop when you change pages or switch apps on your phone. This is fundamentally inaccessible from a WebView or browser context.

No existing native Bubble plugin exposes these hardware compression APIs or background upload capabilities. This appears to be a hard platform limit that makes several legitimate use cases simply impossible to build cleanly in Bubble today. This would be a valuable addition for Bubble to consider.