Theme App Extension Framework Pain Points

Extensions
1

Hi there,

I wanted to share some pain points I’ve noticed while developing theme app extensions over the past year or so:

Deprecating/removing settings

  • No available_if_not: It would be amazing if we could make an app block usable only if a specific metafield were not present. This would make it very easy to deprecate outdated app blocks for new users.
  • Settings do not have available_if/available_if_not: This makes it very challenging to remove settings from an app block.

A pretty common scenario is:

  • Based on customer demand for a specific feature in the storefront, I create a new app block
  • As time goes on and I gain a better understanding of the problem being solved, I want to change the implementation of the app block. Maybe I’ll be removing settings. Or maybe, the entire setup could use an overhaul. I’ve found that app blocks lack flexibility and make such changes difficult.

Deprecating app blocks

  • It’s hard to know which users are actively using which app block. Your best bet is to use the Theme API and parse the JSON templates, but this might not be all too reliable if, for example, some existing users haven’t granted you read_themes access or if you no longer have a valid session token for them.
  • As a result, if you want to remove a deprecated version of an app block, you risk breaking your users’ stores without being able to at least contact them beforehand.

Onboarding

  • Deep links cannot contain configuration information. Let’s face it: most users do not read the settings/documentation when adding app blocks to their theme. People frequently miss important information. It would be amazing if apps could just deep link users to the perfect settings for their theme.
  • Though you can autofill settings of type product, you can’t do this for collection.

Lack of dynamic configuration

  • App blocks cannot contain other app blocks as their children. This would make it possible to have more dynamic configuration. For example, if you had a “Collection list” app block/section, and wanted users to be able to provide different settings for each collection in the list, there’s no way to do that right now.

Conclusion

  • Theme app extensions are very much a “once you add this app block/setting, it’s there forever, and removing it might be unsafe” situation.
  • It is difficult to improve the onboarding process for theme app extensions.

Thanks in advance for your consideration. I recognize this is a long list. It would be interesting to hear if any other developers are facing similar challenges.

2 Likes
2

My issues:

  1. Cannot use a deep link for multiple app blocks installation
  2. limiting settings - max 25 allowed
  3. Users don’t read docs, I don’t have an installation process but forced to have one after upgrading to app blocks from section liquid files. But most users find it hard to follow.
  4. BFS has a hidden assumption to have 1 app block added to the existing product template as a widget. Most apps work like this. If you don’t follow this convention, it’s hard to pass the storefront performance test.
1 Like
3

Hi Tobe & Benny,

Appreciate you sharing your experiences and feedback here - I’ll ensure that the product team in this space is alerted to these. And we also welcome more feedback from other devs in the community building theme app extensions.

1 Like
4

Some more pain points

Restrictions on the assets under the theme app extensions

  • Unable to upload font files to the assets folder

Settings in theme app extension are not accessible via a api - the api helps in case merchants face customisation issues today! We need to ask for collaborator access to achieve any customisation on top of the extensions when a merchant is unable to do one themself

Theme app extension webhook
A webhook that informs when a app extension is enabled or disabled

1 Like