That’s why my apps with only a Launch Screen File is classified correctly.
It may be possible for CoronaLabs to provide some way for us to specify this file in the build process. However that does mean we all will need to get acquainted with Xcode Interface Builder to design this file.
Or perhaps as a workaround corona always creates (while creating the app file) a default (white or black) launch XIB or storyboard file for the iPhone 6/Plus
Not an acceptable solution for many, as the black/white Launch Screen File will override anything else for all iOS 8 devices (not just iPhone 6 / 6 Plus) meaning that you won’t be able to specify your own launch image at all.
Is LaunchScreen.nib (or .xib) an actual file that sits inside MyApp.app ; if built+compiled by XCode ?
Would it be possible that we manually stuff one of these inside our Corona project folder, specify the plist in build.settings, and then let the SDK wrap it along the build and perhaps hoping iOS can pick it up?
Looks like if we just “give” the app a .nib file, specify an extra key in build.settings, iOS8 launching will work !
Here’s what I did and have it to work only in XCode Simulator , I got no actual iPhone6 devices to test this out, and ran out of time to plug in + test out my other physical devices.
I created a LaunchScreen out of a fresh XCode 6 project. Build the project, find the .app file, locate the LaunchScreen.nib file and extracted it out of the .app bundle.
In build.settings, add an extra key to the plist (no .nib extension): UILaunchStoryboardName = "LaunchScreen"
Place the LaunchScreen.nib file into a Corona project , build it (I built for XCode Simulator)
Launch the app in simulator; you will see when if running under iOS 8 environment, the LaunchScreen.nib file will be used. (see White screenshot)
If running in iOS 7, standard launch images will be pulled (see black screenshot)
Annoyingly, XCode simulator basically just takes a screen-cap out of your launch screen package, and draws itself a png file and store it in the cache folder (wtf)
It’s fair to say having 1 launch image bundle is fine, but they (Apple) should still classify other apps as iPhone6/6+ compatible if devs are supplying compatible static launch images anyways…
Anyways, it’s not the end of the world yet, we can still squeeze in this content manually in our projects and at least triggering the LaunchScreen.nib file, which hopefully App Store will accept it and classify it as “iPhone 6 / iPhone 6 Plus Compatible”
I’m launching my app in a week’s time so I’ll report back using this method, see what happens.
Guys, just a dummy question: All this effort is just to have the “Optimized for iPhone 6/6+” to appear, right? I.e, our apps already works fine on iPhone 6/6+, even with Lauch Images (if following Corona guide instructions), without problem. Am i correct? (Because I tested here on my iPhone 6 and my apps are fine)
…having said that. It *is* favorable to use a Launch Screen File in the sense that it replaces the need to use the UILaunchImages array entirely. You only need one xib file instead of having to create a bunch of static PNG files as before.
If you need iOS 6/7 compatibility you just supply your old launch images (PNG files) in the root directory as before in addition to the new Launch Screen File (no need for the UILaunchImages array).
It’s not just about getting the compatibility note. It has a major implication as far as app store searches are concerned. Try searching “iPhone 6” on the app store and you will only get apps that are optimized for iPhone 6 and iPhone 6 Plus. Apparently a LOT of people search for optimized apps this way and getting listed in that search result could mean improved sales over your competitors who haven’t optimized their apps yet.
Since no iPhone 6 or 6 Plus will ever run iOS 7 or earlier, you would not need to include those launch images to support previous OS builds. Your existing set of launch images should be sufficient without having to touch anything. I think Ingemar (and company’s) use of a Launch XIB file is probably going to be the best way to attack this. I will have to learn how to build this file and then perhaps write up a tutorial on that to go with the rest of this and change that as the recommended way to deal with launch images.
However before I do that, I’ve emailed Engineering to see if there is some magic we can do where we take some static file like “Default.png” file and magically build the XIB file behind the scenes and inject it in the project for you. If we could do that, it would be the best way to go. So let’s give them time to think about this.
In the mean time I would recommend following this thread’s suggestion if you want to get that tag in the App Store.
Thanks @ingemar and the tutorial with a much better way implementing the xib file using Interface Builder
And thanks @rob for relaying the info to the Engineering team
Although there will be some extra efforts, but for now it is very good to know there’s still options for those (myself included) that wanted th extra classification & App Store tagging.
Now onto teaching myself Interface Builder :wacko: :wacko: :wacko:
[…] if there is some magic we can do where we take some static file like “Default.png” file and magically build the XIB file behind the scenes and inject it in the project for you […]
It a good idea, and it might work. The challenge is how to handle the “bleed-zones” so that the launch image will fill the screen across all aspect ratios. I tried something similar a few weeks ago when I was creating my Launch Screen Files, but I gave up. (admittedly IB-fu isn’t up-to-par with what I’d like it to be :()
Admittedly I have looked at this for all of 10 minutes but there seems to be scale to fill. So iPhone 5-6-6+ can scale, iphone 4 and iPad can scale and cut off at top and bottom?
Edit: Never mind, that didn’t work at all like I expected.
That’s true. Scale-To-Fill works in cases where the size of the objects in the launch screen are not important. However most of the time (for my launch screens anyway) size does matter. The size of the objects in the launch screen need to match the final content size of the Corona scene, in which Scale-To-Fill causes a problem and Scale-To-Fit will not work either for other reasons.
CoronaLabs might find some way to create a useable approach with static images, but I still think the best way to create these is to use Interface Builder directly.
@ingemar, were you having success in having using a Launch Image that is equal to your first screen? I was found out that both never be identically positioned… (don’t think it is a Corona bug, even candy crush shows that problem).
Anyway, Apple recommends that you use your Launch Image as the background of your first scene, not the whole scene. SO, a scale-to-fill would be fine…
I didn’t include all objects as it’s only a launch screen. Just enough to make the user see something is going on.
I had no problem with having these basic objects identical in size between the launch screen and Corona content. I do remember that it took a while before I found a procedure that worked across all devices and aspect ratios. But it is possible.