feat: Support for Apple tvOS and Apple visionOS.

[atteneder]

With this patch it's possible to compile against tvOS and visionOS SDKs.

Similar to iOS:

• ktx/ktx_read default to Framework
• ktx/ktx_read default to library type STATIC
• Tools and test targets are disabled
• Bit-code embedding can be enabled via KTX_EMBED_BITCODE

Differences to iOS:

• It's possible to build a dynamic/shared library (via KTX_FEATURE_STATIC_LIBRARY=OFF).

I cannot remember why the library type was restricted to STATIC for iOS, as it compiles just fine. I haven't tested the resulting framework though. Could it be that (only) the loadtest apps require a static library? Not part of this PR, but maybe that restriction could be lifted off of iOS as well?

Thanks for reviewing!

[MarkCallow]

I cannot remember why the library type was restricted to STATIC for iOS, as it compiles just fine.

As I understand it App Store submission will fail if the app has dylibs within its bundle. Have to be static or frameworks. There is no advantage to using dylibs or frameworks on iOS as they cannot be shared with other applications. Lastly with a static library there is one less thing that needs signing.

I suspect most or all of the above apply to tvOS and visionOS too. What do you think?

The VulkanSDK was recently changed to provide Vulkan loader and MoltenVK "dynamic frameworks" to be included in app bundles because of the App Store restriction. I will wait until I update the loadtests to that SDK before considering creating a similar framework for libktx.

[MarkCallow]

One question, what does the VAR in APPLE_VAR_OS stand for?

[atteneder]

I cannot remember why the library type was restricted to STATIC for iOS, as it compiles just fine.

As I understand it App Store submission will fail if the app has dylibs within its bundle. Have to be static or frameworks. There is no advantage to using dylibs or frameworks on iOS as they cannot be shared with other applications. Lastly with a static library there is one less thing that needs signing.

I suspect most or all of the above apply to tvOS and visionOS too. What do you think?

Most certainly. They are all very similar. I'll keep things as-is, so default is static and experienced users are able to create dynamic frameworks this way. In a future update (for example when you do that MoltenVK update) we could lift the limitation on iOS as well.

Thanks for explaining.

[atteneder]

One question, what does the VAR in APPLE_VAR_OS stand for?

That's just poor variable naming, for the lack of a better idea. Let's find a better one:

1. APPLE_NON_MAC_OS: Easy to read, but I prefer names to explain the actual thing instead of what it's not.
2. APPLE_IOS_TVOS_VISIONOS: A bit verbose, but most descriptive
3. APPLE_MOBILE_OS: Stationary tvOS does not really fit that description.

Out of those I'd prefer APPLE_IOS_TVOS_VISIONOS, but feel free to make suggestions and pick something else.

[MarkCallow]

Most certainly. They are all very similar. I'll keep things as-is, so default is static and experienced users are able to create dynamic frameworks this way.

How do experienced users create a dynamic framework? MACOSX_BUNDLE is not set in the libktx target.

[MarkCallow]

Out of those I'd prefer APPLE_IOS_TVOS_VISIONOS, but feel free to make suggestions and pick something else.

My concern with this name, besides its length, is what if they come up with another OS. Some random thoughts: APPLE_LOCKED_OS, APPLE_DEVICE_OS, APPLE_APPLIANCE_OS.

[atteneder]

Most certainly. They are all very similar. I'll keep things as-is, so default is static and experienced users are able to create dynamic frameworks this way.

How do experienced users create a dynamic framework? MACOSX_BUNDLE is not set in the libktx target.

Bundle (for executable targets) is not related to frameworks. The CMake setup defaults to frameworks:

if(APPLE_VAR_OS)
    set_target_properties(${target} PROPERTIES
        FRAMEWORK TRUE
    )
endif()

The only thing left to do for a user is to set -DKTX_FEATURE_STATIC_LIBRARY=OFF.

[atteneder]

My concern with this name, besides its length, is what if they come up with another OS. Some random thoughts: APPLE_LOCKED_OS, APPLE_DEVICE_OS, APPLE_APPLIANCE_OS.

I love the subtle statement in APPLE_LOCKED_OS, so let's go with it 😄