Free application with some paid features paid outside the application

I have a specific problem. I've published a free application on AppStore. Now, I want to add a new feature which is a part of a complex subscription system, and this feature should be hidden by default, i.e. visible only to users who already have subscription paid on our web portal. There should be no link inside the app which asks the user to pay for that service/feature, they even will not know that there is a paid feature which could be purchased on our web site. This is not my application, but the application which I'm developing for my client, and he thinks that our app could be considered as a "Reader app" (Review guidelines 3.1.3a), we don't force or ask the users to purchase anything. The iOS app is just a feature for the complex system developed on the web portal, so we just want to enable our web users to access their services in our mobile app. The app is completely functional without the paid features. Will we have to implement IAP, or not? Will we have a problem during the review process? What would u do if you were me?

Replies

The application is free, and it has enough functionalities so it conforms to 4.2 Minimum Functionality, so it is not a problem. The app as also live, with all features free.
The problem is that our app is not a player, but a set of different tools for organizing business activities. The feature which we want to add at the moment is a kind of messaging, and a lot of other features/content, so I'm not sure if it can be considered as Reader app. Do 'reader' apps include only previously purchased content, or it can include previously bought subscriptions for a different kind of features. For example, this solution offers a package with different features, like some digital services, non-digital services, cloud solutions. The feature I would like to add is just a part of the subscription plan.

In your example, I'd think the ASRG's more recent addition of 3.1.3b Multiplatform Services pertains, rather than just reader app, which it seems it is not 😉


I would move to add IAP/subscriptions, keeping in mind that no one here can promise what App Review will/won't accept reject.


Good luck.

If I were you I would drop that client immediately. What you (or at least your client) is planning is a blatant violation of your Apple and App Store developer agreements. It might even be illegal depending on the content of those messages.


Whose account is this app published under? In additional getting your app rejected, something like this would get your entire account closed. Apple has ways to tracking who opens accounts so you might not be able to open a new account.


This is a idea and client that you really need to drop. Do this now.

We don't try anything iillegal or against the Apple/App Store developer agreements, so you shouldn't accuse anyone in that way. That's why I've asked the question, because the Apple Review Guidelines aren't 100% clear, or at least I don't understand them, but as I can see, many people don't understand them, and a lot of things depend on the person who reviews the application. We'll send the app on review with all information relevant for reviewing, so we'll see which answer we'll get.

A reader app does not unlock functionality within the app. That read/display functionality comes unlocked but can only be used to 'read/display' content that the user purchases. In that case the user can make that purchase outside the app using non-IAP means. By your description above, it sounds like the app is not a reader app.


The app could be a multiplatform app (as suggested by someone else above) only if it is actually functioning on another platform. If you are adding features to the app that are not on that 'other platform' then you need to charge for them only through IAP.

Everybody understands the App Store Review guidelines. But anytime you have literally billions of dollars flowing, people are going to try to game it. You needn't be so defensive. Take a look at the questions being asked here. A very high portion of all the questions on the Apple Developer forums are from developers complaining that Apple is enforcing its developer contracts.


What I am telling you is that you need to be careful with your choice of pronouns. I wasn't addressing the plural "you" in terms of you and your client. I was giving advice to you, personally. From what I understood in your initial post, you published this app under your own account. Any negative repercussions will be on you. You are the one who will never have an app in the app store again. Your client will easily find some other developer who is either more clueless or better at gaming the system. It doesn't matter to them what happens to you.


The App Store Review guidelines are clear: "Don’t include any hidden or undocumented features in your app". That is, word-for-word, what you asked about. And that's just Apple's guidlines document. What does your client really intend to do with this hidden messaging system? That could very well be illegal in much of the world. Who is going down for that? You or your client?

Thanx for the answer.


"Don’t include any hidden or undocumented features in your app". That is, word-for-word, what you asked about.

  • I haven't even known about this rule, so thanx for noticing it. Honestly, I am not very familiar with Apple Review Guidelines, I should read it several times to know all aspects of it
  • We didn't have the intention to cheat the system, I just was asking do we need to implement IAP since we already have purchasing system outside the app, but we don't force the users to make any purchase.

But based on some answers here, we'll definitely do everything to comply with Apple Review Guidelines, wherever we like them or not.

That is something that trips up many developers in the app store. They only think about their own intentions. Then they get upset when Apple arbitrarily rejects their apps. But there are millions of developers. Some of them don't have good intentions. There is no way for Apple to differentiate between the two. Sometimes Apple detects patterns and discovers illicit, malicious, or illegal behaviour. Sometimes the press discovers it before Apple. Then, Apple's rejection trigger finger gets pretty itchy the next time something comes past that looks identical to 1000 other scams.


I suggest you don't try to hide anything. Study those guidelines. Try to think about how your app would be evaluated by an Apple reviewer who has just rejected 20 obvious scam apps in a row. You can tell your users about those other features, you just can't link to them. I can't tell you whether or not Apple will interpret your app as a "Reader app". There are some complex legal and market analyses that go into those determinations.


If your app does have features that might be interpreted as "hidden", make sure that you tell Apple when you submit your app. There is a field just for these kinds of explanations.


Also make sure that you include these uncertainties into the contract with your client. You don't control Apple. You may need to make substantial changes, like implementingn IAP, to get accepted. Because your account and reputation are on the line too, you can't try anything that could even be interpreted as unethical or illegal. Your client needs to be the one to fund this effort, not you.