I would like to put a free version of my ios app on appstore. This is a data driven app that remembers events on certain past dates. Can I limit the time of past event to ,lets say, 2 weeks? And if the client want to see the events added more than two weeks ago, he has to upgrade to full (for a fee) ? Is this possible, or will the app be rejected by the apple review process?
You'll probably be able to get away with this. You'll likely want to use an In-App Purchase mechanism to unlock archived events as opposed to having separate free and paid versions of the apps on the app store.
Related
Short Version:
My freemium iOS app sends the app receipt to my server for validation and to check wether a users is eligible for subscription introductory offers. I noticed that there are a lot of receipts with no IAPs inside. This would mean that many users have been using the free trial version for years, which is quite unlikely.
So when is IAP informatioin added to the receipts?
Long Version:
My app has been offered in the iOS App Store for several years using a Freemium Model: User can download the app for free and test it for an unlimited time with limited features. A non-consumable in-app purchase can than be uses to remove these feature limits.
In theory users can use the app indefinitely without any purchase just using the test feature set. However, the due to the limitations this is highly unlikely.
Recently I have updated the app to offer subscription. To check if users are eligible for introductory offers the app receipt is send to my server for validation.
I noticed that there are a lot of receipts with no IAPs inside. Even for receipts with original_app_versions which are several years old. This would mean that many users have been using the free trial version for years, which is quite unlikely (due to the very limited feature set).
So when is IAP informatioin added to the receipts?
The new app version send the receipt to my server on the first start. There are three possible cases:
The app was never used before and this is the first installation of the app ever.
original_app_version == current version
Of course on the first start there are no IAPs, so nothing unusual in this
This an updated of an earlier version which was installed before
original_app_version < current version
The app / App Store hat plenty of time to include possible IAPs in the receipt
An earlier version of the app was used but than uninstalled. Now the current version has been re-installed
original_app_version < current version
Since has just been installed it might be possible that the IAPs are not included in the receipt yet?case.
So, only the 2. and 3. case interesting here. Why should previous non-consumable IAPs be stored in the 2. case since the app has been installed and running for a long time?
On the other hand it quite unlikely that thousands of previous users have now re-installed my app and thus resulted in case 3. Even if this really the case, is there anything the app can do to manually trigger the store to add previous IAPs to the receipts? Or does the user have to restore previous purchases first?
EDIT:
As far as I understand the Appel docs it does not really matter what information is stored in the receipt which can be found on the devices. When I upload this receipt to my server it acts like an token when being send to Apple for validation.
Apple than responds with the latest receipt information available (if the receipt/token was valid) in clear text.
Thus it shouldn't really matter how long the app was installed on the device or wether it was a new install or a re-install: Apple provides the latest information available. Thus if there ever was an IAP it should be included in the returned information. Right?
But this would mean that there are thousands of users which have been using a very, very, very limited trial version over years which seems very, very, very unlikely...
Is there any other explanation?
We have an iOS app available on the App Store.
We want to release an update of the app but we want the release to happen in a phase wise manner i.e. the updated app should be available to only 10% of the users initially. After some time, say 1 week, it should get available to 20% more users and so on.
I was told this is possible on Android.
Can it be done for iOS apps as well? I tried to search (including this link as well) but could not get concrete answers.
Thanks in advance!
Unfortunately, we cannot do this in AppStore. If you want to do A/B testing(https://en.wikipedia.org/wiki/A/B_testing), then there are several tools in market to assist you with that. If you want to do beta testing, then TestFlight is the one to go for.
https://itunespartner.apple.com/en/apps/videos#testflight-beta-testing
You can use TestFlight where you send you test subjects the app to their email, and then they open your app with the apple TestFlight app. The limit is 2,000 people I think.
Currently this is possible for both iOS and Android
Apple phased release
If you choose this option, your version update will be released over a 7-day period to a percentage of your users (selected at random by their Apple ID) on iOS with automatic updates turned on. Users are not notified that that they are in a phased release of your app.
Android staged rollouts
You can release an app update to production using a staged rollout. With a staged rollout, your update reaches only a percentage of your users, which you can increase over time.
For (beta) testing there are different options. You could create specific groups within TestFlight and rollout to them or share your app over DIAWI with the people you want to reach. For production - let's say AppStore - it's not possible to do a partial rollout or update cycle.
I have integrated Flurry Analytics into my iOS app. I haven't released the app yet so there can't be any real users except for myself. However, the second day I found that Flurry reports there are 5 new users. How is that possible? I did delete and rebuild my app to my phone several times for testing purpose, but according to Flurry FAQ, the same device should only be counted once. Does rebuild app from Xcode change the device id? or the hashing function of the device id?
Flurry relies on IDFV for metrics purposes. In the event that you uninstall the app and have no other apps on that device from that developer (meaning you), then the device will register as a new user.
On top of this, when submitting for distribution, Apple seems to run some automatic analysis on the app. This typically results in around 10 to 20 new users, though this effect is only observable in small apps.
I've found the same thing, I was developing with 3 devices yet according to their stats I had dozens and dozens of unique users. I wrote and politely asked what was going on and would they offer an explanation, they couldn't be bothered to reply. Same thing happened after releasing the app to the app store - the app registers with my server so I know how many users there are, yet the number reported by flurry versus the actual number differed by a huge amount. So I've come to the conclusion their figures are total bullshit.
If there's somebody from Flurry reading this please feel free to refute this and offer an explanation, if you can.
I have an app and I want to know, if I want to provide a paid version that's ad free, do I have to make a totally separate app? Like one app that has ads, and then do I have to completely remake the app without ads?
Probably the best practice is to make a full version of your app but limit the functionality. Then you provide in-app purchases to enable the functionality that was limited. You can do this all at once or in parts.
For example, a game where level 1 is free, levels 1-5 are $0.99, levels 1-10 are $1.99, and so on.
According to Apple (https://developer.apple.com/app-store/review/rejections/):
Submitting several apps that are essentially the same ties up the App Review process and risks the rejection of your apps. Improve your review experience — and the experience of your future users — by thoughtfully combining your apps into one.
I am moving my iOS app from paid to free and need to know, after the user has installed the update, whether they have purchased the original app.
This way I can reward the user for their previous purchase.
This wasn't possible (easily) before iOS 7 but now it can be down by downloading and parsing the App Store receipt. This is (frustratingly) a lot harder than it sounds. You might want to consider using an Open Source project like RMStore.
I wrote a blog about my experience.