IOS 8 progress

Hello ,

What is the state of IOS 8 support has anyone tried it so far ?
I tried a few months ago and it was doing all kinds of crazy stuff in Xcode
6 so I reverted back to Xcode 5.

Thanks,

Alex

It works for me. However, SDL is lacking support for iOS 8’s new
LaunchScreen NIBs. This is the only way to get the “Optimized for
iPhone 6 and iPhone 6 Plus” badge (unlock achievement, har har) on the
App Store as far as I can tell. I’m also noticing that SDL’s existing
launch image support doesn’t fully conform with iOS 7 Info.plist
rules.

I wrote a patch that adds support for iOS 8 LaunchScreen NIBs. I’m
really behind on things (thanks to 4 unrelated hard drive failures in
a month), but I’m hoping to post a bunch of things later this week or
next week.

Thanks,
EricOn 11/5/14, Alexander Chaliovski wrote:

Hello ,

What is the state of IOS 8 support has anyone tried it so far ?
I tried a few months ago and it was doing all kinds of crazy stuff in Xcode
6 so I reverted back to Xcode 5.

Thanks,

Alex


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Nice work !
I can test it when you are done.
Have you tested on actual device ?On Wed, Nov 5, 2014 at 11:53 AM, Eric Wing wrote:

On 11/5/14, Alexander Chaliovski <@Alexander_Chaliovski> wrote:

Hello ,

What is the state of IOS 8 support has anyone tried it so far ?
I tried a few months ago and it was doing all kinds of crazy stuff in
Xcode
6 so I reverted back to Xcode 5.

Thanks,

Alex

It works for me. However, SDL is lacking support for iOS 8’s new
LaunchScreen NIBs. This is the only way to get the “Optimized for
iPhone 6 and iPhone 6 Plus” badge (unlock achievement, har har) on the
App Store as far as I can tell. I’m also noticing that SDL’s existing
launch image support doesn’t fully conform with iOS 7 Info.plist
rules.

I wrote a patch that adds support for iOS 8 LaunchScreen NIBs. I’m
really behind on things (thanks to 4 unrelated hard drive failures in
a month), but I’m hoping to post a bunch of things later this week or
next week.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I guess this is a good time to mention that I have a fork[1] of SDL with many improvements and fixes to the iOS backend. It might need a bit more testing before it?s ready to be merged into mainline SDL, but that?s my intention.

Here?s an incomplete changelog:

  • Retina resolutions are handled like they are in OS X (via the SDL_WINDOW_ALLOW_HIGHDPI flag.)
  • The UIKit backend uses ARC instead of manual reference counting.
  • Updated a lot of UIKit code to use cleaner and more modern Objective-C.
  • Fixed several rotation/orientation and fullscreen-related bugs, especially on iOS 7+.
  • Fixed many memory leaks by adding missing autorelease pool blocks to the UIKit code.
  • Removed the custom iOS splashscreen code, since it was causing several rotation bugs and it didn?t support newer iOS devices and versions.
  • The SDL_HINT_ACCELEROMETER_AS_JOYSTICK hint is respected on iOS.
  • Added iOS support for sRGB OpenGL contexts.
  • Added support for native-resolution rendering (when ALLOW_HIGHDPI is enabled) on the iPhone 6 Plus ? i.e. 1080x1920 rather than 1242x2208.
  • Added iOS-specific SDL_iPhoneGetViewRenderbuffer and SDL_iPhoneGetViewFramebuffer functions.

Feedback is appreciated, especially with the new functions I added. I?m not sure if they should exist, especially if I eventually add MSAA support to OpenGL contexts on iOS (since that needs a separate ?resolve? framebuffer and renderbuffer.)

[1]: https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvementsOn Nov 5, 2014, at 7:02 AM, Alexander Chaliovski wrote:

Hello ,

What is the state of IOS 8 support has anyone tried it so far ?
I tried a few months ago and it was doing all kinds of crazy stuff in Xcode 6 so I reverted back to Xcode 5.

Thanks,

Alex


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That is a really good long waited update. Is it worth testing on IOS 7 and
8 ?On Wed, Nov 5, 2014 at 6:46 PM, Alex Szpakowski wrote:

