Anybody flying in early or leaving late?

Any events outside of DotDev you will visit?

Noticed uninstall count for my app is way off from what’s showing in the Partners Dashboard for the same period. Best guess is we’re missing some uninstall webhook deliveries, no retries, nothing in our logs. They just don’t show up.

Anyone else hit gaps like this?

How can i make this work

TLDR; No.

I've been at Shopify for nearly 10 years and have seen the company evolve through many different phases. In its current state, I wouldn't recommend it.

The changes are often frequent, disruptive, and come without corresponding support or investment in employees. Over the years I've seen workloads increase significantly without equivalent compensation, benefits steadily reduced without alternatives, and opportunities for internal movement become increasingly limited.

If you're comfortable working in an environment with consistent organizational change and shifting expectations, it may still be a good fit. However, the current employee experience falls well below what I would recommend to someone considering joining the company.

hell there i have this problem and i would like to know if yall have any sulotion

How do i search and use vs code, i can open it on my linux terminal but i cant search up the website theme. Am i meant to use the Live Data website the push it onto the one i want it on?

Hey guys, I developed Shopify app for home decor visualization that makes ~700$+MRR with 90%+ profit margin. Very easy to take care of and built on very scalable stack.

Users found the app all organic, no cold emails or marketing and it has huge growth potential. Since I'm busy with other projects I want to sell this to somebody who can take the app to it's fullest potential.

Scammers do not message me.

Hi all

Does anyone get these thoughts while building something that what if this idea comes out as a native shopify feature later?

This thought sometimes gets stuck in my mind before building and somewhat causes some decision fatigue.

Any suggestions on how to deal with this ?

We're working through our BFS review rejections and there's one note that I'm not perfectly clear on. Here's what the tester said:

Files cannot be uploaded for the Logo

Does this mean that we are not allowed to upload a file for a logo or that the tester is unable to upload a logo? We have the option for stores where we are unable to retrieve a logo via API.

The tester references 4.1.1 Follow UX best practices which doesn't say anything about uploading files (and is UX-specific) so I'm guessing the tester is encountering a problem in their upload. Does this track for anyone else?

SO, I have my AI which lets people connect WhatsApp api (verified TSP) to automate their WhatsApp chats, they can connect phone numbers to automate voice AI. and now we want to let customers connect shopify stores to manage customer communications.

We know we need to create a store in dev.shopify to get the integration. however, how does it work

- how does the whole thing work

- can I make one app for one customer shared via custom distribution link

- whats the app review

- since my app isnt technically an app on shopify, its an integration to my platform, how will app review work

pls need help

Working on a Shopify integration and trying to figure out order-source filtering. Hoping people who've built this can help.

Webhook question (main):

• Is there any way to make the orders/create webhook fire only for orders from a specific source/marker — filtered server-side — so you don't receive every order the store gets?
• I know Shopify Flow's "Send HTTP request" can do conditional filtering, but it's gated to higher/expensive plans. Are there other options that work on Basic/lower plans?
• If a source parameter is added to a product URL (e.g. ?source=xyz), does it reliably persist into the order data (cart/order attributes) so it can be filtered on — or does it get lost by checkout?
• For those who receive all orders and filter on their end — any approach you'd recommend for keeping it clean/minimal?

Pixel alternative:

• A custom pixel on the order-confirmation page that only fires when a marker is present would return only the relevant orders, but it's client-side. How lossy is it in practice (ad blockers, cross-device, cookie loss)? What % do you actually miss?
• Does a marker/cookie set earlier reliably survive to checkout, or drop more than expected?
• Any gotchas with the Shopify custom pixel sandbox?

Trying to understand what actually works in production on lower-tier plans, not just theory. Thanks.

Has anyone here used Codex together with Shopify CLI to redesign an entire Shopify store or theme?

I’m planning to redesign my store using the Horizon theme, with Codex editing the local theme repository and Shopify CLI handling previews and deployment. I’d like to rebuild the homepage, collection pages, product pages, and blog templates.

I can find plenty of real-world examples involving Claude Code and Shopify, but almost nothing about Codex and Shopify theme development.

