I've read everything I've found on in-app purchase and don't know whats the best way to go in order to do the following:
I have an app I'm developing and want to set two paid options + 1 free option in order to access sample content and paid content.
I'd like to offer a paid 24 hour access and I've read this goes against apples TOS. (sorry but cant find the doc now). Says something like they wont allow apps that recognize and restrict content for specific amount of time.
Wondering if creating two consumable items
One Year membership Item
One day access item
Could be a good option and if doing this would be OK with Apple's TOS.
Apple's docs about consumables only talk about games, such as weapons, food, levels.....
Feel free to comment and suggest other ways to accomplish what I'm after.
At first I thought of subscriptions, but I think the shortest subscription term is a week.
Related
I want to create a "personal finance" app with Flutter.
I want to access my bank account stats from my app in order to keep track of the money I spend and/or I earn.
Is that possibile? (which I think it is 'cause other apps seem to do it)
And if it is, what's the smartest & safest way?
Well, flutter can help you achieve this based on the following:
Your financial institution permits you to carry out such actions.
Your financial institution provides necessary API's for such developments.
I was just wondering if it was possible to make 'direct' payments in swift (Stripe/Apple Pay), from 1 person to another, where the owner get's a specific percentage of the total, as a markup for the service? pretty much like how Fiverr works, etc.
Would I have to store all of the card information encrypted & salted server-side, or what are the safest options then?
And also, where can I find a tutorial that shows you exactly how to do this?
I would suggest having a read of Stripes documentation before posting.
However it would sound like you want to use Stripe Connect, which would allow you to build a "market place" type solution you are describing.
Note their are a few different ways to implement stripe connect - and you should read up / contact their support before deciding on the best way forward.
I see that many iOS games nowadays don't hardcode their store, and items, description, price etc. are loaded from an external server.
What would be the easiest way to implement this? I am a game programmer with very little experience in server side programming. (Have done hobby PHP scripts a long time ago)
Please let me know what libraries can ease the effort on server side / client side. I would like something that is easy to manage. How do they announce offers like 50% off on certain items etc. whenever they want? Doesn't every in-app purchase manipulation need to get approval from Apple?
Also I would want to maximize security, and prevent the game store getting hacked as much as possible.
You are correct that this has to go through Apple's IAP. You'll want to read about this at https://developer.apple.com/appstore/in-app-purchase/index.html. You setup the IAP items in iTunesConnect (iTC). Your in-app store lists only items that you've setup in iTC, though you can choose not to list every item in ITC. To make your store dynamic, the easiest way is probably to use a UIWebView and then have your store be a series of webpages. This lets you update it on your server easily.
You might check out http://stackmob.com which makes it relatively easy to do just the store part of your in-game store without having all the server admin aspect of it (and associated security). Also, http://urbanairship.com provides hosting for IAP items.
I am developing an app that has an sqlite file embedded inside.
That sqlite file is being copied to the /documents folder of the app, and contains the data of a specific version of a book (it's an advanced search app for a specific book).
I've also implemented an subscription service (via inapp payments) for that app, for updating the content. for Registered users only. Basically the app update will occur once a large number of update entries is fulfilled or a bug fix, so that the newer user would have to download a lesser number of updates.
The problem is that the old users have paid for a specific book. New users could pay for the extra book, at the same price (consider it an updated version). Is there any way to "forbid" the old users from having access to that book resources since they have not paid a subscription or the app at a latter time?
There are different types of inapp purchases: non-replenishable, replenishable, subscriptions, and auto-renewing subscriptions.
The user will always get what's embedded, though, if you don't track user status yourself (which probably is not worth it) - and then you have to deal with the problem of giving him that exact version.
The main question remains though: Do you really want to penalize your early buyers? Their money came to you first (so it is more worth than the current buy), and now they are left behind with less.
If there is really new content frequently, you might want to go the subscription route. Personally, losing my purchased data like a book just because you bring an update would leave you with one frustrated customer less.
A different route is to limit the support for that app to a specific date and then get your users to buy a new (different) App, maybe with making the first app cheaper during its final stages, and then removing it altogether.
You should aim to make your users buy as soon as possible. But with your business model, it is actually better to buy as late as possible, and often late equals never in practice.
This question is for those familiar with implementing the iphone in-app store functionality.
The app I'm building has only built-in features that are unlocked when features are purchased. Further, any modifications or additions to store items will require an app update. Also, it is only in English so has no localized languages for the items.
If we take those assumptions, is it feasible to skip the step of retrieving the product info with SKProductsRequest and simply use hardcoded data within the app? While I may want to extend my app to greater complexity in the future, I'd like to know if this step to keep it simple would introduce some serious issues.
One issue might be, for instance, if we have to expect a few of the items to occasionally be unavailable due to issues on Apple's side and simply trying to purchase it and letting it fail would not be a permissible or workable option in that case (especially if it is uncommon).
Thanks.
I suspect that Apple would object if you used hard-coded prices in your app, although I can't say for certain that they'd reject you.
Bear in mind, however, that localization isn't just about languages. It also gives you localized prices. Currency values fluctuate, so we can reasonably expect the localized prices associated with a given tier to change from time to time. The possibility of getting money from users in Canada, UK, and other territories beyond the USA seems like ample justification for using SKProductsRequest, whether it's technically and contractually required or not.