I guess this is a good time to mention that I have a fork1 of SDL with
many improvements and fixes to the iOS backend. It might need a bit more
testing before it?s ready to be merged into mainline SDL, but that?s my
intention.

Here?s an incomplete changelog:

  • Retina resolutions are handled like they are in OS X (via the
    SDL_WINDOW_ALLOW_HIGHDPI flag.)
  • The UIKit backend uses ARC instead of manual reference counting.
  • Updated a lot of UIKit code to use cleaner and more modern Objective-C.
  • Fixed several rotation/orientation and fullscreen-related bugs,
    especially on iOS 7+.
  • Fixed many memory leaks by adding missing autorelease pool blocks to
    the UIKit code.
  • Removed the custom iOS splashscreen code, since it was causing several
    rotation bugs and it didn?t support newer iOS devices and versions.
  • The SDL_HINT_ACCELEROMETER_AS_JOYSTICK hint is respected on iOS.
  • Added iOS support for sRGB OpenGL contexts.
  • Added support for native-resolution rendering (when ALLOW_HIGHDPI is
    enabled) on the iPhone 6 Plus ? i.e. 1080x1920 rather than 1242x2208.
  • Added iOS-specific SDL_iPhoneGetViewRenderbuffer and
    SDL_iPhoneGetViewFramebuffer functions.

Feedback is appreciated, especially with the new functions I added. I?m
not sure if they should exist, especially if I eventually add MSAA support
to OpenGL contexts on iOS (since that needs a separate ?resolve?
framebuffer and renderbuffer.)

On Nov 5, 2014, at 7:02 AM, Alexander Chaliovski <@Alexander_Chaliovski> wrote:

Hello ,

What is the state of IOS 8 support has anyone tried it so far ?
I tried a few months ago and it was doing all kinds of crazy stuff in
Xcode 6 so I reverted back to Xcode 5.

Thanks,

Alex


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Oh Nice! Good Work! :slight_smile:
does your improvements include Virtual Keyboard with variable height support?------------------------
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com

Wow, very impressive. But, wait, no Metal backend for the SDL 2D
renderer? Ha ha.

We’re going to have to resolve the differences for the launch screen
code. My patch’s behavior adds new behavior only if iOS 8 is detected
at runtime, and then falls back to legacy behavior.

Thanks,
EricOn 11/5/14, Alex Szpakowski wrote:

I guess this is a good time to mention that I have a fork1 of SDL with
many improvements and fixes to the iOS backend. It might need a bit more
testing before it’s ready to be merged into mainline SDL, but that’s my
intention.

Here’s an incomplete changelog:

  • Retina resolutions are handled like they are in OS X (via the
    SDL_WINDOW_ALLOW_HIGHDPI flag.)
  • The UIKit backend uses ARC instead of manual reference counting.
  • Updated a lot of UIKit code to use cleaner and more modern Objective-C.
  • Fixed several rotation/orientation and fullscreen-related bugs,
    especially on iOS 7+.
  • Fixed many memory leaks by adding missing autorelease pool blocks to the
    UIKit code.
  • Removed the custom iOS splashscreen code, since it was causing several
    rotation bugs and it didn’t support newer iOS devices and versions.
  • The SDL_HINT_ACCELEROMETER_AS_JOYSTICK hint is respected on iOS.
  • Added iOS support for sRGB OpenGL contexts.
  • Added support for native-resolution rendering (when ALLOW_HIGHDPI is
    enabled) on the iPhone 6 Plus - i.e. 1080x1920 rather than 1242x2208.
  • Added iOS-specific SDL_iPhoneGetViewRenderbuffer and
    SDL_iPhoneGetViewFramebuffer functions.

Feedback is appreciated, especially with the new functions I added. I’m not
sure if they should exist, especially if I eventually add MSAA support to
OpenGL contexts on iOS (since that needs a separate ‘resolve’ framebuffer
and renderbuffer.)


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Sorry for the delay. I finally posted everything and submitted the
bug. I did not test on a real device, but went through all the
permutations of the iOS Simulator available to me. I did see behavior
differences between iOS 8 simulator and iOS 7 simulator so I have
confidence they are representative in this case. But real device
testing (and additional testing) is welcome.

Here is the Bugzilla link and the copy of the body is inline below.

