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.
Related
I have an app that has been released on the app store with separate versions for iPhone and iPad. Now I wish to convert the app to a Universal version but I have an issue which I'm not sure can be resolved.
Both versions of the app use a different bundle identifier (for example com.mycompany.app.iphone and com.mycompany.app.ipad). I want the new (universal) version to overwrite either of the old versions when downloaded from the app store. To complicate matters further, core data stored for that app needs to be retained.
I'm not sure its possible and perhaps the protocol is to release the universal version under a new bundle identifier and have users start again but if a workaround is available it would be really helpful.
your options:
1: Update both your iPhone and iPad apps with this universal binary (with respective bundleIDs and app names)
2: Create a way to sync data between apps by creating a web service. one of the apps I have used extensively - Gas Cubby, does this for transferring data from its free app to paid app. You could implement it in a similar way
3: Nuke one of the apps, update the other app with the universal binary
Option 1 is the easiest. 2 will take longer. 3 is dirty.
(will update this answer with more options if I come across any)
As far as I know and from what I've read before, you can't change the bundle identifier of an app published in the app store.
Due to the sandboxing, accessing the data of your old app from the new app is also impossible.
There are several ways you could go about solving this issue, depending on which one suits you best. You could create a new universal app, and abandon the old ones hoping that the users change their preferences, or you could be pushing the same update to both applications, essentially, having the identical app under two different names. I'm not sure what are Apple's stances on the second option, but it will be a hassle either way. Good luck!
I'm about to start a new project which will take 6 weeks or so. There are lots of tableviews in this project, and most of them would take advantage of custom prototype cells and static layout tableviews.
Given I will have so many, I'm wondering if I should go down the path of doing iOS 5 only, therefore I can use Storyboarding and get the new tableview goodness.
What are your thoughts on going a iOS 5 only app now, or should I be waiting for the install base to increase?
If this question is 'would it be better practice to use iOS 5 given the user base at the moment' - I'd have to answer that there are a number of trains of thought on this. The first is that as with all new iOS versions, it's gonna take a bit of time for people to get up to the latest. The other is that if someone wants your app enough, they will get their device upgraded (assuming there isn't an alternative).
My developer buddies are always telling me I should just jump to the latest version because from the developer point of view, it makes no sense in starting on an old version. I used to support iOS going back to version 3.1 - but it's getting harder to do that these days.
If it were me, I'd give the customer the choice and say you can have older support but it will cost you more money, or you can have latest support and it will be less.
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.
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.
There has been a lot of talk around iPad-Apps / Approval / Store-related Questions. I've recently built an App which I'm just about to release / send to Apple for approval.
I'm thinking about developing a dedicated iPad-App as well.
Now, in order to not have two seperate Apps in the Store (one for the iPhone, one for the iPad) i want to create an universal-App for both platforms.
However, i couldn't figure out if it is possible to first send in my iPhone-only app and later publish an update that enables my app to run on both platforms.
Does anyone have an idea on that topic?
thanks in advance
sam
Yes, you can update an iPhone app to become a universal app.
Many apps are already doing that. Universal apps provide the better user experience, I think, as they reduce the number of "duplicates" in your iTunes library (and on your iPad).
Unfortunately, a great many developers are going the "two separate apps and make the iPad one really expensive" route instead, too.
The only downside to universal apps I can see is the increased size (all the iPad-only stuff that iPhone users do not need), which could be a factor for the more fancy applications. Does anyone know if iTunes is clever enough to strip this out when syncing?