Gabe Weatherhead:
Hit Shift-⌘-\ to enter the Safari “Show all tabs” mode. From there it’s just a simple ⌘-F to search the open tabs.
This is great. I was aware of the Show All Tabs mode but had no idea that it was searchable. Why on earth is the search field hidden until you invoke the Find command?
(I still think it’s too bad you can’t see a list view or rearrange your tabs.)
Update (2017-12-05): Bartek notes that you can just start typing your query without even pressing Command-F.
John Gruber:
It seems crazy to me that you can use this to find tabs open on other devices, but not tabs open in other windows on the Mac you’re currently using.
Mac macOS 10.12 Sierra macOS 10.13 High Sierra Safari Web
Juli Clover:
The absolute fastest way to charge an iPhone 8, iPhone X, or iPhone 8 Plus is with a USB-C power adapter and an accompanying USB-C to Lightning cable. Charging with USB-C activates a “fast-charge” feature that’s designed to charge the iPhone to around 50% in 30 minutes, and I saw about that level of charge in all of my USB-C tests.
5W wireless charging and 5W wired charging with the standard iPhone adapter were the slowest methods that I tested. 7.5W wireless testing was faster than 5W wireless charging, but not by much.
Charging at 12W with the iPad adapter wasn’t ultimately too far off of the fast charging results at the end of an hour, making this one of the better compromises between cost and speed.
[…]
For a separate post on wireless charging options, we’ve been investigating third-party wireless chargers, and it’s looking like there may be a restriction put in place by Apple to limit 7.5W charging to approved manufacturers. […] Just because a wireless charger offers more than 5W, it’s not necessarily going to offer 7.5W charging speeds when used with an iPhone.
Previously: iPhone 8 Charging Speed.
Update (2018-11-13): Ryan Jones:
This super handy app measures iPhone charging speeds. Found out my 2.1A Griffin was terrible (3.68W!), bought a $9 4.8A Aukey and getting 12-24W!
3-6x faster charging for $10.
iOS iOS 11 iPhone iPhone 8 iPhone 8 Plus iPhone X Power Qi Charging USB-C
Daniel Jalkut (tweet):
Big news today: MarsEdit 4 is out of beta and available for download from the MarsEdit home page and the Mac App Store. This marks the end of a long development period spanning seven years, so it’s a great personal relief to me to finally release it. I hope you enjoy it.
[…]
After the trial expires, all features of the app continue to work except for actions that update published content on the web. […] Anybody who purchased MarsEdit 3 on June 1, 2017, or later, is entitled to a free update to MarsEdit 4. Anybody who purchased MarsEdit 3 earlier than June 1 is entitled to a discounted $24.95 upgrade. This applies to Mac App Store users as well! Because MarsEdit 4 embraces the Mac App Store’s in-app purchase model, the app can use a downloaded copy of MarsEdit 3 to validate a discounted or free upgrade to MarEdit 4, as appropriate.
MarsEdit is one of only a few third-party apps (along with BBEdit, LaunchBar, and OmniOutliner) that I’ve used nearly daily for the last 13 years or so. Here are the highlights of what’s new.
Previously: MarsEdit 4 Public Beta, Acorn 6 Public Beta, Omni’s IAP Trials and Upgrade Discounts, MarsEdit 1.0.
Update (2017-12-05): Brad Ellis:
Updated the MarsEdit icon for the latest release. Teal and orange, because I enjoy Michael Bay movies.
Brent Simmons:
My blog doesn’t have a browser-based interface at all. None. Every single post goes through MarsEdit.
Jeff Johnson:
There seems to be zero info in the Mac App Store about how much the app costs.
Also quite surprised that “purchase a full license” is allowed in the description.
Nick Lockwood:
I’m constantly amazed at the tortuous purchase processes Apple is willing to put users and developers through instead of just providing the free trial mechanism that we’ve all wanted since day one.
See also: John Voorhees.
John Gruber:
The basic premise — a native Mac blog editor that follows the basic layout and structure of an email client, remains as sound today as it did 13 years ago. MarsEdit is both great in terms of its integration with various blogging platforms and its integration with MacOS as a native app.
Movable Type, Blogspot, and LiveJournal are all still around, but today they’re dwarfed in usage by WordPress and Tumblr. It’s a testimony to the strength of MarsEdit’s engine-neutral design that it remains relevant today, despite a nearly complete change in the publishing systems people use to blog.
Manton Reece:
We are so used to these silos and these apps that are not compatible with anything, that we just accept it. But that’s how it should work.
You should be able to use multiple apps to post to different services. And that’s what’s happening with apps that are built with some compatibility in mind, especially on IndieWeb standards. That’s what’s happening with MarsEdit and Micro.blog, although on a much smaller scale.
Update (2017-12-07): Jeff Johnson:
As I suspected, App Store doesn’t show the price until someone purchases. Which is absurd.
Note that this is criticism of MAS and not of MarsEdit.
Update (2017-12-18): See also: Vector.
Business In-App Purchase Mac Mac App Mac App Store macOS 10.13 High Sierra MarsEdit RSS Web
Jeff Johnson:
The recent article Strings in Swift 4 by Ole Begemann talked about how Swift String equality is implemented as Unicode canonical equivalence. As a result, two String instances can be equal even if they contain different Unicode code units. […] Two NSString instances are equal if they have the same sequence of UTF-16 code units.
[…]
This difference in behavior between Swift and Objective-C is troubling. Suppose that you had some old Objective-C code that saved user defaults in dictionary format with string keys, and then you wrote new Swift code to access the user defaults, naively using dictionary(forKey:), because of course that’s what you’d think to use.
What happens is that you get a weird bridged Swift Dictionary. This is supposed to be an O(1) wrapper around the NSDictionary. Indeed, its count is the same. But when you look up the keys it uses the Swift rules for string quality. So a lookup that would find no matches in Objective-C may find one with Swift. Removing an entry removes multiple entries with equivalent keys. When you get the description it coalesces the entries with equivalent string keys, so that the description doesn’t match the count. And if you try to cast it as NSDictionary, which should always succeed and just give you the underlying wrapped dictionary, it crashes.
Update (2017-12-11): Joe Groff:
It’s a known problem. Eventually we want to do away with the “lazy bridging”, which would allow the crash to at least happen deterministically on bridging and avoid the inconsistent view of the Dictionary.
It’s supposed to crash if it detects a key collision introduced by the difference in equality model (theory being that keys differing only by normalization form are almost always by mistake).
Another possibility is to opt out APIs from bridging when they deal with NSStrings that may significantly differ in normalization.
We already know we need an opt-out mechanism for things like Core Data NSArray/NSDictionary objects where their class-iness is part of the magic.
Airspeed Velocity:
Bit of clarification: the crash is definitely a bug. The code to bridge into Swift from ObjC coalesces keys and shouldn’t trap, but it assumes the count from the NSDictionary, an invalid optimization.
O(1) bridging from Swift to ObjC only happens when the types in the ObjC container are verbatim-bridged. Which String/NSString aren’t.
Bug Cocoa Objective-C Programming Swift Programming Language Unicode
