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.
Related
I am updating one of my apps and I have a dilemma:
In places I wanted to add iOS 4 unique features I had no choice but to implement them only for supported devices - no dilemma here.
The dilemma is when I have 2 ways to achieve the same effect, one in the "old way" and one in a "new way".
A good example is using blocks for animation, I can use this syntax:
[UIView animateWithDuration:2 animations:^{
self.segmentedControl.alpha=0;
}];
that will be supported in iOS 4.0 only. or use the old way which will be supported in all versions including 4. (There are many other similar examples.)
What do you do and why?
The blocks are really great but I will have to write more code if I want to support previous versions? What do I earn from using them in that situation?
Generally, the rule is to support the lowest version of the OS that provides the capabilities that enable you to deliver the product you want to. I made all of my applications require iPhone OS 3.0 about a month after that launched because I needed to support custom copy and paste, as well as in-application email. For the free version of one of my applications, I wanted to try out iAds, so I made that 4.0-only.
The possibilities for internal code improvements that are provided by a new OS are a little trickier to make rules about. As Joe points out, the time you spend struggling against an old way of doing things, that could be saved by moving to a new OS version, is time that you aren't fixing bugs or adding that next great new feature. At some point, the elegance of a new way of doing things (like blocks and GCD) is just too compelling to ignore, even though it may not directly add any new features to your application.
On the Mac, many developers maintain support for the current version of the OS plus the previous one released by Apple (Snow Leopard and Leopard, at this time). Only when a new OS comes out do they drop support for the previously one-behind version. Others, like Wil Shipley, advocate jumping on board the new OS exclusively right away and ignoring old versions. The argument here is that people who won't pay for Apple's new OS versions or who don't keep their systems up to date are much less likely to buy your third-party application.
I've seen this as well on iOS. For example, I ran a test of ads targeted to different versions around the launch of 3.0 (when iPod touch users still had to pay for their OS updates). While downloads of a free version of my application were relatively consistent between 2.x vs 3.x users, almost no 2.x users paid for the application while 3.x users did.
No one complained among my paying users about the early move to 3.0 (they did speak well about the new features, though) and only two people have complained about my free version going 4.0-only, compared to 56,000 that have upgraded without a problem. While I would give a little time for a transition period, I believe in moving to new OS versions relatively soon after they launch. Right now, I'm in the process of making everything of mine 4.0-only so that I can modernize the codebase.
Finally, one last benefit you get from going with the new OS version is that you become much more attractive to Apple, who always wants to promote applications using new features in their new devices and OS versions.
What is your goal for developing this app?
If it's revenue (or fame from high download counts), then look at the size and purchasing power of the additional market segment versus the development (and test and QA and support) costs.
Old device owners and old OS users are (1) a minority (check the analytics for the current number, on the order of 10% or less and dropping), and (2) they buy far less apps on average than people with the latest devices and OS versions. For non-blockbuster apps, this small additional percentage of potential downloads may not be worth the extra device testing and QA time that supporting these customers requires, much less the development effort.
If you are doing an app for charity or learning, then go ahead and donate your hours of effort to the 1 guy (or other small number) who likes new apps for their old device. It's good skill set to have if you want to jump to using some super new feature in the latest OS release just as it comes out, a few weeks before the majority of users upgrade their device's OS to match.
If you're trying to make money selling your software, by all means you should support as many versions of the OS as possible, and the easiest way to do that is to write one piece of code that will run on all versions - hence, use the old style of animation blocks.
With the new animation way you can use a block for completion, rather than having to create a separate method, it's much cleaner if you have multiple animations that need to do something on completion. Also it's easier to read, because its not so spread out. There's bound to be some technical advantage but I don't know about that side of things.
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.
I have an app on the Store for which we’re readying an update.
The other members of our team have the App Store version already loaded up (~purchased) on their respective iPhones -- and those contain User Data which each member needs to be able to keep.
In the meantime, we need to test out a Beta version of the next version of the app.
Presumably, we’d need to have the two versions (ad hoc, and app store) co-existing on each device, at least until everyone’s signed off on the beta and it’s uploaded to the store (at which point, they'd delete the beta version).
[Once it’s on the Store, of course, they can each update their main (i.e., Release) version of the app via the usual App Store 'update' mechanism. In that case, all their user data is still retained intact.]
So assuming that’s the proper workflow ...
How do I issue a Beta to the team, and have it not replace/overwrite the existing App Store version?
I’ve tried customizing parameters in the beta’s “[appname]-Info.plist”, but haven’t found a setting yet that allows the two versions (beta and release) to co-exist on the same device.
Any ideas? And is this is the proper approach to them being able to keep their data?
(And last, how might I do it with & without a script? I assume there's just one parameter that'd need to be changed.)
I hope this all makes sense -- thank you in advance for your help!
So you want to have two versions of the same application on one device? I don't think there's a way to get this effect -- updating an application, which keys on unique CFBundleIdentifier, replaces old version bundle but not data.
For the effect you want, you must have two distinct applications. They need different CFBundleIdentifiers, so they won't overwrite each other. They then cannot share data, so you'll have to arrange for export/import involving an off-device shared space.
If you don't want this hassle, issue the team extra devices and test on those. The team's primary devices remain on the AppStore version. You must still export/import to bring content from the test devices to the primary devices. Any paid content each has on the App Store version should be available for their beta, though, as usual for app upgrades and one-owner multiple-devices scenarios.
I am near the end stages of developing an iPhone application and will be releasing it as both a 'lite' (ad-supported) version and a 'pro' (ad-free, likely with additional functionality at some point) version.
I've followed suggestions here and elsewhere about creating multiple targets, etc. and am able to build these without any problems.
But this does bring to mind a question: What is the best, most user-friendly, accepted way in which to handle transitioning from a lite version of an app to a pro version?
As I see it - and please correct me if any of my assumptions are wrong - there are potentially two ways to do this:
Give each application its own Bundle identifier (ie. com.companyname.fooapplite and com.companyname.fooapppro). This will result in both being treated as being completely separate entities. Data is not automatically migrated should a user move from one to the other and both could very well have both installed on the same iPhone at the same time.
Give each application the same Bundle identifier (ie. com.companyname.fooapp), so that they are treated as essentially the same application. The lite version of the application will be overwritten by the pro version if they download and install it. Data from the lite version is maintained in the pro version.
The latter seems ideal to me - I can't imagine someone wanting to keep a lite version after they've just purchased a pro version - but this brings up a few questions:
Does Apple even allow option #2?
Will using option #2 result in any goofiness I should be aware of, ie. the two versions stepping on eachother in some way.
If it's not allowed, is there a suggested practice in place to migrate data from what are basically two completely different applications? I'm aware of StoreKit, but it isn't supported on free applications.
As it is, this current app doesn't really generate data of huge value and the worst thing that will happen is users will have to re-enter some authentication credentials upon upgrading to pro. But down the road, if I were to develop a similar app that stores valuable data locally, I'd like to know how to best transition users and their data in a seamless manner.
Thanks,
Jeff
One more option is to exchange data from the Lite to the Full version via a URL. Register a myFullApp URL with the full version and have the Lite app present an upgrade option that calls that URL with the various data you want to exchanged encoded in it.
That does require the user fire up your Lite version and hit a button, but it's fairly simple too.
I have not tried this myself, but a third option to exchange small amounts of data is to use the Keychain API. Apps that share an identifier stub -- com.companyname.foo as a parent to com.companyname.foo.fooapp and com.companyname.foo.fooapplite -- can supposedly write to the keychain from one app and read from the other. Haven't seen this done, but a lot of people claim it's possible. And in any case, the keychain is probably a good place to be storing things like authentication credentials.
Option four would be to have the lite app store some user data on a server you operate, and have the full app retrieve it from there, but there are all kinds of problems with that approach.
Those of us with iPhone apps (released or unreleased) are able to send out limited beta builds using ad-hoc distribution. While the Apple docs for this have a few holes in them, there are a number of blogs, postings and other articles out there on "the net" that fill the gaps.
However, one thing I haven't seen anyone mention, and I was curious about: When you do a beta build do you use the same app id as your released (or to-be-released) app?
The argument for using a different id is that the beta could then still run alongside the released app. This is probably more important if you already have a released version in the field.
An argument against is that the beta would not have access to any data the released app may have generated, and vice -versa. This may or may not be what you want on a case-by-case basis.
Are there any issues with this approach? I only have one app id registered currently, but IIRC there are no obstacles to just creating more as necessary..?
Would be interested to hear what others are doing.
We use the same app ID, just for simplicity. There are enough headaches in ad-hoc distribution that we don't want to confuse anybody with "why are there two apps on my phone?" problems.
I use both different Bundle Identifiers to allow my testing team to have multiple versions of the app installed as well as different Bundle Display NAmes, so they can easily see that they are using a development or beta build and report that number back to me when issues are found.
I think it depends on how important the data in your app is. If the data is valuable I don't think beta testers would want it putting at risk, hence having a separate AppID would make sense. Of course, that also means that they won't test the application as fully either and any "upgrade" code won't get tested.
In my case (Yummy), the data is just a cache of delicious.com so a catastrophic bug in my code would mean, at worse, downloading all your bookmarks again. So I tend to use the same AppID for everything.