Android (MacRumors, Hacker News):
It’s not about the color of the bubbles. It’s the blurry videos, broken group chats, missing read receipts and typing indicators, no texting over Wi-Fi, and more. These problems exist because Apple refuses to adopt modern texting standards when people with iPhones and Android phones text each other.
John Gruber:
RCS messages are only end-to-end encrypted sometimes, if both the sender and recipient are using Google’s Messenger app — and never for group chats, even with Google’s Messenger app.
So, practically speaking, neither RCS nor iMessage is actually private for most users. Right now, the experience of communicating with Android users from Messages is not very good. And it happens via SMS, which is even less secure. Whether or not you consider RCS to be a real open standard, it seems like it would be better than what we have now, and I don’t see Apple proposing a better alternative. It’s unclear whether this is a case of perfect being the enemy of good, RCS having genuine problems, Apple deliberately making things worse for their customers for strategic reasons, or simply not caring.
Regardless, they should also make Messages work better with SMS.
Ron Amadeo (via Jack Wellborn):
Google has been pushing this strategy since the beginning of the year, but coming from the company with the world’s most dysfunctional messaging strategy, it just comes across as a company tired of reaping what it has been sowing.
[…]
RCS has hung around so long and is still so poorly implemented because it was created by the carriers (through the GSMA) as a carrier-centric messaging standard. Carriers did this in the heyday of pay-per-message SMS, when carrier messaging was a real revenue stream. Now that carrier messaging is commoditized though, the carriers in control of RCS don’t have an incentive to care about RCS. RCS is a zombie spec.
Dave Mark:
What is the down side to RCS?
I get why Apple doesn’t want RCS (walled garden, green vs blue bubbles differentiator, etc), but is there a technical downside to switching to RCS?
Matt Birchler:
The thing for me is that everyone who is railing against Apple adding support for RCS are saying it’s because it’s not as good as iMessage, but that’s not what it’s replacing…it’s better for everyone than SMS, which I think is the better comparison.
Previously:
Update (2022-08-11): Dieter Bohn:
SMS/MMS are bad for texting on any platform, so Google worked with carriers to fix it. Yes, it’s been messy - it’s a hard problem. But sunsetting SMS/MMS and replacing it with something better is what’s right for users.
Russell Ivanovic:
SMS sucks bad. RCS sucks way less. Yes a dedicated end to end encrypted messaging app is better, but RCS is a good step forward.
The world would be a better place if Apple implemented it, period.
Update (2022-09-08): Sami Fathi (Hacker News):
During a panel at Kara Swisher’s final Code Conference yesterday, Cook was asked why iOS has not yet adopted support for the RCS standard and how Steve Jobs would feel about it (via The Verge), despite repeated calls from the industry for the company to do so. “I don’t hear our users asking that we put a lot of energy in on that at this point,” Cook said in response to the question.
[…]
The reporter who asked the question pushed Cook on his response, saying he and his mother find it difficult to send photos and videos to each other because she uses an Android while they use an iPhone. “Buy your mom an iPhone,” Cook told the reporter who posied the situation.
Update (2022-10-06): Abner Li:
Before Google’s “Get The Message” campaign in August, Android’s Messages app was updated with iMessage reactions at the start of this year. In a very weird turn of events, Apple appears to be taking credit for Google adding iMessage reactions on Android.
Update (2022-12-05): Juli Clover:
Google’s new blog post points out that this week marks the 30th anniversary of the SMS messaging standard, as the first SMS message was sent on December 3, 1992. Google argues that it’s time for an update, calling out Apple for “dragging its heels.”
Update (2023-06-02): Cassidy James:
even without e2ee to start, RCS would be leaps and bounds better of an experience ON BOTH ENDS than SMS. Apple absolutely is holding back the experience and only they can decide to support RCS.
messages would ultimately arrive in a Google-owned messaging client with a phone number and the message contents, exactly like they do today with SMS. Except with SMS, everyone in between can also read the contents in clear text, whereas even without e2ee, RCS message contents are encrypted similar to how HTTPS works. So it’s still a massive improvement. Plus typing indicators, full quality video, reactions, etc.
There’s no excuse for Apple to use SMS but NOT RCS.
as it stands, Apple knows any messages sent to anyone but an iPhone are sent in the clear, with a worse experience. They could, idk, work with the GSMA to enable end-to-end encryption in RCS if they cared. But they care about their marketing image, not securing actual communications.
We both know they enjoy the twisted perception of non-Apple phones being inferior at messaging because they themselves are refusing to improve things.
Meanwhile, Apple continues to reverse blue-bubble themselves where Android users now have nice rich messaging ootb, until an iPhone user joins and ruins it for everyone.
Android iMessage iOS iOS 15 Messages.app Privacy Rich Communication Services (RCS) Tim Cook
What’s new in AppKit:
The most prominent update to the sharing experience is the new sharing popover. This replaces the existing share menu with a rich interface that includes more information about the document you’re sharing and familiar features like suggested people. It supports all of the same APIs and delegate methods as the previous picker, so you can still do things like filter the list of sharing services, or insert your own custom services into the picker.
[…]
The new sharing picker is great for kicking off sharing from somewhere like a toolbar button, but sometimes you want to start sharing from a menu, like the main menu bar or the context menu for a selected view inside your app. Previously, you might’ve constructed your own menu to handle this, by enumerating sharing services and then building menu items for each one. Although that does work, it bypasses the standard picker, so now you’re missing out on all of those new features. In macOS Ventura, NSSharingServicePicker can create a standardShareMenuItem for you. You can add the standard item to any menu to easily kick off sharing. Once selected, the menu item summons the sharing popover, and for context menus, it’ll even anchor the popover to the same view that produced the menu.
I love the idea of an API to create the standard Share menu item, but I think it should create a submenu rather than a popover. The popover just doesn’t work very well.
Jeff Johnson:
- It takes one click to get the Share menu on Monterey, two on Ventura.
- The contextual menu and its Share menu item disappear when I open the Share menu.
- Nonetheless, the Share menu is anchored at the now empty space previously occupied by the Share menu item.
- The Share menu refers to the Support link on the web page, which is nowhere near where the Share menu is visually anchored.
[…]
I can no longer navigate the menu at all with the keyboard!
The arrow keys and type-selecting by name no longer work.
To me, the worst part is the location of the popover. Say that you are trying to share a file from Finder. With a submenu, the sharing choices always appear just to the right of the cursor. With the new design, if you choose Share… from the menu bar, the popover appears, not near the menu, but potentially way on the other side of the screen, i.e. near the icon that was selected. Even if you choose Share… from the contextual menu, the popover does not originate from the where you initiated the command but from the icon. So it’s not just a matter of needing an extra click—which, as with Control Center, feels slower than the menu it replaced—but you also need to first move the cursor to a different area of the screen.
Previously:
Keyboard support was also removed from Menubar controls like Sound/Vol. and Wi-Fi with the overhaul in Big Sur.
And most of the new UI has zero support for Apple Script automation, making it inaccessible to those having to rely on it.
That’s the wrong direction to take macOS to.
Seth Willits:
My theory is that NSMenu is a little too limited in its customization capabilities. I’ve run into it now and then.
Ex: As soon as a menu item has a view, it’s no longer a clickable/selectable item like the others. Sometimes want it to be.
Customizing the style and size of individual items is not clear. (Attributed titles get you there with text attachments for images, but … awwwkward)
[…]
But all in all, yes… a popover masquerading as a menu is a terrible thing. Crazy that they did it.
Cocoa Design Mac macOS 13 Ventura
Stephen Warwick (via Kosta Eleftheriou):
An investigation into seven different apps on the Mac App Store, including the number one PDF reader in the U.S., has found that all of them are orchestrated by the same Chinese developer using fake reviews and command-and-control exploits to try and target users.
[…]
For example, an app could determine whether it was in Apple’s review process, changing its UI so as not to fall foul of any App Store guidelines before unleashing popups asking for money on unsuspecting users. […] Finally, multiple spammy versions of the same app with slight variations were uploaded “in order to gain as much market-share as possible in some niches.”
[…]
[These] apps would push users to make purchases using deceptive windows offering purchases of trials or subscriptions with no close or cancel button in sight, leaving the user no option but to click okay and possibly making a purchase.
Alex Kleber:
The developer is well known of abusing the Appstore review system under the account of Polarnet Limited were previously reported by other Mac Appstore vigilantes few months ago. At that time, Apple took action and removed many reviews of this developer.
Alex Kleber:
Apple removed all 7 developers’ accounts mentioned in the article.
Jeff Johnson:
I’ve found proof that the apps SmartPlay for Safari by Best App Limited and StreamPlay for Safari by Xiaobo Wang are actually from the same developer.
Needless to say, these are among the top apps in the store.
Rafael (via Kosta Eleftheriou):
two apps of mine almost only get 5-star reviews. However, recently a competitor of mine started writing fake reviews in the review sections of these apps to lower the score of my apps and even uses these reviews to tell people that there were better apps out there, with features that match exactly the features of his apps.
I contacted Apple about this issue and they deleted one review, that was obviously fake and contained bad language. However, they said they could not do anything about the other fake reviews, because these reviews did not violate their guidelines about App Store reviews.
Marcos Tanaka (via Federico Viticci):
Had to request an appeal to the App Review Board. I asked three times for a screenshot or concrete evidence of this supposed hidden functionality in my app, but the reviewer only answered with vague sentences such as “money gambling functionality”.
Previously:
Update (2023-03-23): Jeff Johnson:
Last year I attempted to raise awareness of an App Store developer apparently committing fraud, both by using multiple fake developer accounts and by posting fake ratings and reviews in the App Store. Recently I noticed that the same app SmartPlay for Safari is still in the Mac App Store and still a top download, currently in the 100 top “free” list in the United States. This app is not really free, however. It has a paywall on first launch, as noted by many of the app’s reviews. (The reviews that aren’t fake, that is.)
App Store Rejection App Store Scams Mac Mac App Mac App Store macOS 12 Monterey PDF
Lawrence Abrams (Hacker News):
Twitter has confirmed a recent data breach was caused by a now-patched zero-day vulnerability used to link email addresses and phone numbers to users’ accounts, allowing a threat actor to compile a list of 5.4 million user account profiles.
[…]
This vulnerability allowed anyone to submit an email address or phone number, verify if it was associated with a Twitter account, and retrieve the associated account ID. The threat actor then used this ID to scrape the public information for the account.
[…]
While no passwords were exposed in this breach, Twitter is encouraging users to enable 2-factor authentication on their accounts to prevent unauthorized logins as a security measure.
For those using a pseudonymous Twitter account, the social media company suggests you keep your identity as anonymous as possible by not using a publicly known phone number or email address on your Twitter account.
Giving Twitter your phone number was supposed to provide more security, but in this case it seems like it made it easier to look up accounts and link them to other public information.
Previously:
Breach Privacy Security Short Message Service (SMS) Twitter Two-Factor Authentication (2FA) Web
