Apple Music, Beats 1, and why you may not want to force TRIM on your SSD.
Apple Music, Beats 1, and why you may not want to force TRIM on your SSD.
I invaded Inquisitive’s Favourite Album series this week to explain why I like Phish so much and why you don’t, even though you’ve probably never heard any of their music.
Bitcode follow-up, ad-blocking in iOS 9 and El Capitan, and how not to insulate your house.
Bitcode, Swift 2, and slim wallets.
John Gruber’s live performance of The Talk Show at WWDC was unusually special this year.
It was announced and sold out without John specifying any guests. He didn’t hype it up or drop any enticing hints. Nobody knew who would be on stage until they walked through the curtains, but we all assumed it would be some of the developers, journalists, and friends who usually join John to give The Talk Show its great personality.
But after a brief introduction from Merlin Mann and Adam Lisagor, John introduced, “and I shit you not,” Apple’s senior vice president of marketing, Phil Schiller.
Being familiar with John’s dry humor, I’m not sure most of the audience believed him. Many cheered. Some hesitated. For a few seconds, nobody walked out, and people started laughing, thinking they got the joke.
And then Phil Schiller really walked on stage.
Apple doesn’t do this.
Apple executives rarely speak publicly outside of Apple events, especially for live interviews. One of the highest-ranking executives of the world’s highest-profile company being subjected to questions, unprepared and unedited, in front of a live audience full of recording devices, is rarely worth the PR risk: the potential downside is much larger than the likely upside. Do well, and a bunch of existing fans will like you a bit more; do poorly, and it’s front-page news worldwide.
Both Apple and Phil Schiller himself took a huge risk in doing this. That they agreed at all is a noteworthy gift to this community of long-time enthusiasts, many of whom have felt under-appreciated as the company has grown.
With the wrong interviewer, this could’ve been a recitation of PR-friendly softball questions with perfectly designed, talking-point responses that would’ve gone nowhere and benefitted no one. But Apple PR doesn’t want that any more than the audience does.
Or it could’ve been boring questions about hardware rumors that no Apple executive would ever answer. I’ve never seen another interviewer that didn’t waste time on these dead-ends that, in their wildest dreams, might answer questions relevant only for a few short months or years.
But John Gruber is better than that, and we all know it, including Apple.
John asked real questions on challenging subjects, including gender diversity, my alleged software-quality decline, discoveryd problems, thinness trade-offs with battery life, the new MacBook, continuing to sell 16 GB iOS devices, and whether the Apple Watch should have shipped without WatchKit 1.0 apps since the native SDK was so imminent.
And Phil gave real answers to each one. Apple iterates, argues, and evaluates trade-offs. Sometimes they don’t get it right. Sometimes they’re more aggressive pushing the tech forward than power users like us think they should be. Sometimes there are trade-offs in product design that we don’t consider, or that we prioritize differently than they do.
Phil made quick, smart, informed references to Apple-related podcasts and sites, including mine, that made it clear that he personally reads and listens to our community.
I’ve heard that this was the case for Phil and many other Apple higher-ups for a long time, but I’m not sure it has ever been made so clear publicly.
Apple is listening.
Between the serious and technical discussions, Phil and John lightly joked about typography and sports teams with each other and the audience.
They had the great rapport of professional acquaintances who’ve known each other for a while and clearly respect each other.
I’d listen to their podcast.
Apple is just people. Their usual communication style makes that hard to see and easy to forget.
Phil’s appearance on the show was warm, genuine, informative, and entertaining.
It was human.
And humanizing the company and its decisions, especially to developers — remember, developer relations is all under Phil — might be worth the PR risk.
Or maybe he just thought it would be cool. He’s a pretty cool guy. I’m glad we got to see that, and we got to see that because of the career, personality, and perspective that John Gruber has been building for over a decade.
John has always seemed to want The Talk Show’s annual live show at WWDC to resemble his fond childhood memories of the Johnny Carson late-night TV talk show. Past years have been closer to that format and pacing, but this was nothing like it at all.
John isn’t Johnny — John is better. And I’d much rather watch this show than anything on TV. Talk shows on TV must be liked by everyone; podcasts sell out live venues by being loved by a niche.
This meant a lot for both John and podcasting. Apple sent an executive to be interviewed on a podcast, and one of the highlights of John Gruber’s career as a writer didn’t involve writing at all.
I’m just hoping he can get Moltz for next year’s show, because I sure as hell wouldn’t want to follow this.
Special thanks to the App Documentary guys for lending me the camera to shoot these photos at the event.
Our WWDC 2015 special from San Francisco.
In How I Killed App Sales By Going Freemium, Shuveb Hussain recounts switching his send-to-Kindle app from $1.99 up front to a free-with-in-app-purchase model:
This is what I came up with: A free app that allowed 10 free articles initially, enough for users to get a taste of the service. After these “article credits” ran out, users would still be able to send one article every day for free. To overcome the one article per day restriction and send articles anytime, users could buy “article credits” via in-app purchases and send articles anytime.
Actually, one article per day was enough for most users. […]
In the past 20 days, Comfy Read 2 has seen just 5 in-app purchases.
Freemium is hard. Its effectiveness depends on where you can put that purchase barrier in your app. Many app types simply don’t have a good place for it.
In this case, Shuveb faces the fatal combination of two major problems:
These seem like opposites: the free tier is both good enough and not good enough. What makes freemium so tricky is that these can both be true simultaneously, and for many app types, this can’t be resolved. That’s why it’s so hard for many apps to succeed with a freemium model.
I spent months debating which features should be behind Overcast’s in-app purchase. If I limited the number of subscribed podcasts for free users, I’d be discouraging people from trying new podcasts. If I put Smart Speed, Voice Boost, and my smart playlists completely behind the paywall, most users would never experience my best features and wouldn’t think my app was very good. But if I kept the paywall too easy to avoid, like showing ads with a purchase to remove them, it wouldn’t sell well. (No-ads upgrades never sell well, by the way.) And whatever features I limited would be free in many competing apps, including the one Apple includes on every iPhone for free.
What I came up with — unlimited general usage and most features being free, with limited demo-like access to premium features before purchase — was a tricky balance and a compromise. Freemium always is.
Paid-up-front isn’t always easy and doesn’t always sell well, but it is much simpler.
The best battery life in the 15-inch Retina MacBook Pro line is the base model (without the high-powered GPU), but Apple’s stated 8–9 hours of battery life is only achievable with very light use — if you’re using tools like Xcode, Logic, or Lightroom, you’re lucky to get more than 4 hours.
I used to eke more battery life out of my 2008 MacBook Air by underclocking and undervolting its CPU to a lower speed with CoolBook, but that’s no longer possible on modern Macs.
Modern Intel CPUs use Turbo Boost to dynamically increase CPU speed, depending on workload, up to their thermal limits. The advertised clock speed — 2.2 GHz for the base-model 15-inch — is only the guaranteed minimum.
Turbo Boost Switcher can temporarily disable Turbo Boost, and I was curious to see if disabling it would meaningfully affect battery life.
I devised a simple battery-testing script to simulate light and moderately heavy loads on my brand new, mid-2014-generation, base-model 15-inch Retina MacBook Pro: it loads some popular websites in Safari over Wi-Fi, spending some time scrolling down each one, while playing music in iTunes, then appends the time and battery status to a file in Dropbox, which promptly gets synced. This cycle repeats indefinitely. For the moderately heavy load, the cycle also includes a clean and full compile of Overcast’s iOS app using
xcodebuild every few minutes.
I ran this test at 50% brightness (with auto-adjustment disabled), no keyboard illumination, and sound muted until the battery ran out and it shut down. Before running the test, the battery’s cycle count was just 2.
When plugged in and fully charged, I also ran the Geekbench 32-bit single- and multi-core benchmarks, and observed the power range drawn from the wall with a Kill A Watt.
My “Heavy” numbers with Turbo Boost line up well with the very similar 2013 model in AnandTech’s “Heavy” battery test, which gives me confidence in my test. While AnandTech’s “Light” test appears lighter than mine, neither of us could reach Apple’s “8 hour” claim for this model, which is disappointing.
|Peak CPU temp.||90°C||60°C|
|Average Xcode build||22 sec||30 sec|
|Average web loop||133 sec||134 sec|
|Battery Life, Heavy||4:02||5:10|
|Battery Life, Light||5:40||7:07|
Disabling Turbo Boost hurts performance of CPU-intensive tasks by about a third, but doesn’t significantly slow down lighter tasks. The MacBook Pro also runs noticeably cooler, and gains about 25% more battery life.
This won’t be worth doing all the time, but it’s nice to have the option.
And I’d still like to see higher battery capacity in normal operation. This is far from a solved problem, and far from any reasonable definition of “all-day” battery life. I hope Apple agrees.
Google Photos, Thunderbolt 3 over USB-C, WWDC predictions, and pears.
Casey Liss’ review of “Underscore” David Smith’s new app, Take Me There.
Even cooler: David made a timelapse video of building the entire app.
Marco Arment wrote last week about a partial list of questions about the Native Apple Watch SDK and I thought I’d do the same and add mine below:
Review by Federico Viticci and a great interview with lead developer Brian Donohue.
I can’t believe how much better Instapaper has gotten since Betaworks took over. They’re doing a hell of a job.
App Camp For Girls is on a mission: we encourage girls to pursue app development as a career by teaching them how to make iPhone apps in a fun, creative summer camp program under the mentorship of women developers. We are shifting the gender balance in our industry. App Camp 3.0 is the next stage in bringing the program to more girls in more locations!
Help bring this great effort to more people, and help close the inexcusable gender gap in tech. Donate now.
Play each sample as much as you’d like in three encodings — 128k MP3, 320k MP3, and uncompressed WAV — and try to identify the uncompressed WAV.
I did slightly better than random selection:
You got 3 out of 6 correct!
Do you spend a lot of time listening to high-quality audio files? Adding specialized equipment to your system can boost the audio quality, but if there are weak links in the chain (say, if you’ve got a digital-to-analog converter and cheap earbuds), you won’t hear as much. Bonus hint: Scroll back up and listen to the uncompressed WAV files again – even self-proclaimed audiophiles say that it takes time for your ears to adjust to the differences in files.
This is what’s so frustrating about audiophiles: they convince themselves, and others, that there’s always more sound quality to be had (and noticed) with an endless money pit of obscure components and upgrades.
But I was already listening with plenty of “specialized equipment”, and even on the ones I got right, I couldn’t really identify what about it sounded better, and any differences were so hard to detect that I wasn’t very confident in any of my choices. I was really straining to hear any difference at all, and I’m not sure I really did.
NPR’s “hint” to then listen again to the now-labeled uncompressed files, since “it takes time for your ears to adjust”, is, of course, bullshit. If they tell you one is better, you’ll subconsciously believe it’s better. This is why blind tests exist.
I stand by my prior assertion that speakers and headphones matter a lot; amps matter a little; and cables, DACs, higher-than-256k bitrates, and higher-than-44/16 sample rates matter so little that almost nobody can blindly detect differences between them. Allocate your budget accordingly.1
The most noticeable quality improvements, by far, come from better-recorded music and better speakers or headphones.
Of my setup: the headphones are incredible and worth every penny, the amp is the cheapest amp that can handle their unusually high power demands, the DAC wasn’t really necessary, and I use cheap cables, well-encoded MP3s, and iTunes without any weird plugins. ↩
My four favorite podcasters have paired up and made two new Relay shows. This should be a great summer.
“Underscore” David Smith:
I find it very difficult to tell the difference between an almost filled exercise ring and an actually filled exercise ring.
I love his suggestion for improving the design.
In Upgrade episode 38, Jason Snell and Myke Hurley had a great discussion about their use of Google products as Apple fans, and asked listeners to tell them why they do or don’t use Google products.
Their main argument was that both companies have flaws and sometimes do bad things, but Google’s services were the best, so any ethical differences were a worthwhile tradeoff to them.
We agree on the broad strokes, but the reason I choose to minimize Google’s access to me is that my balance of utility versus ethical comfort is different. Both companies do have flaws, but they’re different flaws, and I tolerate them differently:
How you feel about these companies depends on how much utility you get out of their respective products and how much you care about their flaws.
Simply put, Apple’s benefits are usually worth their flaws to me, and Google’s usually aren’t.
* * *
There’s a widespread assumption that heavy use of Google products is unavoidable and that they’re always the “best”. That hasn’t been my experience.
I’m still very happy with DuckDuckGo for search, and Apple Maps has been no worse than Google Maps for me recently. My standard IMAP email host, FastMail, works great, and the spam filtering is nearly perfect since I’ve put MailRoute in front of it — I’ve heard it’s better than Gmail’s.1
I suspect the ease of switching away from Google depends primarily on whether you use Gmail. I never have — it solves problems I don’t have, and I greatly prefer native IMAP email apps — so Google has never had deep integration with my data or a significant presence on my iPhone.
I didn’t set out to aggressively quit Google-everything, but once I changed my browsers’ default search engine to DuckDuckGo, that has mostly happened. The most surprising part was how easy it was for Google to mostly fall out of my life, how quickly it happened, and how little I missed it.
I don’t actively avoid Google today — I don’t hate them. I still participate in a shared Google Doc and calendar for ATP, and I still occasionally go to search and Maps for a second opinion. But Google has become far less relevant to me, I don’t depend on it for anything, and I feel better about that.
In a fun crossover with Rocket, special guest Christina Warren joins us to discuss Pebble Time, the Apple Watch native SDK, and Jony Ive’s promotion.
Jeff Williams confirmed yesterday that Apple is releasing the SDK for native Watch apps at WWDC. This is a pleasant surprise a few months earlier than I expected. I have many questions, most of which I hope will be answered in two weeks:
This is very soon after Watch OS 1.0. Will it be stable but limited, powerful but immature, or the worst of both? (The best of both — stable and powerful — seems unrealistic this early for the platform.) I’m guessing it’ll be stable but limited.
The Apple Watch is much more constrained than any iPhone in screen size, battery life, connectivity, and practical interactivity. App interactions must be as fast and simple as possible, and the screen can’t be on for very long without a significant battery impact. I think designing Watch 1.0 software to be good, useful, and responsible with the most limited resources (battery power and user patience) will be harder than writing apps for the first iPhone.
Background operations and multitasking are significant battery drains. Will any be possible? If so, what new limitations will apply? (My guesses: No background refresh, no background URL sessions, aggressive termination of backgrounded apps after a brief task-completion window, and maybe continuous background operation for audio and GPS apps.)
Which Foundation APIs will be available? Will any of UIKit be available, even if it’s just the lower-level bits and pieces like UIColor and UIImage? (My guess: Most of Foundation and some of UIKit, but no stock iOS view controllers or UI controls, which will be replaced with Watch-native, simpler alternatives.)
AVFoundation, Core Image, and Core Audio are huge and complex, but required for lots of app types. Will any audio, video, or image APIs be available? Will they only be possible through limited, high-level interfaces?
WebKit appears to be missing from the Watch. What other major APIs are missing or will be unavailable in the public SDK?
Will apps be permitted that must leave the screen on for long periods, like video playback or action games?
How fast is the Watch? How much of the 512 MB of RAM will be available to apps? (My guess: A4-class performance, and maybe a third of the RAM available.)
How much storage can Watch apps use?
Presumably, Watch apps will be bundled with iOS apps. How can Watch apps communicate with their iOS counterparts? Will they be able to read shared containers, presumably only when the phone is within range? Will there be any built-in methods to sync data between an iPhone app and its Watch app?
How quickly can data be transferred to a Watch app? Can it transfer over Wi-Fi even within Bluetooth range to speed up large transfers, or will it be Bluetooth-only when possible to save power?
Will a Watch app be able to fetch data from its iPhone app whenever it wants, or only during user-initiated times such as Handoff? Will Watch apps be permitted to download large files or stream data continuously from the internet, their iPhone app, both, or neither?
I’m assuming native Watch apps can present all three current WatchKit views — apps, glances, and custom notifications. Can our glances have buttons and controls on them, like Apple’s, or not, like WatchKit glances?
Can we make third-party watch-face complications? (I assume we won’t be able to make faces.) If so, how will the many shapes, sizes, and colors be enforced for a consistent look? How often will they refresh their data? Can they make network requests?
Can Watch apps include in-app purchases?
Can our apps become locked as the “active” app that shows immediately on wake instead of the face, like Workout and Remote? (I assume not.)
Will most people’s battery life take a big hit after native apps are widespread, since more apps will likely be in frequent use, the screen will likely be on more often and for longer spans, and some background updating may be happening?
A new platform is an opportunity for Apple to advance internal political goals. Will Watch apps be required to be written in Swift? Will ads be allowed? Which app types and features that are allowed on the iPhone will be prohibited on the Watch?
On all of these, I have no idea. This will be an interesting summer.
My friends at Lickability asked a while back if I’d be interested in selling Bugshot to them. Since it was worth approximately $0 under my stewardship and I had no plans to ever update it again, I just gave it to them and wished them the best, hoping they’d someday do something with it. Now, they have.
And what an update! They’ve rewritten it from the ground up with a more modern UI, better device support, multiple colors, deletion, and the most requested feature I ever got but never implemented: text annotations.
If you had Bugshot, you already have Pinpoint — it’s the same app ID in the App Store. If not, go get it for free. And if you all go out and buy the color pack, there can be more to come.
See Federico’s review as well.