Location Permission Popup does not use CFBundleSpokenName - ios

When asking the user for access to his/her location using the CLLocationManager subscribeToAuthorizationStatus method, a system alert dialog is shown with the title "Allow <'appname'> to access your location?"
When using the accessibility voiceover for such a system alertview, the appname that is pronounced seems to be the CFBundleDisplayName and not the CFBundleSpokenName.
Is there any way to get the voiceover to pronounce the appname with the CFBundleSpokenName text?

Is there any way to get the voiceover to pronounce the appname with the CFBundleSpokenName text?
That's definitely what the CFBundleSpokenName is made for: if there's a native component that doesn't abide by this rule, I strongly recommend to open a radar in order to bring a solution as soon as possible.
About this key, the Apple documentation states:
CFBundleSpokenName (String - iOS, macOS) contains a suitable replacement for the app name when performing text-to-speech operations. Include this key in your app bundle when the spelling of your app might be mispronounced by the speech system. For example, if the name of your app is “MyApp123”, you might set the value of this key to “My app one two three”.
If your appname isn't spelled out as you wish with VoiceOver, the CFBundleSpokenName should do the job wherever you are on your device: if your problem still exists in iOS 13, that's definitely a bug that should be reported.
⚠️ ⬛️◼️🔳▪️ EDIT ▪️🔳◼️⬛️ ⚠️ (2020/04/03)
I wrote a Developer Technical Support Incident (no 732724589) for this question and the Apple's answer admits that's a problem they can't provide a solution.
I submitted a bug report entitled VoiceOver: the location Permission Popup does not use CFBundleSpokenName with the reference FB7650152 in order to have a solution as soon as possible.
Now, you know why the Location Permission Popup does not use CFBundleSpokenName. 😥

Related

Siri reading CFBundleName instead of CFBundleDisplayName when using INSendPaymentIntent

We are facing some weird case when sending money via Siri, as it doesn't spell the app name defined in CFBundleDisplayName, so it does the one defined in CFBundleName on iOS > 14.0
First let me introduce the scenario to reproduce this.
Have 2+ Apps installed that offers the Send Money functionality via Siri.
Enable Siri via "Hey Siri" activation and ask to "Send Money"
When Siri asks you what app do you want to use and spells their name, is using the one defined in CFBundleName, but the name displayed in the screen is the one defined in CFBundleDisplayName
We tried the same scenario on iOS13 and iOS12 and both spells the correct CFBundleDisplayName.
We didn't find any related change to this on iOS14 or Xcode12 changelogs, so not sure if this is a bug or what.
Changing the CFBundleName (which points to $(PRODUCT_NAME) right now) solves the issue, but that's a change that we don't want to do, since could add us some extra problems we don't expect.
Does anyone experienced this issue, and is there another way to fix it that is not changing the CFBundleName?
Thanks

SiriKit INSearchForAccountsIntent not using CFBundleSpokenName for app name pronunciation

I have a SiriKit extension in my iOS app that uses the INSearchForAccountsIntent to display account balances via the Siri interface. However, Siri pronounces the app name incorrectly and when given the correct pronunciation via setting the CFBundleSpokenName in the property list, Siri still uses the CFBundleDisplayName instead. I've seen this pointed out as a bug on Apple's side in a forum, but that was reported over 2 years ago and I'm wondering if anyone else has run into this and found a workaround?

Are voice shortcuts for custom SiriKit Intents supported on watchOS?

I’m trying to get a voice shortcut for a custom Siri Intent working as part of an Apple Watch app, but I’m not sure whether that’s possible. Has anyone had success with this or know if it’s supported?
There isn't much code to share in this case, since most of the code is auto-generated by Xcode, but here’s a quick overview of how I have everything set up.
I created a custom Intent with a .intentdefiniton file and separate Intents Extension targets for my iOS app and watchOS app to handle the Intent.
I set up and donate the shortcuts at the appropriate time. I included an INUIAddVoiceShortcutButton in my app so a user can easily add or edit a phrase for the shortcut.
Everything works fine on an iPhone: the shortcut shows up at relevant times throughout iOS, and the Intents Extension in my iOS app handles the shortcut when I say the invocation phrase to Siri.
Since 20% of my app’s users use the Apple Watch app, I want to provide a congruent experience on watchOS. The donated shortcut shows up on the Siri watch face, as expected. I trigger the shortcut from the Siri watch face, and is handled by the Intents Extension that's part of my watchOS app.
When I say the intent’s invocation phrase to my Apple Watch (Series 3 GPS-only), however, it doesn’t work. Siri says:
Checking with the app...
Then a few seconds later:
I do not recognize that command.
I’ve tried this with a separate Intents Extension for my watchOS app, and without. I get the same results in both situations. It works on the simulator, but not on a real device.
I’ve also made sure I have my Watch Extension and Watch App selected under Target Membership for the .intentdefinition file.
I’ve also tried going into Settings > Developer and enabling Display Recent Shortcuts then tapping Force Sync Shortcuts to Watch, but that doesn’t change the behavior.
Are voice shortcuts for these custom intents even supported on Apple Watch? I haven’t been able to tell one way or another with Apple’s documentation. The SoupChef sample project is set up with an Intents Extension for the watchOS app, which makes me think it should be supported. And, since it works on the simulator, that makes me think it should be supported.
However, this page doesn’t list custom intents as being supported on watchOS, so that makes me think they may not be supported: https://developer.apple.com/design/human-interface-guidelines/watchos/user-interaction/siri/
If anyone can help me figure out whether this is supported I’d really appreciate it. I’m not sure if I’m doing something wrong or if this just isn’t supported.
The problem was on my Apple Watch.
I was able to get it working by erasing the watch (Settings > General > Reset > Erase All Content and Settings) then restoring it from a backup.

