WhatsApp is automatically suffixing a number to the device name in the list of Linked devices shown in WhatsApp app settings. The suffixed number has no correlation to the actual number of linked devices at that time. For example, a number “2” is suffixed to the device name in list of Linked devices shown in WhatsApp, even though that computer/ device is the only one shown as a linked device. If we try to edit the device name to remove the suffixed digit, it does not move forward.  I think it has something to do with the restoration of chats from cloud, because the suffixing happens subsequent to the restoration of chats from cloud. Whatsapp does not respond to emails about this issue. Anyone else?

Toggle button for SMS forwarding (iOS Settings app > Apps > Messages > SMS Forwarding) missing in iPhone. Instead of Toggle button for SMS forwarding (iOS Settings app > Apps > Messages > SMS Forwarding) in iPhone ,a grayed out text appears if the other Apple device is logged in to iCloud after the primary iPhone. Messages in iCloud are switched On for all devices, and all devices are on latest iOS, iPadOS, macOS. iMessage is also On. The toggle button appears for SMS forwarding (iOS Settings app > Apps > Messages > SMS Forwarding) in iPhone against any device logged in to Apple account in the following conditions: 1.) the iPhone is restored as new and logged on to the iCloud ID, after the other Apple device was logged in to iCloud with same ID. In other words, the iPhone under consideration and its Messages in iCloud are logged on in the last out of all other Apple devices (iPad, macBook, any other iPhone); or 2.) the messages in iCloud is toggled "Off" in the respective other Apple device. Perhaps the above condition (2) is emanating out of the Apple support article https://support.apple.com/en-in/102545, but the condition at (1) definitely does not seem to have any basis. The behaviour at (1) seems a bug.

'Remove Download' button in right click menu for iCloud folder in Finder on macOS does not work if total number of selected files/ folders at the time are more than 10 nos. If more than 10 non of files/ folders are selected at any time, then the 'Remove Download' button disappears from the right click context menu in macOS Finder for iCloud folders. To click and act on the 'Remove Download' button on context menu of Finder upon right click, the total number of files and folders together must not exceed 10 nos. Is this the behaviour expected, or am I missing something and this observed behaviour is a bug of Finder?

Is it possible to install some specific file on macOS running Ventura, instead of installing the complete Xcode 15 beta to enable syncing iOS 17 beta device with the macOS. I tried checking device support files on Xcode 15 Beta, but it does not have device support files for iOS 17 under Contents > Developer > Platforms > iPhoneOS.platform > DeviceSupport. The latest iOS version folder available there is for iOS 16.4. Surprisingly, iPadOS 17 beta syncs with macOS Ventura without installing Xcode 15 beta.

