public enum IosXcodeVersion
- Object
- Enum<IosXcodeVersion>
- IosXcodeVersion
ImplementsComparable<IosXcodeVersion>
Which Xcode the build server compiles an iOS build with.
The constants are the majors a current build server image carries. That
domain belongs to the image rather than to this framework, so it moves on
its own schedule and this enum can only follow at the pace of a release –
which is why leaving the attribute unset is the normal thing to do, and why
a version outside this set is still reachable through a plain
codename1.arg.ios.xcode_version=<version> line in
codenameone_settings.properties. That is not a conflict: an attribute left
at DEFAULT writes nothing, so there is no second declaration to clash
with.
A minor version is the same story – the builder accepts 27.1 and this
cannot spell it. The constants cover the case that is worth type checking,
which is naming a whole major the servers do not have.
The pre-26 values this hint once took – 12.4, 11.3 and the Xcode 7 to
10 chain before them – are deliberately absent. They name Xcodes that no
current build server installs, so offering them as typed constants would
promise a selection that cannot happen. A project still carrying one of them
in its properties file keeps whatever it has always built with.
Enum constants
DEFAULT | Say nothing, and let the build server choose. |
XCODE26 | Xcode 26. |
XCODE27 | Xcode 27. |
Methods
public static IosXcodeVersion[] values() | |
public static IosXcodeVersion valueOf(String name) |
Inherited methods
Enum constant details
DEFAULT
DEFAULTSay nothing, and let the build server choose.
It prefers its own default and falls back to the newest Xcode it actually carries, so a server that has not been re-imaged keeps building and logs which Xcode it used. This is the right answer for almost every application: pinning a version opts out of that fallback.
XCODE26
XCODE26XCODE27
XCODE27Method details
values
public static IosXcodeVersion[] values()valueOf
public static IosXcodeVersion valueOf(String name)