Justin O’Beirne:
At its heart, this series of essays is a comparison of the current state of Google’s and Apple’s cartography. But it’s also something more: an exploration into all of the tradeoffs that go into designing and making maps such as these.
[…]
Apple is labeling more cities. And Apple is also showing more roads. But Google has more road labels.
[…]
That means that out of a combined total of 35 unique places on both maps, the two maps have only 5 places in common.
[…]
It’s clear that Google thinks transit is important, while Apple thinks that airports, hospitals, and landmarks are important.
He does not look at rural areas, on the grounds that “the things that are labeled are the area’s only things.” Nonetheless, I’ve still noticed major differences, with Apple Maps typically omitting smaller roads, in favor of showing nothing, unless you really zoom in. In urban areas, I like that Google always shows the transit stations.
Nick Heer:
As noted earlier, I find the most striking difference to be search. Google Maps is very good at it; Apple Maps isn’t. The latter is getting better, insomuch as it less-frequently shows me results in Delaware and Washington D.C. instead of Calgary, but Google is still leaps-and-bounds ahead.
Khoi Vinh:
O’Beirne refrains from calling one or the other superior, but for me, the clear difference is that Apple Maps is concerned with cartographic integrity where Google Maps is concerned with the experience of using the application. That is to say, at most given zoom levels, Apple Maps presents formally better maps, but holistically, Google Maps presents more of the right information at the right time. Which is consistent with what animates each company: Apple is focused on beauty and elegance, and Google is focused on information delivery.
I still greatly prefer Google Maps, both for its design and map data. However, Google has made some changes recently that seem like regressions.
Previously: Google Maps & Label Readability.
Update (2016-06-08): Lee Bennett:
Two huge reasons I prefer Google Maps: Street View and single handed (one finger) zooming.
Apple Maps Design Google Maps iOS iOS 9 Maps Search
John Gruber:
Midroll owning Stitcher is not good for the podcast ecosystem. Stitcher is popular, but my show is not on Stitcher because Stitcher re-hosts the audio, compresses it to hell, and unless you opt out, inserts their own ads. That’s not how podcasting is supposed to work. I firmly believe podcasting should be open, like the web.
Marco Arment:
I’ve never been more proud to be operating a large podcast app that’s built on standard RSS, open access, and standard playback of podcasters’ original files directly from their servers, with no garbage ads being inserted, no behavioral tracking for advertisers, no proprietary lock-in, and absolutely no requirements that podcasters register with me, do anything differently, lose any control, agree to any terms, or even be aware of my app at all to be played, shared, and promoted in it.
Don’t let proprietary podcast platforms convince you that we need them.
Stephen Hackett:
I’m not as worried with services that re-host files — like Google Play — as Gruber is, but I agree that locking advertising to a select platform is bad for the industry.
Update (2016-06-07): Ben Thompson:
Midroll sells ads for over 200 podcasts, including some of the most popular ones like WTF with Marc Maron and the Bill Simmons Podcast. The not so-secret reality about podcast ads, though, are that advertisers are quite concentrated: a FiveThirtyEight intern heroically listened to the top 100 shows on the iTunes chart and counted 186 ads; 35 percent of them were from five companies. More tellingly, nearly all of the ads were of the direct marketing variety.
[…]
The real money in TV and especially radio is brand advertising; brand advertising is focused on building affinity for a purchase that will happen at some indefinite point in the future, so the focus is less on conversion and more on targeting: knowing in broad strokes who is listening to an ad, and exactly how many. For podcasting to ever be a true moneymaker it has to tap into that — and that means changing the fundamental nature of the product.
[…]
I know this breaks the modern concept of podcasting, and power users with tens of subscriptions in their podcasting player of choice will be annoyed if they have to download multiple apps. Often, though, a solution that works for power users is actually prohibitive for normal users, and the other solution — a Facebook of podcasts — would be worse for everyone.
Update (2016-06-08): Michael Rockwell:
The best we can hope is that Midroll treats Stitcher users like Neilson households — a small sample size that can be used to represent all podcast listeners.
Advertising Business iOS iOS App Podcasts Privacy Stitcher
Matt Gallagher:
Using a mutex in Swift isn’t particularly difficult but I’m going to use the topic to highlight a subtle performance nuisance in Swift: dynamic heap allocation during closure capture. We want our mutex to be fast but passing a closure to execute inside a mutex can reduce the performance by a factor of 10 due to memory allocation overhead.
[…]
One of the advantages with closure capture is how effortless it seems. Items inside the closure have the same names inside and outside the closure and the connection between the two is obvious. When we avoid closure capture and instead try to pass all values in as parameters, we’re forced to either rename all our variables or shadow names – neither of which helps comprehension – and we still run the risk of accidentally capturing a variable and losing all efficiency anyway.
[…]
It turns out that despite being a private function in the same file – where Swift can fully inline the function – Swift is not eliminating redundant retains and releases on the the PThreadMutex parameter (which is a class type to avoid breaking the pthread_mutex_t by copying it).
We can force the compiler to avoid these retains and releases by making the function an extension on PThreadMutex, rather than a free function[…]
[…]
But despite the speed increase, using a semaphore for a mutex is probably not the best approach for a general mutex. Semaphores are prone to a form of priority inversion.
Long-term, Swift should be able to keep @noescape closures on the stack.
Automatic Reference Counting (ARC) Concurrency Grand Central Dispatch (GCD) iOS iOS 9 Mac Mac OS X 10.11 El Capitan Optimization Programming Swift Programming Language