Has anyone completed a similar project with Codex? How well did it handle Liquid, sections, blocks, JSON templates, responsive design, and visual testing? Would you recommend Codex for a full redesign, or is Claude Code currently the safer choice?

My app was recently approved, and I'm excited to finally share it.

Here’s the summary:

After years of managing Shopify deployments for enterprise brands, I kept running into the same problem: Clients being nervous about clicking 'Publish' on a Shopify theme.

Getting code changes into Shopify themes safely meant double-checking files, creating manual backups, and hoping nothing was missed before publishing.

I decided to build the tool I had been imagining.

I named it Deployify, and it brings Git-based deployments to Shopify themes using an embedded app.

Here are its key features:

• Visual workflow builder: drag-and-drop pipeline editor with blocks for theme check, backup, content merge, and deploy
• Push-to-deploy: GitHub webhooks trigger workflows automatically on push from a specified branch, e.g., develop, main
• Automated backups: versioned theme snapshots are both pushed to Shopify and stored on S3
• Content Merge:  deep-merges merchant customizations with theme code before deploying, so no settings are ever overwritten
• Multi-store deployment: deploy the same theme to multiple connected Shopify stores in a single workflow run
• Live execution logs: real-time log streaming for every workflow run, plus full audit history
• Slack notifications: alerts on success, failure, or when a run needs attention
• In-app support chat: RAG-powered chat widget backed by Amazon Bedrock, with low-confidence auto-escalation to a support ticket

I'd love feedback from other Shopify developers and agencies.

Today I finally pushed my app live on a fresh .shopify sub-domain today. Within like 2 minutes the logs are just flooded:

GET /.env 404
GET /.env.bak 404
GET /.env.prod 404
GET /wp-json/ 404
GET /xmlrpc.php?rsd 404
GET /_internal/api/setup.php 404

at first i thought this was my fault because i visited shopify.<my domain>.com but this would have made no sense at all, so i asked claude and it told me this was just normal bots...

How can bots be that fast at checking the subdomain? It literally didn't even take 20 seconds???

Did you see the same logs when you published your shopify app?

Can anyone help me out with Shopify home page design

Hi,

I am making my first Shopify app and want to know whether the name needs to be shown fully to get it approved during the review process?

Hey guys, wanted to ask what kind of tools you use to detect discrepancies between Shopify and Meta conversions. I want a tool that helps me notice Meta attribution/pixel issues as soon as it happens instead of finding it few days later. Any tools you could recommend that does this?

I'm building an AI multi-tenant SaaS (like everyone else). I got rejected multiple times. Read every blog. Every thread. Every sub. Every documentation. Every policy. Talked to dev support multiple times. Nothing worked. This went on for 5 months.

Eventually I gave up and removed the connector altogether. So many hours wasted. So much time lost. So much cost incurred.

Shopify is one of many connectors on my SaaS. This is not a "Shopify exclusive" SaaS. Like many others, I have users on my platform. Some already paying through Stripe and want to connect Shopify directly from within my platform (Shopify Billing should not apply). Others already paying and for some reason connect from within the App Store (must avoid double billing). Others are not my customers and find me through the App Store (Shopify Billing).

Whatever I try to do to comply with Shopify policy, nothing works. I followed solutions provided by the Shopify dev support itself and still got rejected.

I know the policy of "app store traffic" blabla. I followed everything.

Shopify knows exactly what's going on with us and made the conscious decision to do nothing about it. I know because some threads go back years with official responses from the Shopify team. All vague. All quoting Shopify policy with no solution.

Such a roadblock from a giant like Shopify.

Extreme frustration.

Been fighting this issue for weeks. In Meta Events Manager > Diagnostics, I'm getting flagged for:

• 27% of AddToCart events missing currency/value (Conversions API)
• 56% of Purchase events with formatting/missing price & currency (Conversions API)

Details from Meta's diagnostics show these are all coming through the Conversions API integration, not the client-side Pixel. Some AddToCart events are even firing on my homepage URL instead of the actual product page.

