Jeff Johnson:
What does not appear to be documented is that Mojave “phones home” to Apple on first launch of every downloaded app, regardless of whether the app was notarized. […] This status is not cached.
[…]
In packet traces I see a reference to http://ocsp.apple.com, which suggests that Gatekeeper may be using some form of Online Certificate Status Protocol (OCSP), a standard method for checking whether a certificate has been revoked. The internet traffic is to api.apple-cloudkit.com on TCP port 443, in other words, https. Thus, the data is likely encrypted.
[…]
It’s important to note that no explicit consent has been given for this information to be transmitted to Apple. In System Preferences, I had disabled all of the Analytics in Security & Privacy and all of the automatic checks in Software Update, so as far as Mojave was concerned, Apple had no permission. I’m not aware of any official Apple privacy policy with regard to Gatekeeper. I have no reason to believe that Apple will use this data for competitive or marketing purposes, but… who knows? It would certainly be a gold mine of information about Mac consumer usage of third-party apps. Apple has announced that app notarization will be required for all apps in an upcoming version of macOS, so in effect Apple is forcing developers and end users to give Apple valuable business data.
I wonder how long Apple stores this data and whether anyone would be motivated to try to gain access to it.
Update (2019-08-30): Jeff Johnson:
Why doesn’t macOS just periodically download a list of revoked notarizations instead of checking on launch?
This would be more secure, because what if there’s a connection failure at launch in the current implementation?
Whereas a periodic system daemon could retry on connection failure and download the updated list whenever internet is reestablished.
This would also protect user privacy. Apple doesn’t need to know when users launch an app.
Code Signing Gatekeeper Mac macOS 10.14 Mojave Notarization Privacy
John Gruber (tweet, Hacker News):
There is a common convention for Undo/Redo in iOS drawing apps — circular arrow buttons, counterclockwise for Undo and clockwise for Redo. (And, thankfully, these are the same icons used for Undo/Redo on the iPad on-screen keyboard. Consistency is not completely lost.) You can see them in these screenshots from Apple Notes and Linea Go on iPhone.
But it speaks to how weak this convention is that Procreate Pocket could do something not just different but totally different — multi-finger taps with no on-screen buttons — and not just get away with it but be celebrated by Apple for it. I’m not saying Procreate’s two/three-finger taps are better or worse than on-screen buttons. (Well, stay tuned.) And I can see the thinking — screen space on an iPhone is so precious that any reduction in on-screen buttons is a win in terms of reducing UI clutter and maximizing the screen space available for showing the content of the illustration. Also, I’m sure the two/three-finger taps are very fast once you’re used to them.
[…]
What it comes down to, I think, is that the menu bar has become a vastly underestimated foundation of desktop computing. Once heralded, the menu bar is now seen as a vestige. I’m not arguing that iOS should have a Mac-style menu bar.
I think iOS could use some sort of menu bar or Start menu. There needs to be a standard place for extra commands that don’t fit as buttons and that shouldn’t be shoe-horned into the Share button.
Previously: On “Shake to Undo”.
Update (2018-12-11): Procreate:
Whether you’re one of our competitors, or in an entirely different field, please feel free to grab the project below. Take it, use it, and give your users the most instinctive Undo and Redo method available.
iOS iOS 12 Linea Notes Open Source Procreate Pocket Undo
Ken Case:
The “purgeable” space is space that the operating system knows how to reclaim when you try to create files that need that space. But it’s not truly cleared up from the disk yet and still shows up in OmniDiskSweeper’s summary list. But even though it shows up in the summary, it won’t show up when you browse the disk looking for files to delete—so OmniDiskSweeper will end up reporting different numbers for space used based on how it scans your disk.
[…]
These snapshots can take nearly zero space at the start (because their contents are exactly the same as the current files on disk), but as files get edited or removed the snapshots start to take up more and more space. In particular, when you delete huge files (because you’re trying to clear up space), they will disappear from your filesystem but will still exist in your snapshots until those are removed. This is where I usually find the bulk of the “purgeable” space reported in Disk Utility.
Also, OmniDiskSweeper doesn’t tell you about APFS cloned files. (I’m not sure how it reasonably could.) So, although it will tell you how much space a given file is using, deleting that file may only increase the free space by a fraction of that amount.
Previously: Dive Into APFS.
Update (2019-04-03): Tyler Loch:
macOS: “Whoa, buddy. You can’t do that. The drive is full!”
Me: “What? Finder says there’s still 50GB available!”
macOS: “Yeah, but that’s actually purgeable data.”
Me: “Ok, so purge it.”
macOS: “No.”
Apple File System (APFS) Disk Utility Mac macOS 10.14 Mojave OmniDiskSweeper Storage
Dave Mark:
This happens to me all the time. I’m in an app that’s attached to my home WiFi and I walk (or drive, as a passenger) away from my house. As I move further from my house, the signal gets progressively weaker and whatever app I’m in just hangs, stuck waiting for a reply from my home WiFi that’s never coming.
[…]
Some time ago, Apple added the setting Cellular > Wi-Fi Assist (scroll down below that long list under CELLULAR DATA) that someone suggested might help with this, though I believe the intent was to help with poor WiFi, not specific to this problem. As it turns out, this is on for me. Does not make a difference.
iOS iOS 12 Networking Wi-Fi
