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!
Related
I have a paid iPhone app, and I'd like to create an updated version that will run as an iPhone app until the user completes an in-app purchase that will have the app use the full screen.
Is there any way to change an app from a small-sized iPhone app to a full-screen iPad app after the app has already been distributed?
Short Answer: No, it's not possible.
Longer Answer:
This would involve dynamically setting the build settings (specifically Targeted Device Family) at runtime. These settings however, are read and compile/build time. The solution is not impossible, would involve rebuilding the app with different settings. This is unlikely to be permitted by Apple anyway
what you can do is check in your app for any payment made and then if the app has been paid load different data.
The easiest way would be to load different xib files for your layout if the user has paid. The user would however need to quit and relaunch the app to have the payment taken into accound. And you would need in your code to programatically decide to load one xib or the other. But it's doable.
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 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.
I am somehow new to objective-c and iOS.
My question is as follows:
I have created 5 iphone apps until now. What I need now it to create a new project that will include all other applications in it. So the user would by 1 application and then from a uiviewcontroller he could launch the individual apps bundled in the application. Like an application bundle for the iphone. I have seen lots of this on the app store especially with games.
I have been searching for an answer for a week now. The only thing closely related that I found is related to targets, but how am I supposed to launch the individual targets from within the main app (if this is even possible).
Can someone please point me to the correct direction? A tutorial or an example would be great.
Thank you all in advance.
Cheers!
Check for any duplication in naming classes and resources in all your projects. Since you want all your projects in one project, you have to eliminate duplication.
Copy the classes and resources to your new project (please keep things organised by using folders for your classes and resources).
Identify the root view controller of each app (where the app starts) call it from your new root view controller.
You need to keep every mini app separate, get rid of all of the app delegates when you copy them in. Each mini app needs its own way of launching, most probably through present modal view controller.
Just have the main app handle all the loading and app delegate stuff.
I have not had much time to read through all the documentation for the 1500 more features included in iOS4, so right now I have 2 questions:
If the app is just a usual utility application, what to do to make it "qualified on iOS 4"?
If the app uses a timer to refresh all the items on the screen every one minute (requires redrawing of the sub views), what are the changes that have to be done? ( I notice that even though when I quit the application, open it again in a 3GS iPhone, the timer is still generating events).
Update
What I want is the technical part of the story, not the description on the appstore, etc...
E.s. Those applications above have to do something with applicationWillResignActive, applicationDidEnterBackground, applicationWillEnterForeground, applicationDidBecomeActive, etc...
This is something that Apple do when testing your app after you submit it via iTunes Connect.
They will test your app on iOS4 and if they decide it works sufficiently, they'll mark it as tested on iOS4.
If, for whatever reason, it doesn't work well on iOS4, they'll reject the app and let you know what was wrong.
It's a label given automatically by Apple after they test it on iOS4. You may not actually need to do anything extra to get it.