Archive for November 18, 2016

Friday, November 18, 2016

Sending a Text Message Instead of an iMessage

We’ve been wanting to do this recently, due to problems where Messages says that an iMessage was delivered, when in fact it never arrived. I’ve been having problems like this on and off since iMessage was introduced, yet as far as I know SMS has never let me down. You used to be able to tap and hold on a message bubble and choose “Send as Text Message,” but that feature seems to have been removed.

The Send as SMS setting lets the phone automatically fall back to SMS when iMessage is not available. However, that doesn’t help in my situation where iMessage is available but simply doesn’t work.

I found several forum posts, but the only solution seems to be to temporarily turn off iMessage, which seems like a terrible solution because it means that you won’t be able to receive iMessages from anyone else in the interim. Worse, the iMessages will look to the sender like they got delivered because they’ll still go to your Mac or iPad.

Ideally, there would be a way to simply start a new conversation using SMS even though there is an iMessage account associated with that phone number.

Apple Storing iPhone Call History

Kim Zetter (via Hacker News):

Russian digital forensics firm Elcomsoft has found that Apple’s mobile devices automatically send a user’s call history to the company’s servers if iCloud is enabled — but the data gets uploaded in many instances without user choice or notification.


The logs surreptitiously uploaded to Apple contain a list of all calls made and received on an iOS device, complete with phone numbers, dates and times, and duration. They also include missed and bypassed calls. Elcomsoft said Apple retains the data in a user’s iCloud account for up to four months, providing a boon to law enforcement who may not be able to obtain the data either from the user’s phone, if it’s encrypted with an unbreakable passcode, or from the carrier.


It’s not just regular call logs that get sent to Apple’s servers. FaceTime, which is used to make audio and video calls on iOS devices, also syncs call history to iCloud automatically, according to Elcomsoft. The company believes syncing of both regular calls and FaceTime call logs goes back to at least iOS 8.2, which Apple released in March 2015.

Dan Moren:

Apple is syncing your calls between devices logged in with your Apple ID. In theory, this is no big deal: Apple says that the idea is if you’re logged in to your iPad and your iPhone, you can see the same call record in FaceTime on both of them. Miss a call on your iPhone? You can return it from your iPad. Makes perfect sense as a feature from Apple’s perspective.

Rene Ritchie:

The Information called it “secretly” and “surreptitiously”, but it’s not only wicked obvious why Apple is syncing call history, it’s fully disclosed in Apple’s security white paper.

I’m not really bothered by this, but I would not say that it’s obvious that an item in the “Here’s what iCloud backs up” section is backed up even when iCloud Backup is off.

If call history sync concerns you, you can disable iCloud Drive in preferences and it’ll stop.

There are no separate iCloud Drive settings for Phone or FaceTime, so if this concerns you I guess your only option would be to disable iCloud Drive entirely, which is probably not feasible because it would break other apps.


There is no option to turn it on or off. This makes it completely opaque to the user that this is being done. Also, the way the devices interact with this data can lead a user to believe this is not the case.

If I clear my call log on my iMac, it doesn’t not clear it on my iPhone, and vice versa.

In a Sync’d system, one would expect the data on all connected devices to mirror the Sync’d source, so changes are propagated across devices.

This isn’t the case for Apple devices (in a number of situations), therefore it makes complete sense that it would seem obvious to someone that Apple is not doing this, especially with their heavy “focus” on letting users know that everything stays on their device and is done locally.

Update (2016-11-18): McCloud:

You know what else syncs with catastrophic results? RESETTING NETWORK SETTINGS. Reset my iPhone, my Mac went off the radar. Couldn’t SSH.

13" vs. 15" MacBook Pro

Curtis Herbert:

I didn’t think 15" would make a huge difference, but I’ve almost doubled my canvas area when I’m on the go. I can actually see an entire view controller at a time without collapsing panels. Of course, this doesn’t hold a candle to what I work in when I’m at my desk on my 27" external monitor.

I still miss the 17-inch MacBook Pro.

Full Screen Is a Preference

Joe Cieplinski:

The isRestorable property in macOS conveniently saves window position between launches without much effort for developers. Unfortunately, isRestorable doesn’t have any knowledge of whether the app is in full-screen mode. It would be nice if Apple provided a simple checkbox for remembering full-screen status in IB somewhere.

Meanwhile, on behalf of Mac laptop users everywhere, allow me to plead with my Mac developer friends: When I put your app in full screen and keep it that way, I’m showing intent. And good developers always pay attention to a customer’s intent, and use it to anticipate their preferences. Consider taking a few minutes on your next version to implement saving a preference for running the app full screen. It’ll go a long way to making your customers happy.

The Apple apps that I just tried this with (Mail, Safari, Xcode) all remembered full screen status, as did OmniFocus. But I see an NSIsFullScreen key in the Saved Application State’s windows.plist file. So I wonder if there isn’t some framework support for this after all.

The .blog Bait and Switch

Chris Schidle (via Hacker News):

At the time the link led to a page where you could sign up for updates (the full website was not up yet). Thinking that had a nice to ring to it, I signed up immediately.


Alright, I guess that’s fair. If multiple Chrises (or Chris’s? whatever) apply then it goes to auction. I’d still have a chance to secure it, and Automattic maximizes their revenue by auctioning it off. Win-win.


Perhaps it’s not fair to call this bait & switch. Really it was bait & refund, and certainly the situation would be far worse had they chosen to not make the application fee refundable.

But still, I thought I had chance at securing the domain. That was the logical conclusion given the terms they outlined (via successful application or winning an auction).


Knock Knock Whois There LLC, the subsidiary of Automattic behind the .blog TLD, has responded with this post regarding reserved domains.