Should i use iOS 4 new features in my app? and why? - iphone

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.

Related

app store - two applications versus in-app purchase

For marketing (as opposed to technical) reasons I'm about to submit a financial services iPad app that comes in two flavors, "regular" for individual users working on their own behalf, and "professional" for financial planners working on behalf of clients.
The "Pro" version functionality includes everything in the regular version and also provides the ability to save and switch between client datasets. Most of the code is identical, only a tiny sliver of code is added to the Pro version build (although more features may be added in the future that might widen the gap in functionality).
Here's the question: Is it better to maintain two separate apps in the store (with separate application IDs?), or as a single app with an InApp purchase to upgrade?
I'd rather avoid the infrastructure of InApp purchase, but I want to "color between the lines" of Apple policy and keep it reasonable for users and for future development.
Most "regular" users will never upgrade. But many (most?) "Pro" users will probably want to start out with the cheaper single user configuration before spending significantly more dollars on the "Pro" version. Advice on how to package?
It seems like the best bet is to create a second target, setup the project to archive both, and then load them as separate apps to the App store.
I base this mostly on reading between the lines in the various answers about provisioning (at least there seems to be some evidence others have taken this route). I'd still welcome comments or other input from those who have gone down this road (or taken the other one). Thanks.

iPhone app - fork or create a new version?

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.

Help planning for an update to my app

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.

Only targeting iPhone/iPod touch after previous universal binary

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.

iPhone Development on Hackintosh

My question is in regards to developing code for the iPhone / iTouch.
What with Apple's transition to the Intel platform for their chip, it is obviously now possible to run their OS on a PC.
So, with that, and my inherently cheap nature, I was wondering if it was possible to bypass the purchase of a refurbished Mac by running the iPhone SDK on a Hackintosh?
As I am more of a hobbyist then a serious developer at present, I'd basically like to get my feet wet before fully committing to this endeavor. In the long term I know that it would be better to purchase a Mac...
Yes, it's totally possible. I developed my first app on a Dell running the iATKOS OSX patch.
Whether it's worth it or not really comes down to how difficult it is to get a hackintosh install (Kalyway / iATKOS) running on your PC. With some PCs it's trivial and everything works. For others it's a nightmare and your networking/audio/graphics will never work completely. If you need to run a patched kernel (e.g. you don't have an Intel Core 2 Duo chipset) things become really awkward.
Your best bet is to take a note of the hardware in your PC and do some research on the various OSX86 forums.
Assuming you get everything working the only future concern is software updates. iPhone SDKs generally require the very latest OSX update (e.g. 10.5.6), but installing updates on hackintoshes with patched kernels is a nightmare.
If you enjoy tinkering with this type of thing and are comfortable partitioning your HDD and playing with boot flags then I'd say go for it. If not, consider picking up a used Mac-Mini on eBay/craigslist or something. If you find out that iPhone development really isn't for you then you can resell it lose practically nothing.
Yes, you can, but save yourself some time and pain.
Pick up a Mac mini or an iMac.
It's possible. But you are restricted to the choice of hardware for the hackintosh. Even if you get it right, no one can guarantee everything will work (sound, lan, etc.). If you can run the OS, you can run xcode with the SDK. But I don't think you'll be 100% satisfied with the end result.
As I see it if you want to run os x it's better to invest in a mac mini than in hardware for a hackintosh. Asuming you'll be buying all the components for the hackintosh.
I was in this dilemma recently, and decided to go with a real Mac rather than a Hackintosh after hearing the stories of my friend (who is doing it specifically for iPhone development). He was able to get iPhone development working, but his hackintosh is always having one issue or another; the most recent one was a constant boot cycling, wherein the machine would immediately reboot after loading the OS.
Look on the bright side: Apple products are popular and easy to sell. If you get one and sell it before the next generation comes out you can get most of your money back - money that would have been spent anyways on a new hard drive (to quarantine your hackintosh, heh) or OSX (assuming you meant to get the software in at least a remotely legal fashion).
Yes, you can. I have. But is it worth it?
If you are doing it for fun it's worth it.
If you are doing it for a real, useable Mac it's not worth it.
Now you will have a billion guys come down on me for saying that because some guys have built some truly impressive rigs but they are missing the point of a Mac. Macs just work well and are a pleasure to use while PC's just get stuff done and you probably secretly hate it.
I did it just for fun but I ended up spending more on a Hackintosh than I would have if I just bought a Mac Mini. Of course my computer is 4x as fast but it's just not the same as a real Mac. On Mac's everything just works... it's really nice. But on my Hackintosh nothing works without direct intervention on my part... not very nice.
I always planned on using that computer for windows development anyway so it wasn't a waste but otherwise it would have been a HUGE waste.
You can do it. I have 3 hackintoshes that we develop on, but at the end of the day you will need a real mac to be an apple developer.
One problem I see with the Hackintosh approach is that if you get it working now, you are not guaranteed to have the same machine working when an update to Mac OS comes out in the future, and this could be especially important if the iPhone SDK and/or developer tools that you want to use are hosted only on the next generation of the system software.
In the long run, I think it'll be better to go with a cheap (and even a used) Mac of some kind, like a mini or a MacBook.
You can do it, I started learning iPhone/Objective-C/Cocoa development using a virtual machine and an image of OSX (it was a pain to setup though and I think I could only use OSX 10.5.2)
It's just not worth the hassle, in the end I just stumped up £365 or so for a second-hand 2007 model MacBook off eBay and it's been smooth sailing ever since.
On a $10 P4 2.4GHz, 1GB RAM, hackintosh works fine and xcode/iphone sdk works as well. Its a little slow, but stable, and a very viable option for someone looking to just test the water of iphone development, without committing the cash.
Yes you. right now I am learning iphone app development in a Hackintosh (iATKOS S3 version2).
See http://wiki.osx86project.org/ and http://insanelymac.com/ for any problem with installing hackintosh
Hackintoshes are a great value. You can spend anywhere from $400 to $4000 and get an extremely capable machine.
You want to go with a Gigabyte brand Z87 motherboard, Intel Core i CPUs, Nvidia graphics, and SSDs. Avoid budget hardware, it usually isn't compatible. Or you could go the Intel NUC route and get a NUC, a small PCIe SSD (32GB or 64GB should do the trick), and some laptop ram.
Do your research and you're good.
Current version of Visual Studio (2019) and Xamarin Forms will enable to develop IPhone apps by utilizing Xamarin Hot-Restart (Preview) feature without requiring a Mac.
In my case, I have an IPhone and would like to develop an IPhone app however I was being forced (until this day) to buy a Mac (or at least chosing the Hackintosh way) develop an IPhone App. Now I can write and debug my app directly on my IPhone (which is fair!).
Details here:
https://nicksnettravels.builttoroam.com/ios-dev-no-mac
If you have so little belief in yourself that you feel the need to save a couple of hundred dollars by hacking a pseudo-Mac together just don't bother trying in the first place.
Furthermore you will pretty certainly fail (or spend so much time trying to succeed you'll have wasted vastly more time getting things to work than you saved on cost). The two clinchers are
You have to run code on a iPhone or touch, because the emulator is not perfect and will mislead you without you even being aware of it - I have code that runs on the emulator but not as expected on hardware
Apple's key signing is hard enough to get working with the real thing, it took me a couple of hours and I'm not alone - there's a great many posts out there on development forums from people having difficulties managing it. Getting it working on a Hacked machine - well you may be lucky, but are you prepared to gamble?