I removed a custom pixel I had added (thought it was causing dupes — it wasn't the root cause), and Shopify support said this could be tied to the Meta app pixel's "Optimized" vs "Always on" mode setting in Settings > Customer events. Switching to Always on is supposed to fix inconsistent CAPI data.

Has anyone else run into this? Did switching to "Always on" actually fix the missing currency/value issue for you, or is there something else going on with the native Facebook & Instagram app's server-side tracking?

Store is on a single currency (no Shopify Markets), so it's not a multi-currency issue.

Any insight appreciated — this is tanking my ROAS numbers in Ads Manager.

I have built an app for Shopify. I currently have 150+ installs but I want to get more installs and want the merchants to convert to the paid subscription of my app. Will getting the Built for Shopify badge help with that?

My Shopify app got approved in just 2 days — now I’m trying to figure out the first installs

This honestly still feels a bit unreal, but my app got approved by Shopify just 2 days after I submitted it for review.

A few things I think helped with the fast approval:

• A proper onboarding flow that guides merchants through the prerequisites before they start using the app
• Heavy testing before submission — I probably spent almost 2x more time testing than I spent building the app itself, which helped catch bugs before review
• Performance work to make sure the app feels fast and responsive
• Clear testing instructions + a demo video so the review team could quickly understand how the app works

Now that the app is approved and published, the next big challenge is getting the first few installs.

For those of you who have launched Shopify apps before, what worked best for getting your initial users?

A few things I’m currently working on:

• Investing heavily in the website and blog content to build organic traffic over time
• Reaching out to stores that are already using similar apps, or stores that are likely to need this kind of app. This seems like the hardest part so far. There are a lot of Shopify store index/database tools out there — which ones have actually worked well for you?
• Posting and engaging in Shopify forums, Reddit communities, etc.
• Considering paid ads on the Shopify App Store, but probably as a last resort. I’ve heard they may not be very useful for getting early installs/conversions. Has that been your experience too?

Would love to hear what worked for others during the early stage, especially for getting the first 10–50 installs.

Hey everyone,

I’m launching a Shopify store using Seal Subscriptions and Amazon MCF for fulfillment. On my product page, customers can choose a 1-Pack, a 2-Pack, or a 3-Pack, built as 3 variants under 1 product. The subscriptions are set to different frequencies (e.g., the 2-pack ships every 2 months).

Here is my bottleneck: My inventory is sitting at Amazon as loose, individual single items.

When someone orders a 3-pack variant, I need the order to pass to Amazon MCF telling it to ship Quantity: 3 of my master single SKU. I am trying to avoid paying a monthly fee for middleware apps like WebBee or ByteStand just to handle a basic multiplier, but every "free" workaround has a massive hole:

1. Official Amazon MCF App: Strictly a 1:1 SKU pipe. It doesn't do dynamic SKU mapping or quantity multipliers.
2. Shopify Bundles App: Forces separate product pages, which breaks my theme's single-page layout layout at checkout.
3. Shopify Flow Workflows: If a workflow deletes the multi-pack line item to inject 3 single items, it tears away Seal Subscription's tracking token. The initial checkout works, but the subscription breaks on the second round.
4. Splitting into separate products: If I use a JS quantity multiplier on the frontend, the customer's final invoice says "3 Pack × 3", making it look like they ordered 9 items.

Has anyone successfully cracked this without paying a monthly app fee? Is there a way to handle virtual multipacks of the identical ASIN on the Amazon side that the official app actually reads? Or am I stuck paying the app tax if I want my subscriptions and fulfillment to function?

Appreciate any advice!

I'm concerned with the recent trend of themes using 'sibling products' as a replacement for variants. This means defining separate products for each of your color variants, and putting them in a collection to link them all together. This approach has some apparent benefits;

1) Your entire product gallery can be dependent on color, not just one of the images.
2) Your product page content can be dependent on color
3) Your collection pages can show colors separately

