Acknowledged

Connect IQ Store Product page misleading information on monetization status

On developer dashboard product configuration there is information:

Section Monetization:

If your app requires or requests payment in order to enable any or all of its features, please let us know below. Failure to choose "Yes" for an app that requires or requests payments may result in the app being removed or de-listed from the Connect IQ Store.

Meanwhile on the:

https://developer.garmin.com/connect-iq/app-review-guidelines/

Detailed Guidelines
d. Monetization of Your App

An app requires payment if the user must pay to access or use any primary feature of the app (i.e., those features that are advertised in the app’s description, excluding any features that are clearly labeled optional). In contrast, an app is not considered to require payment, if the only features that require payment or subscription are optional.

And then:

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/tips-for-monetizing-your-apps
Your primary features should be listed in the app description. Note that for watch faces, it is assumed that viewing the time is a primary feature of the app. This will show the "Payment Required" badge in the app store.

So, we have 2 cases here:

1. product page suggest that you NEED to check Monetization info as Yes (paid).
2. guidelines suggest that you need to enable Monetization if your app requires payment only for PRIMARY FEATURES.

Please guys, clarify and fix it. This information should be consistent.

For me, logically obvious solution is applying THE GUIDELINES, because it's official document and it's explaining reasoning quite well. But product page, Monetization section is misleading.
So, my watchface has PRIMARY free features which allow for full usage. Additional SECONDARY/OPTIONAL features are not needed for usage, but they add value for the user if he wants more OPTIONAL features. In this case I don't think I should check Monetization:YES for such app and this should be more clearly stated or instead given link to guidelines as single source of truth.
  • You're correct that there is some inconsistency here that must be addressed. In the past, our guidelines were to require the flag if your app requires payment for the use of primary features. A common example is a watch face that is free to use, but can unlock the ability to change background colors with payment. That was the intent behind that guideline.

    With the imposition of the EU Digital Services Act, we've had to tighten those guidelines so that the flag is required if payment is needed for use of any features in your app. Developers are currently allowed to request donations & tips without the payment required flag for apps that are otherwise free to use.

    In the case presented by the OP, the payment required flag should be checked in order to comply with the EU DSA. We know that there is inconsistency between our documentation and the developer dashboard—this will be addressed soon.

  • *you won't be violating any of them.

    *than to go to another page 

  • Also, I think it would make more sense for the product details page to have the correct monetization rules, because it's the same page where the developer actually has to choose whether payment is required or not, and it's also the page that they see every time the upload / update an app. Not only is the text on the same page, it's right next to the monetization option itself.

    They are much more likely to read those rules, and make the appropriate choice based on those rules, then to go to another page in the main developer site or the forums. It's also the most likely place for the Connect IQ team to focus their efforts (again, because the monetization option is right there.)

    In other words, for any option in a user interface, given the choice of believing text that's right next to the option as opposed to text that's on a couple of other websites, I know which text I'm going to believe.

    Here it is for the benefit of anyone else reading this who hasn't seen it (and for posterity, in case it changes one day):

  • I think the most logical solution, in the absence of additional information, would be to follow the strictest possible set of rules. That way you can be sure that no matter which set of rules is actually in force, you're won't be violating any of them.

    However, jim_m_58 is correct and the current monetization section (which states that "any or all features" should be considered for monetization, and that either requiring or requesting payment is considered "monetization") is the current set of rules.

    I agree that the documentation should be clear and consistent.

    See here for context on the new rules:

    https://forums.garmin.com/developer/connect-iq/f/discussion/362127/can-t-we-have-a-donation-link-in-the-app-description-any-more/1739242#1739242

    [quote userid="2116" url="~/developer/connect-iq/f/discussion/362127/can-t-we-have-a-donation-link-in-the-app-description-any-more/1739242#1739242"]

    We've had to make some shifts to our policies in order to be compliant with the Digital Services Act, as described in the rejection message you received. I am not a lawyer, but we have been advised by the Garmin legal team that any app that requires or requests any kind of payment in the app listing on our store, which includes tips and donations, must be flagged "Payment Required."

    We haven't updated our policies on developer.garmin.com to reflect this yet, and we're discussing some changes to the store that will provide some nuance to those asking for tips vs. those that actually require payment to use their app. At this time, the only mechanism we have in place is the Payment Required flag.

    We'll be auditing existing apps for this at some point, but for now, we're enforcing this policy change on any new app submissions.

    [/quote]

  • I would go by what it says in "Section Monetization" as that's the current rules.  It's changed a few times over the last few months.

    The other docs need to be updated and could be from a while back.