shorebirdtech
feat: asset support
What this would mean is making it possible to add images/assets via a patch. Right now we're only able to change code, but adding asset support would mean that we would diff the assets as well (between the patch and the release) and send any changed assets (images, icons, etc.) with the patch to the devices in the field.
This requires some infrastructure work, mostly in preparing for now arbitrary-sized patches, which means we need to improve our download mechanisms on device (which are currently very simple because code-only patches are generally tiny).
As of Jan 2025, this is very close to the top of our list, but still not scheduled.
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).
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?
UpdateAssetResolverByType appears to only be used to update the APK asset resolver, so we should be fine.
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.
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).
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...
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: https://github.com/shorebirdtech/shorebird/issues/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 [email protected]. Thanks!
This is entirely blocked behind us getting our 1.0 release out, which is blocked on finishing iOS: https://github.com/shorebirdtech/shorebird/issues/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.
Hello @eseidel , Is there any updates regarding the asset support in the new patches?
No updates. We continue to focus all our efforts on https://github.com/shorebirdtech/shorebird/issues/674
as the iOS 1.0 is about to release, is there a schedule to do this assets support? it's a important function 🥲
thanks.
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?
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).
Hi @eseidel , Have you started working on this work yet? If not, what are the higher priority tasks?
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. https://github.com/shorebirdtech/shorebird/issues/1892 https://github.com/shorebirdtech/shorebird/issues/112
Our planning boards are all public: https://github.com/orgs/shorebirdtech/projects/19
As part of doing https://github.com/shorebirdtech/shorebird/issues/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).
We ended up doing #112 without needing to move to a container format (for now), but we've done the planning and so know what we need to do when we get back to this. We're mostly still focused on finishing https://github.com/shorebirdtech/shorebird/issues/1892 before we take on new features.
any update?
No update at this time. Felix is currently still assisting existing customers in adding iOS and Bryan is currently working on https://github.com/shorebirdtech/shorebird/issues/2223.
I'm still waiting for this feature to decide whether to use this service. Since #2223 is done, any plan? Will you make this prioritized?
me either， it's really an important feature
rockingdice @.***>于2024年9月7日 周六上午11:30写道：
I'm still waiting for this feature to decide whether to use this service. Since #2223 https://github.com/shorebirdtech/shorebird/issues/2223 is done, any plan? Will you make this prioritized?
— Reply to this email directly, view it on GitHub https://github.com/shorebirdtech/shorebird/issues/318#issuecomment-2335022645, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALUOYT5MXOOO6XOFWPI4VT3ZVJXNNAVCNFSM6AAAAAAXDRKPU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZVGAZDENRUGU . You are receiving this because you commented.Message ID: @.***>
We've not forgotten. :) Just busy with other things. Currently working on shipping https://github.com/shorebirdtech/shorebird/issues/739
2025 do you have plans to develop it?
We're currently working on https://github.com/shorebirdtech/shorebird/issues/397, but this is likely to be our next big feature after that.
Hello, could you please answer my question, is it possible to deactivate shorebird remotely (say via firebase config) in a project that is already released and running?
It's all about last year's crash on your side (applications were covered with symbols..) after which people had to urgently release a new release. I would like to be on the safe side and in such a case simply disable shorebird and the application would roll back to the default code (of the latest release).
duplicate (from linkedin)
