I have an iphone app that has been downloaded in the last two months by 150,000 persons. This app has in-app purchases and thousands of people bought them.
I have decided to create an iPad version of that app. On the way doing that, I decided to rewrite the app, making it easier. But in order to do so, I had to create a new interface. Now that I have this new app for iPad, I have created an iPhone version out of it.
My question is: should I release this iPhone version as a upgrade to the current version or create a new app?
My answer is not money related at this point. I ask this because I had an app in the past that I changed radically like that, and I got several people complaining they preferred the old interface. All I have to say is: there's no comparison in quality of the new interface with the old one. The new one is far superior, is easier and more intuitive and requires far less clicks to get the results. The new interface is totally in OpenGL (10 times faster) than the old one in Quartz. I would say the new interface is 80% similar to the old one, regarding to the workflow needed to get the final results.
Having in mind the old timers that will probably complain about the new interface and people that will get lost after seeing a new interface, what should I do? Create a new application or a version of the current one? Have in mind that if I create a new one, people who bought in-app purchases on the old version will have to buy them again.
What do you guys would do? thanks.
You are upgrading a product and as you mentioned yourself, people already invested in it so launching a new version as a new product would require them to repurchase all of it, which is worse then making them adjust to the new approach. People will always complain, that's in our nature, so don't be bothered by that. Even if you have the best product people will try to bring you down. Trust your gut and if you personally use your product and find your new version much better then you will be fine upgrading it. If you need to test the user experiance on the new interface take a look at heatma.ps SDK
I'd release it as an upgrade. As Cyprian said, you have in-app purchase and you don't want to hurt the people who already bought it.
As you say most people will like the new UI more, and I'll assert ALL people will like not paying for in app purchases again. So the course of most happiness and fewest complaints is make the new universal one an upgrade. No fork.
Related
I wanna know if it is okay to submit an update to an app that is different from the first release. For example, my first release would be a game, but on my next release, I want to remove the game but instead make a couple of web views and table views, etc. Will Apple stop me from updating the app?
The Mailbox is one example. When I first downloaded it, it doesn't really do anything but countdown on the number of people getting the app. Honestly, I lost patience and didn't bother trying it out. But I don't think it's an entirely different app, just that the countdown was a layer on top of a fully functioning Mailbox app, correct?
Every time you update new version, apple review team will review your new ipa, so what have updated write in new version.
So if your new updated app is valid means follow all guidelines than there is no problem.
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 am planning to release version 1.0 of my app now. I plan to release 1.1 in the next 2-3 months.
What are the things I need to take care of now for the initial release?
Also what should I select as SKU Number and Bundle ID in iTunes Connect for submitting 1.0?
Version numbers in software are completely arbitrary. Usually, you have a major version and a minor version. Consider the version "1.2". It's version one of the software and there have been two minor updates since the original release. (Note that this is subjective because it could technically be version 3 - where each release is a version change.)
You should not release a second version just for the sake of pushing an update. Generally, an update contains a bug fix or a feature enhancement. (For example, I made a game called "Nippon". I'm updating it to have a new user interface on the iPad as well as fixing bugs. In contrast to this, consider another update I made to another app, which I just changed the icon. See the difference?)
As far as when to release your app, that is totally up to you. You don't need all of the features right away, but make sure that those that you do put out are completely implemented. Don't rush to put out something with features that are incomplete. Users will hate you for it. Instead, choose a core group of features that are your app. Make those work really well and then work on other things for the next version.
Here's a related excerpt from the Apple Developer Resources "submission tips" section (requires login):
The two most common reasons for application rejection are issues with core functionality and crashing. Core functionality encompasses the belief that customers rightfully expect all the features described in the marketing text and release notes to work as described, and likewise that all the buttons and menu items within the application will be fully functional (i.e., no grayed out buttons or notifications that a feature will be implemented later). Before you submit your app for approval, make sure that every aspect of your application is fully functional and that the marketing text and release notes correspond to the end user experience.
Also, make sure you thoroughly test your application on iPhone and iPod touch in addition to the iPhone Simulator. A large percentage of applications are rejected due to various types of crashes, including crashes on launch, which would have been found and dealt with if they'd been tested on an actual device. Don't skip that step in the development process.
Make sure that your app works and works as advertised. That should be your goal for version 1.
As far as SKU and bundle ID:
SKU is supposed to be a four letter code, representing your app. In the old iTunes connect, you would see your SKU represent your downloads. I just checked and it seems that they print out the entire name of your app. However, just to illustrate, a valid SKU for Nippon would be NPPN. (I actually use that one.)
Your Bundle ID should be a reversed domain name. For example, com.mosheberman.myapp could be a bundle ID for my app. You don't have to actually own the domain name, by the way. For Nippon, I used com.yetanotheriphoneapp.nippon.
Hope this helps.
Please bear with me, this isn't a programming question per se but a question about releasing for the App Store.
I have an App on the store that is a universal binary, with a separate UI for the iPad. I've been creating some new features and working exclusively in the iPhone version. I've been rethinking my iPad UI because I feel like it's kind of poor and could be more well done. I'd like to branch off and create a specialized iPad only version and abandon the iPad code in the current universal binary, and instead just target the individual platforms instead of both.
The reasons are as follows:
I want to be able to do a release with new features without having to commit to working them all in on the iPad version of the universal binary.
I want to distinguish the iPad version from the iPhone version.
First, I want to know if this is even possible. Second, I want to know what kind of fallout is possible from something like this. I remember two years ago when Tweetie 2 was a new bundle and the general public mostly whined about having to pay again. My app is much smaller than Tweetie 2 and I don't have a ton of users. In fact, I don't use any analytics to discover daily use, feature use, or anything.
Have any of you ever done something like this?
Thanks for your time, and please don't flag.
That would really suck for iPad-only users who bought your program.
What you could do is leave the existing app out there as version 1. Don't upgrade it.
Release version 2 in separate iPhone and iPad flavours. No existing customer gets left out. You get to split your releases. If your app is truly good then people will pay again for the upgraded version.
We have an app on the app store that we need to remove. As such we have a new version to upload as a completely new app with a new app SKU and Id but we want to offer a free upgrade for those who have purchased the original version.
Is there a way to do this?
But if you're willing to give new App for free for everybody who's got an old one why do you create a new application and not just update old one? You can change anything you want about app except SKU# as I understand. Do you have anything tied to old SKU# or you have other reasons to create a new app?
I agree with the other posters. Apple does not have a mechanism to do this.
What you can do:
-make a black and white or very washed out icon for the old app
- change the app description to say that this is an old version / no longer supported / deprecated and to search for the new version.
- Make sure the new app title show something like NEW, 2.0 or some signifier to draw attention
I have not heard or seen anything about it. Only thing that comes to my mind is to give a promotion code. This of course opens up some other questions:
How to communicate that to your customers?
How to secure that it is not explored by users who have not bought the first app?
Don't have any good answers to that (time limited offer?) but maybe it could lead you to some new ideas.
Good luck!
Unfortunately there's no real way to do this. Apple intentionally keeps information about the users of your old app private.
Well, there's one way I can think of, but it requires some forethought (and I'm not certain it would be ok by Apple) and it would cost you a bit: When your old app runs it contacts a server of yours with the device's UDID, which you save on the server. Then you show an alert in the old app that tells existing users to contact you via email with their UDID (you could make it easy on the user by putting together the email in-app with the UDID in the subject or body). You then send a gift of the new app (via iTunes) to every user that emailed you that way.
You'd take a 30% hit (Apple's cut) but the rest of the gift price would end up back in your bank account. People who pirated the app would get the offer, too, and there's no way you could tell a pirating user from a valid user. But it would more-or-less work.