I'm building an educational iOS app and I'm wondering whether it's possible to limit the number of installations per user. I expect elementary schools to be one of my primary customers, however many schools use one Apple ID for all of their iPads, and therefor would only have to pay once for my app regardless of the number of iPads it's being installed on. Does anyone know whether it is possible for me to limit the number of devices it can be installed on based on the subscription fee?
This is not currently possible. A solution for this is to have the subscription tied to an account and require the user to log in. If you do that then you can ensure that only one user is logged in per account.
If you are using a framework that allows you to see the device UUID then you could also tie the subscription to that.
Create a service and ensure that only N number of apps are open at any time for each account. It's essentially what Netflix and other subscription based services do.
In any case, there's no way for the App Store to validate your service subscription before allowing people to download the app.
Related
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 have currently an app that through in-app purchases a user can unlock content on the app. What I have noticed is that some users "abuse" of this by logging with their Apple ID in multiple devices and I'm currently looking into possibilities on how to limit the use of the content to the device where the purchase was done. I understand that Apple doesn't allow that, so that means the payment system should go away from the app.
Therefore, introducing logging will help me to be able to identify the person that is using the app against a backend but still, I need to be able to limit on a device. As far as I know, the UUIDString of the CurrentDevice is not really a way anymore. What other options are?
I saw this library, which seems to promise unique identification:
https://github.com/fabiocaccamo/FCUUID
Another solution probably would be to create a licensing system, so one license can only be used at the time.
Thanks!
I will describe our experience with using same account on different devices (VOD):
User is able to use application on how many devices he want, but he able to watch content only on 5 uniq devices.
Each time user try to watch content, app check if device registered with some UUID, if not then try to register. UUID is uniq per installation, it mean that if user will watch content, then delete app, download again and watch, then he basically lose 1 device.
In same time user able to unregister device via web, but he had only like 25 unregistrations (I don't know what happened if user use them all).
We don't use in-app purchases and accounts are cross-platform (android, iOS, web, tvs, etc), so not sure if it helps you.
AFAIK, Apple does not have limit on how many devices you can user Apple Id. You can have 6 family members so number of devices could be lot more.
I feel it is bias how Apple's guideline talks about limiting music, movies, shows and books to 10 devices but does not say anything about Apps!
Apple - Family Sharing
If your family has purchase sharing turned on, music, movies, TV shows, and books can be downloaded on up to 10 devices per account, five of which can be computers.
I have not seen any application limiting IAP on devices. You could run into risk of Apple rejecting your app, potentially on every update you submit. I would reach out to App Store or if your company have Sales rep contact and get their suggestions/buy-in before spending lot of time and money.
Also, create issue/radar and give specifics about issue. More people request this feature, has better chances of it getting added.
One way you can achieve this is to keep track of receipt you get for IAP and check how many users/devices using that receipt. You would need to build entire flow to educate user about device limitations. Like updating App Store page, warning before purchasing, option to add/remove device and more...
If you are planning to implement device limitation, please beware of the rejection risk.
In an iOS application, When I detect a users improper action (for example posting violent content), I wan't to suspend the user from using my application. The basic idea to implement this feature is to create and save an unique id for each application installs and suspend the usage from server api's.
My question is, how can I implement this feature even if the user re-installs the application, and still pass the Apple's iTunes submission?
I came up with two ways to technically implement this feature, but wondering how Apple would respond.
Store the IDFA (I understand that users can reset the id on their behalf)
Store an app generated udid to the Keychain (which should not be deleted even if the user deletes the app)
I know there are no perfect answers, but would appreciate to discuss this issue with anyone that have tried submitting a similar application, or anyone that is well aware of the Apple's guidelines. Thank you.
Apple will reject apps that inappropriately use the IDFA.
If your app does not use server login (at which point, whatever flags you require could be delivered to the client), keychain storage would be the only real solution.
However, if you don't use server login, you block the device, not the user. Is this your intent?
BTW, without server login, a determined user can still get around keychain storage: Reset keychain on the device
You can block a given account. Most people these days key an account with an email address. Some require a credit card (Facebook fully validates accounts using credit card numbers), others require a bank account (PayPal has to send money somewhere!) and it is growing in popularity to request a phone number (Twitter is getting there). In the end, to really be effective, you have to block something that is difficult to produce.
With email, your users can always create a new account. Check out mailinator.com. Alternatively, all you need is one domain to have as many email addresses as you want -- I use five different email accounts daily, and I use about two dozen more on a monthly basis.
Installation ids are ok but users can always just uninstall/reinstall. And if you do manage to get a device-identifying number (easy to do really, even in the post-UDID era) so that you can block a given device, your users can just get a new device, or hack your app to use some random value, or spoof your API with cURL. I own three iPhones, two iPads, two Samsung tabs, three other Android phones, two Mac Book Pros, a mini, two PCs, and I run three virtual Linux boxes, and one virtual XP box. And what happens when somebody sells a blocked device to a non-abusive user?
So just block the user's account, keep excellent log files, and keep fighting the good fight.
I have a client who wants a mobile app that requires the user to enter a code to start using the application.
This is basically a promotional campaign for a new product: each product bought gives the user a code that he can put in the app to "advance" to the next level. The "game" consists of six levels. All users that finish the game will participate in a draw to win some prizes.
Is this allowed? I am concerned that the user cannot use the app without buying the product first.
All I could find, here and on Google, refers to selling stuff in app but nothing about this particular case.
Final thought: if this is not the right place to ask this question then I apologize...
11.1
Apps that unlock or enable additional features or functionality with
mechanisms other than the App Store will be rejected
11.16
Apps may enable additional approved features or functionality when
used in combination with specific approved physical products (such as
a toy) as long as the additional features and functionality are either
completely dependent on such hardware (for example an App that is used
to control a telescope) or also available through the App without the
physical products, such as by way of reward for achievement or by use
of IAP.
They just don't want you using any trick to avoid giving Apple their share. If your app is strictly promotional, you may get a pass for 11.1.
11.16 is for things like Skylanders. You can also follow the above clause or also available through the App without the physical products, such as by way of reward for achievement.
They do allow apps for sweepstakes/raffles, as long as you don't buy the raffle in the app, so it might fall into that category:
Contests, sweepstakes, lotteries, and raffles
20.1
Sweepstakes and contests must be sponsored by the developer/company of the App
20.2
Official rules for sweepstakes and contests, must be presented in the App and make it clear that Apple is not a sponsor or involved in
the activity in any manner
20.3
It must be permissible by law for the developer to run a lottery App, and a lottery App must have all of the following characteristics:
consideration, chance, and a prize
20.4
Apps that allow a user to directly purchase a lottery or raffle ticket in the App will be rejected
If you're worried about 11.1, I think one trick here is to make it not usable at all until you enter a code. "Additional" being the key word in "additional features". Then, it's the NetFlix model.
You'll need to provide codes for Apple to test the app.
We are looking at using consumable (non-renewable) IAP for subscriptions for our app after being rejected for auto-renewable subscriptions. I've read through many posts pertaining to this, but haven't seen any discussion on limiting the number of iOS devices a user can use the consumable on or "restore" to.
The main concept seems to be, let user create an account (optionally) on your server, and allow them to enter account info to restore/share across multiple devices.
My primary question is, how can we limit the number of devices a user is allowed to use the subscription on, and the number of devices a user is allowed to "restore" to, and still meet Apple's requirements for restoring purchases?
If we setup a server, and allow the user to optionally create an account to store the receipt information, how can we keep that user from sharing their login information with anyone if we have no way to uniquely track the number of unique devices that are using the account? (perhaps I'm wrong here, but with the deprecation of UUID and the possibility of identifierForAdvertising changing if the app is deleted and re-installed, there is no way to cache a unique device to determine how many devices have used the subscription, correct?)
I've contemplated storing an auth token in the user's iCloud, but from my understanding, there is no upper limit on how many devices can share an iCloud account.
I'm sure I'm not the first to run into this problem, how is everyone solving this?
Thanks -
Matt
Consumable items are intended to be device-sepcific. And once consumed, the user must purchase it again, even if it were purchased previously on the given device.
Apple doesn't officially want you to limit the number of devices for subscriptions or non-consumables - they want your IAP subscriptions and non-consumables to be available on ALL of a user's devices. See: https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html
Why not use iCloud to transfer an IAP non-renewable-subscription between devices? That limits it to just the user's device set. Why do you care if they have 2 devices or 10? I bet that users don't typically share their apple-id's outside of their immediate family.