Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade RoboVM to 2.3.21 and minimumOS version to 12 #7376

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

obigu
Copy link
Contributor

@obigu obigu commented Apr 2, 2024

XCode 15 has dropped support for iOS 11. I've checked on my live games and the game with the higher iOS 11 user share has 0.03% (popular in developing countries amongst young users) and the others have 0.01%. Worth noting as well that no Apple device has iOS 11 as its latest supported OS version.

@Berstanio
Copy link
Contributor

Interesting, that this seems to be no where documented in the XCode release notes, or am I blind?

Is there any issue with staying on iOS 11? From my test it seems to create no problems during build.

@obigu
Copy link
Contributor Author

obigu commented Apr 2, 2024

Interesting, that this seems to be no where documented in the XCode release notes, or am I blind?

Is there any issue with staying on iOS 11? From my test it seems to create no problems during build.

XCode 15 has a minimum deployment target of 12 which is where the minimum OS version is taken on XCode built apps. You can find it on the first paragraph of the release notes: The Xcode 15 release supports on-device debugging in iOS 12 and later (https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes). My understanding is that apps can still be built setting the minOSVersion manually to 11 but can't be tested running/debugging them directly from XCode.

In practice this change has no real impact on existing apps (that's why I wasn't sure if add the Breaking Change tag), it only sets a reasonable default on new Gdx Apps. Several popular 3rd party libraries including AdMob require iOS 12 and I don't expect we test libGDX on iOS 11 from now on. If we add the incredible low user base I think it's the right move.

@Berstanio
Copy link
Contributor

My understanding is that apps can still be built setting the minOSVersion manually to 11 but can't be tested running/debugging them directly from XCode.

Okay, I understand, thank you!

In practice this change has no real impact on existing apps (that's why I wasn't sure if add the Breaking Change tag), it only sets a reasonable default on new Gdx Apps.

Alright, I see! So do we want to still keep minOSVersion 11 in jnigen/ObjectAL for building?

@obigu
Copy link
Contributor Author

obigu commented Apr 3, 2024

Alright, I see! So do we want to still keep minOSVersion 11 in jnigen/ObjectAL for building?

My understanding is that we don't currently set the minOSVersion explicitely for the natives on libGDX config side and we just use the defaults of the jnigen lib right?

If that's the case and we keep this approach, imo it'd make sense to upgrade to a new jnigen with the new default minOS before the next release. Considering we dropped support for iOS 11 on July last year and next libGDX is probably months away it'd be good timing (policy of deprecating 1 version per year is consistent with Apple and Google policy/strategy). But, if you don't want jnigen project to force the default to 12 for some reason then I don't think it's a big deal either and we can always set the minimumOS version manually on libGDX side.

@Berstanio
Copy link
Contributor

My understanding is that we don't currently set the minOSVersion explicitely for the natives on libGDX config side and we just use the defaults of the jnigen lib right?

Correct!

But, if you don't want jnigen project to force the default to 12 for some reason

I think I just don't really like to cut ties/deprecate versions, without an specific reason to do so. E.g. dropping iOS 9 and going to iOS 11 as min version made sense, because we could get rid of the armv7 build/configuration complexity. However, I don't see any complexity/downside for minOS 11 vs minOS 12. It just seems like a restriction, where there doesn't have to be one.

However, since iOS 11 users are very rare as you pointed out, my hesitation is not that high.

@obigu
Copy link
Contributor Author

obigu commented Apr 3, 2024

My understanding is that we don't currently set the minOSVersion explicitely for the natives on libGDX config side and we just use the defaults of the jnigen lib right?

Correct!

But, if you don't want jnigen project to force the default to 12 for some reason

I think I just don't really like to cut ties/deprecate versions, without an specific reason to do so. E.g. dropping iOS 9 and going to iOS 11 as min version made sense, because we could get rid of the armv7 build/configuration complexity. However, I don't see any complexity/downside for minOS 11 vs minOS 12. It just seems like a restriction, where there doesn't have to be one.

However, since iOS 11 users are very rare as you pointed out, my hesitation is not that high.

Fair enough. I wouldn't say there's no specific reason though, trying to support versions not fully supported by Apple itself is a bit risky. It may work for a long time but it may also break something we won't be able to test. I'd rather reduce unnecessary risks for the tiny price of droppping an unused version. In any case, as I said, it's up to you jnigen guys to decide, it doesn't make a difference for this PR (except for the BREAKING CHANGE tag maybe but I'd rather leave it there).

@obigu obigu requested a review from Berstanio April 13, 2024 14:18
Copy link
Contributor

@Berstanio Berstanio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather reduce unnecessary risks for the tiny price of droppping an unused version.

Fair enough I think, iOS 11 is really tiny.

Related jnigen PR can be found here: libgdx/gdx-jnigen#67

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants