Hi we have an iOS app in itunes which have more than 20,000 downloads.
since we have re-branded our company we have developed a new app which includes extra features than the existing app. New app is with new name and Bundle id.
So now rather than taking out the existing old app, we want to redirect all the existing users to our new app. How can we do that ?
what we did was , we updated the existing app version with the popup, which says this app no longer available please download our latest app. but this got rejected by apple.
Any best practices to decommission an ios app
Thanks
Apple will not allow you to completely drop all of the features in an app - they want users to still be able to use the app. Imagine if all of a sudden Facebook make it so no one could use their app, and forced everyone to download a new app. It probably wouldn't turn out too good for them.
What you should do is just make an update to the old app. All of the users will be able to update easily, with no hassle, and you won't lose and users.
Another way to do this is by calling your new app MyAppName 2, although this will really only look good if you're developing a game.
If you would really like to get rid of your old app, I would recommend removing it from the app store and contacting Apple (You'll have to give them a good reason. Wanting people to pay for a new app doesn't count as one)
What many developers do, is add code to an app that checks a specified endpoint for instructions at each launch. The instructions are either, run as usual or, display this message and URL.
Personally, I would do this, and also update the old app as a freebie teaser for the new app. Apple pays less attention to reductions in functionality than they do to "kills".
Run the teaser for a year or so, then kill it.
I am moving my iOS app from paid to free and need to know, after the user has installed the update, whether they have purchased the original app.
This way I can reward the user for their previous purchase.
This wasn't possible (easily) before iOS 7 but now it can be down by downloading and parsing the App Store receipt. This is (frustratingly) a lot harder than it sounds. You might want to consider using an Open Source project like RMStore.
I wrote a blog about my experience.
I am publishing my first iOS app to the App Store. However, the company that hired us wants to see the app work before we publish. Is there a way under the $99 developers plan to allow them to see the app work on a real iPhone?
For completeness there is another way. Although I've used TestFlight very happily for years, it can prove to be too complicated for some testers!
If your app has been approved by Apple (but you've set release date in the future), you can give people promo codes (which you can get from iTunesConnect) and they can download the unreleased app. This is great for getting your app to reviewers.
From iOS Developer Library:
Promo codes apply to a specific app version, so when users redeem
promo codes for a version of an app that hasn't been released yet,
they download the prerelease version.
https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ProvidingPromoCodes.html
Obviously in your case, you probably want to get your client's approval before even submitting to Apple, therefore #Anil's answer is better for you.
This is possible through multiple platforms.
iOS 8
As mentioned above, refer to the following link:
http://blog.thebetafamily.com/2014/09/10/testflight-beta-testing-ios-8/
iOS 7 and below
Test Flight - https://www.testflightapp.com (Acquired by Apple and available on iOS8 as described above)
Hockey App - http://hockeyapp.net
Test Flight is free and simple to use. All you need to do is upload the certificate and it'll take care of the rest. Test Flight used to support other OS like Android. But after the acquisition, I think it only supports iOS.
Hockey App is also simple. But only supports certain numbers of builds or projects for the free version. Hockey App provides direct update during the app launch if a new build has been uploaded.
here is my question, i made an app and put on appstore, but i wish to charge the version without any iAd for 69p ...and the version WITH iad built in for free...
so, should I make two separte projects for each version?
and how do i make the free version with iAd should a pop up alert recommend user to go to appstore buy the ad free version?
is it just a normal UIAlertView with delegate method to call the App Store or open it as UIWeb in browser? how do i implement that?
any suggestions ?thank you very much
You can use compiler flags to wrap around your code so that you can have one source, and create multiple targets from the same project and build multiple apps (with different app identifiers and everything).
However, this causes you do have to manage two different apps in the app store (entering the same meta data twice), and deal with the review process on two different apps.
Also, people might skip over your paid version, whereas they would have installed your free version, and upgraded later.
I recommend that you have one source, one project, one target, and one app in the app store and use in app purchases (IAP) to turn off advertisements.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Can anybody help me out to know the possible reasons for which Apple store can reject or raise objection to submit any iPhone application.
Here are possible reasons (unofficial, from here):
Vibration. It is not permitted to use continuous vibration in your apps - short bursts as warnings is all that is allowed. Don’t bother trying to set up a timer to keep the vibration going, it will cause your app to be rejected.
Linking to private frameworks. This is obvious, but somehow in playing around with stuff we had linked to the MoviePlayer.framework. That’s a no-no, and cost us about ten days while we unlinked that framework, recompiled, and then resubmitted.
Improper handling of editing in tableview cells. Also obvious, but be aware that if you enable table cell editing, you’ll have to manually specify which cells should respond to editing controls and which should not. We had some random prefs cells in one of our early apps that were able to be swiped to bring up a ‘delete’ badge. Of course it didn’t do anything, but Apple justly considered this poor design and rejected our app.
Icons. Make sure the 57 pixel icon is identical to the 512 pixel version. Also, use a different icon if you are creating ‘lite’ and ‘pro’ versions of your app (i.e., free and paid). Using the same icon for both sends your app straight to … you guessed it … the bin.
Copying existing functionality. This one is much more subtle and insidious, and has probably affected the great percentage of developers. In addition to the widely publicized Podcaster debacle, reports from user comments indicate that Apple is casting a wide net when looking for duplicated functionality. Mini web browsers, or apps that essentially show web pages, seem particularly vulnerable, even if they add new and/or useful functionality. Stay away from email clients as well.
Using appropriate keyboard type. If your app asks for a phone number or other numeral-only input and you present a keyboard that also includes the possibility of entering standard alpha-numeric input … yep. (Thanks Jeremy1026)
Version numbers. If your app is currently at version 0.99 or below, you’d better consider giving it a promotion as Apple seems to prefer 1.0 and above. One of ours was recently rejected for being .016, with a message suggesting that our version number wasn’t even numeric. When we resubmitted the same app from scratch as version 1.0, it went through.
Network Reachability. If your app requires any type of network access you need to make sure it works when that access isn't available. If it doesn't it will be rejected. Apple provides sample code to test this which you can use as-is in most cases: https://developer.apple.com/library/content/samplecode/Reachability/Introduction/Intro.html
And last, but not least:
Flatulence Don’t even try. ;-) UPDATE: sorry, this seems to be outdated by now. Apple makes a lot of money now with "fart apps": see this article.
Edit:
Here is a link to a recent article about ten iPhone Apps That Didn't Make Apple's App Store.
And a tip: Apple has a Mac app called Application Loader that you could install. Once you install it, it analyzes your app's zip file. It verifies all the certificates, icons, and other things are correct before submitting to Apple. Using the Application Loader minimizes your chances of app rejection.
Another interesting resource: App Store Roundtable: Transparency and the Approval System (appleblog.com)
Yet another edit:
New rules by February 2010: "No Swimsuits, No Skin, And No Innuendo" (source: TechCrunch article, Wobble author's blog)
By the way: during the iPhone 3.0 preview event (march 2009), an Apple spokesman told that 96% of all submitted application were approved.
Apple have now (as of 9th September 2010) published their official list of app store review guidelines:
appstore approval guidelines
(apple developer login required)
or a mirror here:
app store guidelines
Will apple want to create an app like that in the future? If (yes) reject.
Do you have a really awesome idea that apple may want to use in the future if(yes) reject
Here's the video of the SDK announcement that describes Apple published list of rejection criteria:
SDK Announcement
As others have noted, Apple also seem to have a bunch of other conditions that they don't publicise. Note that rejection notices are now covered by the NDA.
I can't confirm this but it makes sense, but people are reporting their apps being rejected for being too simple or too trivial.
Just got a bounce for handling network outages badly. If you connect to the network, be prepared to handle any error conditions that may come up.
My paid version of app was rejected by appstore.
After Purchasing and downloading app first screen was "User Agreement" and when user taps on " I agree" only then he is able to continue using app.
Apple described the reason of rejection "when user purchased app from appstore and download in phone then you must not restrict user to Agree with Agreement" instead display your agreement before downloading app in iTunes.
Amazingly, apps can get rejected for trying to keep their interface consistent with Apple's own apps. (ie, using pinch zoom/expand gestures)
There is a site I know which can help you generate great advertising ideas with iPhone. see this site:
http://itunes.apple.com/app/adpack/id359562015?mt=8
I submitted a paid app to app store but get rejected and i learned another possibility of app rejection
My app was Game Center enabled. When app starts first screen was login screen that prompt user to login through GameCenter to continue.
They rejected the app giving reason- As user will not be able to get services of your app unless he is not logged in with Game Center although he paid you to download app. You cannot restrict user to login through Game Center each time before app starts.
From 1st May,2013 onwards if we don't support iPhone 5, your app will be rejected.So iPhone 5 support is must.