I have already developed an app for iOS and I want to upload it to AppStore. I am about to buy an Apple developer licence for iOS so I would like to ask some questions to people that are already enrolled in a program like that.
First of all I am an individual programmer, I don't own a company, so I should get the individuals' license currently costing $99. When I submit an application as an individual to AppStore will it show my real name as the company or can I choose whatever name I want?
Secondly the name mentioned above will be the same for every application I upload using this licence?
Thirdly and most important. My application will not be free. However I would like to have a free edition too to show the basic functionality of the paid version. What's the difference between:
having one application that is free for starters and then you can upgrade and pay?
having 2 different applications where one would be called light version?
Is it harder for people to crack and put on installous the first option? Because many times I've seen on installous downloading an application but it was without the paid upgrade (maybe I am wrong here, though...)
You still select a company name which will appear on all your apps and is very difficult to change.
With regards to having a lite version, you may find apple would rather you use the in app purchase upgrade route and may reject one of your versions.
Regardless, the In App Purchase upgrade would be less "crackable" than a paid for full version. Especially if you verify receipts.
My company currently has two applications in the app store: a full, paid version that includes two ebooks, and a "lite" version that does not include both books. We've just developed a new version of the app that instead implements the two books as IAPs, with the intention of merging the two apps into one. I'm at the point where I'd like to submit the app, and I'm not sure of the best way to proceed.
Current plan:
Update free app to the new version with the IAP books.
Rename the free version, removing the "Lite".
Delete the existing paid version from the app store.
Potential problems with this plan:
Those who've already paid for the existing full version might feel ripped off, since their version won't be receiving any of the other updates in this new version.
There will be a name conflict, since we want the new app to take the name of the old paid one (removing the typical "- Lite" signifier). This won't be much of an issue in the App Store if we immediately remove the paid version from the store, but can make for a confusing user experience if a user downloads the new version alongside the old paid version.
Along the same lines, if we delete the old paid version as soon as we upload the new free version (with the same name as the old paid version), it's easy to imagine some confused users of the old paid version deleting their existing paid version and downloading the new free version, only to realize they'd lost the books they'd already paid for, with no way of re-downloading the old paid version.
My questions:
From a real high level, are we handling this the wrong way? I've Googled and Googled, but I haven't been able to find much guidance on how to combine paid and free version of apps into one.
Is there any way for me to determine who's already purchased the paid version, and "gift" them the book IAPs in the new free version? If we thought this threw sooner we could've logged the unique IDs of all of those paid versions, but I do believe that's against the rules now anyway, correct?
What other sorts of issues might arise by giving the "- Lite" version the same name as the old full version?
Thanks in advance for any and all assistance or feedback.
We just did that with our FileApp Pro and the free FileApp. We got rid of FileApp Pro and now the new FileApp has In-App Purchases. However we wanted to have all users that bought FileApp Pro to have all In-App purchases of FileApp for free.
Here is the method we used:
We are sharing flags between FileApp and FileApp Pro using the iOS’ “Keychain sharing entitlement” which allows two apps to share the same keychain data. This allows FileApp to know that FileApp Pro is installed. Then we wanted to make sure that FileApp Pro privileges remain available in FileApp through the iTunes account of the user so we used a free In-App purchase to do that. The FileApp Pro user when launching FileApp for the first time is asked to purchase a free In-App purchase so all his privileges remains across devices even if he reinstall FileApp.
You will find a complete article on our bog describing the method:
http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
Edit: Here's the archive link to the above post that doesn't seem to be available now: https://web.archive.org/web/20160309135133/http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
I would think it might be best to turn the paid version to the free so at least your original paid customers are taken care of the most. Depending on your user base you could even ensure the original paid users aren't shown any ads or other restrictions by doing an intermediate release to have those users save something to user defaults. Then you could provide an update to the free version with a UIAlertView that asks them if they want the full version for free and direct them to the app store to download it. I assume you have many more free users but you would probably upset less people with this path.
I know two apps that did something very similar. The Economist, and USAToday app, which literally alerted the user to ditch the current app and download the new one. (Not sure why they had to do it that way though). So I am quite sure you are not the first one thinking of doing this.
If there is an option for you to provide account+sync capabilities, that'd be the best way to merge both the apps. One of my favorite apps, Gas Cubby, handled this pretty well. Gas Cubby has a free and a paid version. If you want to upgrade your from free Gas Cubby to paid one, you download a different app, and then sync data.
For your worries about how to restore content for the paid customers in your Lite app, you can use a URL scheme in the Lite app, which, when called by the current paid app, will enable those books for free.
As #rooster117 says, its best to turn the paid version free, and ask the lite version people to move to the paid-turned-free version. Of course put hard stop date in the app that you'll discontinue, so that all those who use it will move to the one app of your interest.
Your Problems:
This is going to happen regardless, you can't make everyone happy
I would go with removing the Free version of the App although, but before you do send a push notification to all the "Lite" version holds saying support for this app will be discontinued and direct them to the paid version
To continue on from #2 if possible, before discontinuing the "Lite" version if you have an account system setup to a server of yours release an update for both versions that syncs all of their books with your own server (not iCloud). This way when they download the new version (after the Lite is discontinued), the app will automatically sync the books back to the device.
Your questions:
As you relise there is no real way to merge two apps, from what I've seen from games to utilities is to remove the "lite" version as some point all together and if the user wants future content updates then they have to download the app still on the App store.
Refer to my Answer to Problem #3
I believe it will be out right rejected by the App Store review process, primarily due to the fact that they both perform the same function, i would suggest to remove the free one altogether
I'd like to use different targets for my free and full versions of my app.
I then want to setup in app purchases, so a full version upgrade can be purchased.
However, I'm unsure how I can modify the target to make it the full version. I assumed that the targets would be different binaries and therefore using targets for this purpose wouldn't work ?
The only example I've found is a simple NSUserdefaults flag, which seems very insecure and sounds very easy to crack ?
If you are doing an In App Purchase, then you provide all the code in your App, but you put some branching logic that excludes the execution of the paid for stuff unless they have paid for it. There is no downloading of a full app one if they do it in app.
What you are discussing is having a free app and an paid app and the user can then go to the app store and purchase the paid for app separately.
Using NSUserDefaults for the In App Purchases isn't necessarily insecure - just encrypt the data before saving it to disk.
I have a lite version of my application. I want to include a link or something that sends the user to the App Store so they can purchase the full version of my App.
I do not want to do that In App Purchase program though.
Is this allowed, just want to make sure, i'm not seeing anything definitive online.
You can make a link to your full version app in the App Store. There's nothing wrong with that. It won't count as an In App purchase, it will count as a regular App Purchase.
The scenario is:
I created a free iOS app that had in-app purchases for premium content
I now want to convert the app into a paid only version of it and remove all IAP stuff
My questions are:
Will the AppStore let all current customers download the app again without double-charging them? (i.e. forcing them to pay for an app that used to be free)
As long as I keep the bundle identifier (i.e. com.yourcompanyname.appname) the same, it will just overwrite the old app like a normal upgrade, correct?
You're correct: if it's the same app -- same bundle id, submitted as an update -- then existing customers will be able to download it for free forever, like any upgrade.