I have been developing an iOS App since 3 years and in the last update I send to App Store Connect they reject it due to they told me that my application din't obey the rules that an app should follow in the App Store.
This means that my app don't target a regular App Store user, they only can login to my App if they hire my company's services.
So then they "recommended us" (obligated us) to distribute our App by B2B distribution.
As I have been reading the way it works is to sign up each of our clients to the B2B program. I hope this could be wrong because we have more than 10000 users that we can't manage their Apple ID to add them to our B2B program one by one.
Do exists another way to distribute my App like give to my user a key/url to let them join to our B2B program or what?
I think that I am missing something.
Thanks for your help, all information I have tried to get from Apple web page is cumbersome and I have tried to talk with them but they only send me Emails 1 per day and with no really relevant info like they don't wanna know about me.
Related
I'm iOS developer and googled my queries's answer but still i'm having some vague concept of following queries so need some expert feedback. Thanks in advance.
How can I distribute my app to my clients(who may have more than 1000s of users), I know i can't go with Enterprise account(as its restricted to only employee but my problem is to distribute to clients not employees), I think Apple Business manager has solution of my problem https://business.apple.com/, am I right ?
I already have published app on store now some of my clients want branding and then upload onto store with their name, so can Is it possible to rebrand app with same feature exist on store with different account ? AFAIK Apple isn't like it and reject app sooner or later ? If its true then what will be right solution to rebrand my iOS App.
Looking for help on these queries.
For case 1, you can create a B2B custom app which the client can then access through Apple business manager for distribution to their users via an MDM.
For case 2, the clients would need to get their own developer program membership and make you a member of their team. You can then rebrand the app and upload a build for them to distribute under their company name.
Both of these scenarios and more are discussed in this WWDC 2019 session
I have a client who wants to deliver the app to 50k specific users, at start. Then he wants to go public with the app after some time. However, this could not be seen by users as beta testing, since it's just an "exclusive" earlier possibility to access the app, not tests.
We know these users since they are a part of other service users group. We will probably create accounts for them and distribute login/one-time-passwords by invitation or give them the possibility to log in with credentials from the other service.
I've been searching for the solution (e.g. https://www.knowband.com/blog/mobile-app/share-ios-app-without-publishing-on-apple-app-store/) but still, I'm not sure which way to go. We're still in the middle of development so we can provide a possible solution and even make changes in the onboarding/login process. But we have to have a decision on this matter.
From possible solutions:
AppStore - we would not give the possibility to register in the app and just people with credentials could log in. But is it even possible with an iOS app and not be rejected by Apple? I know that many apps don't have registration within the app (e.g. banking apps) - how do they do that? They just say that registration is available only on some www/in person at the bank and you receive credentials to your account somewhere else?
Enterprise distribution - this is probably not possible since users won't be employees of my client. These are regular people.
VPP - I've heard about it recently and never tried it but isn't it just a "simpler" Enterprise solution and shouldn't users be also employees of my client? Can VPP apps be changed to regular AppStore apps afterwards?
I think right now option 1 seem the most possible one since the app will be distributed to all the users after some time (we will add registration then). Any ideas on the matter? How can we not be rejected using solution 1 during a review?
Solution 1 is possible, you provide apple with certs in App Store connect when you submit to the store. Specifically the field 'Sign-in required'
I would do that, it's got very little time overhead as compared to the other two.
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 have an important question to ask here. First of all I don't know where to exactly post this question. Sorry about that.
It's about making an iPhone app. I've client from Constanta, Romania. He provides billing services to customers. The scenario is like this:
His customers submit their utility bills and the respective bill payments to him and from there on he takes care of submitting them on their behalf. And he takes service charges from the customers.
He wants to make an iOS app for this. Where in people will scan their bills via app and submit the bills along with the payment of the bill to him using their credit card (like stripe for iOS or PayPal) and then he submits their bills.
The question I have in mind is, does Apple allow this? to have such an app?
I have a doubt that this cannot be done at an individual level as he is not selling a tangible product in return for the money but a promise. Is my doubt correct?
But if the entity thats providing such services is properly legalized and has all the end user agreements and proper licenses available in the app for the user to accept, is it fine then to go ahead and make the app?
I want to know the possibilities of this scenario as this is a limited scope application and the target audience belongs to a particular area or community.
Would an adhoc distribution of the app work?
It would be great if someone can give me a good analysis of this requirement and the possibilities. Thanks!
I would like to suggest to build app using third party payment gateways
eg.
1) ekashu credit call.
2) Dibs.
3) Payment Express.
4) SIX Payment gateway.
you can see above payment gateways in app which is developed by me.
1) https://itunes.apple.com/se/app/waytopark/id803005911?l=en&mt=8
2) https://itunes.apple.com/us/app/waytopark/id886660669?ls=1&mt=8
first two payment gateways implemented & rest two is in development/testing phase.
If you want to build and install application for limited area/community then you need to send application manually to that users for install OR install app manually from your end, OR build separate web application for download .ipa to install.
if you use AdHoc distribution for distribute app to that area/community, you could, but AdHoc distribution valid for one year and 100 devices only. App will work only up to valid provisional profiles (1 year).
first screen of app will have a enter code, code will be validate at server side, if valid code entered, app will open to use else block/stop processing. unique code will generate at your side and distribute code to each user which belongs to area or community. App upload on app store,instead of distribute manually because if you update app, you need to notify each user to install app updates that manage by app store and you don't need to distribute app manually using AdHoc distribution.
Hope this will help.
The only thing that Apple should probably not allow is if the App does sell virtual goods and you do not use In-App-Purchases.
Everything (legal) else is fine if you use some other services.
We're a small company and have developed an iPad app we would like to give to our customers. I've read through the B2B option but don't like our customers having to register their DUN info with Apple.
Should I just load it in the App store and put in the description that it's a private App? It requires a login so it doesn't matter if other folks download it.
Currently, we're using it in house via the internal tester scenario.
No one but Apple can say for certain what Apple will do in any specific case, but your description suggests it will be rejected.
From Apple's App Review Guidelines (https://developer.apple.com/app-store/review/guidelines/):
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
If you don't have a base functionality that applies to the general public, you will, in all likelihood, need to go Enterprise delivery.
Distributing publicly might be the best option, but I don't think you would get an approval if you describe it as a private app in your description.
Without knowing too much about your business or the nature of your app, it's hard to suggest, but possibly you could add some public usefulness on the front-end of your app, even if that's business info, contact information, a news feed, etc... with the real intent of the app being tucked behind a login portal. (all total speculation).
Distributing the app outside of the app store has a lot of limitations as well: http://mobiledan.net/2012/03/02/5-options-for-distributing-ios-apps-to-a-limited-audience-legally/
I would just submit to the app store and see what happens. Apple may reject it, but that is true in any case. I have an app of this nature, submitted with a couple of test accounts, no problem getting it approved. When the app launches, it pops a logon screen, and has a short message about where to get an account (which won't make much sense to people not in the intended audience).