I want to create an automator quick action to enable creation of tar archives using tar command on macOS on any selected file or folder in finder. Do I have to use Shell Script or something else? I am unable to do it. Someone please help. I am unable to run the following script for creating tar files. Getting error message. Tarfile="$1.tar" count=1 cd "${@%/*}" if [ $# -eq 1 ]; then while [ -e "$Tarfile" ] do let count++ Tarfile="$1 $count.tar" done else Tarfile="Archive.tar" while [ -e "$Tarfile" ] do let count++ Tarfile="Archive $count.tar" done fi /usr/bin/tar -chf "$Tarfile" "${@##*/}"

Notify when left behind not working for any device connected to iPhone on ios 15.2 betas.  However it is working of the iPhone is having iOS 15.1 public release. It also did not work on 15.1 betas, but worked on public release.  Does it mean, notify when left behind does not work on any beta, and is activated at the backhand off apple only for public release.

iOS 15 beta 8: While iOS native Mail app is not running in the background (by virtue of being killed from app switcher), the scheduled fetch of favourite mailboxes of any IMAP account does not occur. I think that iOS Mail app has the privileges to fetch even without showing in the app switcher. Thus the existing behaviour appears erratic. In this situation however the Inbox of IMAP mail account gets fetched on schedule even if Mail app is not running in the background. When the fetch happens, the corresponding notifications also appear as per configuration. Is the behaviour of iOS Mail app correct in not fetching favourite mailboxes on schedule if the app is not running in the background?

iOS Mail App not doing Scheduled fetch and notifications for favourite mailboxes on IMAP mail accounts that do not support Push (Yahoo/ Gmail / IMAP accounts)- fetching in such favourite mailboxes only on manual opening. Observed behaviour: iOS Mail app is not performing the scheduled fetch for favourite mailboxes of IMAP accounts (like Gmail, Yahoo and third party IMAP accounts) which do not support Push. The behaviour does not change with any of the frequency of scheduled fetch - 15 minutes, 30 minutes, or hourly. Scheduled fetch does not occur with any of the frequencies on favourite mailboxes. Mails are not fetched on schedule from any of the favourite mailboxes even after a lapse of many hours/ multiple fetch cycles. Notification for any mail in favourite mailboxes is also not being generated with any of the possible options for selected scheduled fetch frequency. The scheduled fetch works only for the Inbox of an IMAP type mail account (not supporting Push) and not for any of its favourite mailboxes of non-Push type. Upon opening the Mail app, the respective favourite mailboxes of non-Push IMAP accounts shows unread count displayed against each. Only the unread count is shown but the actual mail is not fetched. The notifications did not happen for those mails in favourite mailboxes. The notifications occurs for Favourite mailboxes only if its mail account supports Push, or it is manually opened. This erratic behaviour occurs irrespective of whether the iPhone is connected to the charger or not, network connectivity is WiFi or cellular. Expected behaviour: The native iOS Mail app should perform scheduled fetch and notifications on favourite mailboxes for IMAP/ Gmail/ Yahoo mail accounts which do not support Push. The scheduled fetch should should work as per any of the selected frequency out of the available options (hourly/ Every 30 minutes/ Every 15 minutes). Every favourite mailboxes should get fetched in each fetch as per schedule and no such mailbox to be missed and left out from any scheduled fetch. A notification should get generated for every new mail fetched in such favourite mailbox of IMAP account which does not support Push.

Observed behaviour: the iOS Mail app is not performing the scheduled fetch  for favourite mailboxes of accounts (like Gmail, Yahoo, IMAP third party) which do not support Push. Notifications for such new mails are also not generated. Scheduled fetch and notifications do not occur with any of the fetch frequencies (every 15 minutes, every 30 minutes, hourly, Automatic) on favourite mailboxes even after a lapse of many hours/ multiple consecutive fetch cycles.  Upon opening the Mail app, the respective favourite mailboxes show unread count displayed against each. Yet they don’t show notifications for those mails. The notifications occurs for Favourite mailboxes only if its mail account supports Push, or it is manually opened. Expected behaviour: The native iOS Mail app should perform scheduled fetch and notifications on favourite mailboxes in every fetch cycle for all IMAP/ Gmail/ Yahoo mail accounts even if they do not support Push. The scheduled fetch should should work on any of the available frequency options (Automatic/ hourly/ Every 30 minutes/ Every 15 minutes).  All the favourite mailboxes should get fetched at least once in every fetch cycle as per schedule and no such mailbox to be missed and left out from any scheduled fetch  - e.g. if the fetch frequency is ‘Every 15 minutes’, then every favourite mailbox should get fetched once every 15 minutes. A notification should get generated for every new mail received on scheduled fetch in each favourite mailbox.

Two of the iOS bugs affecting my work, have been reported multiple times on Feedback Assistant over last many months, yet they are not fixed yet. Anyone else too facing them? They are: Sending SMS Text message (Green Bubbles) on a dual sim iPhone FAILS upon using “Respond with Text” with an incoming phone call from a caller to whom SMS has not been sent earlier after a reset of iPhone settings.  Scheduled fetch and notifications not done by native iOS Mail App for favourite mailboxes on non Push supporting mail accounts (IMAP/ Yahoo/ Gmail etc accounts)- favourite mailboxes updating only upon manual fetch.

iOS 14.7 and earlier: Unable to send SMS text message (not iMessage) without deleting a conversation, if previous messages were iMessage and iMessage is disabled after initiating that conversation/ sending few iMessages. Expected behaviour: If a conversation is initiated with iMessages (blue bubbles) with any contact, and the user wants to continue the same conversation using SMS messages (green) instead of iMessages, the iOS Messages app should permit it. The conversation should continue using SMS even if the earlier messages sent in it were iMessages and not SMS messages (Green bubbles). There should be no need to delete the existing iMessages conversation in order to send an SMS message (green bubbles) to the same contact if iMessage has been disabled subsequent to sending an iMessage. Observed behaviour: If subsequent to initiating a conversation by sending an iMessage, the iMessage is disabled in iOS Settings > Messages > iMessage > [Disabled], and an SMS text message is attempted in the same conversation, the sms sending fails. SMS text message does not get sent. Instead ot generates error “Message Failed to Send” or “Cannot Send Message”.  If a conversation is initiated with iMessages with any contact, then the user is forced to continue that conversation only using iMessages and not by SMS text messages.

iOS 14.7: Respond with Text SMS FAILS- with an incoming phone call from a new caller to whom SMS has not been sent earlier after a reset of settings on a dual sim iPhone. This issue is regarding dual sim iPhones. If sending SMS message is attempted from incoming phone call screen by the option of using “Respond with Text”, the SMS sending fails if an SMS has not been sent earlier to that caller from the iPhone after a reset has been done of its settings. This happens irrespective of the receiving phone line is setup as the default Data line, default Phone Calls line, or default for both Data and Phone calls, or default line for none. The SMS text message using “Respond with Text” option gets sent and delivered to that caller only if that caller has been sent an SMS message from the iPhone earlier.  Further, if an SMS is subsequently attempted to be sent to that caller (after SMS sending fails while using Respond with Text options), a prompt (“Number not available. Which number would you like to send the message with”) appears in messages app asking to select one out of two phone lines to be used - out of two mobile phone lines of dual SIM iPhone, which has to be selected before any SMS message gets sent from using “Respond with Text” options on incoming phone call screen. This confirms that the phone line of the incoming call is not getting utilised  automatically at the back end of Phone app/ Messages app for sending SMS through “Respond with Text”. Neither is the default phone line configured for calls or data getting used. This unexpected behaviour persists until atleast one sms is sent to the caller on messages app from that iPhone prior to receiving the incoming call (but after a reset of the iPhone settings).

mail account name, favourite mailbox name and count of total number of unread mails is not shown at the lower edge on the top notification in a collapsed group of mail notifications on notification centre.  Expected behaviour:  The mail account name, favourite mailbox name, and count of total number of unread mail notifications present in any collapsed group of notifications on the notification centre should be displayed at the lower edge of the top notification.  For example: a group of 4 mail notifications will show “3 more notifications from Gmail - Saved”, at the lower edge of top notification. This feature is/was available in every collapsed group of mail notifications for mails received in any mailbox on iOS 13, iOS 14. Observed behaviour: On iOS 15 betas, the top mail notification does not display the mail account name, favourite mailbox name, and count of total number of unread mail notifications in that group of collapsed notifications on the notification centre. The user thus is unaware and is misled about the account and the total number of notifications currently present in that group. Also the favourite mailbox name / location containing the respective mails received in a favourite mailbox is not displayed on the lower end of top notification. This confuses and reduces available information to the user.

Content type key header added by iOS mail app contains ‘@yahoo.com’, - causing mail to get rejected by some IMAP servers. Issue is occurring on all iOS versions including 14.6, 14.7 betas, and iOS 15.0 betas. On the iPhone, I am unable to forward a mail containing attachments received from a web browser based @yahoo.com or @icloud.com mail account. When the iPhone native mail app forwards a mail received from @yahoo.com or @icloud.com mail account using a web browser like Safari, it adds the following header content to the mail:  Header added by iPhone mail app: --Apple-Mail-91EF9D82-D8B5-41DD-A98A-69489ED47254 Content-Type: image/jpeg; name=image0.jpeg; x-apple-part-url="xxxx-yyyy-zzzz@yahoo.com" Content-Disposition: inline; filename=image0.jpeg Content-Transfer-Encoding: base64 Content-Id: xxxx-yyyy-zzzz[AT]yahoo.com The header added by iPhone mail app is rejected by some third party IMAP mail accounts who reject the message from iOS mail app. The error message generated at IMAP mail servers is as follows: Mail send failure log: Action: failed Status: 5.0.0 (permanent failure) Remote-MTA: dns; [***.***.***.***] Diagnostic-Code: smtp; 5.3.0 - Other mail system problem 550-'5.7.1 Attachment type not allowed. File "image0.jpeg;  x-apple-part-url="xxxxxxx-yyyyy[AT]yahoo.com" has the unacceptable extension "com"' (delivery attempts: 0) Is the error of mail rejection on account of iPhone incorrectly adding the header, or is the mail server behaving incorrectly by wrongly rejecting the mail?

deleted.