TL;DR: Is there a way to verify that a user has purchased another app (of mine) from the Mac App Store?
In a brief, I want to completely rebrand one of my applications on the Mac App Store. The current version is very buggy and has a user base of nearly 90% pirates. I want to shut down the old application and completely rebrand it as a new product.
However, I don't want to completely screw over my current, legitimate customer base. I am hoping there is a solution to this. The way I was hoping to go about this was to:
Create a new application – completely rebranded
Make it free
Have an In-App Purchase that unlocks the Pro version
Allow customers of my previous app to "restore their purchase" to unlock the Pro version
The new app will have extensive anti-piracy measures. Furthermore, the current application requires a connection to one of my servers. When I release the rebranded app, I will shut down the current app.
I realize the forcing users to migrate may cause some backlash; however, I am hoping that, by providing the new and improved version 100% free, the backlash will pass.
Look for the old app using NSBundle bundleWithIdentifier
get the receipt of this bundle using appStoreReceiptURL
validate the receipt
unlock functionality
Bare in mind that the terms and conditions of Apple say something along the line of "only appstore IAP should be used to unlock features; don't roll your own license mechanism"
Related
My company had outsourced an iOS app to another company, and they published the app on the App Store using their Apple ID. The app have been available for download for a few months and has a number of users. Now my company developed a slightly newer version of the app and would like to distribute the app using our own Apple ID. What's the correct way to do it? The major concerns we have are:
Should we submit the newer version using our ID before or after we take the old app down from the App Store. Would it happen that the newer app get rejected because Apple feel the two apps are too similar? (Actually they are quite similar, for that the update is slim.)
Is there a graceful way to notify the currently online app's users that they should switch to the newer app? And How to coordinate it, since the newer app may take a certain amount of time to get approved.
Thanks.
There are some different scenarios here, I am going to try to address some of them to see which one helps you the most:
1-)You have a current application that contains no use of push notification and no use of in app purchase. This is the easiest one. Basically, It does not matter what version the user has had before. You can remove the old one from the previous developer account and add it to the new developer account. By completely removing the previous application (not just from the app store listing, but from the developer account), you can reuse the bundle ID. When the user reinstall the app, the user will be able to replace the old application with the new application (note that the new application will not appear on the user's update list).
2-)You have push notification. Here, you will have to keep the old application if you wish to maintain the push notification certificates, so, the new application will have to use a new bundle ID, which means that the app will appear on the user as a new application, and the user will be able to have both app simultaneously.
3-)You have in app purchase and subscriptions. You will need to remove the old in app purchase entries from the old developer account, and add it to the new account (if you wish to reuse the product id, if not, you will have to create it either way).
I am not sure what kind of measure you need to take if you are using iCloud and/or other services. Best course of action is to contact Apple developer support. They will give you some guidance on what to do with your specific case. Also, when submitting, make sure to point to the reviewer that you are trying to move the application from one company to another. I think they can access review notes from the review to the previous submission(instead of reviewing it as a new app), and speed up the process.
Edit: You can not transfer apps between companies using iTunes connect. More information here: link
I have to restrict a Free app from being downloaded or installed for a 2nd time on an iOS device, as I would like to user to purchase the paid version of the same. A first time user of the free App can download the Free App and install it on their iOS device, but after using the Free App for certain number of times, the Free App will work with limited functionality as I would like to promote my paid version, so I prompt the user to buy my Paid version of the App. At this time the user can delete my Free App and Re-Install the same from either the iTunes store or the iTunes on their computer or iCloud backup.
Question is how can I restrict the user from re-installing the same Free App on their iOS device a 2nd time ?
Is there any way to tell the iOS on the user's device to stop the 2nd time install of the same Free app ?
Or is there any other way to achieve the same results ?
Thank you.
You're unlikely to reliably get past Apple's review process with these restrictions.
Free/lite apps are supposed to be fully usable apps in their own right. So, using a todo app as an example:
You could limit it to ten TODO items
But you'd get into trouble if it stopped working after ten days
Clearly you can also limit in terms of what functionality you offer. My apps, for example, only allow editing in the paid version; the free one is read-only.
I'm not sure that you can reliably do what you want. (What about if I have to wipe my phone and restore from a backup? Does that count as reinstallation?) But even if you could, it wouldn't necessarily be a good idea.
i think the recommended way is to use in-app purchase. You can enable a full Version to the user when he buys it. So there is no reinstall needed.
I'm not sure why you have the requirements you do, but this does not fit the model of the App Store. You are likely to have your application rejected, even if you were to find a way to do this.
If you (or your stakeholder) are insistent in this approach, maybe the App Store is not for you.
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
This is a conceptual workflow problem. I'm converting an app with an existing user base from Paid to Free with an in-app purchase (FWIAP) to remove ads. The problem I'm trying to avoid is having the existing paid customers updating the app and now suddenly seeing ads and being insulted/assaulted with the "option" to pay again to remove the ads they never bought in the first place.
Luckily, I do have some breadcrumbs in the form of persistent data (pData) that will indicate whether the app was already installed. So my thought is to have the new version check for existing installs before deciding whether to proceed with displaying the ads.
One problem I foresee is later updates then considering all those first-generation users as now eligible for ads again, so I'd have to then add another persistent flag (pFlag) to identify the two groups of users and then hope to remember for even later updates (i.e. third-gen., etc.) to check against the pFlag instead of the pData, as the pData values would have long changed by then.
Does this seem like a sound approach or is there another good known solution to this?
The problem with breadcrumb schemes is with users who upgrade, or have to get a replacement device, and don't have backups to restore from. When they re-download your app, there will be no breadcrumb.
I don't think you'll ever be able to support cases where someone has bought the paid version and installs it directly from the app store on a new device or a device where the app has been deleted.
We recently had this problem in the opposite direction. We have a FWIAP app that customers wanted to be able to purchase through the volume purchase program, which doesn't apply to IAP. So we built a paid version and sell it as a separate app, and it generates as many sales as the FWIAP version, basically doubling revenues (so far).
I think the simplest approach is to just release a separate app. If you convert the existing app, the biggest risk is negative reviews, which could drive down your star ratings and thus downloads. So if you do take that route, I'd have as generous a customer support policy as possible--give anyone who claims to have purchased the paid version a code that lets them unlock the FWIAP version.
But that's likely to be a headache in the future, and from my limited experience, you may make more money by just having both versions in the store.
The paid to free-with-inapp-purchase workflow is supported; it’s referred to as paid-to-fremium and is discussed in the 2013 WWDC video:
Using Receipts to Protect Your Digital Sales https://developer.apple.com/videos/play/wwdc2013/308/
I have created an application and I have purchased an account in AppStore.
I wish to configure the app such that it will run for free twice and after that the user will have to purchase the full version. I want to implement the purchase of the full version inside the trial version (using in-app purchases).
Apple does not allow trial software in the App Store. You can have 'lite' versions of your applications, but Apple requires that they are fully functional applications that do not expire and are not simply advertisements for your for-pay app.
Once you figure out what type of features you want to offer in a 'lite' version, one thing you could do to offer an in-place upgrade for customers in to use the in-app purchase mechanism. Apple now allows free applications to sell in-app purchases. So you could have an app call 'Foo' and inside 'Foo' you could have a menu option to unlock additional features, which would bring them to the in-app purchases dialogs where they could pay you to unlock more content of the app.
Check out Apple's tips & tricks for App Store submission: http://developer.apple.com/iphone/news/appstoretips/
There (listed on Sept. 18th, 2009) you will find a tip titled Just Right "Lite" that reads:
Using a "Lite" version to show how it
feels to use what you make and what
kinds of things your app can do is
definitely a good way to find
customers who will pay for the full
version of your application. But store
shoppers tell us it only works if you
follow a few simple rules:
Make sure the functionality you decide to include is complete. Battles
that require weapons only available in
the full version, for instance, are
annoying and irritating instead of
enticing.
Don't set time limits on your "Lite" version, either for run times
or life times. Applications that will
only run for a set number of minutes
per session, or that expire altogether
after some period of time, don't
recruit customers so much as leave a
bad taste in their mouths.
Only display the UI for what your "Lite" version will do. Grayed out
menu commands, "more track/car
choices" you can see but not select,
etc. makes your "Lite" version feel
more like a commercial than a product,
and an annoying and ineffective one at
that.
Do include information about your full application, including an option
to buy, in either your application's
About section or on the splash screen.
Just make sure the option to continue
using the "Lite" version is there as
well. A good impression lasts forever.
It's important to follow these simple
rules not only to create a better user
experience, but also because your app
will be returned to you by the App
Review Team for modification if it is
found to have time limits, incomplete
functionality, or disabled
functionality.
The most relevent part of that text for yourself and your proposed App design is the last sentence that contains "... your app will be returned to you by the App Review Team for modification if it is found to have time limits..."
Here's a good walkthrough on adding in-app features to your app.
http://blog.mugunthkumar.com/coding/iphone-tutorial-%E2%80%93-in-app-purchases/