I'm building an app which I intend to distribute through the Mac App Store. I will use in-app purchases to allow users to buy "credits" which they can consume in the app. I will use Apple's IAP APIs to handle the money transaction side of things, but I'm wondering how I best go about securely storing the current balance of credits.
Obviously, I'd like to avoid "clever" users from messing with my app's files on disk to increase the number of credits, so at the very least I need to encrypt this file. But even that is not sufficient, because a user could simply restore from a backup copy to restore their credit balance.
One obvious option is to run my own webserver and have the app connect to that for every transaction, but that sounds cumbersome. I've looked for virtual currency services for iOS (since this is much more common in iOS apps), but most (all?) of them have some cross-marketing angle to them, forcing me to put ads in my app which I don't want. I will gladly pay for a service with a simple API as long as it's completely transparant to my users. E.g. I don't want my users to have to sign up for an account on some 3rd party's website.
What are my options here? Any advice?
IF you actually want any real security, you need to use a server.
No matter what kind of cryptography you do client side, users can always reset the state of the app and then add the receipt for IAP that you will then validate. In short, they can always erase the phones memory that they consumed those credits.
If what they are purchasing is only in the app(i.e. its just programaticly unlocked functionality) and is not provided by an outside server/ service, then a sufficiently motivated user( likely with a jailbroken phone) could simply tweak your code to provide that functionality. So you can't have real security in that case. Your best bet is just obfuscation.
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've written an enterprise iPhone app for the field workers in our company, and the powers-that-be are considering offering it to some of our client companies as a freebie for their field workers to use. I assume that Apple would not allow enterprise distribution to users who are not company employees, so I would have to place it on the App Store.
However, we would like to restrict the user base to approved users or companies, so I would like to avoid making it available to just anyone. The app does communicate with our servers, which makes it something of a risk, in my opinion, of hacking; we'd certainly like to avoid that.
I'm wondering if there is a way to restrict App Store downloads only to certain users or companies? Or is there an alternative method to prevent just anyone from downloading and using the app?
Posting as answer, as per the OP...
For your case, you probably want to look at Business-to-Business distribution: https://developer.apple.com/programs/volume/b2b/
You could use the new "DeviceCheck APIs" that is release in iOS11
Using the DeviceCheck APIs, in combination with server-to-server APIs,
you can set and query two bits of data per device, while maintaining
user privacy. You might use this data to identify devices that have
already taken advantage of a promotional offer that you provide, or to
flag a device that you've determined to be fraudulent. The DeviceCheck
APIs also let you verify that the token you receive comes from an
authentic Apple device on which your app has been downloaded.
https://developer.apple.com/documentation/devicecheck
I know, that this question is not directly related to any coding but there are several other question on SO about the App Store and its Guidelines. So I assume, this question is OK.
There are other questions about (more or less) the same issue. However they where asked / answered several years ago and the Guidelines have been updated since then. Additionally the circumstances are always a little bit different.
I am well aware, that nobody can give me any kind of guarantee on which interpretation of the Guidelines is correct. Not even Apple could do this, since everything depends on the review staff an its current mood. However It would help a lot get to know your opinion on what is allowed and what is not. Maybe you already encountered the same problem and have some useful recommendations.
The set of facts:
A Shopping List app is offered in iOS App Store. The app offers functions to create and manage any kind of shopping list. These functions do NOT depend on any external purchase. The fee version limits the number of lists. This limit can be unlocked using an In App Purchase.
There is also a WebApp version that offers the same functions (and a little more) as the iOS version. The WebApp has a one month free trial and can then be extended using a subscription model. Subscriptions can only be ordered within the WepApp, not from within the iOS app.
Both version can be used completely independent from each other.
Additionally the apps can be connected (REST API) to sync lists between them.
Obviously there are pages/controls within the iOS App, that allows to setup the connection (enter username, password, etc.).
Obviously the WebApp has to be described in some way to the user within the iOS App.
Once the free trial ended or a subscription has expired, the sync will no longer work. In this case the user needs some kind of hint why sync is no longer available ==> There has to be information about the subscription model of the WebApp and a discription on how to renew the subscription.
The "Problem":
The current App Store Guidelines are pretty vague on wether this kind of business model is allowed or not:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions,
in-game currencies, game levels, access to premium content, or
unlocking a full version), you must use in-app purchase. Apps may not
include buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
This paragraph is not as clear as it my appear on first sight. Unlocking functionality within your app is only allowed by using IAP. Fine, so unlocking a app feature (e.g. creation of more than 2 shopping lists) would be not allowed. But is the sync functionality I described before also covered by this? Of course there has to be functionality within the app to connect to the WebApp, but the complete sync logic is implemented on the server, not in the iOS app.
The functionality the iOS app offers is "Establish a connection to the WebApp". This functionality works independently from wether the WebApp subscription is active or not. Only the functionality of the WebApp changes depending on the subscription status (accept or deny sync requests).
So: Is it allowed to add some text like "There is a WebApp, too. Use this link to got to the WebApp. Follow this link to renew your subscription" to the WebApp or not?
Or is the part "Follow this link to renew your subscription" forbidden?
What makes the whole thing even more confusing is the following paragraph form the Guidelines:
3.1.5 Physical Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed
outside of the app, you must use purchase methods other than IAP to
collect those payments, such as Apple Pay or traditional credit card
entry. Apps may facilitate transmission of approved virtual currencies
(e.g. Bitcoin, DogeCoin) provided that they do so in compliance with
all state and federal laws for the territories in which the app
functions.
Does this read as "Physical Goods and physical Services" (e.g. postal delivery in contrast to digital Services) or this include all Services?
So, is the "WebApp Sync Service" covered by this paragraph and thus the usage of external payments not only allowed but necessary?
Of course I could ask these question directly to Apple. But I would never get an answer. Even if I would, this would still be no guarantee, that the review stuff shares the same interpretation of the rules. So your experience and opinion will be the best "guarantee" I will ever get.
Thank you very much!
I am building an app that downloads an XML file and ultimately presents stats for financial quarters.
If I wish to add a button that prompts the user to allow another quarters worth of data, can I simply add a boolean value to my app, send them to the store, toggle the flag and allow the download of further XML files from my website?
Read many articles on the web, but my head is spinning!
Ideally I would prefer apple to handle all the backend restoration of data on the device once it is purchased :)
Any useful links or advice would be great :)
In theory, yes. It depends how secure you want the process to be.
In your suggested way, the paid-for content (your XML files) still remain accessible to download across the public internet. You could authenticate the download, but that will require infrastructure on your end, rather than Apple's.
Basically, once a user goes off and makes an in-app purchase your app is sent back a) whether the transaction was successful, and b) if so, an iTunes receipt.
The receipt is critical, since it allows you to verify someone really has paid for the item they're trying to get. Most developers implement receipt validation on their own servers (although you can, in theory, do it on device as well).
You may decide if your app has a sufficiently small market that this isn't required. For apps where it could be quite likely people would want to pirate data, perhaps you want to consider some receipt verification.
It is possible to use a third-party service to simplify the process, if it's something you find a little too complex to integrate yourself. I've never used any myself, but one I've heard reasonable things about is Urban Airship's IAP service: http://urbanairship.com/
for a client, I have been developing an app which has been tailored to make their employees every day lives easier. Think of it as a calendar designed to fit the needs of their special business.
Now it turns out that other companies in the business are interested in the very same solution too. My client suggested we could sell the app on the appstore.
Since the app is equally useful for companies with hundreds of employees as it is for a team of five, I wonder what would be the best way to sell it.
It is my understanding that a company, once they purchased one copy of the app, may install it on as many devices as they want, as long as they use the devices with the same iTunes account. This is especially true if the company would equip their employees with new devices for the purpose, like my client did. Right?
This is obviously not what I want, I'd rather like to charge a small price per device. Usually, this would cry for a volume license, which is not part of the appstore concept, except for educational institutions.
Now I am looking for a convenient way to achieve something with the same effect.
I was thinking about checking the UDID of the device against a whitelist on my server to allow each purchased license to run on just one device, while allowing migration of course.
To enable a company to purchase a "volume license", I would offer packs of additional licenses via In-App-Purchases, as well as individual licenses. The app itself would be free while featuring only demo capabilities, full functionality would be available after assigning the device to one of the purchased licenses. Means to manage licenses would be included within the app.
What do you guys think? Any technical reasons why this concept could fail?
Do you know of examples that actually implement something similar?
Any other ideas how to sell apps in volume? Maybe there are even some examples on how to implement something like this?
Do you think apple would approve this kind of use of in-app-purchases? (I know this last question is not of a kind that can be answered here without uncertainty, but let me hear what your gut feeling tells you..)
This question has been flagged as being off-topic twice, so I think I should back up the fact that I am mainly interested in a technical solution (and emphasized the important sub-questions accordingly). Of course I am interested in whether apple allows the proposed use of their appstore, however before I contemplate that further I need to know if there are technical caveats to my approach. I would love to offer code snippets to support the technical nature of my inquiry, however I'm just planning things so there is no code yet...
While the core question is still business-related here, and thus off topic, I'll bite.
The standard App Store end user license agreement has this wording:
a. Scope of License: This license
granted to You for the Licensed
Application by Application Provider is
limited to a non-transferable license
to use the Licensed Application on any
iPhone or iPod touch that You own or
control and as permitted by the Usage
Rules set forth in Section 9.b. of the
App Store Terms and Conditions (the
“Usage Rules”). This license does not
allow You to use the Licensed
Application on any iPod touch or
iPhone that You do not own or control,
and You may not distribute or make the
Licensed Application available over a
network where it could be used by
multiple devices at the same time. You
may not rent, lease, lend, sell,
redistribute or sublicense the
Licensed Application.
Therefore, if you consult the "App Store Product Usage Rules" section of the iTunes Store Terms and Conditions, you see this wording:
(i) You may download and sync an App
Store Product for personal,
noncommercial use on any iOS Device
you own or control.
(ii) If you are a commercial
enterprise or educational institution,
you may download and sync an App Store
Product for use by either (a) a single
individual on one or more iOS Devices
you own or control or (b) multiple
individuals, on a single shared iOS
Device you own or control. For
example, a single employee may use the
Product on both the employee's iPhone
and iPad, or multiple students may
serially use the Product on a single
iPad located at a resource center or
library.
(iii) You shall be able to store App
Store Products from up to five
different Accounts at a time on
compatible iOS Devices.
(iv) You shall be able to manually
sync App Store Products from at least
one iTunes-authorized device to iOS
Devices that have manual sync mode,
provided that the App Store Product is
associated with an Account on the
primary iTunes-authorized device,
where the primary iTunes-authorized
device is the one that was first
synced with the iOS Device or the one
that you subsequently designate as
primary using the iTunes application.
The rules are quite explicit about commercial enterprises not being allowed to just purchase one copy and install it on all devices at that company.
It is for this reason that Apple offers volume discounts for applications purchased in bulk (where the developer has checked the box in iTunes Connect allowing for this). I can't find the business equivalent, but here's Apple's page on the educational bulk discount program.
While I could see how you could use in-app purchase to activate functionality in an application and make sure that it was properly licensed, I've heard complaints about the practical difficulties of deploying applications using this in educational and business settings. Many applications use this approach for free Lite versions that upsell into the full paid application, so Apple has no problem with this.
One thing I do recommend is that you not abuse the ad hoc distribution system to do any licensing workarounds. The last time some geniuses did this caused Apple to clamp down on everyone's ad hoc licenses and make our lives more difficult.
The correct answer here is for the companies you sell to to purchase an Enterprise program from Apple, then for you to license the application to them. You can use over-the-air distribution to get the application onto their devices, and charge them a per-user or per-device fee.
Let anyone download the app for free in the app store, but charge for licenses/subscriptions outside of the app store. You can then require them to register each device they want to use and you charge accordingly.
Can I bypass Apple's in app purchase mechanism by outside billing?
Thq question was asked long before, but still I feel that the answer might help someone having the issue. All you need is Apple's Volume Purchase Program. It provides the option for custom B2B apps developed by third-party developers, that too can be seen and downloaded only by the authorized client. Cool, isnt it? :-)
For clarifications, see the FAQ
The client can do a bulk purchase, on which they will receive a bunch of URLs. By opening the URL in iOS device is enough to install the app. Of course, you need a Apple Developer account for download and install, I think.