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.
Related
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.
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.
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'm whipping up a short specifications/requirements document for a small prototype iPhone app project. Describing the basic functionality and behavior is not an issue for me. But, since my mobile application and iPhone development knowledge is very weak, I'm not really sure what else should be in such a document regarding best practices and such.
Example: In my programming world (server side Java), when spec'ing a project for outsourcing, I state that the project must pass static bug analysis by FindBugs.
Example: I understand that there are API calls Apple does not want app developers invoking. These can be cause for having an app rejected from the app store. But I'm not sure how to say that we want Apple's guidelines respected. (I don't even know how to test for that.)
What should I include in a two-page requirements and specification document that is specific to iPhone app development?
These are some points you can mention
1. The application should be developed based on Apple's user interface guidelines
2. There should not be any private API call inside the project which makes the application rejected from apple
3. There should not be any memory leak or excess memory allocation issue during the application running state
4. The application should be supported in all iOS after [your option]. (It mainly depends on the features used in the application)
5. The application should be supported in iOS 4
6. The application should work properly on iPhone 4
Hope this helps
A private API wont be mentioned in any header file or in the documentation so one way to test for that would be to manually go through the source files and search for the functions used in the headers and documentation to see that they are there. It's really not feasable if the project grows but for a small app it could work :)
In addition to the things already mentioned here, I'd add a few more:
The app should work fast, no action should give the user the feeling, the device is doing something
Everything that takes a while should be run in background and even better, be cancelable
Make sure you use animation only where it makes sense but not too seldom. A smooth feeling is most important for users.
These things also imply that you try to minimize application startup time.
There are often tricks to work around performance issues. The feeling a users gets from your application is not how fast it is, but how fast if feels. In my opinion this is the single most critical requirement, besides obvious ones like no crashes etc..
What's the problem with using a private API?
Moreover, I would add that it will be tested on iPhone 3G, 3GS, iPod, 4, all with iOS4 and 3.