I'm implementing IAP for SaaS application. I nearly finished with Store Kit's integration, receipt validation and other development related stuff. But I still have 2 more questions regarding Apple's guidelines which I couldn't find answer to on the docs.
The first question: I read on few places on the web that my app should provide minimum functionality even if the user is not subscribed. I offer a SaaS app and I don't want the user to be able to use the app if he's not subscribed. I will allow him to purchase a subscription if he is not subscribed. Is it enough for minimum functionality? (I suspect that these minimum functionality restrictions are old and obsolete, as they sound absurd).
The second question: I want to offer the user a possibility to try the app for free without subscribing at all (Without Store Kit's Free Trial option), because I don't want make the user make a commitment to pay before he tried the app (Apple also doesn't provide a convenient way to cancel the subscription, which may cause abandon-users to be charged even if they don't use the app, which will cause bad reviews etc). So the question is, can I do this without risking my app to get rejected? Does apple allow such kind of Free Trial feature which is managed solely by my server?
Forgive me if this info is somewhere on Apple's docs, but I couldn't find anything related. Thanks!
Okay after sending a query to Apple (Which didn't help me much to understand) and submitting an app to the App Store, I may have an answer:
Apple do allow SaaS apps and did approved my SaaS app. I honestly don't know if they checked my app enough to tell if it is okay but it was approved.
My app implements the Free Trial mechanism without App Store's free trial option. It is clearly written on the registration view controller that the app offers 3 month of free usage without obligation, and then continues without popping and App Store free trial page or something. My app was approved so I guess it is actually okay and within Apple's guidelines.
Hope it'll somehow help someone.
Related
I am building out a iOS & Android app. My app may not fully scale to support users and have some limited functionality out the gates. I wanted to put an invite list on the front of registration like Mailbox did a few years ago.
I was trying to read the Apple app store guidelines to creating a "waiting list / invite list" and couldn't get a clear picture. I assume Android is more flexible on this, so I figured I could start with Apple's guidelines first.
Here is what I can find.
In Apple's docs, it says under 3.2.2 "UnAcceptable"
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
In this specific case, I am not blocking by location or carrier. I am just putting up a wall to use the app since some of my users can use it in a limited form, but I can't open it up to everyone on Day 1.
I understand I can run a "testflight" release, but I wanted to make our app available in the App Store for anyone to download since it will be publicly available, just not fully ready for a million people to hit it. My understanding is that the testflight release requires a bit more work based on their docs and isn't as simple as just putting it in the public app store so anyone can get to it.
Apple has the ultimate authority for approving and rejecting apps in their app store so nothing on SO can really be perfect advice. If you are really concerned about approval, you can try to contact apple developers support. Here are a few things I would advise:
Make sure in the developer notes for Apple when you submit to them you include a free account.
In the notes for the app store let the users know that it may take up to __ hours for their registration to get activated.
My understanding is you are doing this to handle the volume of users as you are launching the app. Be advised though that if you start restricting users too much you will possibly get poor reviews. Only restrict usage if absolutely required. If you run into issues make sure you are communicating with the users so they understand.
Good luck with you new app!
I am working on a mobile iOS app that is customized to each client, with their own app icon, startup screen, and a few other changes. Each is then submitted to the app store as an individual app.
This is working just fine so far, but what will happen if there's 1000 clients instead of around a dozen? Does Apple have any rules on quantity, submission rate or uniqueness? Any reviewer would clearly see that the apps are basically the same outside of the branding.
Don't do it. You will get kicked out of the appstore.
Read 2.20 of Apple iOS Guidelines which says that developers that spam appstore with similar apps will be kicked out completely!
Notably developers like AppGratis got kicked for this and many others reasons.
Sorry can't disclose, if you have a developers account though you can check the requirements
from https://developer.apple.com/appstore/resources/approval/guidelines.html
I know this is an old thread but somehow it popped up and the answer selected is not entirely correct. The requester needs the custom B2B program here:
https://developer.apple.com/programs/volume/b2b/
That is specifically made for the purpose she/he asked about: to distribute customized apps to a business without cluttering the app store. There is no cost but your customers will need to join the Apple Volume Purchase Program for Business though that doesn't cost them anything.
The reason I say the accepted answer is partially correct is because obviously one should not spam up the app store with similar apps intended for one business, which is entirely correct. But that does not answer the underlying why they wanted to do this and how they could achieve the result they need which is to use the B2B program.
I have an app in the iTunes store that has full functionality. I attempted to release a Free version which contains half of the functionality, and contains a link to the full version if the user tries to use the other functions.
Apple rejected the app on the basis that rather than having two apps, I ought to have the main app released for free and have the extra functions unlockable using in-app purchasing.
That's fine; I can do this. The only problem is that since I released the full version initially, some people have already paid for and downloaded the full version. When I update this app so that it is free, it will be restricted by default. Those users that have paid for the full version will have lost the functionality they've paid for.
I don't really want to release a second version of the app since I intend on continuing to update the app and managing two release streams would be unwieldy.
Is it possible to somehow offer for free the in-app purchase to those users that have already bought the full version of my app when I update the app to the new (free, in-app supported) version?
Edit: An (unpreferred) alternative would be a way of refunding the purchases to the original buyers, along with a note explaining why. Any ideas how?
What I'd do is add a already paid option within the application itself, and then allow users to enter a license code, or email address depending what you prefer, Which you can automatically issue from their contact details if you have them or ask them to contact you if you don't, which most will as they have paid.
Now as far as the licensing and the verification of these codes you could setup a cheap VPS which verify s the code and only activates with codes that you have entered on the server, meaning you won't fall victim of Keygeners.
Just my 2 cents.
If your app doesn't currently have a username/password registration, I would suggest releasing an update to the paid app that explains to your users on an initial popup view something like:
Thank you for supporting our app. Due to changes in Apple's policies, we will be converting this app into a free app with in-app upgrades. Since you already purchased the full app, you will be awarded all features! Please input an [email_address or username] so that we can provide a painless transition.
If your app has a user login mechanism already in place (username/password), then just store those details and have the user log in later in the "free" app to unlock all of the features.
Obviously, both of these suggestions require a backend for validation, but shouldn't be too difficult to create that.
This is tricky due to section 3.3.3 of the license agreement and Attachment 2. I'm not a lawyer so I'll save my interpretation but, read them.
Another option would be to make the free version a new, different app and leave the original one in the store but unavailable. Then you can still publish updates to it but new users won't see it. Apple would probably allow this considering you are still only presenting one app to new users. The downsides are (1) you have to maintain two versions and (2) you have to start over in terms of reviews etc.
We are using Amazon FPS payment gateway for purchasing goods through IOS app, now we need to upload it to apple review team and as this is production app, it is pointed to production/live Amazon FPS account so here I want to understand if apple really want to buy anything then they need some credentials by which they can test the purchases.
So first thing really apple tests the whole purchase flow? If yes then what credentials should I provide? or should I update the server for sandbox mode till apple approves the app?
You should submit your app and select "Hold for developer release".
Then you can provide Apple with credentials on your sandbox server to test with.
When Apple approved your app, you can switch your server to production, then release your app.
But, I have a feeling they are not going to approve your app because it provides a mechanism for folks to buy things that does not give Apple a cut of the action. This is not unlike the issue with magazines and newspapers (or anyone) selling subscriptions via non-Apple Store mechanisms: Apple doesn't like when they get cut out.
Apple would prefer you use In-App Purchase, so they get a cut.
Good luck!
EDIT:
Indeed, there is a distinction to be made for real versus virtual goods, which I guess I missed when I read your post. Sorry.
To your actual question: Will Apple test it? No one knows. :-) You should assume they will, and provide some test credentials for them to use.
I can tell you from experience with a (free) commercial app I built, before we launched the service, we had the app submitted, and Apple did register on our backend and test out the app.
We released a charitable "micro-giving" app on iOS that uses Amazon payments to externally process the donations. We submitted the app with our production payment system.
According to our server logs, during their review Apple never submitted a payment or even initiated one.
It took a couple of submissions to get approved, but their feedback largely was focused on making sure we were complying with Apple's guidelines (donations must be processed external to the app, i.e. via safari), and making it clear to the user what the exact donation process was.
I think it's unlikely that Apple would spend money to test your app, nor would they wait to see if you actually delivered the goods as promised either. However, I do think that they will make it clear to you in their feedback if they want to test without spending real money.
For these 2 rules:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.
Is the applicability of these rules reduced/removed if the enablement/disablement of the features/functionality (11.1) or the content purchase (11.2) does not actually occur within the app on the device.
For example, you write an app that requires free registration but if you visit a website outside of the app (and not linked to from the app) to "upgrade" your registration (by paying money) the app gains some more functionality or content next time you use it.
Thoughts?
My thoughts: you'd be violating the guidelines, but your app could get approved, of course. The payment does indeed not occur inside the app, but the application "utilizes" such a system (which is very broad) thus is in violation.
This reminds me of the Newsstand/subscriptions discussions going on before. Basically, if you offer something outside an app, you have to make the same (or better) offer inside the app (via IAP subscriptions). Perhaps this is applicable in your case, too. Although, according to 11.3, you may not offer services outside your app if purchased via IAP (so you may not unlock features on e.g. a website too.)
You'd also try and offer a free app. Once users (somewhere, somehow) upgrade their account, they can access the members only app, a new, separate app. But approval is still questionable, which brings me to my last part:
"We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it."
— https://developer.apple.com/app-store/review/guidelines/
In short: submit, pray and find out.
What you describe sounds similar to the situation that resulted in apps that used Dropbox being rejected (Link). Apple determined that since the apps that used Dropbox functionality required the user to visit the Dropbox site to sign up those apps were in violation of those rules and were thus rejected.