summaryrefslogtreecommitdiffstats
path: root/mkspecs/macx-ios-clang/Info.plist.app
Commit message (Collapse)AuthorAgeFilesLines
* Apple: Add CFBundleAllowMixedLocalizations=YES to Info.plist filesTor Arne Vestbø2022-10-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* qmake: Align iOS Info.plist file with the CMake oneAlexandru Croitor2022-08-251-6/+3
| | | | | | | | | | | | | Remove keys that are not needed: CFBundleSignature and LSRequiresIPhoneOS. Add CFBundleDevelopmentRegion, which is added by default in new Xcode projects. Pick-to: 6.4 Task-number: QTBUG-95838 Change-Id: I090c14561bc812ec255f55001b658d2dc60e11f3 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* qmake: Reformat mkspecs/macx-ios-clang/Info.plist.appAlexandru Croitor2022-08-251-33/+46
| | | | | | | | | | Replace tabs with spaces. Add some newlines. Pick-to: 6.4 Task-number: QTBUG-95838 Change-Id: I0fa0e7b74590e7a093d22de85e24d4456ece4a63 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* iOS: Add a variable to customize where the launch image is taken fromAndy Shaw2020-07-221-1/+1
| | | | | | | | | | | | | For those who are providing their own launch images for their iOS projects then QMAKE_IOS_LAUNCH_SCREEN can be set to point to the location where the launch image to be used over the default. [ChangeLog][Platform Specific Changes][iOS] Added support for specifying a launch image to be used for an iOS project. This can be achieved by using QMAKE_IOS_LAUNCH_SCREEN. Change-Id: Ibb236655b282132ab5eee747986a93abb9802200 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove CFBundleGetInfoString from Info.plist templatesTor Arne Vestbø2019-10-041-2/+0
| | | | | | | | | | Is't been deprecated since Mac OS X 10.5. Task-number: QTBUG-74872 Change-Id: I8b1ad7aca6448883cb164fd0c4b329592ca60548 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Rewrite the Info.plist variable replacement handlingJake Petroules2018-01-061-6/+8
| | | | | | | | | | This ensures that the same set of variables can be successfully replaced in both the Makefile and Xcode generators. It also switches the default templates to use the Xcode-style ${var} syntax instead of the @var@ syntax for better Info.plist compatibility across generators. Change-Id: Iff330bafd152773aafac9143c4a34e34f92f0ce6 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Sort keys in Info.plist templatesJake Petroules2017-08-081-12/+12
| | | | | | | | This makes editing the templates easier since they can be read alphabetically. Change-Id: I6af5e4f13718ba1145c2dec1f8a05bc600ea937a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove exec bits from files that should not be executableDmitry Shachnev2015-06-071-0/+0
| | | | | | | Change-Id: I66f49c6db82eadc3b11cc9b1cf01375e9596a8e6 Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Mark Brand <mabrand@mabrand.nl>
* iOS: let qmake generate default LaunchScreen.xibRichard Moe Gustavsen2014-11-111-0/+2
| | | | | | | | | | | | | | iOS8 will check if the app has a LaunchScreen.xib to determine if it supports iPhone6/6+ (scale factor and resolution). So we follow the same pattern as we do with the launch image for iPhone5, and generate a default LaunchScreen.xib. The xib file in this patch is a copy of a default file generated by a native Xcode project (with quotes escaped), but with the text label set to be $$TARGET. Change-Id: I163ab48b6f4edea4cc1f6840a1f3d8b3cc0326db Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Set up default Info.plist to support all interface orientationsTor Arne Vestbø2014-10-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the UISupportedInterfaceOrientations key is missing, iOS will start up the application in the orientation defined by UIInterfaceOrientation, and if that key is also missing, it will default to portrait orientation. Unfortunately, when the application has finished launching on an iPad, there is no way to re-evaluate the current device orientation unless the user actively rotates the device, so for example if the device is physically in landscape orientation, and the application is started up in portrait, the application will not auto-rotate to landscape after starting up. It would seem that [UIViewController attemptRotationToDeviceOrientation] would be the right API to do this, but even after telling the device to beginGeneratingDeviceOrientationNotifications the device orientation will still match the startup orientation until the device is physically rotated. For iPod/iPhones this is not an issue, as the OS will update the device orientation after startup. Presumably the difference in behavior between the two device classes is due to the iPad supporting any orientation for the application grid. Since we would prefer the application to either start up in the right orientation directly, or at least rotate to it after startup, and the latter can't be done, we apply UIInterfaceOrientationMaskAll to the Info.plist file. This also has the benefit that the application will show any splash screens in the right orientation. Change-Id: If0421bc7b82b7f14a510fa1f34eac4f6407f570f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Add missing LSRequiresIPhoneOS field to Info.plistCaroline Chao2014-09-231-0/+2
| | | | | | | This field specifies whether the app is an iOS app. Change-Id: I38cfcbec97b32f517a14a9a34f1eb871b9fa1ef7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* qmake: Pick up default bundle prefix from Xcode preferencesTor Arne Vestbø2013-10-311-1/+1
| | | | | | | | | But still fall back to 'com.yourcompany', just like Xcode does for the initial launch. Change-Id: I89afadefafc254a0014aca197741d42a0199943e Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Move iOS makespec out of unsupported directoryTor Arne Vestbø2013-09-121-0/+28
It's a supported platform from 5.2, and we want build-scripts/CI/etc to adapt to the change as soon as possible. Change-Id: I8c78351191f59a6ecab33acc0829d2535379c787 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com> Reviewed-by: Simo Fält <simo.falt@digia.com>