A little less than a month ago, I was in the honeymoon period after signing up for Spotify for the very first time. I was impressed with Spotify Connect and the integration with the Amazon Echo. But having been burned pretty badly by Apple Music, I wasn't ready to fully commit to the streaming lifestyle. I set a reminder a couple days before my trial was set to expire called "cancel Spotify?"

This past week the reminder fired. My phone buzzed, I pulled it out of my pocket, and I immediately swiped the notification and tapped "Mark as completed". There's no way I'm canceling Spotify right now, for a few reasons.

I'm far from the first person to say it, but Discover Weekly is the killer feature that sets Spotify above Apple Music and all other comers. I've put a handful of new-to-me albums into heavy rotation as a result. I've found Good Graeff, a Spotify minnow with around 10,000 worldwide listeners, who are quickly becoming my current favorite band.

It's hard to put a price tag on that experience, but $2 per week seems very conservative. Some months that covers the entire Premium subscription fee; other months, $2 are leftover to go towards access to nearly every other song on the planet. Apple Music always felt like the full $10 went just to catalogue access, even though they're putting in more human curation effort.

I am bafflingly lost every time I try to use Music on iOS or iTunes. When my Apple Music trial expired, I more or less stopped listening to music at work because my library was so inaccessible (I had relied on iTunes Match before). On Spotify, I still have some organizing to do: I feel like I don't yet have a library there. But on the other hand, I don't need one; search is adequate. Even in the Mac app, which is little more than a web view wrapper and doesn't even have a ⌘F keyboard shortcut, searching is faster and more effective than in iTunes. (Better than iTunes, an app that at its introduction touted type-ahead search! It is not hyperbole to say that iTunes has regressed.)

I used to roll my eyes at Spotify links and embeds across Twitter and the web because I thought I couldn't listen to them. But Spotify is the lingua franca of music sharing, and it is accessible with just a free account. An Apple Music link is a dead end to someone who's not a paid subscriber. Apple needs to find a compromise between having a premium-only service and being so exclusive that they drive away business. I should know, because I've taken mine elsewhere. I've paid my first Spotify bill and it won't be my last.

I’m going to send my Spotify bill to @cue’s house.

