Need 3.1.3(f) Guidelines Clarification

According to Apple's built-in dictionary app, "e.g." is from the Latin "exempli gratia ‘for the sake of example’".

However, you haven't mentioned what kind of app you have. It's curious, when developers get an app rejected for spam or some other criteria, they'll often include 4-5 paragraphs going into great detail about their app and why it shouldn't have been rejected, as if we could overrule App Review. But usually, their description only serves to support App Review's rejection.

To be clear, I'm not asking for 4-5 paragraphs. But a couple of sentences might be useful. All anyone knows at this point is that you seem to think your app would be rejected. You know your app better than anyone I suppose.

Never forget the "living document" clause: "This is a living document; new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this."

Thanks for the thoughtful response. And, yup, the post was made during our process of getting an app reviewed. Sorry I didn't keep this short...your question gave me an opportunity to think critically about our app, so I'm as much detailing this for myself.

I'll do two things here as a follow-up:

• provide a little verbatim text from our reviewer
• describe our app

We have been going around-and-around on our app, going through their "appeals" process, and seem to be stuck on 3.1.3(f) currently. Here is the most recent verbatim text from our reviewer:

Please note that Guideline 3.1.3(f) only applies to apps offering one of the following kinds of web-based services:

• VoIP

• Cloud storage

• Email

• Website domain hosting services

As far as I can tell, the reviewer is simply interpreting the "e.g." parenthetical as the specification for the types of apps that qualify as Free Stand-alone apps and ONLY those types of apps qualify.

Our Product - we create a no-code data system creation platform that allows someone to integrate IoT data, human-form data, and other data into a time-series oriented database, run calculations on that data, and produce visualizations and integrations to their other systems. The platform is desktop-only for creating database systems. Note that we're a bit like AppSheet or even AirTable as a service.

The person that subscribes to our service cannot use a mobile device to create the data systems - they must use a desktop/laptop style system.

Our App - The person who creates the database system can invite a number of viewers or data inputters(based upon their subscription) to input data into the data system or view the output from it. These are the users that will use the mobile app. We don't charge for the app, and it is optional. Only those users who need the mobile access for data need the app.

Note that the users of the app are normally completely different from the person who created the data system. The app-users don't buy anything - they simply use the data system created by the subscriber. They are normally part of a team within a larger corporation, where the subscriber is billing the subscription to the company.

I REALLY appreciate the attention and help on this. :-)

Thank you for your post. We believe we have resolved this issue. If you continue to experience issues during review, please contact us.

Based on your quote and description, I would agree with your interpretation and confusion.

But it is important to remember power discrepancies in any relationship. For all but a few developers, Apple holds all the power and can interpret "e.g." to mean whatever it wants.

I'm curious now. App Review says that they have resolved your issue. What was the resolution? What does "e.g." mean in the context of the Apple App Review Guidelines? Does it mean "for example" or "specifically"?

I had a good conversation with a reviewer on the phone. Here's the important points regarding my previous post:

• All of the reviewers consistently interpret the 3.1.3(f) "e.g." as "specifically". The reviewer and I talked about this directly. Even though there are cases such as 3.1.3(a) that use the term "specifically", 3.1.3(f) is being interpreted by the reviewers as IF it says "specifically." Doesn't seem to be a way around that.

• The reviewer(s) got confused about what our app does, by looking at OUR OWN website. That's on us. In particular, although our project is meant for teams, we were using words that targeted the MANAGER of the teams for the subscription. For example, we used the word "INDIVIDUAL" payment plans. This meant "an individual team manager", and it was clear that the subscription included other non-paying team members. HOWEVER, it was misinterpreted to mean that the product was meant for an individual. So we corrected the web site wording. With this change, we should qualify under 3.1.3(c).

• Also, we used too much "marketing speak" on the web-site for the reviewer. One of our tag lines was "create apps for inputting data." But that was referring to our app presenting an input form that LOOKED like it was running as a separate app. IMHO we did a great job with the software to give the end-user a great experience. But those words weren't accurate from a product point-of-view (we weren't actually creating an app) and they caused the reviewer to believe we were running afoul of 2.5.2. We are changing the website wording for that.

• Finally, our app included the ability for invited users (those who are joining a team subscription) to "sign-up" through the app. They can only do something if they are part of a team, because the app shows nothing otherwise. But this lead the reviewer to believe that they should be allowed to create a subscription through the app...which isn't possible. So we're going to change that.

My advice to others in this situation is two-fold:

• know that the reviewers take into account the entire picture of your app that you present. So be aware of the perception that they can get from the way you present your product on your website.
• get a reviewer on the phone - the reviewer can't approve your app over the phone, but given all of their experience they can steer you in the right direction - like with the 3.1.3(f) issue.

We're not approved yet, but we have a direction that looks to be promising.

That's for the detailed follow-up!

I suggest submitting a bug report against the wording on the guidelines. I think that "e.g." should be changed to "specifically".

I think this is one of the under appreciated aspects of App Review. They are an unbiased, outside set of eyes looking at your product and website. If they're confused, then end users likely would be confused too.