We currently don't have any machinery for qmake or CMake to map
translations declared via TRANSLATIONS += or qt_add_translations
to the Info.plist CFBundleLocalizations key.
This results in macOS and iOS falling back to the development region,
CFBundleDevelopmentRegion, as the only supported localization of the
app, which is in most cases set to 'en'.
Unfortunately this doesn't work well with the behavior of iOS 11+
and macOS 10.13+ where the OS will set the locale of the app to
the best match between the app's supported localizations and the
user's preferred language.
https://developer.apple.com/library/archive/qa/qa1828/
Since we only support a single localization, the development region,
the locale always ends up as 'en_<REGION>', which after QTBUG-104930
is also reflected in the QLocale's uiLanguages(), resulting in the
QTranslator machinery always picking English translation for the app.
As long as we don't explicitly declare CFBundleLocalizations we need
to opt out of the system's behavior of finding the best match between
the app's declared localizations and the user's preferences, which we
can do via the CFBundleAllowMixedLocalizations key.
Fixes: QTBUG-63324
Pick-to: 6.4
Change-Id: If7586d342148cbbb1d2a152cef039aad4448b13c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The key only applies to macOS bundles. Also, qmake doesn't have it.
Pick-to: 6.4
Task-number: QTBUG-95838
Change-Id: I438f0079cc7b74672dfbe956769138a8bb006669
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
To support per-target iOS launch screens we need a way to specify
custom Info.plist entries without using cache variables, which we were
forced to use due to the implicit configure_file done for
MACOSX_BUNDLE_INFO_PLIST.
We now introduce an extra configure_file call done in a finalizer,
before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST.
This extra configure_file call allows us to insert / substitute
additional Info.plist entries that CMake does not allow setting.
If a custom Info.plist file is provided, the finalizer will simply
skip the logic for creating a new one.
Amends e5b3436255
Pick-to: 6.4
Fixes: QTBUG-101064
Change-Id: I65496da146c9430a949a8163817021d54da28386
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This ensures that the Xcode 'Display name' input under
${target} -> General -> Identity -> Display name is not empty.
Because adding ${PRODUCT_NAME} directly in the Info.plist.in template
will cause CMake to evaluate it as variable expansion, work around the
issue by putting the dollar sign into a separate cache variable that
after evaluation will result in ${PRODUCT_NAME} being in the file
verbatim, so that Xcode evaluate it at build time.
Amends 4d838dae5a
Pick-to: 6.2 6.3
Task-number: QTBUG-95838
Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Bundle a default LaunchScreen.storyboard file for an iOS app and make
sure it's referenced in the generated Info.plist file.
When launching Qt examples, it ensures the app uses the whole screen
space on the device rather than just a square-ish part of it.
The storyboard file is a copy of the qmake one, which qmake adds
to the Xcode projects it generates.
A custom launch screen can be provided either by setting the
QT_IOS_LAUNCH_SCREEN variable or by setting the
QT_IOS_LAUNCH_SCREEN target property.
The value must be an absolute path to the launch screen file.
The automatic addition of the launch screen entry in the Info.plist
file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN
variable to TRUE.
The automatic bundling of the launch screen file in the application
bundle can be prevented by setting the
QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE.
The current implementation has a limitation that only one launch
screen storyboard and one iOS executable can exist within a project.
If there are multiple executables in the project, all of them will
use the launch screen that is specified last (the last
qt_add_executable call).
Because of this limitation, the API is marked as Technical Preview,
to be improved upon in the future. For now it simply serves as an
improvement to the out-of-the-box experience of iOS apps built
with CMake.
Amends 4d838dae5a
Pick-to: 6.2 6.3
Fixes: QTBUG-95837
Change-Id: I6b067d703d635122959a1ef17fcca713da694a86
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It's been deprecated since Mac OS X 10.5.
qmake templates fixed in 0768a28fbf.
Task-number: QTBUG-74872
Pick-to: 6.2
Change-Id: If7d988f27f07b6fa095b2ea51a87c306361d63d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The CFBundleLongVersionString Info.plist entry has been deprecated and
removed from Apple documentation for a long time now.
Remove it.
Pick-to: 6.2
Task-number: QTBUG-95838
Change-Id: I4e4f74e00d678fd67875976c8884a80cdbb8cec4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add an iOS specific plist file like we do for macOS.
If the user hasn't specified a bundle identifier or a development
team id, do what qmake does and query the Xcode preferences file to
pre-populate those if possible.
This allows running
cmake -GXcode ./foo
on a Qt example project and building it with xcodebuild on the
command line without having to go through the IDE to set a development
team id or modifying the example project to add a product
bundle identifier.
Note that the change assumes that the development team id has been
previously set / configured via Xcode. If no such id is found, then
the value will not be set and the user will still have to specify it
either in the project file or via the Xcode UI after the project
has been generated.
Amends 3a2fa3fec5
Pick-to: 6.1
Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