I have a pull request for support for iOS 8’s new LaunchScreen NIBs.
Apple changed their way of handling it yet again. Their motivation was
that it is getting unwieldy to provide so many different launch screen
permutations for every device and orientation. Their "Autolayout"
system can handle this in a simplified/unified way, so for iOS 8, this
is the new way to do it.

Furthermore, this is the only way to get the “Optimized for iPhone 6
and iPhone 6 Plus” badge on the App Store as far as I can tell. So
this patch is necessary.

This normally should be automatically handled by the operating system,
but because SDL reverse-engineers and reinvents the CocoaTouch launch
and run loop, SDL doesn’t inherit this new behavior.

This patch uses the old launch screen handling code as a starting
point. It mirrors the original technique, i.e. creates a new class to
handle it. To not break legacy behavior, a runtime check is done for
iOS 8 or greater.

Additionally, this patch conforms to Apple rules of behavior. This
only kicks in if the user has made an entry in their Info.plist.
They must specify the key UILaunchStoryboardName and supply the name
of the NIB/XIB file (without the extension).
Example:
UILaunchStoryboardName
LaunchScreen

Presumably, the NIB/XIB is already correctly made with AutoLayout for
their launch screen.

Omitting the Info.plist setting will then revert to legacy behavior.
The code will result in Cocoa throwing an exception if the Info.plist
specifies the key, but the corresponding nib does not exist.

Additional note:
I noticed the legacy iOS 7 behavior does not conform to the rules
Apple has in their documentation. iOS 7 is supposed to allow you to
manually specify launch screens for different resolutions, devices,
and orientations, but SDL lacks this code. I consider this a bug and
was scratching my head for a really long time. While it would be good
to fix, the rate of latest iOS adoption may render the need for that
obsolete within 3 months.

Furthermore, AutoLayout does technically work on iOS 7. It might be
possible to activate this new iOS 8 behavior for iOS 7. However, some
people might be surprised if we do this.

Testing notes:
I tested on all the different permutations of devices on the iOS
Simulator for both iOS 8 and 7, to verify that both the Launch Screen
was working on iOS 8, and the legacy path was taken on 7.

I did not test on a real device though. (Key signing problems at the moment.)

Thanks,
EricOn 11/5/14, Alexander Chaliovski wrote:

Nice work !
I can test it when you are done.
Have you tested on actual device ?


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

The new Storyboard/XIB method is just one way to get native iPhone 6 / 6 Plus support, I believe. The other way is to provide appropriately-sized launch image files in your app?s Xcode project ? just like you?d do for older iOS devices and versions.

I?ve successfully used launch images sized for the iPhone 6 Plus in order for my app to use the proper resolution (1242x2208 @3x, and native 1080x1920 on the device.)On Nov 20, 2014, at 8:16 PM, Eric Wing wrote:

I have a pull request for support for iOS 8’s new LaunchScreen NIBs.
Apple changed their way of handling it yet again. Their motivation was
that it is getting unwieldy to provide so many different launch screen
permutations for every device and orientation. Their "Autolayout"
system can handle this in a simplified/unified way, so for iOS 8, this
is the new way to do it.

Furthermore, this is the only way to get the “Optimized for iPhone 6
and iPhone 6 Plus” badge on the App Store as far as I can tell. So
this patch is necessary.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If I ever get an iOS device that supports Metal then I do want to add CAMetalLayer support for SDL windows on iOS, at least. I can?t do that right now, though. :slight_smile:

One of the reasons I removed the faux splash image code is because it caused really nasty rotation bugs. We?ll have to make sure that doesn?t happen with your new code.On Nov 20, 2014, at 8:13 PM, Eric Wing wrote:

Wow, very impressive. But, wait, no Metal backend for the SDL 2D
renderer? Ha ha.

We’re going to have to resolve the differences for the launch screen
code. My patch’s behavior adds new behavior only if iOS 8 is detected
at runtime, and then falls back to legacy behavior.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

To be clear, I’m talking about the footnote on the App Store. You can
make an app that runs fine without the LaunchScreen NIB on iPhone 6
and 6 Plus. But from everything I’ve found, the only way to get that
badge/footnote that says “Optimized for iPhone 6 and iPhone 6 Plus” is
to use the LaunchScreen NIB system. As far as I can tell, using the
legacy system is not sufficient in getting the badge.

