I don't understand, why i need versioning in my IPhone apps.Could anyone explain.
Apple uses the version number when you submit an update to your app. If the update you submit does not have a version number greater than the currently shipping app, then Apple will not accept the update.
That is the only technical reason.
There are other reasons:
it gives you a way to track issues against different releases
it allows users to know whether they are up to date
Etc
If course if you are never going to update your app then you can just set the version to 1.0 and forget about it...
You don't have to support different versions - you can just choose one (probably the latest) and just develop for that. However, it will limit the number of devices that can run your application.
Read the accepted answer to this question (the one with the green tick next to it) for information about supporting different versions of iOS :
How To Make iPhone App compatible with multiple SDK (firmware) versions
Related
My employer has a free iOS app in iTunesConnect that was originally released a couple of years ago and has received various updates over time. They now wish to stop supporting older versions of the application (1.x) and disable these older versions of the app.
My questions are:
Can we stop users from re-installing old versions of the app? If yes, how?
How do we disable/remove old versions of the app in iTunesConnect?
What is Apple's policy regarding disabling/removing old versions of applications?
I'm not an iOS developer and am unfamiliar with the whole Apple application development process. I have searched the web as well as the Apple developer centre and I've read through the Apple Developer Program Terms and Conditions but I haven't been able to find answers to any of my questions.
I have managed to find information about removing an application from sale but this removes the entire application, rather than just specific versions. (Deleting a free app from iTunesConnect)
David Smith's article (http://david-smith.org/blog/2012/06/20/hacking-paid-upgrades/) on Paid Upgrades mentions the ability to provide fixes for previous versions if they're not deleted from iTunesConnect. When I log into iTunesConnect, I only see the current version of the app listed so I'm assuming prior versions have been deleted already. I would, however, like to confirm that users can no longer download old versions of the app.
This article mentions users being able to download old versions of apps from iCloud (http://www.macrumors.com/2011/06/09/icloud-supports-re-downloading-some-discontinued-apps/) - can we prevent this? One option would be to mark the the version as having a "legal issue" but what ramifications does this have? and if I can't see the app in iTunesConnect then how do I do it?
I found a post asking about how to force a user to upgrade the application every time a new version is released but this doesn't answer my questions either. We want the users to upgrade but we're not wanting to force it programmatically. (Can I force an iPhone user to upgrade an application?)
I've also found lots of posts asking how to revert to previous versions of an app in the app store but again, this is not what we're wanting to do. We're wanting to disable older versions of the app but leave the most recent versions alone.
Before the flame wars begin:
Users that are unable to update to the latest version of the app for whatever reason are able to use a mobile website in place of the app. The website has the exact same functionality.
Can answers please be kept on-topic rather than getting into great debates over whether one should/shouldn't maintain legacy versions.
Thanks in advance :)
Users can typically only ever download the latest version of an application. There are a few ways I think they can get around that but in general only the latest version is available to users via the normal means.
If, however, you absolutely must prevent the old versions from being released you can do so when submitting a new update. Right after you say "Ready for Upload" you will be asked a question about if this update was for a 'legal reason' if you click YES then you will be given the opportunity to disable old versions of the app from download.
As to Apple's policy on this...I have no idea. But I can't think of any policy that would require you to support older versions moving forward.
Am I being particular dense today? I'm working on an app that needs to offer legacy subscriptions to old iOS versions and auto-renewing subscriptions to newer iOS versions.
Normally I would check using a respondsToSelector test for something appropriate in the classes I want to use, but I can't see anything in the storekit that has changed that would allow me to do the test.
So how should I check to see if the device supports auto-renewing subs? I know I could check the explicit iOS version number, but I'd really prefer not to do that.
Is there a more sensible check I can do?
Why not just check for the iOS version that you need? How hard is that?
Hey Roger I was in a local meetup group for iOS developers and the topic of auto-renewing of subscriptions came up.
1 It is meant for "Magazines", which I would assume works only with Newsstand Apps
2 and it is ONLY meant for "Established" publications.
Which implies a printed version, and not just any ole' publication. This must be a nationally syndicated thing, something you would find on every major news stand in the country.
From what I gather in the conversation, Apple does not mean for the auto-renewal feature to open any new monetization channels for app developers (not yet at least), but rather the feature was created to extend the existing business model of print publications to the iPhone iPad digital media. Perhaps sometime in the future, this feature will be extended to all apps in the app store. Here's hoping.
I have a question about iPhone app versioning.
I know there is the build version number (BundleVersion) and the release
version number (BundleShortVersionString) which is visible to customers.
I want to make a free version of the app and the full version.
I assume these versions should have the same release version number (e.g. 1.0),
but can they have different bundle versions?
I need different bundle versions because I am using OpenFeint for keeping highscores, and I want just one leaderboard in the free version, and all the others in the full version.
I am really not sure how to do this..Is there maybe an option to hide the leaderboards from inside the code?
I would appreciate any help, tnx :)
You can set any bundle version. It does not matter for OpenFeint.
You need use some AppID from OF, for two application. And you'll got one project for Open Feint. And then comment code that use another leaderboard for lite version, and you left one leader board in the free version.
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.