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.
Related
We have third party payment gateway on our application and apple rejected our app stating we need IAP.
Our app is supposed to be a coaching/career/testseries related app i.e. something like where you can buy content to study and practice on demand
Here's our business model and I need insights on how to approach it with IAP
Our platform let's user buy "x tests for y amount of money that expires in z days"
If you have used all "x" tests then you can check the new available plans and purchase them and similarly if you have passed "z" days.
These plans are non-renewable cause the tests are limited in nature and the pricing, no of tests and expiry keeps on changing depending on the market.
How do we approach this case?
Also the added complexity is also adding third party payment capability which in this case seems almost impossible but I'd like to ask
You cant use 3rd party payment gateway if the goods are digital.
your options:
make an in-app currency (coins) like games, so the user can buy a package of coins (for example 1000 coin) using app store IAP, then use it to buy stuff in your app as if it was 3rd party payment gateway.
show the different programs that the user can purchase and tell them to buy them from your website (but you cant put a direct link to your website in app) you can see how Spotify handels this in its iOS app install Spotify App and see how they do not even link to the main website of the service from the app because this is not allowed.
you can only show description and tell people to go to your website without linking to your website.
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.
Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
I am completely new to this so please bear with me.
I am developing a service and as part of that service I'd like to give users the option to upgrade their account to get some additional features in return for a small monthly fee.
The service is mobile-first and will run on iOS and Android, as well as a website with some of the features you can get from the app, account management, that kind of thing.
I don't really want to have to encourage people to use the website to signup as the app is supposed to be mobile first. Equally I need their account across any device they wish to use to recognise that they are a premium user.
My question is related to how IAP's work for this monthly subscription:
Do IAP's apply here or can I just use my own sign up and credit card processing? The user isn't buying any downloadable content, just the ability to access a couple of small features on the app.
If they do apply, how would my website or the Android app know that the user has purchased a subscription on iOS?
Thanks in advance
IAP do apply in this case, but please be aware that it might be against some policies to buy some service on iOS and use it on android and vice verso.
About the process itself, you can use non-renewable subscriptions or renewable subscriptions and communicate the electronic receipt to your server to verify it with apple/google servers and keep your client status on server (active/paid or not active/not paid). And you only authenticate with your server and get the status, while on client make the decision to show the option to buy/extend subscription.