I have some doubts about Newsstand/In-App Purchase that I really can not figure out. I'll try to be concise.
Scenario: magazine app that must offer the user the option to buy (in addition to subscriptions) a single issue. The issues will be released weekly, so even after the publication of the app.
My doubts (operational rather than technical) are related to how to deal with in-app purchases when the app has already been approved. How to manage the publication of future issues?
I thought it was enough to upload the new issues on my web service and then create a new product in the "In-App Purchase" section of iTunes Connect (because Apple says that individual magazine issues are non-consumable items), but how long will it take before the issue is on sale?
If in-app purchases (inserted after the app has already been approved) are subject to approval, it's almost impossible to meet deadlines of weekly publications...
How do apps (like Wired or various newspapers) sell individual issues?
Thank you in advance
Sorry if i'm not understanding you question but you want to know how to release new issues of your magazine?
This might help:
https://itunesconnect.apple.com/docs/NewsstandAtomFeedSpecification.pdf
Sorry if im wrong
EDit: also if you need help with the app itself apple created a video here
Anticipating future IAP products to make them approve, and activating them at the right time
Related
This is a conceptual workflow problem. I'm converting an app with an existing user base from Paid to Free with an in-app purchase (FWIAP) to remove ads. The problem I'm trying to avoid is having the existing paid customers updating the app and now suddenly seeing ads and being insulted/assaulted with the "option" to pay again to remove the ads they never bought in the first place.
Luckily, I do have some breadcrumbs in the form of persistent data (pData) that will indicate whether the app was already installed. So my thought is to have the new version check for existing installs before deciding whether to proceed with displaying the ads.
One problem I foresee is later updates then considering all those first-generation users as now eligible for ads again, so I'd have to then add another persistent flag (pFlag) to identify the two groups of users and then hope to remember for even later updates (i.e. third-gen., etc.) to check against the pFlag instead of the pData, as the pData values would have long changed by then.
Does this seem like a sound approach or is there another good known solution to this?
The problem with breadcrumb schemes is with users who upgrade, or have to get a replacement device, and don't have backups to restore from. When they re-download your app, there will be no breadcrumb.
I don't think you'll ever be able to support cases where someone has bought the paid version and installs it directly from the app store on a new device or a device where the app has been deleted.
We recently had this problem in the opposite direction. We have a FWIAP app that customers wanted to be able to purchase through the volume purchase program, which doesn't apply to IAP. So we built a paid version and sell it as a separate app, and it generates as many sales as the FWIAP version, basically doubling revenues (so far).
I think the simplest approach is to just release a separate app. If you convert the existing app, the biggest risk is negative reviews, which could drive down your star ratings and thus downloads. So if you do take that route, I'd have as generous a customer support policy as possible--give anyone who claims to have purchased the paid version a code that lets them unlock the FWIAP version.
But that's likely to be a headache in the future, and from my limited experience, you may make more money by just having both versions in the store.
The paid to free-with-inapp-purchase workflow is supported; it’s referred to as paid-to-fremium and is discussed in the 2013 WWDC video:
Using Receipts to Protect Your Digital Sales https://developer.apple.com/videos/play/wwdc2013/308/
I am trying to submit my first iPhone app that has in-app purchasing features. Needless to say, I have been banging my head against the wall for a while. I have read through several tutorials, such as: http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/ and http://blog.mugunthkumar.com/coding/iphone-tutorial-%E2%80%93-in-app-purchases/ but it seems these are outdated? For instance, I can't find where the developer is to reject the submission on iTunes connect.
Additionally, I am submitting the app the in-app purchase features included in the bundle(I don't have them stored on the server- I just want to unlock the code when the user purchases the feature). What is the best way to do this?
Thanks!
Some of the information in the linked tutorials is in fact outdated: I could create in app items in iTunes connect without having to submit (and reject) a binary first. Just be sure NOT to submit your items for review while you are testing. Also changes to the items (e.g. price tier) have been processed almost immediately and I did not had to wait 24 hours.
To unlock your feature, you may use storing and retrieving the purchased status in NSUserDefaults . But this could easily be tempered with by users with jailbreak or acces to the apps folder. Have a look at http://maniacdev.com/2011/08/open-source-ios-keychain-wrapper-for-easily-securing-user-data-for-your-app/ . This offers a simple way to store data in the keychain. Still this will not prevent someone to 'hack' your app and enable the purchased feature without actual purchase, but it's not that easy...
In-App Purchase development is definitely a pain point in iOS development - their sandboxing model for this is ridiculous.
Needless to say - the articles you're reading are still up to date. The developer reject is definitely the way to go (I think can do from within the binary details). One thing to remember is that you need to have accepted the appropriate contracts and tax schedules also - if you haven't then the store "just doesn't work".
One thing that caught me: when you submit your final version of the app - make sure you tick the in-app purchases to be included; else the in-app purchases won't be reviewed (and accepted)!
Update: Although it's pretty long... you may want to flick through this: https://itunesconnect.apple.com/docs/iTunesConnect_DeveloperGuide.pdf
Explains how to developer reject etc.
I need some help/clarification on how the paid vs free works. I have an App and I have a free version with ads. When the user purchases I want to disable the ads... that's no problem. But, how do I know they purchased? When the user goes to the App store, to purchase do I get an e-mail, or anything that I can key off of? I do not want to have two versions and if I do, how does Apple evaluate both? I am ready to submit the App, but I am confused on how I transition from free to paid.
I hope this makes sense and someone can clarify the process for me.
Thanks
You could use inApp purchase or compile a different version that will have a price and sell it separately.
#Helge is right. You can do it either through In-App purchase or a separate app version.
If you want to knw about In-App purchase pls go through this Tutorial
With apple's in-app purchase approval system, is it not possible to have new in-app purchase content available every day? I've read in various places that the process typically takes 1-2 days .. sometimes longer. I know the typical answer to this would be to create a back log, but we're working with time-sensitive content and need it to be delivered every day (think newspaper-esk). What's the next best solution other than back logging?
Any ideas?
Use the same in-app purchase identifier for rotating consumables.
It might be against Apple's policies, though it's highly unlikely that your app will be reviewed regularly after it's approved. I recommend checking the developer agreement before you move ahead with this.
Several years later ...
A good way to do this is to submit several in app app purchase items ahead of time via iTunesConnect. I recommend you submit these IAPs at the time of your app submission. If you have any IAPs waiting for review at the time your app is being reviewed, they will also get reviewed at the time.
I have an app that I was going to release as a free (lite) version with some of the total functionality and a paid full version with advanced functionality. Now, with in app purchase for free apps I am thinking of going that route with the ability to unlock features as needed. I'm not talking about a trial version that expires.I want people to be able to try out the app and get an idea of the interface and functionality before deciding to purchase the full functionality of each major section of the app, basically.
Here's an analogy of what my app would be like. Let's say you have a cooking app that teaches you to cook in different styles. There could be major section for French, Italian, and Chinese. Each section could have some rudiments unlocked in the free app so users can see the UI and basics of the functionality. Then, the user could decide to purchase each major section (or not) individually with in app purchase or buy the full versioned app (with the free/paid model).
One concern I have with offering a free app with in app purchase would be with feedback. I would be very clear in my description in the app store that there is in app purchase for full features but I'm worried that less serious users could/would leave negative feedback. I suppose that's always a risk but curious about any experience with this.
It also seems that it could be a whole lot more complicated keeping track of what portions of the app are locked and unlocked with in app purchase. I know I'd have to have all the code for the full functionality and "lock" the portions that haven't been purchased. How do people usually lock portions of their code? I'm not talking about the process of purchasing (I've read the In App Purchase Programming Guide) but after the purchase has been made. Would I just keep track of what the user has purchased and put conditionals on the sections that are initially locked? Or is there another way to do this as well?
My instinct is for the in app purchase (particularly since users could purchase the major sections that they want individually).
I would highly recommend using the in-app purchasing over having different versions available.
If you have different versions, users need to re-download the whole thing if they want to upgrade. This means they need to have twice the storage space and use up twice the network bandwidth to upgrade.
I don't think your review concerns are founded. If your application is well made and users like it, you'll get positive reviews. To avoid having users be confused, make sure the application clearly states what can be purchased. Also, some people just dislike everything and will give you one star. These users are unavoidable, but if your app is good, there should be enough good reviews to balance them out.
You're correct in your assumption that you would have to have conditionals for locked/unlocked content. However, this shouldn't be an enormous issue. Just persist what the user's purchased in a plist (suggested by Apple) or other persistent storage and make a class that you can query to find out if a particular feature has been purchased.
I suppose it makes sense to have lite app (with unlockable content via IAP) and full paid app. I'm saying this basing on own experience of selling apps on the AppStore. If interested you may want to look at my post in our company blog about IAP vs paid app.
http://bees4honey.com/blog/marketing/in-app-purchase-vs-paid-app/
In two words - having lite version with IAP and paid version will increase a total revenue in comparison with having only lite with IAP or lite+paid.