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.
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.
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.
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?