Sorry for the delay. It looks like we would need to apply a flag on our end to perhaps get this working in your production app. Before we do that, let's work through this a bit and I'll start by adding some context:

The embedded app SDK in its current state maps to App Bridge functions behind the scenes. The problem is that app bridge does not have support for the ShopifyQL methods, and therefore when you call these methods, they fire as blanks. We would need to get your API client into legacy mode which means it will not map to app bridge methods, and instead function on its own codebase as it did before.

I've noticed that your development app has this flag applied and would in theory work with ShopifyQL, in addition to the legacy version of the EASDK. If you have the chance, could you check this on your end to make sure everything works as you expect it to? With that confirmed, I can apply it to your production app. I just don't want to do it right away if it means some of the non-ShopifyQL behaviours change in an undesired way ahead of flagging the application.

I wanted to interact with you here instead of through a private support ticket in case anyone else experiences/is experiencing this issue so we can help them as well, since this admittedly hasn't been as clear as we would want it to be.

I think App Bridge looks great and if we are forced to migrate to it, that's fine by me, it is a good change long term, but please don't migrate us automatically unless it really is backwards compatible. Did I miss the communication about this API removal?

And not one answers for a whole week..

Anyway I'll stop ranting now, Alex thank you for looking into this. I confirm that it works fine in our dev app so can you please apply that flag on our app.

There won't be other unintended consequences right?

Also, do we have any control over that flag?

Also, will all apps eventually be forced to use Shopify Bridge or is there a plan to make it actually backward compat?

I agree with a lot of your points. It's been a definite miss on our part, and we're initiating some conversations on our end to address that miss so we hopefully don't have to make the same mistakes in that regard.

I've applied to flag to your app, so the analytics API should be working for you now. To answer your questions:

There shouldn't be any unexpected consequences since as you mentioned before, you are not using app bridge methods. You do not have control over that flag, so it's something we'd have to enable on our end. Part of my engaging you on this thread is definitely to help anyone else experiencing this issue who need the Analytics API that might have been missed. I can't say much about the road map just yet regarding the future of the EASDK, but the current thinking as that app bridge will offer total parity with the EASDK before the EASDK is deprecated/sunsetted.

I'll be watching this thread closely, so if anything undesired occurs for whatever reason let me know and we'll get that addressed. To re-affirm though, you should be ok.

@ClementG I don't have a definitive answer on what will happen specifically, but in a case where developer behaviour needs to change, it should be of course treated as an actual migration cycle.

Current thinking being tossed around is either extracting it into its own library or of course facilitating it within App Bridge itself.

We're actually working on clarifying on the whole backwards compatible thing in documentation, since as you stated that is not accurate. Total agreement there.

@AbdelilahLbardi if you need your app to have access to the analytics api, give me the app ID here (you can get this from the URL in your partner dashboard when viewing your app, at the end). Just know that once I add this, App Bridge will not work well if at all, you'll be exclusively able to use the Embedded App SDK only.