We have a paid app on the App Store with id following the lines of com.company.client and we want to add a free version, optimally with the id of com.company.client.free. I need to figure out how, if a user buys the paid app after using the free one, they can get their data from the free version into the paid one... I recall reading somewhere this was possible but I can't for the life of me find it in the apple documentation. I vaguely remember it had to do with the app's bundle ID and using a wild card, but since we already have a version on the app store that we can't change, I don't know how that would affect it. Any help or links to proper documentation would be greatly appreciated.
You can share keychain data between applications in the same family. I would however only recommend this for small user data such as passwords, username etc.
See this guide on how to do that:
http://useyourloaf.com/blog/2010/04/03/keychain-group-access.html
For heavier data, I recommend that you use an online service with user accounts to share the data between your apps. (as mentioned by Clafou, iCloud might help you here for iOS5 and above)
A third option for you could be to make the paid version free, and then use add in-app-purchase for the paid content. But maybe that could cause problems like how to handle the users that have already paid for your app.
I have a similar requirement and am yet to try this out, but if you are happy to use iCloud then you could use the same iCloud identifier (which is different to your Bundle IDs) in both versions of your app so that the data could be sync'ed across devices and across your app versions (paid and free).
Related
I am building out a iOS & Android app. My app may not fully scale to support users and have some limited functionality out the gates. I wanted to put an invite list on the front of registration like Mailbox did a few years ago.
I was trying to read the Apple app store guidelines to creating a "waiting list / invite list" and couldn't get a clear picture. I assume Android is more flexible on this, so I figured I could start with Apple's guidelines first.
Here is what I can find.
In Apple's docs, it says under 3.2.2 "UnAcceptable"
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
In this specific case, I am not blocking by location or carrier. I am just putting up a wall to use the app since some of my users can use it in a limited form, but I can't open it up to everyone on Day 1.
I understand I can run a "testflight" release, but I wanted to make our app available in the App Store for anyone to download since it will be publicly available, just not fully ready for a million people to hit it. My understanding is that the testflight release requires a bit more work based on their docs and isn't as simple as just putting it in the public app store so anyone can get to it.
Apple has the ultimate authority for approving and rejecting apps in their app store so nothing on SO can really be perfect advice. If you are really concerned about approval, you can try to contact apple developers support. Here are a few things I would advise:
Make sure in the developer notes for Apple when you submit to them you include a free account.
In the notes for the app store let the users know that it may take up to __ hours for their registration to get activated.
My understanding is you are doing this to handle the volume of users as you are launching the app. Be advised though that if you start restricting users too much you will possibly get poor reviews. Only restrict usage if absolutely required. If you run into issues make sure you are communicating with the users so they understand.
Good luck with you new app!
I am planning to make an app on iOS. The app will be free. This app will work without the internet. The app should not be able to query my database if the subscription is not paid.
However the app will still receive "notification" or RSS links even without subscription. The subscription will be monthly minimum.
I did some research but some people are saying it is not possible and some are saying this has been changed by apple and it is now possible.
Edit
I would like to add that the app will be as much secured as possible. I will have an SQLCypher database inside - so the key will be stored there too (hidden).
Here is the problem that someone told me: The user can use the app only if it paid the monthly/annual subscription, so the key has to be revocable. It seems not compatible with that because the app will have the database deciphered with the key. And if it is deciphered one day, then it will be deciphered next month too.
Why exactly people tell you is not possible?
The only problem I see from what you write is if the free version of your app doesn't do anything. As a general note Apple doesn't allow "demo" versions (even if that concept is not always clear or enforced consistently): a free app must do something not trivial (and of course lots more if the customers pay).
I would like to create an iOS App for a limited set of people.
It should be possible to download the app for free from App Store, but in order to use it
the idea is that you are required to be a member of the organization, which in this case is a local sports organization.
To solve the problem I thought of giving away activation keys to members that can be entered when they create an account, and therefore only members will be using the app.
Will the app be rejected by App Store? If so, is it possible to go around this in some away?
Thanks.
No you will not be rejected by the App Store.
During the review you will only need to give the access to demo account.
Your app will be available to anyone but you are free to give the credential to any person you want.
edit
Fyi I have such apps. The AppStore only block 'discriminating' app based on carrier or location (you can choose the countries anyway), but you are perfectly in the rules if you give access only to your clients...
edit edit
2.22 like I said is against arbitrary criterias, not linked to the login mechanism
for 11.1 and so on, I understand the point, but in my case (and I think yours) there is no problem if
you sell your service before, the app is just complimentary
you dont sell anything within the app
you dont charge for the app itself or anything within the app, you charge only the use of the server/back office/whatsoever
I guess that Apple dont care, they just don't want to bypass the applestore but I dont think that it is your case.
You should try Enterprise distribution for such purpose.
Yes your app may be rejected. Check the App Store Review Guidelines. In 2.2 it says
Apps that arbitrarily restrict which users may use the App, such as by location or carrier, may be rejected
There are different alternatives.
You can opt in for the Apple Developer Enterprise Program, this'll cost you 300$ a year and requires you to be a legal entity.
If you want to test it with a limited number of people (<1000) try looking into Testflight it was bought by Apple and is deeply integrated in the development process.
No, there will not. You need to to give some demo account info as test data to review while submitting to app store in the iTunes Connect portal.
Demo use case(worked for me): Implementation is like, there need some userid/unique pin to the registered account holders to start the application. At the time they input this pin, authenticate the user with our server and give the permission to let in to the app.
Otherwise you need to go for enterprise distribution. Find more about enterprise distribution here.
In iOS, is there a way to figure out the version of app the user originally bought from?
For example, what if i want to implement some special behavior only for user who purchased v1.0. one obvious "feature" is disable in-app purchase so they can enjoy the rest without paying? I thought up some ways to do it but unfortunately, it wont survive the test if the user deleted the app and also i didnt user icloud early enough to persist this metadata.
Unfortunately this can't be done. At least not in any perfect manner. There is no API to get any details about the user and their purchase. If your 1.0 version of the app doesn't already persist some meaningful clue, your only solutions would be partial at best.
Your issue is made worse if you already have newer versions of the app out (such as 1.1) and you want to add this new feature to a newer version (1.2 or 2.0). There is no way to know if anyone ever had 1.0.
You basically have two options:
Leave it alone. You can't convert a paid app to a free-with-IAP app without hurting at least some portion of your existing customers. If anything, leave the app paid but add IAP for any new functionality. This way, everyone pays the same for the base app and everyone has the option to pay more, through IAP, for additional features.
Depending on your ethics and the number of existing customers, you could just make the switch and make existing customers pay again for functionality they already paid for. Obviously, this is a bad idea but it is an option.
I have an app in the iTunes store that has full functionality. I attempted to release a Free version which contains half of the functionality, and contains a link to the full version if the user tries to use the other functions.
Apple rejected the app on the basis that rather than having two apps, I ought to have the main app released for free and have the extra functions unlockable using in-app purchasing.
That's fine; I can do this. The only problem is that since I released the full version initially, some people have already paid for and downloaded the full version. When I update this app so that it is free, it will be restricted by default. Those users that have paid for the full version will have lost the functionality they've paid for.
I don't really want to release a second version of the app since I intend on continuing to update the app and managing two release streams would be unwieldy.
Is it possible to somehow offer for free the in-app purchase to those users that have already bought the full version of my app when I update the app to the new (free, in-app supported) version?
Edit: An (unpreferred) alternative would be a way of refunding the purchases to the original buyers, along with a note explaining why. Any ideas how?
What I'd do is add a already paid option within the application itself, and then allow users to enter a license code, or email address depending what you prefer, Which you can automatically issue from their contact details if you have them or ask them to contact you if you don't, which most will as they have paid.
Now as far as the licensing and the verification of these codes you could setup a cheap VPS which verify s the code and only activates with codes that you have entered on the server, meaning you won't fall victim of Keygeners.
Just my 2 cents.
If your app doesn't currently have a username/password registration, I would suggest releasing an update to the paid app that explains to your users on an initial popup view something like:
Thank you for supporting our app. Due to changes in Apple's policies, we will be converting this app into a free app with in-app upgrades. Since you already purchased the full app, you will be awarded all features! Please input an [email_address or username] so that we can provide a painless transition.
If your app has a user login mechanism already in place (username/password), then just store those details and have the user log in later in the "free" app to unlock all of the features.
Obviously, both of these suggestions require a backend for validation, but shouldn't be too difficult to create that.
This is tricky due to section 3.3.3 of the license agreement and Attachment 2. I'm not a lawyer so I'll save my interpretation but, read them.
Another option would be to make the free version a new, different app and leave the original one in the store but unavailable. Then you can still publish updates to it but new users won't see it. Apple would probably allow this considering you are still only presenting one app to new users. The downsides are (1) you have to maintain two versions and (2) you have to start over in terms of reviews etc.