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?
Related
I've seen this done before with apps that I use, but I was wondering how it would be possible to share IAPs between an iPhone and iPad application. More specifically, I want to make sure that users that make a purchase in one app, do not have to re-buy the same product in the other.
I've read in a few places where this could only be accomplished with a universal app, but I wanted to see if this was, in fact, the only way that it could be done.
As far as I know, in-app purchases are app-specific. But it's really pretty easy to go universal - try out some of the excellent tutorials. You obviously have the advantage of only having to maintain a single code base (though of course you could be disciplined and share some core code, but it usually lapses...).
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 want to create an ebook store app which has in app purchase.
All the ebooks will contain images, sounds, text and XML file and will be stored on a web server.
XML file will contain mapping on what sound to play and what text to display on particular page.
1) Being a newbie for in-App Purchase, I would like to know whether I should download all images, sounds, text and XML together or one after another. Or what would be a better mechanism to download all these items?
2) I have read that Apple requires that if a user purchases an item through in-App purchase, all his devices should be able to access that purchased item. How do we ensure that?
Also, if you have experience related to similar project, can you please share the challenges that I might face and possible solution to it.
I really appreciate your advice.
Thank You.
I would compress all the files into one archive and then decompress them on the device. This will speed up the download and will also make your code a little simpler as you'd only need to download one file per ebook.
The StoreKit framework has methods for determining if a user has already purchased an item. If an ebook has already been purchased, then just have the app download it to the device. This is all documented in the StoreKit documentation.
I am very new to developing apps on the Iphone (In-fact I am new to application development all together). I would like to know what the feasibility for an idea for a app on the iphone is.
1)The application would allow users to download content (audio or if possible video files) onto the device.
2)Each of these files will need to be purchased before downloading, at a fixed price.
3)The user can then play the downloaded files on the device.
Is such an app possible to be made on the Iphone?
If so can anyone give me pointers on how the payment procedure should be, and how revenue will be shared with apple?
From what you described, that sounds very possible.The users would pay you directly through a credit card for the files.
If you are already a registered apple-Developer, have a look at the InAppPurchase(IAP) ProgrammingGuide in the iOS-Devcenter.
The purchase of any content must be handled through IAP.
This is written in the App Store Review Guidelines, Item 11.2 (Because I'm new, I can't provide a link. Sorry for that)
It is not possible that users pay you directly.
I am working on releasing an app that will greatly benefit from using the in app purchase model. The app is a sort of book viewer, and the content I would like to make available for purchase will be more books in various languages. Each book is stored in sqlite format, in separate .db files. Now, the way that my developer has set it all up is that he added a line onto the bottom of the info.plist file called databases. Inside that database section, I can type in 'es' as the key, and for the value the name of the spanish database, and it populates in a uitableview in spanish, using NSLocale. So it is very easy to setup and implement different databases, which is great, but now I am confused about how I can implement my in app purchase model. Sorry about the long winded intro, here is my question: Is it possible to have an in app purchase add a line to my info.plist file? Or if not, is it possible to have the purchase reveal a new and updated plist file altogether that I would have already setup correctly? Any help here would be appreciated. Thanks
You can not edit you're info.plist file dynamically. When you submit your app to The App Store, your app bundle, which includes info.plist, can't change because the signature created when you compile you app is based on the bundle.
You can have an in-app purchase do whatever you want. You could have the data already stored in the app and just unlock it with an in-app purchase, or you can have the app download the new data in plist format or any other format you want. Services like ilime and Urban Airship make this really easy for you.