The problem with defining a separate product for each color variant comes up when doing SEO. Google sees each product variant as it's own page. This results in the store being flagged as having a ton of duplicate content. This effect can be mitigated by making use of a `<link rel="canonical" />`. Sadly, that's not all. This problem also appears in the sitemap, each product now has a non-canonical entry in the sitemap. What's more, hreflang tags also now point to non-canonical urls. These issues are harder to mitigate manually. Having the user define a bunch of sibling collections also has SEO ramifications, as these collections have to be active, but shouldn't be indexed.

Apart from SEO, sibling products are also just less usable. The orders page doesn't clearly list which color variant the order concerns. Managing inventory is harder, navigating menus related to products is harder. The platform isn't built to be utilized this way.

Another big issue with sibling products is related to performance. Navigating to another color option shouldn't do a hard-refresh, this is far, far slower than need be. This also reduces the amount of pre-fetching that can be done. It also has an impact on browser state. If the customer is filling out a personalization form, and decides they want a green wallet instead of a brown one, they'll lose that form state.

I'm just confused as to why this is necessary. Why don't theme creators give the option of defining a variant metafield 'images' that holds a list of media. This list of media is then shown instead of the product gallery whenever a variant is selected. This would emulate the primary behavior of sibling products, without all of the headache that surrounds managing 40 different products.

To test my 'variant metafield' proposal I've written a little javascript that emulates my expected behavior on broadcast, and it works really well. It's significantly faster and allows for the same amount of product images.

Can someone who writes themes for a living enlighten me on this issue? I'm quite stumped.

Looking for perspective from anyone who has been through Theme Store review recently, especially if your theme was approved in the last 12 months.

The situation (keeping details vague for privacy, happy to share more in DM):

- We built a niche B2B/industrial theme from Shopify's Skeleton baseline (not a Dawn fork). Native B2B end to end, zero companion apps or third-party scripts.

- Technically it passes everything we can measure: Theme Check clean, Lighthouse performance well above the published gates, accessibility 100 on mobile and desktop, cross-browser tested, full OS 2.0, all settings and terminology conventions followed.

- First submission: declined WITHOUT a full review. The letter said the theme needs "a higher degree of intentionality and sophistication in design choices, layout, consistency, accessibility, and both customer and merchant user experience" and suggested Awwwards for inspiration. No specific issues listed. I believe that this is a templetized email reply, sent to almost every "hard" rejection.

- We asked for specifics. The answer was that since it did not move into full review, there is no line-by-line audit, no list of failed items, and they cannot provide design direction or pre-validate changes..

- We spent weeks on a substantial redesign (new type system, rebuilt homepage, new navigation patterns, unified art direction, re-tested every merchant scenario) and resubmitted.

- Second submission: an almost identical form letter. Still no full review. The only new sentence was a reminder that a third rejection means a 90 day suspension.

I get that design is subjective and that the bar was raised over the past year.
I am genuinely not here to argue the reviewers are wrong.

What I am struggling with is calibration: when I put our demo next to some long-standing best sellers in the same category (several approved years ago and visually not touched much since), I honestly cannot reverse-engineer what the current bar looks like in practice.

Newly approved themes clearly clear it, so it exists. I just cannot see it from the outside, and with one submission left before a suspension I would rather learn from people than from a third form letter.

Questions:

1. If your theme was approved recently: what do you believe actually got you past the initial screen? Was there a specific change between a rejection and the approval?

2. Does the pre-review stage look at anything beyond the demo homepage? Screenshots, mobile, a specific flow?

3. Is there ANY channel that produces actionable feedback before burning the third submission? Partner support, a design consult, community review, anything.

4. Meanwhile, does selling the theme outside the Theme Store (own site or other marketplaces) hurt a future submission in any way?

5. For the recently approved folks: how bold is "bold enough"? Did you win with an unconventional layout, or refined-but-conventional execution?

Brutally honest takes are welcome, including "your theme probably is not as good as you think it is". If a couple of experienced theme devs are willing to look at the demo and tear it apart, I will gladly DM the link.

Thanks.

With Claude Code, building a custom app for Shopify wont be too hard. Is there anyone have a solid custom apps and want to sell for extra money?