Do I need to add a privacy "purpose string" to my app's Info.plist to allow it to run on iOS 10?

General Query
Does precise documentation exist for which API methods/properties require privacy "purpose strings" in iOS 10?
Specific Query
I have an app that links against the CoreBluetooth framework that accesses only the following methods/properties:
CBCentralManager:
state
- retrieveConnectedPeripheralsWithServices:
CBPeripheral:
name
In the documentation, I have found the following vague statements (emphases mine):
An iOS app linked on or after iOS 10.0 must include in its Info.plist file the usage description keys for the types of data it needs to access or it will crash. To access Bluetooth peripheral data specifically, it must include NSBluetoothPeripheralUsageDescription.
[...]
When the system prompts the user to allow usage, the value that you provide for this key is displayed as part of the alert.
[...]
To protect user privacy, an iOS app linked on or after iOS 10.0, and which accesses the Bluetooth interface, must statically declare the intent to do so. Include the NSBluetoothPeripheralUsageDescription key in your app’s Info.plist file and provide a purpose string for this key. If your app attempts to access the Bluetooth interface without a corresponding purpose string, your app exits.
[...]
The data and features that require user permission are described in Table 1-2.
(Table 1.2 states that NSBluetoothPeripheralUsageDescription is required to access "Bluetooth peripherals")
My app does not currently exit when it calls the APIs listed. Neither does it "prompt the user to allow usage".
However, this blog post suggests that the lack of a crash does not indicate that no purpose string is required.
(Despite the fact that my app is not "linked on or after iOS 10.0" (the current version has been in the store since before iOS 10 existed), it does crash citing a missing NSCameraUsageDescription when it attempts to access the camera.)
Furthermore, my reading of the documentation above suggests that I should be including an entry for NSBluetoothPeripheralUsageDescription.
Is there any other documentation that I've missed that lists which actual API calls are covered by which privacy purpose strings?
Do I need to add an entry for NSBluetoothPeripheralUsageDescription to my Info.plist?
Is there any harm in adding such an entry if it turns out not to be required?
Yes you're definitely need it, it was optional in pre-ios10 but now you have to explicit add the comment into the info.plist
IF you're build with iOS10. It will crash the app but If you build with pre-ios 10 it's fine. It's based on Xcode build not based on Device version
So basically, next time you update the app you need to add it.
and By the way, I couldn't find document for it, this is my own experience that we have when shifting from iOS9 to iOS10

About Info.plist file and Xcode 5

I have some questions regarding the information I should include in my project's Info.plist file before submitting the app:
A) About CFBundleIcons: I see this key when I open the file in Xcode as source code and the xml format is displayed but, when I open it as property list, I only see an Icon files (iOS 5) entry, is that correct? On the other hand, I've changed the app icons I firstly had in the General tab of the target settings, and the Info.plist file keeps listing the old app icons as well, and the new icons I added do not have the .png extension in their name... should I handle this information manually, or did I something wrong when I changed the icons in the target's settings? Should the names include the png extension? Should I list all versions of an icon (standard and #2x), or just the name for the standard is enough?
B) Regarding UIRequiresPersistentWifi key, Apple's docs say that
Include this key if your app requires a Wi-Fi connection
I'm not sure if I have to include this key: my app performs network operations but they could be done via WWAN, not only via Wi-Fi. And not all my app's features need network connection to be performed.
C) About UIRequiredDeviceCapabilities key. I have in turn some questions here: Apple says that
The value of the UIRequiredDeviceCapabilitieskey is either an array or a dictionary that contains additional keys identifying features your app requires (or specifically prohibits).
What do they mean when they say "features your app requires": those features which the app won't work at all without them, or all those features that your app can use? For example: my app includes an option for listening the device's location. It is an optional functionality, users can enable and disable it. I check [CLLocationManager locationServicesEnabled] when the user enables the option. I've no set the location-services value in the plist file and the app has been tested and the feature works, and the compiler has never complained. Should I include the value if I want to submit the app?
Something similar happens with another capabilities, for example microphone and still-camera. I use UIImagePickerController at some point of the app, as well as the microphone for speech recognition, but that are also optional functions of the app that the user has to select, they don't affect its overall operation. And I neither have included such values in the plist yet and they are working...
Thanks in advance
A: If you want to publish iPhone app only you need provide the 2 icon's(#1x, #2x),Now I think #1x is not for necessary, if you want to publish Both iPad & iPhone, you may need to provide 4 icon. But if you dont care about the quality 1 icon is OK.
B:This line UIRequiresPersistentWifi is not necessary.
C:Same as B) This line UIRequiresPersistentWifi is not necessary. if you have more require from iOS system.

Resources