I have an old app on app store that is divided into one free version for both iPhone and iPad and one paid version for both, so four different apps in total. I am going to make a complete new version of it so that it gets easier to handle. I want it, if possible, to be one universal app that maybe can use in-app purchase for customers to get the "premium" content.
However, people have paid for the previous version, is it possible to somehow let them have access to the premium content in the new one?
Or do you think that it is better to make a complete new app with another name? :P
Any suggestions?
They can still use the old one if I remove it from app store right?
This is something that you would need to discuss with Apple, for the most part, they do not like it when potential sales could be lost. After that is all said and done, there are ways for apps to share data with one another.
Have a look at this tutorial, it should give you an idea on how to do it.
http://www.enharmonichq.com/sharing-data-locally-between-ios-apps/
Related
I have an App currently in the App store that I've been adding functionality to. I've never worked with In-App purchases, but from what I have been reading, it looks like the "improvements" offered are code adjustments to add, or unlock features.
For my "improved" version, I actually added an entirely new (additional) VC plus a Master VC to switch between the two (using the storyboard), so it's not just a matter of unlocking code to provide the additional features. Can I still use the In-App purchase to provide access to this version, or would I have to submit it as an entirely new product?
If you are trying to add some kind of "premium" feature that only people who pay X amount will have access to, but are still maintaining a "basic" version of the app for everyone else, then yes, you can create an In App Purchase to do this. Or, if you wanted to, you could create a separate "premium" version of your app. It's really up to you. I wouldn't necessarily say one way is preferred over the other, because I've seen it done both ways.
Even if you wanted to charge for the new features, they are not present in the currently released version of your app, so no matter how you decide to market this, you will have to submit a new version of your app. It can contain an in-app purchase or not, but it will be a new version. It certainly does not have to be a different app; adding functionality, possibly including an in-app purchase, is what a new version is for.
In short: you don't need to add a totally new app in any case unless and until you want one more app to be on app store
Detailed answer: If you are just making changes in the underlying architecture of your app it doesn't make any sense to give it to user as in app purchase( and i guess apple will also reject your in-app products). You should only add in-app purchase if you are adding a new feature or giving the user some bonus stuff.
And as per me you should add new version of the app only if you feel that this is a new app.( for example Badlands and Badlands 2 are similar apps but internally they are different from each other so they uploaded them as badlands 2)
I'm trying to develop an app that can be used to generate multiple apps. Let's say for now I'm doing an app for fruits, but tomorrow the client will want to create an app for vegetables, and the day after tomorrow for meats, and so on.
So what I'm doing right now is creating an app with same codebase and generating different Targets for each topic (fruits, vegetables, etc.) with its own settings.
That is working really good for now, but I want to make sure that my apps all passes the AppStore review guidelines. The one that concerns me is this one:
4.3 Spam
Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, and Kama Sutra apps already. Spamming the store may lead to your removal from the Developer Program.
So I've read some posts that talks about the best way to accomplish doing multiple apps with same codebase, but hadn't seen anyone lately talking about the Apple restriction to this stuff.
If using different targets it's not a solution for Apple to approve, and you know one, I'll be glad to hear it! What I wanna avoid is making one app and make the user select the type of food he wants (following my example scenario). So my goal is having multiple apps for all different topics, and make Apple approve it.
Thanks in advance!
This is great question. I hope someone from apple team can answer this correctly.
My personal experience
Creation of separate app is perfectly fine as long as end app provides something unique compare to other bundleId. In my case We have 100+laws apps having each law app created using same code base but different data and from User perspective they need it in separate app compared to grouped app.
The visual schema should be different in each application. Please try to make different colors, logos, URL's / data for each flavor.
Each app name-should be unique ( Apple doesn't allow you sell app with same name). Adding hypen, or cosmetic name changes will be definitely candidate for app rejection.
Having said that there is no gurantee to get your app approved each time. In appeal also if you try to tell them that similar app is approved, you are at their mercy to get it approved.
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 am soon gonna release my first game on Apples AppStore, which is a Tower Defense game. My question is if the preferable choice is to release two version, one lite and one full, or to have one version with in-app purchase to unlock the rest of the game (levels 6-20)?
The first priority is to follow apple's guidelines (I do not want it rejected).
Second priority is financial (which gives the most money)
Lastly, which is easiest to maintain (I believe both methods are almost as easy to maintain if you do it right)
I think that many developers faced this problem, and i believe, that in-app purchase give you lot's of benefits and is really a right way to go.
You don't split up downloads. All the purchases of your app counts to the only one.That puts you higher in the App Store. All the reviews. All the stars. That's what you want.
It's easier for user, who has chosen the free app to switch to the paid one. To press just one button is not the same as delete old one and install new app.
If saving user settings and progress is imortant for your app, you just save it in NSUserDefaults and continue using after upgrade. Imagine, what you'll need to do, if you have two separate apps.
Jailbreakers. They download cracked apps in Installous. Not your's.
You need to maintain only one app.
Of course, you'll need to implement in app purchase in your app, and there is still iAP cracker, but, as for me, choise is obvious.
We have some small similar apps in appstore with small portion of content in each, every app is paid.
Now we made large app with in-apps and all content from previous apps + new features and some new content. App is free.
Users are asking for getting content from previos apps for free and it's honest - some of them already paid for it
Update:
To be a little more specific - I need to choose between 3 ways:
Updating small apps (like said in the first answer) to use
keychain
Updaiting small apps to send sone unique codes to our
server (or other custom way of detecting)
Find a way to it
without updating small apps (a lot of them!)
You should take a look at this post. Shows how to check if a user has a specific app using the canOpenURL Method.
Simplest way in my book.