SFML community forums

Help => General => Topic started by: jwurzer on April 04, 2018, 10:00:27 pm

Title: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability
Post by: jwurzer on April 04, 2018, 10:00:27 pm
Hi,

I want to compile SFML (and the demo app) for my iPad 3 (armv7, iOS 9.3.5).
I already solved some problems and it runs on the iOS Simulator.

I use the current master branch (from today) and XCode 9.2 and macOS 10.13.3 for XCode.
I used the tutorial „SFML for iOS“ with the iOS.toolchain.cmake file for the upcoming 2.5.0 version. (I have always used the 2.5.0 description instead of the 2.4.2)
https://github.com/SFML/SFML/wiki/Tutorial:-SFML-for-iOS

First I compile SFML and the demo app for the iOS Simulator.
It compiles but the app closed immediately.
It seams like the sfmlMain() was not called. I had included the <SFML/Main.hpp> and have the main() function and I have tried it without the <SFML/Main.hpp> and rename directly from main() to sfmlMain() instead.
I have solved the Problem by removing the libsfml-main-s.a library and instead copy the SFML/src/SFML/Main/MainiOS.mm directly to my iOS subfolder from the SFML demo app.
So the demo app run now perfect on the iOS simulator!

Next challenge is to get the demo app running on my old iPad 3.
There were several problems.
The first problem was that the SFML library was compiled for arm64 only.

$ lipo -info libsfml-graphics-s.a
input file libsfml-graphics-s.a is not a fat file
Non-fat file: libsfml-graphics-s.a is architecture: arm64

I set the iOS Deployment Target to 9.3 and try by Build Settings armv7 for Architectures and Valid Architectures. But armv7 alone doesn’t work. Compiler put an error that arm64 is not possible because only armv7 is valid…

I solved the problem by edit the architecture directly in the iOS.toolchain.cmake from arm64 to armv7.
Now I have the libs for armv7 ;-)

=== 1) Is it possible to create a fat file for armv7 and arm64 (by set both in iOS.toolchain.cmake?) ?

On the SFML demo app I also set the iOS Deployment Target to 9.3 and the arch to armv7.
And now it compiles! But I can’t install/run it on my iPad.

Unable to install “iOS”
“iOS” requires the “metal” capability which is not supported by Jürgen's iPad

It seems like the problem is from the target template iOS Game.
Because wenn I create a new iOS Game Project (without any SFML stuff) and set the iOS Deployment Target to 9.3 and try to run it on my iPad 3 I get the same error message (only the target name „iOS“ is different).

I also have tried another demo app (without sfml). It is an example with cmake (https://github.com/leetal/ios-cmake) and this hello world example works on my iPad 3.

=== 2) Does anybody know which settings must be changed to remove the error message with „Unable to install „iOS“. „iOS“ requires the “metal” capability which is not supported by … iPad“

Best regards
And sorry for my bad English :-)
Title: SOLVED, Re: SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" cap...
Post by: jwurzer on April 05, 2018, 01:11:35 am
Solved ;-)

The problem for "iOS" requires the "metal" capability... was that wenn I create/add the iOS target with the template iOS->Game I didn't change the default value "Metal" for the "Game Technology" :-(

I find no option to change the "Game Technology" after creating the iOS target.
Therefore I create a new "iOS" target with the template iOS->Game and use "SpriteKit" instead of "Metal".

Now the sfml demo app runs on my iPad 3 :-)

Maybe a note/hint should be added at https://github.com/SFML/SFML/wiki/Tutorial:-SFML-for-iOS .

If a old device / old iOS version doesn't support the Metal API but the sfml app should run on it then SpriteKit should be selected for the "Game Technology".
Title: Re: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability
Post by: Ceylo on April 05, 2018, 08:02:01 pm
Hello jwurzer,

You should note that your iPad is unlikely to be supported by the official iOS release if/when it comes out: 32 bits support was recently removed (https://github.com/SFML/SFML/pull/1374) because it is useless for apps that would be submitted to Apple's App Store today.

So you're currently lucky that the dependencies used for the iOS build still contain both 32 & 64 bits ARM architectures. 32 bits ARM data may be removed from these dependencies at any time.
Title: Re: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability
Post by: jwurzer on April 07, 2018, 04:43:00 pm
Hi Ceylo,

thank you for your reply!

I'm not really familiar with apple's app store but is it today not possible to upload an ios app which includes both binaries, armv7 32bit and arm64 64bit?

This would have the benefit to be downward compatible to e.g. iOS 9.0 devices.

Or is it not possible to support old iOS 9.0 devices per app store?

Currently I find many apps for my iPad 3 in the app store.
Can a developer update its app at the app store without losing the compatibility to iOS 9.0?
Title: Re: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability
Post by: Ceylo on April 07, 2018, 06:01:22 pm
https://developer.apple.com/news/?id=06282017b

SFML iOS support is still in development, iOS 11 doesn't support 32 bits ARM anymore, all devices since 2013 or later supports 64 bits. So even if it was possible to also support 32 bits, it's just not worth it.

It's really more a matter of "what's worth it" rather than "what's possible" (at least for now).
Title: Re: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability
Post by: jwurzer on April 07, 2018, 08:16:09 pm
I can understand the decision to only support 64 bit.

But on the other side it would be really nice if an option would exist to simple compile for 32 bit ;-) (e.g. Current XCode supports a development target downward to iOS 8.0)

Maybe a option to compile sfml as an ios fat binary library for armv7 i386 x86_64 arm64 (like the libs in SFML/extlibs/libs-ios are) would be fine ;-)
Title: Re: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability
Post by: Ceylo on April 07, 2018, 10:40:27 pm
Providing an option for it means supporting it. So if it's not supported, then no option for it. Both must come together. Even if I understand that it is annoying for people with "old" devices.