I currently have an App on the App Store with features a, b, c, d
I am looking to make features c and d paid for using in-app purchasing in the future but until that is all programmed/implemented; also restrict or remove (visible) access to those features. Note anyone that had previously setup c or d will maintain access to them.
Is it ok to remove features like that in a submitted application?
I would try to use your applicaion's version for that purpose.
Three steps to follow:
Detect the app's first launch Link for first time app launch
and at that moment you save your version number Link to get app's version number
once you intend to display a feature do something like
NSString *currentVersion = #"1.2.0";
NSString *versionAtAppDownload = #"1.1.5";
if ([currentVersion compare:versionAtAppDownload options:NSNumericSearch] == NSOrderedDescending) {
//decide what to do
}
This should be added in your next app version. Once done, everybody who already downloaded your app should have saved their current app version.
Now your update to your next bigger version i.e. 1.2.0, this version will be the one that hides content for users that have not yet paid. The users who downloaded your app at any previous version should be able to still see everything.
Something like this should work, good luck!
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.
Got a general question(s) for you on implementing a free and paid version of an app.
I have it setup now where I have 2 targets within the 1 app/project and I specify with the def syntax for what is in the lite vs paid version.
It works and runs both targets.
1) How do I have the user purchase the paid app directly from the free version? (Found multiple older articles saying linking is fine and others saying that will get rejected and must use in-app purchase)
Can I use a link tied to a tab bar item or button like this,
NSString *iTunesLink = #"http://itunes.apple.com/gb/app/wired-news-uk/id435728870?mt=8";
[[UIApplication sharedApplication]
openURL:[NSURL URLWithString:iTunesLink]];
OR do I need to implement the storekit for an In-App purchase?
2) I was going to put a new Tab Bar item at the bottom (to link to paid version) - haven't tried yet but I should be able to setup the tab bar one way for the free version and another way for the paid version, correct? Essentially, hiding the tab bar item to purchase the paid version once upgraded.
3) Submitting each app (free and paid) version to the app store - I'm assuming I will be able to set the target and archive the binary for upload for each, right? Two separate app submissions in itunesconnect?
I have several Lite/Paid app pairs in the app store (all were originally created before IAP existed). I've made many updates to these apps over the years so it seems Apple is fine with the idea in general, if you do it right.
1) You can't actually purchase the paid app from inside the free app. The best you can do is send the user to the store for your paid app.
2) That should work. In one of my apps, I have an extra icon in the main toolbar that brings the user to the app store page for the paid app.
3) Yes, you submit two completely separate apps. You setup two apps in iTunes Connect each with their own unique app id.
A single project with two targets is the easy and proper way to setup your code. For me, I do two archive builds, setup two apps or app updates in iTunes Connect, and submit the two apps/updates to iTunes Connect. I always keep both apps in perfect sync. Apple always seems to review them together and always pushes them out to the store at roughly the same time. Only once did the two get approved more than an hour or two apart.
The main thing you must be careful with is the free version. It can be "Free" or "Lite" but not "Demo". The free version must fully function. DO NOT have any UI elements in the free version that are disabled because they only work in the paid version. It will get rejected. If it doesn't work in the free version, make no mention of it at all in the free version.
Most of my app pairs, the free version allows for limited data compared to the paid version. When the user attempts to add data beyond this point, I popup an alert with a nice reminder that the free version a limit and offer them the chance to upgrade. Other than this, there is no other annoying popups offering the paid version. It's OK to have a button or whatever in the free app to let the user upgrade, just don't shove it their face or popup any sort of reminder after X uses or time. A free version of an app must fully function in its own right.
Here's my take on free/paid app pairs versus IAP:
Cons of IAP:
- No promo codes for IAP
- You can't make IAP free for some period of time (sale or whatever)
- Free apps tend to get lower ratings because any yahoo can download.
- Extra coding for IAP
Cons of free/paid pair:
- Two targets, two app releases, two sets of images, two sets of stuff in iTunes Connect
- Split downloads and ratings/reviews.
Personally, since I've been doing this for several years now, the extra effort of submitting two apps is trivial.
Edit:
One thing I forgot to mention - there is still no guarantee that Apple will accept the apps this way. But there are plenty of examples of such apps so it should be OK if done correctly.
If you want to have two apps, then you must have two technically independent submissions with different app id-s. It may be tricky to have it from the same project, not sure if you can do it using two targets. Technically AppStore rules do not allow "upselling" paid version from free one, but if it is not too aggressive, then maybe it will be approved. Safe solution would be to use InApp Purchase, this gives you many benefits:
quite is easy to implement
no need for two application codebases
you have single download count and item in appstore
Actually this solution with two separate apps made sense before in-app purchases, I do not see much point of that today.
If I offer an in-app Non-consumable purchase (say a book, or a song) within my app and then 2-3 months after it has been released I realize that there is something wrong with my digital content, Can I do an update of the digital content? So if I had a digital article as an in-app purchases for $1.99 and sold 1,000 copies, then I realized that I have a spelling error on page 3. Would I be able to upload an updated article that would go out to all the people who bought the article and prevent people from downloading the old copy? If not, how is this situation handled in the real world? I have looked in apples doc, but cannot find an answer.
Edit: Assume I am using the new io6 feature of hosting the content through apple.
Yes, as a matter of fact, provided that you do a few steps, you can keep track and systematically, efficiently keep track of what is downloaded.
1.Yes it's possible. Provided you keep a track of who has bought what pack (ie. keep a bool value as an NSUserDefault), then they will still have access to it (even if you add more stuff/levels to it).
2.It depends what you mean by notified; they will know if they read the update comments when they install the update. Also you could just choose to alert them when the load the app after the update - your call.
3.If you're submitting the code Apple will review it. Just think of it like any other update to an app.
This is taken directly from here: Update in-app purchase content for iOS app?
After you have updated your content for the app store, you can allow your users to Restore Purchases and obtain the updated content!
Overall, have a mechanism to keep track of the version of the in-App purchases' version and then update when needed!
There is always, apple's own documentation:
Here you go! :)
I hope this is clear and helpful!
EDIT:
After checking the user's content version number and finding that it's outdated, you would call the method (by the way, you would probably implement this checking mechanism in your app delegate.
[[SKPaymentQueue defaultQueue] restoreCompletedTransactions];
This would restore the transactions, but make sure you also need to include the rest of the implementation code!
I assume you know the code to restore in app purchases, but if not, here are a couple good links!
Restore already bought in-app-purchases on iPhone?
http://www.iosdeveloperguide.com/in-app-purchase-heads-up-to-avoid-app-rejection/
http://appotography.com/2011/07/06/restoring-purchases-on-iphone-and-ipad/
About AppStore Hosted Content
I have not tried, but browsing inside Apple doc, I've found this which confirms that you can upload multiple versions of a digital content hosted by Apple.
"You can have multiple versions of hosted content, but each one needs to be approved by Apple before it can be purchased by users."
Also, you can check this and this tutorials, that shows that you have to specify the Content Version and IAP ProductIdentifier in the ContentInfo.plist when you create an App Store Hosted Content with Xcode.
How to notify the users that content has changed
This depends of how you implement your purchase system, the content delivery, and how you keep track of the "state of your purchased products". Usually we keep track of the version of the purchased products, thats means, we save the product_id with the content version when the purchased content is downloaded. We can save this data in files or inside a DB locally. Also, you don't have to worry about non downloaded (and non purchased) products, those do not need an update. When you update your in-app store with the last information of your available products (via update button, or app launch, or whatever you implemented) you should compare the last content versions with those you have downloaded, then you can notify the user that an update of his purchased product is available. Finally, you have to enable the download for that product.
This all depends on how you make the content available to the user. When the user makes their original purchase of the in-app content, where does the content come from?
If it is part of the app bundle, then the only way to get updated content to these users is to submit an update to your app that includes the updated content. When the user installs the updated app, they will see the updated content.
If, upon purchase, the app downloads the content from your server then you can build in a mechanism in your app that checks your server for updated versions of the content. If it detects there is an update, and the user has the IAP, then the app can download the updated content.
Edit: This doesn't cover the new iOS 6 feature of Apple hosted downloadable content.
For the above problem:
please have a look at the following urls for separate things:
Following link is the link to the SKDownload API:
http://developer.apple.com/library/ios/#documentation/StoreKit/Reference/SKDownload_Ref/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011851
Following link is the link to a great post which explains the working of SKDownload API:
How to download In-App hosted content?
Now in your position we can follow the following steps:
Push another package on the Apple Account which is to be hosted (with corrections).
Push an update the app on the App store with the following changes: (This handles any new download from the new users.)
a. Update your code of the InAppPurchase with the new identifier of the file
Now we have to handle the old users, we can consider the following two approaches:
a. We can show the user a restore button, by tapping which the user would be downloading the article again.
b. In iOS for things to go automatically to all existing users we do have a mechanism of push notifications, on the receiving of this the user would be triggering the event to again download the data from the Apple Hosting.
I want to find a way if it's possible to re-install an IPhone app from inside it?
Let's say my users have the app already installed in their phones and now new version is released, can I make my app such that it will check over internet if new version is available and if it is, download it and ask the user to install it. If user says yes, it will first un-install the current version and will install downloaded version.
Is it possible anyhow?
Apple wont allow this.
For one reason, un-installing the app removes all the user documents (if applicable), so theres no way to preserve user data.
Apple already has a medium for updating (iTunes App Store).
If you want to be able to check if there is a newer version of your app, you can do that simply by checking a text file (for example) on your server, and notifying (by UIAlertView possibly) the user that there is a newer version of your app. But again, Apple already has a standard system in place. (Badges on the App Store icon)
probably not because to uninstall an app it requires the app to be closed
You don't have to do that. If you upload a new version to the app store, a notification badge will appear on the app store icon on your users' phones. You aren't allowed to install apps any other way than through the app store, anyway.
It depends on your app and what you want to update. It's not possible to reinstall the native app, but you can download data and update your app using that data. For example, we have an app in the store which is mainly a webview inside the native app. The first time it launches, it uses the internal data, but checks our server if there is an update. If there is an update, it downloads remote data and replaces the internal. It's what most magazines do for updating their libraries.
This question already has answers here:
Can I force an iPhone user to upgrade an application?
(16 answers)
Closed 5 years ago.
I am about to upload my Iphone application to the apple store, however I intend to release more versions in the near future. Is there anyway to make my application auto update once I upload a new version to the apple store?. That is as I am about to upload version 1.0, once i upload version 1.x, can the user be notified of this or can the application be auto-updated?. Can anyone point me in the right direction?. Any help will be greatly appreciated. Thank you.
-Oscar
No, this functionality is not available on the iPhone. The AppStore provides updates through the store only, and Cydia provides updates through Cydia only.
The direction i've seen many applications take is at start, check an XML file that you host for information on newer versions, and typically display a message to the user (preferably in a news ticker or non-obstructive manor) about a new version being released, and why they should upgrade.
You can't auto-update, however as far as I'm aware nothing prevents you from notifying the user that a new version is available, within your app. For example you could contact a web server to find out what the latest version is, and compare that to a build number in your app bundle, then display an appropriate alert/notification to the user. Or, you could get fancy and use the 3.0 push notifications for this.
In theory the appstore app/itunes will do this anyway, but it's clear that a lot of users don't see that.
Another thing you can do using the method I outlined (that the app store won't do) is tell the users that a new version is available, what it does, and that it's waiting for apple.
Even simpler is just to embed an 'announcements' channel in your app somewhere. That lets you talk to your users without waiting for apple - you can tell them there is a new version on the way, etc. I do this with an app I'm beta testing - a button on the main screen shows announcements, which I pull from my server.
Maybe if enough app developers did this, apple would start turning the approvals around quicker. Or change the legalese to prevent it [assuming it doesn't already] :-)
This is functionality provided by the app store. When you submit new versions, after apple has approved them, they will become available through the app store as updates to users that already have the app installed.
User will see new available updates to apps he owns in iTunes. User can then choose to get the update.
I'm not sure about updates via iPhone but if you pay for data downloads you would prefer to download apps/updates over iTunes on your Mac and then sync to iPhone. It's cheaper that way.
My guess is automatic version updating is intentionally left out. Think about it: what kind of strain will they have on their server if everyone on the planet with an iPhone downloaded An update to Fruit Ninja at the same time? I think their passive notification to the users via the red circle and white number allows them to spread out/stagger the update downloads and reduce server load.