feat: asset support

[eseidel]

Another thing we could do is that even if we don't support assets, if we kept the whole aab, we could explain to the user that their patch contains non-code changes that will not be reflected?

[eseidel]

Update: So we built some of the infrastructure for this already. We do store AABs from releases and we will check and report when you have changes other than dart-code in a patch.

What's missing to make this feature work is some changes to updater library:
https://github.com/shorebirdtech/updater/tree/main/library
to download the bundled assets and place them in a new directory and changes to the Flutter Engine code to create a DirectoryAssetBundle:
https://github.com/flutter/engine/blob/e4873bbb44f146329aa1737c762f7cdf129ec524/assets/directory_asset_bundle.h
and insert it into the AssetResolver chain.

There is work to figure out if you can add/modify and delete (not sure if delete is necessary) assets between patches, and if we can be smart about not re-downloading assets which aren't in the base APK, but were updated in patch 1, thus don't need to be downloaded again in patch 2, just copied over from patch 1's install directory (can be a later feature).

[eseidel]

OK, I'm starting this.

Notes:

• First add the directory creation in rust code. Fill it with some random image from the internet.
• Build an example app with a different picture, same name, verify it shows the unpatched one.
• Send a patch to that app (which changes to the patched image name). Verify that the image fails to load.
• Expose the assets directory path from rust to C++.
• In C++, create a DirectoryAssetBundle? pointing to the directory path from rust and PushFront onto the AssetManager.

Questions:

• Where do we actually insert the DirectoryAssetBundle? Settings.assets_path seems to be an embedder api concept. RunConfiguration seems to be partially integrated, but not always?
• https://github.com/shorebirdtech/engine/blob/655974aed33b608d1075cffae0fcaf06772d90d8/shell/platform/android/android_shell_holder.cc#L334 might be the location for Android?
• https://github.com/shorebirdtech/engine/blob/655974aed33b608d1075cffae0fcaf06772d90d8/shell/platform/darwin/ios/framework/Source/FlutterDartProject.mm#L385 might be the iOS hook?
• Should we use DirectoryAssetBundle? We could make one which reads out of a Zip like ApkAssetBundle does.
• Is UpdateResolverByType going to break us? Is that used in release mode?

[eseidel]

UpdateAssetResolverByType appears to only be used to update the APK asset resolver, so we should be fine.

[eseidel]

Status update: I looked at this extensively but got drawn into other things. I still don't think this will be very hard (and honestly is getting easier every day as we continue to build out our build and test infrastructure).

We're just focused on getting a production-ready (fast!) iOS shipped first, so this is still probably a few weeks away from getting our full concentration.

[eseidel]

One other note is that assets support likely has downstream effects, e.g.:

• When we add asset support we give developers the ability to make patches a lot bigger (by adding/updating large assets)
• will us to want to update our patch install logic. Right now our patch install logic does not restrict itself to only unmetered networks (it should), but it also doesn't matter for customers much since patches are tiny (bytes or kilobytes). Once patches can easily end up as megabytes (with asset support) we will want to make that more clear to developers and update our patching logic with partial downloads, etc.
• This will also change incentives pricing around patching (not immediately, but it will change things). Right now we don't charge for network or disk (or have limits on either), since we're almost 100% responsible for patch size (and we have work we can do to make patches smaller).

None of that needs to be solved for our v1 of assets support. Just noting that asset support will have follow-on effects (that I'm excited to solve) and is just one more reason to put it after we get iOS into production (since that's by-far our top ask from customers).

[GeylanKalafMohe]

One other note is that assets support likely has downstream effects, e.g.:

• When we add asset support we give developers the ability to make patches a lot bigger (by adding/updating large assets)

• will us to want to update our patch install logic. Right now our patch install logic does not restrict itself to only unmetered networks (it should), but it also doesn't matter for customers much since patches are tiny (bytes or kilobytes). Once patches can easily end up as megabytes (with asset support) we will want to make that more clear to developers and update our patching logic with partial downloads, etc.

• This will also change incentives pricing around patching (not immediately, but it will change things). Right now we don't charge for network or disk (or have limits on either), since we're almost 100% responsible for patch size (and we have work we can do to make patches smaller).

None of that needs to be solved for our v1 of assets support. Just noting that asset support will have follow-on effects (that I'm excited to solve) and is just one more reason to put it after we get iOS into production (since that's by-far our top ask from customers).

I wish to have a pricing guarantee. How can we as a company rely that the current tier subscription will be the same in upcoming Shorebird release cause of changes like assets charges...

[eseidel]

I wish to have a pricing guarantee. How can we as a company rely that the current tier subscription will be the same in upcoming Shorebird release cause of changes like assets charges...

Our current pricing is honestly just a guess based on our underlying costs. We essentially try to predict our costs and charge exactly that assuming full-usage of a plan. We don't yet know if it's way too high or way too low yet. We plan to eventually offer annual pricing: #733, which would be a path towards a "guarantee". We've changed our pricing model at least 3 times in the last 6 months (each time reducing our prices). We're just still trying to figure out our costs as we continue to scale. Regardless, happy to work with you on pricing that works for your team, just reach out to me at contact@shorebird.dev. Thanks!

[GeylanKalafMohe]

Any plan or update when it's going to be implemented?

[eseidel]

This is entirely blocked behind us getting our 1.0 release out, which is blocked on finishing iOS: #674. I think it will depend on how quickly we can resolve that (we've been working on it for months, but I'm hopeful we're only a week or so away). And then how much other customer work falls out of our 1.0 launch. But asset support is pretty high on our list. We already did some of the work needed, just need to go back and finish it. Like Flutter, we take 👍 into account in prioritizing issues, so that helps.

[tabibo]

Hello @eseidel , Is there any updates regarding the asset support in the new patches?

[eseidel]

No updates. We continue to focus all our efforts on #674

[ronaldoandjames]

as the iOS 1.0 is about to release, is there a schedule to do this assets support? it's a important function 🥲

thanks.

[robsombarros]

No updates. We continue to focus all our efforts on #674

The issue #674 is closed. We need this asset update feature to enable the use of Shorebird. Do you have any estimate for fixing the 'missing assets' warning?

[eseidel]

No ETA at the moment. We're currently dealing with an influx in customer requests due to 1.0 and then once that settles down I would like us to finish some of the "easy" features like this one. We did about half the work ~6mo ago and then paused to finish iOS (which we've now done).

[timi888666]

Hi @eseidel , Have you started working on this work yet? If not, what are the higher priority tasks?

[eseidel]

Hi @eseidel , Have you started working on this work yet? If not, what are the higher priority tasks?

We've not resumed this work yet (we did some of the needed work a few months ago). The team is currently focused on finishing iOS support and shipping signed patches.
#1892
#112

Our planning boards are all public: https://github.com/orgs/shorebirdtech/projects/19

[eseidel]

As part of doing #112 w'ere back in this code doing more related work (updating the format of the "patch" that we use so that it's a container and can contain more than one file). We're still probably many weeks away from shipping this though (since we have a bunch of other high priority work to finish first).