Thanks,
EricOn 11/20/14, Alex Szpakowski wrote:

The new Storyboard/XIB method is just one way to get native iPhone 6 / 6
Plus support, I believe. The other way is to provide appropriately-sized
launch image files in your app’s Xcode project - just like you’d do for
older iOS devices and versions.


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

I understand what you?re saying, but I don?t think it?s correct. iOS just needs to understand that the app can support the iPhone 6 / 6 Plus resolutions, and then it will give the correct resolutions at runtime and the App Store will tell users that it?s supported. Having appropriately-sized standard launch images should accomplish this.

I believe Unity still uses the standard/old launch image system, and recent versions do export apps that fully support the iPhone 6 Plus (including the notice on App Store pages.)

The Apple HIG page says:
"You use a launch XIB or storyboard file to indicate that your app runs on iPhone 6 Plus or iPhone 6.?
"Although it?s best to use a launch file for iPhone 6 and iPhone 6 Plus, you can instead supply static launch images if necessary.?

i.e. the first sentence doesn?t exclude static launch images from being used to indicate iPhone 6 Plus support, it just says what the XIB/storyboard can do.On Nov 20, 2014, at 8:36 PM, Eric Wing wrote:

To be clear, I’m talking about the footnote on the App Store. You can
make an app that runs fine without the LaunchScreen NIB on iPhone 6
and 6 Plus. But from everything I’ve found, the only way to get that
badge/footnote that says “Optimized for iPhone 6 and iPhone 6 Plus” is
to use the LaunchScreen NIB system. As far as I can tell, using the
legacy system is not sufficient in getting the badge.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Actually I just read a bunch of posts by users on the Apple developer forums saying the same thing as you ? it looks like I was wrong. Sorry for the noise!On Nov 20, 2014, at 8:50 PM, Alex Szpakowski <@Alex_Szpakowski> wrote:

[?]

On Nov 20, 2014, at 8:36 PM, Eric Wing wrote:

To be clear, I’m talking about the footnote on the App Store. You can
make an app that runs fine without the LaunchScreen NIB on iPhone 6
and 6 Plus. But from everything I’ve found, the only way to get that
badge/footnote that says “Optimized for iPhone 6 and iPhone 6 Plus” is
to use the LaunchScreen NIB system. As far as I can tell, using the
legacy system is not sufficient in getting the badge.

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

If you sign into Apple Developer Forums and search for the string,
every thread says the NIB is required (including complaints about the
policy).

Additionally, the Corona forums have this long thread that confirms
with their own experience.

Thanks,
EricOn 11/20/14, Alex Szpakowski wrote:

I understand what you’re saying, but I don’t think it’s correct. iOS just
needs to understand that the app can support the iPhone 6 / 6 Plus
resolutions, and then it will give the correct resolutions at runtime and
the App Store will tell users that it’s supported. Having
appropriately-sized standard launch images should accomplish this.


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

No problem.On 11/20/14, Alex Szpakowski wrote:

Actually I just read a bunch of posts by users on the Apple developer forums
saying the same thing as you - it looks like I was wrong. Sorry for the
noise!

Next question: is any custom code even necessary to support Launch Screen storyboards? I just created a new one in Xcode and set one of the SDL demos for iOS to use it, and it worked as expected in the Simulator without any new code in SDL.

(I am using my branch of SDL which doesn?t have the old buggy faux-splashscreen code.)On Nov 20, 2014, at 9:02 PM, Eric Wing wrote:

No problem.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I don’t know. I was based on the main branch. And without my code, it
definitely did not work. Since the pre-iOS 7 and iOS 7 behavior (I had
an explicit Info.plist for all the different types) didn’t work, I
assumed iOS 8 wouldn’t work either. But I didn’t think of trying it.

But either way, I still need the legacy pre-iOS 8 behavior to kick in
on older OSes, so I think the patch needs to stand. (As noted, we
could try to extend the new LaunchScreen behavior to iOS 7, but that
means we need this code still.)

Thanks,
EricOn 11/20/14, Alex Szpakowski wrote:

