Some native iPhone applications (like Clock) display different default images while loading depending on where the user was when the app shut down last.
I wonder if that's something only Apple apps can do, or if mortals can do that, too.
Use a blank Default.png and then in your app delegate's -applicationDidFinishLaunching: method, load a UIView that contains your dynamic content. This solution sidesteps any conflicts with Apple's SDK terms as well as all technical problems.
AFAIK it's for immortals only. There is however one for each orientation and a separate set for the iPad. But nothing that allows you to change those once built.
Related
I have an iPhone application developed with iOS and I need to convert the application to universal so the app can appear in the iPad apps section of AppStore.
It just so simple as changing the Device section in my project to universal or I have to re develop the app, create new views, etc?
It depends strictly on your app, but generally speaking, yes, you will need to create new views.
I mean, even if you want to keep exactly the same UI, chances are that it will be more convenient to provide iPad specific versions of your xib files, or adapt the views you created programmatically. This is due to the fact that the iPad is not simply larger: it has got different ratio (3:4 vs. 2:3) and this changes things completely. You might try to play with autoresizing settings for your views and grouping views to make the same xib work as desired on both screens, but I suspect that this is not so easy except for very simple interfaces.
In any case, this is not the end of the story.
Actually, you will not want a "good" app for iPad to have the same UI as the iPhone version, since the larger screen space really screams for using different layout and organization of the information and controls.
As I said, it depends strongly on your app (with games being the strongest exception to the above rule), but in most cases, your app will greatly improve if you redesign it specifically for the iPad, rather than simply adapting it (so that it is not shown in the 1x/2x mode).
The simple answer is yes, just change the device family to Universal and you are done. But this would be pointless and you might even get rejected by Apple.
Take the time to actually create an app that takes advantage of the bigger screen. Use a split view controller and popovers or whatever is appropriate to your app.
Just making your main view bigger is a bad experience for your users.
I've seen tons of questions and answers regarding merging an iPhone and an iPad app into an universal app, but that isn't what I want to do. What I am going to do is use in app purchase to unlock an iPad interface and then display the correct interface using conditionals. If the interface is purchased, the app displays the iPad Nib, and if not, it just displays the same way as an iPhone application does (with the option to scale the app, etc). The conditionals are very simple and I have already implemented them, however the issue I run into is this: If the IAP is NOT purchased, the iPad displays the iPhone Nib, but not in the typical way. It is just in the corner with no option to scale it, rather than in the center with the black border that you usually see. Does anyone know how I can set it up so i fixes this issue? I'm a little stumped to be honest.
The Info.plist file in an iOS app contains a key, UIDeviceFamily, which lists the devices that the app natively supports. If the key's value is 1, or a array containing 1, the app natively supports iPhones and iPods Touch. If the value is 2, or a array containing 2, the app natively supports iPads.
If UIDeviceFamily says the app supports iPads, then it will run the app in native iPad mode, not in iPhone-wrapper mode.
The Info.plist file is part of your app bundle, and you can't modify files in the app bundle.
So there is no way to enable or disable the system's native-iPad support at runtime. You'll have to move your app's top-level view into a wrapper view that centers and scales its child, and use that wrapper view as the UIWindow's subview.
UIDeviceFamily in the Information Property List Key Reference
This isn't possible, unfortunately. The iPad will know that the app is iPad ready and will tell draw the screen at full size. Even if you showed iPhone xib file on the iPad, they would still be scaled to fit the full screen using the UIViewAutoresizingMask params you've set for them.
One thought would be to force the size of your UIWindow to be iPhone sized (remember to account for retina) and centered, but I'm not 100% sure how/if this would work. You may have to change each UIView frame. I'm not sure.
I've seen tons of questions and answers regarding merging an iPhone and an iPad app into an universal app, but that isn't what I want to do. What I am going to do is use in app purchase to unlock an iPad interface and then display the correct interface using conditionals. If the interface is purchased, the app displays the iPad Nib, and if not, it just displays the same way as an iPhone application does (with the option to scale the app, etc). The conditionals are very simple and I have already implemented them, however the issue I run into is this: If the IAP is NOT purchased, the iPad displays the iPhone Nib, but not in the typical way. It is just in the corner with no option to scale it, rather than in the center with the black border that you usually see. Does anyone know how I can set it up so i fixes this issue? I'm a little stumped to be honest.
The Info.plist file in an iOS app contains a key, UIDeviceFamily, which lists the devices that the app natively supports. If the key's value is 1, or a array containing 1, the app natively supports iPhones and iPods Touch. If the value is 2, or a array containing 2, the app natively supports iPads.
If UIDeviceFamily says the app supports iPads, then it will run the app in native iPad mode, not in iPhone-wrapper mode.
The Info.plist file is part of your app bundle, and you can't modify files in the app bundle.
So there is no way to enable or disable the system's native-iPad support at runtime. You'll have to move your app's top-level view into a wrapper view that centers and scales its child, and use that wrapper view as the UIWindow's subview.
UIDeviceFamily in the Information Property List Key Reference
This isn't possible, unfortunately. The iPad will know that the app is iPad ready and will tell draw the screen at full size. Even if you showed iPhone xib file on the iPad, they would still be scaled to fit the full screen using the UIViewAutoresizingMask params you've set for them.
One thought would be to force the size of your UIWindow to be iPhone sized (remember to account for retina) and centered, but I'm not 100% sure how/if this would work. You may have to change each UIView frame. I'm not sure.
I have an iPhone app that I want to change into an iPad app. I do not want to make it universal. The result should be an iPad only app. The main problem I see is converting all of my .xib files. I realize that I will have to change some things around manually, but I would like as much as possible (including all of the painstakingly made connections in IB) to carry over. Also, if there are unlikely places where I need to change settings, please give me a hint to that as well. Thanks!
Xcode has a convert option. It gives you the choice between a new app or a universal one.
This will convert all your NIBs, but quite how useful that is will depend on how thorough you've been with the sizing options in Interface Builder. For me is mostly worked. A couple of minor tweaks for a couple of views and a complete rewrite for some others.
Of course you'll also have to work with view controllers that "manually" build the view.
The gotchas I found were around orientations (iPad apps should work in all four orientations) and with the screen size. There are also some oddities with the keyboard and modal views if you have any of those (there are a few kinds of modal view, and the keyboard does not always dismiss). As ever when you're making automated changes, testing is key.
The full process took me a lot longer than I was expecting.
Few thoughts for changing iPhone app to iPad app.
Xcode has the provision to change the current iPhone app to iPad app by using "Upgrade current target for iPad" menu command.
http://www.enscand.com/roller/enscand/entry/ready_for_ipad
resize all current view to the ipad size 768*1024(portrait) and then resize all the subviews respectively. the connections doesn't get lost by doing this.
I know it's possible to create a dynamically changable Default.png by creating a symbolic link. But that's not possible in iPhone SDK 3.0 anymore (only in 2.0).
How can I make this in 3.0, or is this impossible?
Tim
This worked on iPhone OS 2.0 http://collison.ie/blog/2008/11/dynamic-defaultpng-files-on-the-iphone but not on iPhone OS 3.0 anymore. The default-screen is always black.
I can change the default-screen in the documents-folder and the symbolic-link does link to that file. I tested that by browsing to the app-folder from the Simulator. I saw the right file in the documents-directory and I saw that the symbolic link points to that (the right) file.
It's not possible in 3.0. It was only possible on 2.0 because it was an exploitable bug. The bug was fixed in 3.0 which is why it's not possible.
Apple don't intend the Default.png to be a "splash screen".
If you read the HIG, you'll see that the Default.png is suppose to represent your user interface as it would be "empty" - without any content. It is intended to give the user the illusion of an "near instant" launch.
Check out all of the Apple apps on the iPhone and you'll see how the default.png is meant to be used properly.
Apple frown upon using the Default.png as a splash screen. They say that it is really only appropriate for apps such as games that don't use the standard UI elements that are provided in the SDK.
That being said - lots of apps these days are using this feature to show splash screens, and seems Apple aren't really enforcing this guideline.
Long story short, you can do a splash screen, but it can't be dynamic - not anymore.
Use a blank Default.png and then in your app delegate's -applicationDidFinishLaunching: method, load a UIView that contains your dynamic content. This solution sidesteps any conflicts with Apple's SDK terms as well as all technical problems.