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?
Related
I have an app I am working on that I want to be free but with ads. I want to also have a premium version that does not have ads but costs a small amount to purchase ($1.99). I want to know if other developers, especially those that have distributed such an app, if it is a better practice to create 2 apps or if it is better to make one app with an upgrade option built-in. I like the idea of having a separate listing for the paid app but I can see where that could be a lot of extra work to maintain a separate app for such a small feature difference.
first of all,
if you are going to develop apps for appstore, you can't create 2 apps have the same basic features but one has pro features
that's according to app-store review guidelines 4.3 spam
says....
4.3 Spam
Don’t create multiple Bundle IDs of the same app. If your app has
different versions for specific locations, sports teams, universities,
etc., consider submitting a single app and provide the variations
using in-app purchase. Also avoid piling on to a category that is
already saturated; the App Store has enough fart, burp, flashlight,
fortune telling, dating, and Kama Sutra apps, etc. already. We will
reject these apps unless they provide a unique, high-quality
experience. Spamming the store may lead to your removal from the
Developer Program.
Blockquote
if not.
then second.
both will work fine,
there are games like limbo have free and paid versions on google play
that's your decision anyway,
if there is a lot of difference between free and paid,
if it's just about unlocking some features and remove ads,
it's a simple answer. if both of options will give the same functionality,
choose the easiest way
and "separate listing for the paid app" not a good idea, why?
#KiloKw2 mention to that
It depends on your personal preference. If you would want to create 2 apps then you need to also have two unity projects at once and if you would integrate the premium stuff as paid expansion then you would need add a code into the game which enables them if the used bought them. I would personally go with having just one game with a built in paid expansion as I find easier that way. Having two of the same apps at once just complicates everything for no reason
I finished working on one iPhone app, and my client wants to port it over to iPad.
Now I created another storyboard for the iPad UI in the same project, and have the iPad UI working and sharing some code with the iPhone code.
The project has one target, with devices supported as universal.
My question is: My client expects that I present him with two apps, one for iPhone and one for iPad, will this configuration work?
When I submit this to the app store, will it know to split it into two apps, or should I just create a separate project for iPad all together?
Thanks.
With your current configuration it will upload to the app store as one app, but for users logging in it will display the correct app depending on the device they use on the app store when they search for it.
So depending on if your clients wants two separate APK files or if they want two apps on the apps store:
If the client is requesting two separate apps you will have to split the project, unless there is an easier way that I am not aware of.
You can also explain to the client that with the current configuration the app will have a little plus icon on the app store to indicate that it is a universal app and will work on both devices, which will be determined by the device they use to download and open the app.
If they want to sell the app, again as far as my current knowledge allows, you will need two separate apps as you can not set different prices for it in the current configuration, this statement is under correction. Unless your client wants to sell both iPad and iPhone apps for the same price then you wont have an issue.
Hope this helps
No, it will not, because it's the same bundle ID, so in this case, in the App Store you'll have one universal application.
If you want to have two applications, you should create a new Xcode project that supports iPad only.
What you can do is to create different target, one for iphone and the other is for ipad. You can follow the answer on this question, it is quite good. Because you have 2 different target, you can have different bundle identifiers, specify different AppDelegate, but all the other code could be shared
I've seen this done before with apps that I use, but I was wondering how it would be possible to share IAPs between an iPhone and iPad application. More specifically, I want to make sure that users that make a purchase in one app, do not have to re-buy the same product in the other.
I've read in a few places where this could only be accomplished with a universal app, but I wanted to see if this was, in fact, the only way that it could be done.
As far as I know, in-app purchases are app-specific. But it's really pretty easy to go universal - try out some of the excellent tutorials. You obviously have the advantage of only having to maintain a single code base (though of course you could be disciplined and share some core code, but it usually lapses...).
I have posted 2 apps on the App Store that are only for the iPad.
I now want to post the iPhone versions for the same apps.
However, I have read that Apple Guidelines state that developers spamming the App Store with many versions of similar apps will have their accounts terminated.
So I basically want to ask 2 questions:
To avoid spamming, should I not post the iPhone versions at all or post Universal app versions?
Apple asks to change name if posting same app for a different device. For iPad, I can say "game_name HD". But what about naming for the iPhone? I was thinking "game_name Pro".
Would appreciate any help very much. Thanks.
In the past, I have used the term "Pocket" for the iPhone/iPod Touch version. As in, Barnyard Bluegrass Pocket Edition.
I am developing an iPhone application which I need to distribute to an organization of about approximately 50 people, no. of users can increase or decrease in future.
I checked my iPhone developer account, there I got that I can distribute my application via Adhoc Distribution up to 100 iPhone or iPod touch users. So I think it should be best way to distribute my application to that XYZ organization.
On further searching I found that there is also an - iPhone Developer Enterprise Program, which is available to companies with 500 or more employees and a Dun & Bradstreet number.
So I want to know - which will be the best way for me according to my requirements ?
Also I want to know that say if I choose Adhoc distribution then is there any way for automatic up-gradation in it ie. to install new version of my application on user's iPhone or iPod without deleting the old version.
Thanks,
Miraaj
If you do not have something seriously wrong with your persistence frameworks, than you should be able to upgrade the app on devices, while retaining the data just by providing the users with a new version of the .ipa file.
Ad-hoc seems to match your needs best, but remember, that you will have to get the UUID of all 50 iPhones the app will be installed on. A bit tedious and time-consuming. Enterprise would be better in that respect, but you might not be able to qualify for it. It's also extra expensive.
I am not surer what you mean by deleting the old one. If you want to have multiple versions of the app available on a device, they will not be automatically updatable and data sharing will be very complicated. Ad-hoc might be about your best option.