I've been working on a simplified, web-based ad-hoc build management service for a while now, and I'm going over the possibilities to my make clients life easier.
While one possibility is to simply create a web app optimized for iOS, I'd rather have a native app instead.
Now, I haven't found any clear advice on whether or not Apple is okay with apps using itms-services links, which would then install 3rd party non-App Store apps, as long as they were signed ad-hoc/Enterprise builds.
In my case, the apps in question would be tied to a specific user/group, and would be behind a login/signup.
Currently all I'm doing is:
[[UIApplication sharedApplication] openURL:_appInstallUrl];
Also, if Apple would be okay with an app like this on the App Store, how would they feel about forcefully suspending apps?
I'm currently doing this right after installing the app:
[[UIApplication sharedApplication] performSelector:#selector(suspend)];
This could be a violation to the App Store Review Guidelines:
2.8 Apps that install or launch other executable code will be rejected
2.25 Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected
But you'll only know if you directly ask Apple, or simply submit it and it goes through.
Posting this as an answer, since it's the official response from Apple.
I first contacted Apple's technical support regarding this, but they couldn't help and instead wanted me to contact the App Store Review Team, remembering to mention that a technician had told me to contact them.
They finally responded with the following:
Thank you for contacting the App Store Review Team.
Please know we are not able to pre-approve proposed application ideas or concepts for developers without reviewing the app itself.
Each application is unique and we would need to look at all its features, and complexity to be able to give you an answer.
Therefore, we recommend that you submit your application for review. We will then contact you if we have any questions.
However, for your questions we do recommend that you review the Functionality and Privacy sections within our iOS guidelines:
2.22: Apps that arbitrarily restrict which users may use the App, such as by location or carrier, may be rejected
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
While this technically doesn't answer my question (at all), it would seem like the idea/app could still go through, depending on the reviewer. At least they don't seem to be against the idea.
Related
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.
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 would like to create an iOS App for a limited set of people.
It should be possible to download the app for free from App Store, but in order to use it
the idea is that you are required to be a member of the organization, which in this case is a local sports organization.
To solve the problem I thought of giving away activation keys to members that can be entered when they create an account, and therefore only members will be using the app.
Will the app be rejected by App Store? If so, is it possible to go around this in some away?
Thanks.
No you will not be rejected by the App Store.
During the review you will only need to give the access to demo account.
Your app will be available to anyone but you are free to give the credential to any person you want.
edit
Fyi I have such apps. The AppStore only block 'discriminating' app based on carrier or location (you can choose the countries anyway), but you are perfectly in the rules if you give access only to your clients...
edit edit
2.22 like I said is against arbitrary criterias, not linked to the login mechanism
for 11.1 and so on, I understand the point, but in my case (and I think yours) there is no problem if
you sell your service before, the app is just complimentary
you dont sell anything within the app
you dont charge for the app itself or anything within the app, you charge only the use of the server/back office/whatsoever
I guess that Apple dont care, they just don't want to bypass the applestore but I dont think that it is your case.
You should try Enterprise distribution for such purpose.
Yes your app may be rejected. Check the App Store Review Guidelines. In 2.2 it says
Apps that arbitrarily restrict which users may use the App, such as by location or carrier, may be rejected
There are different alternatives.
You can opt in for the Apple Developer Enterprise Program, this'll cost you 300$ a year and requires you to be a legal entity.
If you want to test it with a limited number of people (<1000) try looking into Testflight it was bought by Apple and is deeply integrated in the development process.
No, there will not. You need to to give some demo account info as test data to review while submitting to app store in the iTunes Connect portal.
Demo use case(worked for me): Implementation is like, there need some userid/unique pin to the registered account holders to start the application. At the time they input this pin, authenticate the user with our server and give the permission to let in to the app.
Otherwise you need to go for enterprise distribution. Find more about enterprise distribution here.
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.
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.