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).
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 created an app which is a paid app. Now I want to make it free so more user can download the app and use in app purchase to limit some features. But some user already paid to buy my app. How can I implement in app purchase for new user at the same time keep full feature access to old user?
If you connect to your server for registering user info, you can always create an API which executes on app launch to verify that user is full access user or not.
But I am afraid your case is not the above one.
In that case you would require to sync your data (some encrypted key in this context) with iCloud and when application is launched you can verify the type of user.
Using data in iCloud is more safer as compared to keychain as it covers device format scenario. But definitely not foolproof.
Other solution can be using Apple Purchase Receipt to verify the version of previous purchase. But this is only supported since iOS7.
Checkout some opensource libs to understand the parsing of receipts:
https://github.com/rmaddy/VerifyStoreReceiptiOS
So combining multiple strategies is the only answer for your question.
You can do this by reading the App Store receipt. The receipt contains the version number and date of the original purchase.
There are two main caveats: first, this only works on iOS 7 and above. Secondly, Apple don't include code for parsing the receipt (so it's not too easy for users to hack I understand). There are, however, onen source libraries, though using a common one will be less secure.
There are no perfect solutions to this scenario.
Suggestion 1:
Roll out one last paid update. In this update, use keychain to store those IAP flags. Then in the free version, check for these flags in keychain. This will work even if app was deleted and reinstalled with the free version later. But it will not work if the device is being reset completely whether due to some iOS version updates or user's unless a backup and restore also is involved.
Suggestion 2:
Not quite a suggestion. But I have seen similar apps on AppStore have just rollout free version. Then app incurred bad reviews from those previous users!
This is a simple example, but if you're working with a database on a server (not on the phone itself), can't you use a boolean for each feature you plan on selling, and just set that boolean to true for all users currently in the database. This is assuming true means they've bought the feature, and false means they haven't bought it.
You could run this query once after releasing your updated app, and then every user after that would have a default value of false for these features you're selling.
I am working on a mobile iOS app that is customized to each client, with their own app icon, startup screen, and a few other changes. Each is then submitted to the app store as an individual app.
This is working just fine so far, but what will happen if there's 1000 clients instead of around a dozen? Does Apple have any rules on quantity, submission rate or uniqueness? Any reviewer would clearly see that the apps are basically the same outside of the branding.
Don't do it. You will get kicked out of the appstore.
Read 2.20 of Apple iOS Guidelines which says that developers that spam appstore with similar apps will be kicked out completely!
Notably developers like AppGratis got kicked for this and many others reasons.
Sorry can't disclose, if you have a developers account though you can check the requirements
from https://developer.apple.com/appstore/resources/approval/guidelines.html
I know this is an old thread but somehow it popped up and the answer selected is not entirely correct. The requester needs the custom B2B program here:
https://developer.apple.com/programs/volume/b2b/
That is specifically made for the purpose she/he asked about: to distribute customized apps to a business without cluttering the app store. There is no cost but your customers will need to join the Apple Volume Purchase Program for Business though that doesn't cost them anything.
The reason I say the accepted answer is partially correct is because obviously one should not spam up the app store with similar apps intended for one business, which is entirely correct. But that does not answer the underlying why they wanted to do this and how they could achieve the result they need which is to use the B2B program.
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.
I hope somebody can help here, its an ongoing issue with no obvious solution.
The background
I created my own personal apple developer account back in 2010 to tinker about with iOS development. The company I worked for at that time asked me to write an app as a test to see if we could a) write an app and b) sell it. It so happens both cases were true and the app has flourished into a successful venture.
The issue:
I am leaving this company and we are trying to figure out how I can give them this app, they did after all still pay a salary while I was making the app so I consider it their app really only its tied to me and my personal developer license. I currently forward any funds it makes to them each month.
We contacted Apple and they suggested the company i work for set up a company developer account and then ask for an app transfer. This sounded great and we started the process but then it occurred to me that re-signing the app under a different developer license would effectively kill the existing app on the store. All our ratings would be wiped (and there are quite a few) which is unacceptable. The ratings of an App are extremely important to its success on the store. Apple confirmed that the ratings and reviews do not get transferred across. We stopped.
So, here I am at this block again.
The company I work for even suggested buying my personal account off me so they can run it themselves but I am worried about this, it seems fraudulent as I am the one responsible for contracts on that account and any issue would come back to me. THey wouldn't be able to change the owner "name" on the account either from what I have read.
Any suggestions how we can resolve this?
Thanks
Geoff
it occurred to me that re-signing the app under a different developer license would effectively kill the existing app on the store.
This is false. As long as you transfer the app like Apple suggests (you need to contact them for this), the company just needs to submit a new version from their account and it will work. You don't lose your ratings, nothing. It all gets transferred to the new account including the iTunes Connect side of things. They can sign it with a different certificate and submit. As long as the app ID is the same as before (which it will be), there is no problem.
It sounds like you have old or inaccurate information, because I know somebody who did a transfer like this, and they kept all the ratings etc.
I have faced this same issue, after contacting apple several times, we concluded that there was not other choice, so we removed the app and re uploaded it a gain on the other account
Not only the rating has been wiped, but also users with old app will not be able to update it when you push a new version to the app store
Its a very tough decision, but we had no other choice