My company is looking to implement a large-scale In-App purchase model for an iPhone app.
Our biggest issue is that we don't want to go with a service like Urban Airship because it doesn't integrate well with our business model and the nature of the application itself.
So now we're looking to set up our own server to handle the In-App purchase communication as well as serving down the purchased content. We are not unlocking content that already exists in the app and will be downloading relatively large add-on content.
Are there any good resources for learning more about the server side component to this. I'm very familiar with how StoreKit works but the server side communication is an enigma to me.
Any help would be very much appreciated!
I implemented this by doing a simple plist + zip file download for purchasable content. The plist has a list of products available in it. There is a plist file for each version of the app, as in my case there are sometimes differences in content based on the version that the user has.
This scheme also supports versioning of individual content items, since sometimes you want to change one of the items in your store.
I do NOT follow Apple's guideline of purchase-then-download. I do download-purchase-unlock. I'm too nervous about someone purchasing the content, then having to wait for it to download. (My content files are pretty big).
Here's how it works:
App downloads .plist for itself. (MyApp_2.1.plist)
Opens up .plist, checks to see what version of each content item it has. Let's say the app currently has version 1 of content A, and version 5 of content B. The plist file above tells it that the current storefront should have version 1 of A, version 6 of B, and version 7 of C. So the app downloads content for B and C.
Content is stored in a zip file. In my case, these are game levels with XML files, audio, and graphical content. There is also a .plist with metadata for that game level, that includes the version number, and the AppStore ID for that item. The app unzips the content and then presents it in the storefront as a locked item. If the user has purchased it already, then they get the updated content automatically. If they purchase it, then I unlock the content at that time.
This is simple, can be done with any CMS (even a plain file-based web server), and supports multiple versions of content across multiple versions of your app.
If you want to see the UI, the app I did this for is a game called Lexitect, you can see how it all is put together from a UI perspective there. (It's free)
Related
I'm making my first iOS app. And I have a question.In my app I want to save the current state of the app: levels completed, score reached, money, in-App purchases, etc. in a Settings.plist. The problem is, how can I place this plist so that if the user updates the app, he/she not to lose these settings. I read about The app sandbox, but I don't understand
how it works, and how can I manage that from Xcode.
You should store these settings in the NSUserDefaults. They are kept when new app versions are installed, so you won't have any problems.
Two points:
a) When you update your app after its in the app store by submitting a new version of the same app the files created by the old version will not be lost. So you can store whatever you like in the app's Document or Library directories and expect it to still be there after an update. The Library/Caches directory will not be backed up or restored by iTunes so don't put anything there that you can't re-create. If you submit a different version of the app (not an update but a new app, so you have two separate apps in the app store, perhaps free and paid) there is no way that I know of for the new version to get to the files that the first version created.
b) It's easy for the user to read, delete, or change whatever files you create in Documents/ or Library/. It can be done with an app on his/her Mac such as iExplorer (downloadable from macroplant.com). So be aware that if the file is human-readable, which a .plist file is, the user can change it to improve his/her score, get more consumables, or whatever. You can prevent that by encrypting the data, or somehow obscuring the meaning, or by some kind of checksum scheme so you can at least detect that it was changed. Any of those measures involve complications of course and may not be worth the trouble.
BTW... if you're developing an app that uses data files iExplorer is a great debugging tool. I have no vested interest in it except that I've learned how to use it and want it to continue to be supported. There are probably other apps that do the same thing but this one works great and is fast and easy to use.
I'm making an app that is for presenting the old versions of a magazine (i have the necessary permissions). Right now, each magazine is sold in the stores, but the older versions, like 2005, are not on the street anymore.
I want to make an app that simply has 12 buttons, one for each magazine edition in a full year, and sell this app as the editions of my magazine for the specific year (i.e., an app for 2005, another for 2006 and so on. The PDFs would be stored locally in each app, thus not requiring internet connection. Also, the pdf reader i already have implemented, with favorites, transactions and stuff..
I couldn't present this magazine in a browser for example, because I don't want the users to download the magazines and share them -- they are supposed to be only for someone who buys the app.
Would Apple reject my app?
The way that I think would be the best for you to organize your applications is to provide a viewer application, and then implement micro transactions that allow for the purchase of the previous versions of your families magazine.
I can imagine a view in a few different ways but simply downloading a magazine into a webview would be the simplest that I can think of at the moment. I'm not sure how a user would share it because even if you included it in an image/pdf format you can disable user interaction, even screen shotting I'd imagine, keeping them from removing it from your app(As far as I know how).
To directly answer your question, no, I don't think Apple would reject your application, though depending on how the built in bookstore works, it may be easier for you to simply try to publish it to that through iTunes, or whatever that process is, and save yourself the code.
I'm developing an iPad app that will be distributed in-house using the Enterprise Program membership. However, "in-house" means distributed to various worldwide locations.
The app binary itself will be universal for all content, client locations worldwide. However, the content (an SQLite DB file) will vary between devices. One iPad in UK has the English content file for a product, whilst another in France has the French content for a different product loaded.
The plan is to send the different client locations their content so that they can connect their devices to iTunes, install (or update, important!) the app and then copy the SQLite DB file to the device.
Can we do this, and how will it work? What are the limitations?
Acceptable answers must include the following:
Confirmation and description on how the SQLite content file can be synced
Confirmation and description/resource on how the distribution will work
I've found one somewhat related question:
Distributing database updates to an iPhone application without downloading the whole database
Would it be ok to have the App start up in a "neutral" mode?
Show icons for the different content types (Language Flags perhaps), and when you touched one, it would download from your server the appropriate data pack.
If certain users are only allowed certain content, maybe you could send them an out-of-band URL or password that they enter to get their personal content.
That way the App distro is always identical, and your server manages the customization packs.
I've now completed the project and can confirm that this technique is perfectly valid. We are distributing the application and SQLite database file along with the content (image and video) to the clients, which by the way has to enter the Enterprise Program themselves. The clients install the application via iTunes in an ad-hoc-manner, and then copy the database file and content files to the iPad in the iTunes interface.
The distribution itself is very straightforward, since the application package we are sending the clients are signed and provisioned. They won't encounter any issues with installing and updating, all they need is the free iTunes account and our application related files.
Different client's iPads can have different content. Updating the content or database file is quick and easy. Updating the application is also easy, just remind the clients to delete the app before adding the new version to their iTunes Library.
Finally a tip; if you're getting an error in iTunes (which BTW don't make sense) about your Entitlements when installing the app - add an application icon.
We have developed a magazine style app for a client. Even though we're pretty happy about it we want to migrate to a in-app purchase version ASAP. The idea is to have an app much like Wired or Popular Science where you can purchase issues on a monthly basis.
We have read the in-app purchase programming guide, but the problem we're having is not related to the in-app purchase process at all. The real problem is the issues themselves, since they are made of View Controllers, assets, and so on.
I guess the question is how do we package a magazine issue and make it available to an app? Does anybody have an idea how to do this?
You could create your content with Interface Builder put the compiled nib files with their linked assets into a bundle and ship that. May you need to add a plist to the bundle that contains information about the content.
You will not be able to ship executable code (ViewControllers) via in-app purchase. There's no way (and your contract with Apple forbids) to get executable or interpreted program code into your app after the user downloaded it.
So you will need to define possible functionality upfront and include all code into your app. Only assets and nibs can be loaded afterwards.
In fact I am not quite sure about the nibs. From all I know and understand they are just a document format without any code, but I maybe wrong.
As a web page, displayed in a UIWebView?
I need to change the bundle identifier of my iPhone app before I can upload it to the app store. However, I also have data in my Core Data store which want to continue using even after I change the bundle identifier. However, it seems that the bundle identifier is how the iPhone knows whether apps are identical with one another, so I end up with two distinct copies of the app -- with two distinct core data stores -- on my phone! I know that I can download the sqlite data store through the Xcode organizer, how can I make sure that my data transfers to the new app package with the new bundle identifier?
With some exceptions for OS4 every app (identified by it's BI) has it's own isolated storage on the phone.
If you really have to change this (will also disable free updates for buyers of the "old version") you have to find an external migration way.
A lot of apps offer some kind of "backup" (on a PC / MAC or something else).
What we did for a customer was to establish a website which allows "short time data storage".
So that the old app could upload the data - and the new one loads it down.
Of course this means updating your old app first for the "export".
But the idea "your app lives in it's own isolated world" also means that you have no access to the data of other apps.
From the point of security this is imporant and good.
For building "app suites" where the apps want to share data it's bad.
But apples made enhancments for this in OS4 - which (I guess) won't help you in your case, since "sharing apps" must also be special designed.
I know this question is very old, but I just noticed it while looking for the answer to the same problem and thought it still might be useful for others. The original poster half-answered his own question, but didn't quite take the next step.
If you have not yet released your app on the app store and you want to change your bundle identifier, it is possible to copy your CoreData store from one sandbox to another using the Xcode organizer as suggested above. Obviously, this is only useful for your own device (which I think is what the original poster wanted to do); this process won't allow data to be transferred on other users' devices if they've bought your app, so DON'T change your bundle identifier after your app has been released.
First, run the old app (the one with the old bundle identifier) on your device. In the Xcode organizer, select your device, then Applications, then select the app (with the old identifier) and download the data to your mac.
Then install the new app on your device (build and run it, then quit). In the Xcode organizer (and on the device itself) you should now be able to see two apps, one with each bundle identifier. Select the one with the new identifier, select upload and upload the data file you saved from the old sandbox. You should now have access to all your old data in the new app. Very handy if you don't want to recreate all the data.