Everybody needs to use Bittorrent sometimes. (If you couldn't pay for something if you tried, or it was offered for free in the first place, it's not piracy. But that's a separate topic.) I relied on µTorrent for years before dodgy business deals made it an adware-infested dumpster fire. That sad turn of events led me to try Transmission, a longstanding Mac client with Apple-like simplicity. I set it loose on a very large, very popular torrent, and it immediately brought down my entire home network.

No matter what I did, Transmission would only run for a couple minutes at best. While it was working, it was nearly saturating my 50Mbps downstream, so I got the hint that it was somehow doing too much traffic for my network to handle. In fact, it was trying to make too many connections over a single socket. (This was never a problem with µTorrent, which must have been making, breaking, and organizing connections differently.)

I assumed that I would have to change a setting in my router's admin control panel to fix the issue. If the relevant settings weren't available, I'd have to consider installing third-party firmware (a mess) or replacing the router entirely (a thought I apparently have frequently). In fact, since it was outgoing connections that were causing the trouble, I only needed to change a setting on my iMac. The maximum connections parameter is controlled by the Unix networking stack at the heart of OS X. Opening a terminal window and typing sysctl kern.ipc.somaxconn=4096 (system control – kernel – IP control – socket maximum connections) allowed more than ten times the number of connections.

And by "system" they meant "every device on your network".

That wasn't a flawless solution to the problem; I also added another safeguard by limiting connections in Transmission's settings. One of the problems is that Transmission seems to be very slow to close connections. Transmission's preferences limit active connections, but setting a limit of 100 there might allow 500 or so total connections to accumulate as peers come and go. Setting it to the same number as somaxconn is still a recipe for having Transmission clobber your network. Of course, the optimal numbers for your setup may vary, but you should be able to arrive at a combination that works. Then nothing will stand between you and the 100% legal "home movies" you want to download.

I've learned to love and hate Back to My Mac since I purchased my iMac last fall. In theory, it's great to have a lifeline to my files that's faster than a Backblaze restore and broader than Dropbox. And beyond that, there's the promise of using Screen Sharing to make my desktop computer somewhat mobile, as long as I have a device with a large enough screen and fast enough internet connection. In practice, since my home upload pipe is pretty wide, both file and screen sharing have been flawless…as long as I can connect.

All Back to My Mac really does is keep track of the public IP addresses associated with your Macs and make that information invisibly available via iCloud; the connections then happen over the AFP and VNC protocols. But even if that address doesn't change, should Back to My Mac somehow lose its record, your Mac is adrift in the vast sea of the internet, inaccessible. Sometimes that's an inconvenience; sometimes it's a disaster, if you're counting on remote access — something I've trained myself out of doing.

There are 1,001 things that can go wrong across the local and wide area networks that separate two Macs. On a couple recent occasions, I've solved Back to My Mac connection failures by restarting the client computer, not the host. Other times I've simply been at a loss to solve anything at the remote end. I've thought about setting up some kind of recurring script on my iMac to refresh Back to My Mac, but I'm not sure whether it would help or harm reliability.

I do wonder if my reliance on a cheap TP-LINK router causes all of my problems. It delivers perfectly fine coverage and speed in my home, but its NAT features are a mystery to me and, it seems, to OS X. I know that there is one Back to My Mac feature that does require an Apple router: waking a sleeping Mac by sending a "magic packet". Whatever I saved on my router purchase, I've probably already paid back in electricity bill (and broader environmental impact) by forcing my iMac to never fall asleep while I'm out of the house, just in case I want to access it. It's a price I'd be willing to pay if leaving my Mac on always would guarantee always-on access. I know Apple can't account for every peculiar home network configuration, but I wish the path back to my Mac was a little clearer.

There's a mild yet deep unease that Apple's commitment to privacy could put them in a tough spot as competitors ramp up their data-gathering and machine learning efforts for next-generation digital assistants. Personally, I appreciate Apple's principled stance on privacy as it becomes clearer every day that strong, end-to-end encryption is the only way to keep my data safe from bad actors (including the state).

Recent discussion has concluded that Apple's reluctance to process data in the cloud — you can't turn over what you don't have — means that Siri is never going to get much smarter. After all, Google's assistant will be able to crunch on your search history, location data, and thousands of Gmail messages to deliver the right response. Apple wants Siri to learn too, but only in the local, on-device context. Add an iOS device to your life or replace your phone and it's like Siri is meeting you for the first time.

It seems like an intractable problem: a user profile that never connects through the cloud will be incomplete. How can the devices talk to each other without a potentially compromising holdover on Apple's servers? Simple. The same way they already are: iMessage. Whenever you log into a new device with your iCloud ID, your existing devices go "Hey, hey, hey, I see a new device!" It's because of clever cryptographic infrastructure. Your messages are all signed with a key that isn't unique just to a device, but to a particular set of devices: your devices. If one joins or leaves, that signature changes. Meanwhile, billions of messages are encrypted multiple times and delivered reliably every day. And of course, in the context of iMessage, they can contain attachments, audio or video.

What if little bits of data about your Siri habits could be wrapped up in the same way? Well, Apple has already done that too, going all the way back to the iPod and iTunes' Genius feature. The iPod couldn't compute music recommendations, so it had to be done on the Mac, packaged up, and sent over. If you sync music to an iOS device over USB, you'll still see this happen, with thousands of song similarity files slowly flying by.

Quizzical. Pataphysical. Slow.

So what's to stop creating a similar format for assistant data, encrypt it with the iMessage protocol, and silently sync across devices? If it becomes data-intensive, it could be designed to only trigger when plugged in and on Wi-Fi, like iCloud backup.

I've made this seem like a simple solution, the flick of a switch, when in reality it's the interconnection of several complex pieces of infrastructure. But it's infrastructure that Apple already has built, tested, and proven — they aren't behind. So I'm holding out hope that Siri can keep my secrets and still become more ingenious.

Last week I talked about app switching on iOS as if it were a totally solved problem on the Mac. It's not, especially if you bring app launching into the picture. There are several ways to open apps on OS X: the Dock, Spotlight, the Finder, and the much-maligned Launchpad. Rewind further to the classic Mac OS and you'll find the Launcher control panel, an application-switching menu and palette, and the reluctant import of command-tab based on its popularity on Windows and as the freeware LiteSwitch.

One common feature among app-switching methods is showing which applications are currently running. On iOS, this distinction isn't made; I argued that it should be, as it would benefit novices and experts alike. On the Mac, only running apps show in the command-tab switcher, with a single and recent asterisk: an app available for Handoff will appear on the far left, before the frontmost app. And although Apple has threatened to kill it several times, there's a system preference that controls whether a dot appears next to running applications in the Dock.

I rely on those dots, especially when managing memory usage on my MacBook Air, which only has 4GB of RAM (it's my work machine — the configuration wasn't up to me). But I have to be careful about trusting them too much, especially after a restart. System-wide restoration of open apps and windows is a great feature in OS X, but it makes the Dock dots lie. If an app was running but with no open windows, after restart it will show as running, but the app doesn't relaunch in any way. You won't find it in Activity Monitor or, indeed, in the command-tab switcher. It saves RAM, which is great until you realize that you haven't received any emails for hours because your "running" email client actually wasn't.

I understand the desire to simplify by ignoring the status of apps, especially in a world where cold app launches can often be measured in milliseconds; then low RAM ceilings only restrict simultaneous use of apps. But aggressive killing of apps (either by the user or the OS) may affect the ability to check for updated information or receive notifications. Perhaps someday we'll have no need to care what apps are running. Until then, clear and accurate app switching interfaces are necessary, and that means both the Mac OS and iOS switchers need continued attention.

Reminders on iOS have gained several new features since their introduction in iOS 5. When Reminders launched, it was almost difficult to use. Setting a reminder meant tapping through several screens to set the task, due date, and location. Siri sped up the process significantly, making it possible to set a complex reminder with a single spoken sentence. And the Notification Center widget made viewing time-sensitive reminders just a swipe away, system-wide. In fact, those augmentations are almost exclusively how I set and complete reminders; I rarely open the app.

Since the Reminders widget is my primary visual interface, I want it to be as smart as possible. It tries to selectively show upcoming and past-due reminders, so your entire Notification Center isn't overwhelmed with to-dos. But I find it's notion of what reminders are due "soon" to be far too permissive. I've set a daily recurring reminder to water my plants at 5:30, around the time I get home from work. Every morning at breakfast, there's my reminder that I don't want to think about for another nine hours plus. A shorter upcoming window would fix this, but even better would be the ability to set smarter reminder criteria.

That's literally the opposite of when I get home.

It's always been possible to set both a time and location trigger for reminders, even by tap-and-swipe in the pre-Siri days. But those triggers don't interact with each other; they just sit side by side. Asking for a reminder to repeat "when I get home tonight" just means it will fire off at 7:00 PM and whenever I arrive home, even if I go home for lunch. The time can't act as a gating factor on the location, which is what we mean in natural language. This is because while features have been built on top of reminders, their basic structure and capabilities haven't improved in five years.

Yes, I could resort to other apps to gain some of this functionality. For example, I could set a recurring OmniFocus task with both a start and end time to restrict its visibility. But barring the introduction of a Siri API, I would never be able to do that with my voice. Having smarter reminders built in isn't an unreasonable request, and Apple's line can't be that simple reminders are good enough when what you say is not what you get. And if Siri is to truly become a smart assistant, it would be great if it could use contextual information it already has access to, taking commands like "remind me to put out the trash bins before it gets dark." These kinds of improvements should be on the iOS team's radar — or in their Notification Centers — they're due soon.

If you read Picomac or have a podcast application with good shownote support, you probably noticed the animated GIF in yesterday's post. As much as the rest of that post was about applying simple tools, that file only got created after unsuccessfully trying several overly complex approaches.

To my credit, I remembered that I could create a basic screen capture video just with OS X's included QuickTime Player app, even though its current incarnation as part of QuickTime X has limited features compared to previous versions. It even allows for selecting a region of the screen (so you didn't have to see the mess on my desktop) and trimming the file (so you didn't have to see me moving the mouse to start and stop the recording). At that point, I had a .mov file. I would have been happy to include it directly in the post, but Squarespace only allows video embeds from services like YouTube and Vimeo.

"Fine," I thought, "I'll just make a GIF of it! That'll be easiest!" A quick search revealed that my best bet would be a dedicated app like GifBrewery, but in a fit of stinginess, I didn't feel like putting down a few dollars on an app to create a single image file. My next move was "There must be some way to do it on the command line," and StackExchange did not disappoint. I wasn't even intimidated by ffmpeg -i in.mov -s 600x400 -pix_fmt rgb24 -r 10 -f gif - | gifsicle --optimize=3 --delay=3, but it required some command line tools that I didn't have. Three failed homebrew installs later, I realized that somehow I lost my copy of the Xcode command line tools — perhaps during a recent OS install.

It was all becoming too complicated. Higher up the StackExchange thread, someone had suggested the site online-convert.com. A comment backed it up, saying "Works like a charm, free and they don't collect your email address." My little window-resizing movie contained no personal information and I wanted to post the resulting GIF publicly anyway. It was worth a shot; at worst, I'd wind up with a useless file. As it happened, whoever runs that site and was willing to provide me a few spare CPU cycles did a great job. The file met my needs and went into the post.

And so, as I opined on what it means to be a power user, I learned a lesson. Sometimes the power user move is letting someone else do the work for you.

Sometimes it seems like being a power user is the ability to pull off complex tasks as a unit. The truth is that much of the power comes from a small toolbox, liberally applied. Some of the most important tools are very simple: the modifier keys shift ⇧, command ⌘, and option ⌥.

One reason it's difficult to master modifier key tricks is because they're so abstract. Option can do one of ten things in ten different contexts: moving a word at a time through text, copying a file, etc. A common use of option in graphics applications is when resizing a selection or object. Grab and drag a handle while holding option and the action is mirrored, keeping the center of the object fixed.

So why would you ever expect to be able to apply this knowledge in, say, the Finder? The only thing you can resize there are windows. They certainly don't have grab handles, not even in the bottom right corner like they did in the classic Mac OS. But they don't need them; as of Lion, any part of a window border can be resized, edge or corner.

And, I discovered completely accidentally, holding option has exactly the expected effect, in the Finder or any application. It's a little weird at first, and can be impractical when dragging from a corner.

But I find myself using it quite frequently when dragging a side edge. If I'm single-tasking in a browser, I'll want the window front and center, but not full-width — it either stretches out the page design or just leaves blank space. Now I can quickly get the window just where I want it by zooming to fill the screen (another option trick, it turns out!) and then option-dragging from the edge of the screen towards the middle.

And, believe it or not, shift also works on edge and corner drags. That's most useful when trying to zoom media in apps like Preview or VLC, which don't automatically constrain window proportions. These are simple tricks, but when used at the right time they make accomplishing a task smoother, or quicker, or generally more powerful.

Google's preview of Android N at I/O last week showed off a revamped app switcher interface. This has sparked some thoughtful discussion, particularly surrounding the inclusion of a "clear all" button. It seems obvious that app switcher interfaces are failing many of their users. Most people shouldn't have to be concerned with the distinction between open vs. suspended vs. purged apps, but that means they probably don't understand why their phones aren't operating properly after they repeatedly purge all. It's impossible to say whether Android's solution is a good one without knowing the technological implications of pushing the big red button (it's not actually big and red, but it sure seems like a kill switch). But we can ask what would make for a better app switcher in general.

The typical form of an app switcher is fixed by precedent: display apps in the reverse order that they've been used. Only after that do the real decisions get made, like whether only active applications are shown in the switcher. The answer is typically "yes" on the desktop, while on mobile, app switchers often scroll on and on to the beginning of time — apps last launched months ago. That made sense when the multitasking tray was first introduced in iOS 4. It was just a quick switcher; apps were being immediately killed when the home button was pressed, so every app in the tray had the same status.

With true multitasking that's not the case. Some tiles in the iOS switcher are "live" while others are "dead", purged to free resources. Even purged apps need to stay in the app switcher to stay eligible for background refresh, so removing an app that's no longer in RAM only does harm. But there's no reasoning with compulsive quitters; they'll swear they're doing good. It means that interface designers have to choose their battles. Android N's "clear all" button concedes that users want to see zero apps in their switcher, regardless of what that means to the operating system. It's a time-saver, eliminating flick after flick after flick.

Good app switcher design could benefit all users, saving time for quitters and providing useful information to power users. The iOS app switcher should only show apps that are suspended, still in RAM and ready for immediate reactivation. (This is similar to desktop app switchers, although there users decide when to quit apps, not the operating system.) This would limit the number of apps displayed to ten or so, but I frankly never look for an app farther back than three or four (Springboard or Spotlight are faster than hunting that far back in the app switcher). It's a simple solution that meets everyone's needs: power users can see exactly which apps are currently running and quit problem apps; most users will learn that the app switcher only shows "open" apps; and quitters will waste less of their time. Win, win, win.

For a couple of months I've been using Fantastical for Mac to manage my home and work calendars. Fantastical has been my calendar app of choice on the iPhone for years — I particularly prefer its information-dense widget. But on the desktop it never did much for me, and this past week we had an ugly breakup.

I couldn't even consider Fantastical on the desktop until version 2.2 was released, featuring Exchange support — necessary for my work appointments. At first, it handled many aspects of scheduling work meetings with invitees and room reservations better than Calendar.app. The "View Availability" window is larger and more functional (Calendar.app has a maddening bug that makes it occasionally fail to show scheduling conflicts). And of course I benefited from Fantastical's natural language syntax for event creation, although I never was able to invite Exchange contacts without separately editing the invitees field.

That, however, is where the positive differences ended. The week view — which I spend most time in — continually puzzled me. The main part of the window looks identical to Calendar.app, down to the minimalist styling of the event blocks. Then there's the sidebar, which adds two more views of the same data (month and list). It's information overload, and the sidebar can't be hidden. That means that even in fullscreen on a small laptop monitor, ordinary event names often get truncated in week view.

Worst of all were the errors. Random, persistent, fatal Exchange errors. Errors so bad that I didn't know that they were silently breaking my Exchange account setup even on other clients. When my trial period expired, I opened Calendar.app to find that I could no longer create events or respond to invitations. At one point during troubleshooting, I had mucked about with Calendar.app's cache files to the point that all of my calendars vanished, both Exchange and iCloud. I hadn't planned on paying to register Fantastical, but I had a moment of considering putting up the $49 on the off chance that it would ransom my data.

Itsycal's minimalist interface

Others considering Fantastical will also have to wrestle with the price tag. I'm not beyond paying around $50 for truly useful desktop software — PDFpen, Hazel, and the like. The fact is that those $50 would buy me so little with Fantastical. I have natural language entry in Fantastical for iPhone ($5) or Fantastical 1, which still runs on El Capitan. The menubar-docked miniature view can be replaced by the free Itsycal, which I find to be an improvement for its smaller size and the readability of its light color scheme. So while Fantastical for Mac hasn't met my calendaring needs, fortunately other apps have, including Apple's own.