Next question: is any custom code even necessary to support Launch Screen
storyboards? I just created a new one in Xcode and set one of the SDL demos
for iOS to use it, and it worked as expected in the Simulator without any
new code in SDL.

(I am using my branch of SDL which doesn’t have the old buggy
faux-splashscreen code.)


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

I should mention that I?ve been using standard launch images (Images.xcassets, etc.) fine as well with no code for it at all in SDL. The only reason the faux splash image code was in SDL in the first place was to keep the regular launch image displayed for longer than normal.

Since that?s now gone (in my branch), launch images are now completely out of SDL?s domain/scope. They seem to work fine with no code in SDL and SDL doesn?t need to touch them, just like app icon images.

To get launch images working pre-iOS 8, you?ll just need to supply the properly-sized images via an Xcode icon set ? it becomes part of the Xcode project?s build configuration file, rather than code in SDL.On Nov 20, 2014, at 10:14 PM, Eric Wing wrote:

I don’t know. I was based on the main branch. And without my code, it
definitely did not work. Since the pre-iOS 7 and iOS 7 behavior (I had
an explicit Info.plist for all the different types) didn’t work, I
assumed iOS 8 wouldn’t work either. But I didn’t think of trying it.

But either way, I still need the legacy pre-iOS 8 behavior to kick in
on older OSes, so I think the patch needs to stand. (As noted, we
could try to extend the new LaunchScreen behavior to iOS 7, but that
means we need this code still.)

Thanks,
Eric


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hey Alex,

Just a quick question because I am using game engine with dependency to SDL
which is currently failing for IOS 8 . I was thinking of using your branch
of SDL as it is more compatible to IOS 8 . But I am not sure have you
changed any high level stuff like name of the functions or files. Is
everything fully compatible between your changes and SDL 2.0.3 ?On Fri, Nov 21, 2014 at 2:31 AM, Alex Szpakowski wrote:

I should mention that I?ve been using standard launch images
(Images.xcassets, etc.) fine as well with no code for it at all in SDL. The
only reason the faux splash image code was in SDL in the first place was to
keep the regular launch image displayed for longer than normal.

Since that?s now gone (in my branch), launch images are now completely out
of SDL?s domain/scope. They seem to work fine with no code in SDL and SDL
doesn?t need to touch them, just like app icon images.

To get launch images working pre-iOS 8, you?ll just need to supply the
properly-sized images via an Xcode icon set ? it becomes part of the Xcode
project?s build configuration file, rather than code in SDL.

On Nov 20, 2014, at 10:14 PM, Eric Wing wrote:

I don’t know. I was based on the main branch. And without my code, it
definitely did not work. Since the pre-iOS 7 and iOS 7 behavior (I had
an explicit Info.plist for all the different types) didn’t work, I
assumed iOS 8 wouldn’t work either. But I didn’t think of trying it.

But either way, I still need the legacy pre-iOS 8 behavior to kick in
on older OSes, so I think the patch needs to stand. (As noted, we
could try to extend the new LaunchScreen behavior to iOS 7, but that
means we need this code still.)

Thanks,
Eric


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I haven?t changed any public SDL APIs compared to the current SDL 2.0.4 / mercurial version. The biggest non-bugfix change to functionality is that SDL_CreateWindow now only enables Retina-resolution if the SDL_WINDOW_ALLOW_HIGHDPI flag is used, and once it?s enabled you?ll need to use SDL_GL_GetDrawableSize (or SDL_GetRendererOutputSize if you?re using the SDL_Render API) to get the size of the drawable in pixels. SDL_GetWindowSize and the active video display modes now always give their sizes in ?points? rather than pixels.

Both the official Mercurial / 2.0.4 version of SDL for iOS and my branch also require you to link your app with the CoreMotion framework, which you didn?t need to do in SDL 2.0.3.On Nov 30, 2014, at 8:16 PM, Alexander Chaliovski wrote:

Hey Alex,

Just a quick question because I am using game engine with dependency to SDL which is currently failing for IOS 8 . I was thinking of using your branch of SDL as it is more compatible to IOS 8 . But I am not sure have you changed any high level stuff like name of the functions or files. Is everything fully compatible between your changes and SDL 2.0.3 ?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org