Let's say that I have an application that helps people "manage" a certain number of "items". Normally they'd have to manage information about these items on paper, but my application will let them do it on the phone.
I want to sell my application by the number of items it supports. For example, I might charge $10 for the version that has a limit of 20 items, and $15 for the version that lets you manage 40 items.
What's the best way to do this? Ideally I'd like to let users download the application for free as a sort of trial that only supports a very small number of items like 2 or 3, then they'd have to use in-app purchases or something to buy additional capacity.
I also need them to be able to "re-download" their license from the app store if they wipe their phone or it gets destroyed.
I also want people to be able to buy upgrades as they go along. So once they find they need to manage more than 20 items or whatever, I want them to be able to buy an upgrade for 40 without having to reinstall the app or something.
Installing extra application bundles for each license or license upgrade seems like a bad way to do things, though I'm sure I could have them all use the same bundle seed ID and have them insert license info into the keychain or something.
Anyway, ideas?
You could use in-app purchase to add extra “items” to the user’s list. That will survive a phone restore and you could support adding as many “items” as possible.
I think the best way is to manage this via some sort of subscription where the 'items' are stored on your server rather than the phone. Then you can control the number of them and use the app to access each item.
So, you run the app, it manages these 'items' and each item is stored on your backend database. Depending on their subscription, you can allow/deny attempts to add items.
Alternatively, I guess you could do a similar thing on the iPhone using the built in database but you'll still need a backend somewhere to keep control of the number of items they can manage, whether that's via some sort of certificate or whatever.
Related
Here's the thing.
were doing some cross-platform game, selling some virtual currency to be used on our game, and life are awesome. Until came the requirements for BI.
The requirements are completely legible - no magic here. Only that with Apple, it's (how to say gently) ...hell.
Here I have to report for every package that was purchased, what is the price that was presented to the user, and what of it was passed to us.
So, OK, after I get a report of a successful purchase and get a receipt
I pass it to my server
I check the receipt with apple, get it decoded
in the receipt I find the package ID - awesome.
But there is no information about sums :o
All this is available when doing billing integration for credit-cards. What would be the equivalent for Apple In-App Purchases?
More info? Ok.
I could cheat a little and solve half of the problem, naming packages like
com.example.vc100
com.example.vc100_promo1
where in both packages the user buys 100 coins of VC, but
vc100 is sold in the usuall case, by the price of some tier that makes sense to our game-balancers, and
vc100_promo1 is sold by promotions by the price of a cheaper tier that makes sense to our marketting.
So, the fallback would be to maintain two lists. one on our servers, and one on the apple back-end, repeating in both ends the relations between a pack and a tier.
Another fallback would be to encode both the VC-sum and the tier in the name. But that would be a partial solution, because we still don't know what price was presented to the user, AND need to maintain a list on our side that would update every-time a price tier is redefined.
Yuck. I refuse to believe there's no better way to do it!
My goal is that marketers can create whatever product-SKU they wish to sell in one place. Obviously, Apple wont let me do that, so at least let it be one list per platform: apple-skus on the iTunes backend, and cross-billing-provider skus in our integration layer for our billing partners, who are much more cooperative than the ...appholes in apple.
Basically, if clients can pull this information and present it to the users - there has to be a way to do it on our servers, and collect this information for BI events.
Having the commission that apple cuts a constant percent from the US price - all we need is to have on our servers the prices for the sold SKU in local currency and USD.
Anybody?
Unfortunately -- incredibly -- Apple doesn't include the price tier as part of the receipt, so the approaches you've outlined are the only options:
The client can store the price tier + local currency price and send it up to the server at time of purchase
The server can maintain a separate list of [product ids -> price tiers], and [price tiers -> local currency price] per tier, both of which need to be kept in sync with iTunes.
It looks like iTunes connect has an (unofficial) JSON API, which could be used to automate #2 (keeping the server in sync with iTunes). I haven't tried it though!
See iTunes Connect API and https://github.com/fastlane/itc-api-docs
so, no long - no answer.
We could not find a way to get this info from Apple in a peer-to-peer request.
What we ended up doing is collect the sums on the client and pass them to the server together with the receipt, protect the values with hashing signature, and send it over ssl.
If there is a better solution - I'd still want to learn about it
I am currently developing an app for a company that is in a very competitive field. I have finished all of the features of the app that they requested except for one, making it somehow protected from their competing companies to download and use. I thought that I could set up a UIViewController with a password field that would check against some kind of database, but I'm not sure how to do the checking against a database part nor the practicality of it, and was hoping I could get some ideas on how to do this so that other companies couldn't steal and use this app without a password or something that changes like every 30 days or something and is kind of like an activation code.
Review the WWDC 2012 video "Building and Distributing Custom B2B Apps for iOS". I'm unsure if your app is in this B2B classification, it seems that it might be from your description.
What I ended up doing (if everyone needs a reference) was setting up a server with an SQL table that has pass codes in it. Since apple does not allow for any sort of system that requires you to "buy the app from outside the app store" I made a dumby username field (shame on me) that takes any value you like and then requires to have a pass code that fits. Once the pass code gets authenticated with the web server in a json sql request (there are plenty of api's to do this with) it comes back and sends the user to the first screen and sets a value in a plist with how many days of use the user has left. Whenever the user opens up the app it checks to see if the date is different from the last date logged in (saved in the same plist file) and if it is different then it calculates the difference and deducts that many. When the count reaches 0 it sends the user to the pass code authentication screen again. A bit complicated but an effective method of getting around Apple's restriction on not having a sort of pass code system like this. Thanks for the answers, unfortunately enterprise did not work for this company since they needed to be able to distribute the app to as many 3rd party members as they wanted to without having to worry about them leaving the company for other suppliers and remote management of the app (I.e ability to remote uninstall) was also not an option. Hope this helps someone someday!
I am working on an application that will allow the user to purchase content from the app store
https://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008267-CH1-SW1
These products require a "ProductID" that ties them to whatever is in the appstore.
I will need to store these IDs somewhere in the application so I know what to send the server when the purchase button is clicked.
I wish to expose these ID's and allow non-programmers to enter any ID they want in both our side and the server side, and not have to call on a programmer to go into the code and change some enum.
I figured a config file would not be very secure, for in the end it's just a text file that a user could potentially view after purchasing the app. May not be a huge problem if a user saw the ID, but I don't like the idea of anybody seeing the innards that go through a payment process
Assuming im making sense here, whats a good way to expose these IDs but still keep them secure so users may not find them?
Also curious, how secure is something like an enum in c++? Can people break the .exe down and see the code and its values?
For your final question, yes and no. If they have access to the debugging information (a PDB in Microsoft land) then yes. But armed with just an exe and disassembler, you will see only the constant values that are assigned to the enum members.
I will make one of my app one day free.
Is there an api or any parameter that can know if the user's app is the purchased copy or the copy with free charge?
Welcome any comment
No, there is no way of knowing the price at which the user has purchased the app. So, answering your question, you have no way of knowing if an application has been purchased or downloaded for free.
do you want the app to behave differently if downloaded on the free day? Maybe you could store the date of first launch, and compare that to some web service you develop that returns an array of those days you made the app free. If the users first use date was among those, assume it was a free download (obviously it's not exact because they could have downloaded and not used until a future date)...
if you just want to know, you could add a call to your server on first use and store that data so you'd have a record...but it's still dependent on date, not literally price
You could do it like this:
You could do it like this: eg. store off a NSUserDefault with the version.
Then make the next version for free, dont forget to increment version.
If no previous entry of a version is in NSUserDefault then you could flag another NSUserDefault, eg. FreeApp with 1.
Then in the next version you put on you will put the price active again. Now you can check if FreeApp was 0 or 1 when reding the NSUserDefault, if it was 1 then those are the ones that updated that got the version for free.
Unfortunately when the app gets deleted so does the NSUserDefault of it and a redownload of it, even when being paid would be free but your app will store it off as paid.
Hope this makes sense.
For my upcoming iPhone application I'd like to offer In-App purchases of expansion content (things like additional unit types), but I'd like to offer them in a booster-style format, i.e., you buy a booster pack and get X new unit types out of Y total units. Units can stack and are useful in duplicate, so you can get some of the same units you already have. I have a few questions about this model:
Will this rub against Apple's "Be clear about what's included in the item"? I can be clear that you are receiving a random set of units and that you may receive duplicates according to a specific distribution mix, but I'm still not sure about this one.
While these booster pack-style purchases will be consumable for the sole reason that I want to allow the user to repeat them, the items they receive are not truly 'consumable'. I'm thinking I can store the user's purchases on my server to allow them to always access and backup their purchased content, but again, I'm not sure if this will get the app rejected or not.
Thanks for any info!
Answering my own question here after forever; I found the application Urban Rivals which apparently employs this approach successfully.