I am beginner and plan to make a Iphone/Ipad application which will receive a questionary xml from restful webservice, parse it, get answers from user..with two buttons(next, back) on screen, as you may guess there will be validation alert messages, display messages..etc..checkboxes, radiobuttons, date pickers depend on questions type.
So what would be the best strategy, to insert if else blocks on user interface and choose the layout for device type while I am developing the application, or first make a working iphone version and convert it to Ipad later on, and would that be easier? what kind of problems should I expect while converting to IPAD..thanks!
When you create a universal app, you have the option to keep all viewControllers and xib files separate for iPhone and iPad. This is very handy. Alternately, you can check which device the user has and load the correct xib that way, but since the structure of the apps may be quite different, I strongly encourage the latter approach instead.
The ipad has a bigger screen. This is numerous consequences for designing most apps. Also, the ipad has a splitviewcontroller which is quite handy, whereas the iphone tabbarcontroller is better there.
iPhone and iPad have different UI requirements. Read the apple iOS human interface guidelines, it's very nicely explained in there. You'll also find the answer of what to do if you usually would use radio buttons, because there are no radio buttons on iOS.
Related
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
For development reasons, I started developing a universal iOS app, but want to launch with the iPhone version only first.
Besides modifying the “Targeted Device Family” to “iPhone” in the build settings, are there any more necessary steps to prevent users opening the already developed iPad classes/views on their iPad?
Moreover, is there a possibility for users (e.g. with jailbroken devices) to enter the app in iPad mode on their iPad? (How) Can this be prevented?
You can put a condition like :
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone){
--- do something--
}
and comment out the calls for loading iPad classes and views
The answer to this varies based on how you've set up your existing code. If for example, you perform run time checks for the current hardware E.g if ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPad) and change the UI based on the result of this, then you'll have to redo some code because even if the app only has an interface for iPhones, that condition would still evaluate true on an iPad.
Then another option is to have your classes split between interfaces. This is probably the best method when done right. By that I mean really sticking to the MVC paradigm and making your two interfaces separately, then linking each to its own controller object and then putting as much reusable logic for your app in one universally accessible object somewhere.
If you're done this the second way I've mentioned, you shouldn't have any trouble. Simply by pointing the project toward a storyboard for the iPhone/iPad versions of the project, the correct class files are loaded etc. Which leads me to the direct answer to your question.
Modifying the "Targeted Device Family” is all you really have to do provided you've set up your project in the second way I listed. And furthermore, there shouldn't be any concern that jailbroken users will access the iPad files. They can get in, but they're all compiled anyway and 99% of people don't know what to do with that big blob of gibberish.
And even if they did, I don't think anyone is going out of their way to try to find iPad versions of iPhone only apps. They know that if an app has a completed iPad version, it will just run on their iPad.
you do not need something else besides modifying "Targeted Device Family" property. I see little possibility that launching iPad mode is possible even on jailbreaked devices, but you can, for example, remove iPad files (and dependencies for them) from your project for iPhone build. I still think this is not necessary step.
We are creating an application which uses one view multiple times inside another view.
I have accomplished this by manipulating the default xib view size to look like the one in the picture below and then importing multiple instances of it inside my main view:
Everything seems to work fine inside the simulator, I'm just scared apple will reject the application when submitting it to the app store.
Is this an acceptible way of accomplishing the task or would apple reject the application?
note, I havn't tested this on an actual iPhone, only in the simulator.
Regards
No apple is not going to reject your application. I always make custom views this way. And reuse them. So Don't worry about it. I have done this thing in lots of apps and all are on app store. You can check this link for apple rejection criteria if you have any doubts.
Reasons for rejecting iPhone application by Apple store Happy Coding!
I have a simple iPhone app, mostly table views, map views and other standard stuff. When I change the project settings to make it universal, everything works fine after a few small tweaks. So the iPad version looks just as a big iPhone app.
Definitely, the app will look better if I use some split views, pop-ups and generally rework the UI to look better on the iPad. But I wonder - will Apple review team accept a universal app that is basically just an enlarged version of the iPhone app?
As long as you explain what's changed when you do an update submission (e.g. "now with an iPad-friendly User Interface!"), Apple should accept your update no problem.
What are you afraid of? That Apple would give you a reason for rejection? Just do it, and if you get feedback make the necessary changes. Even if Apple is control freak #1 and a humbling power monster megacorp, I'd be much more worried about it being published and USERS not approving it. :)
iPad users can download and run your iPhone app just the way it is and get the same results either way. From any non-marketing point of view, what would be the advantage to calling it 'Universal' with no changes?
Btw, I've submitted the app without any changes, and it was accepted without any problems.
I wrote an iPhone app. Then, I changed the interface a fair bit, added higher res images, and made an iPad version of it. In a perfect world, I would like for anyone who buys the iPad version to get the iPhone version for free (though not conversely). Since Apple doesn't seem to have a way to do that (right??), my next favorite solution is to make the iPad version include the iPhone version somehow.
I know that I could just convert the iPad version to "universal", but since the face of the app is so different, that seems like a real pain. I have many view controllers and they are almost completely different between the two versions. Some of the methods are the same, but only about 30%. Is there an easy solution along the lines of this:
Check if device is iPhone or iPad
If iPhone, then use one group of files
If iPad, then use a different group of files
Thanks in advance!
Try creating a new project in Xcode and choose to make it a universal app. In the default way Xcode lays it out, there is a distinct divide between the iPad and iPhone versions. You can make the two versions of the app as similar or different as you want.
In addition, you can check which device you are running on at runtime by using UI_USER_INTERFACE_IDIOM(). Currently the two values for this are UIUserInterfaceIdiomPad and UIUserInterfaceIdiomPhone.
The "easy solution" you describe is basically how iOS loads Universal apps.
There's no other real way around it. You'll have to merge your two projects into one again to do what you want.
The first problem will be that some (many?) names of classes will be common between both projects. You can save yourself some pain by using the "Refactor..." functionality in Xcode to change the names of the classes in one project (say, your iPhone app, since it's older) before you merge them together. The second problem will be your Info.plist; you'll need to ensure that the correct "Main nib file base name", the correct supported interface orientations, icon files, and so on are set to correct values for both iPad and iPhone respectively.