all micro contact rss

Wearable Challenges

Well, it’s finally come to this.

airPodsWithSleeves

After more than a year of walking around New York with my AirPods, I finally gave in and bought these silicon hooks from EarBuddyz to keep the darn things from slipping out of optimal sound position, or worse, falling out of my ears altogether.[1]

I had remarked when I first got my AirPods that they were not exactly a snug fit. Over time, it seemed like they were actually getting looser, if that’s possible. My ear holes have gotten bigger over the past year, I suppose[2]. Factor in obstacles like scarves, hats, balaclavas, and other accoutrements of winter, and you can imagine a scenario where AirPod “incidents” were on a sharp rise over the past month.

Fortunately, these sleeves do their job, and now I can move around as much as I want without worry. The AirPods not only stay in my ears now; they also stay in the optimal position for sound, which is great. I can finally lie in bed on my side and my AirPods stay put, which is also great.

What’s not great? Having to take the sleeves off to put the AirPods back into the charging case. And then having to keep the sleeves somewhere safe while the AirPods are charging.

More importantly—the very notion that these sleeves are necessary is a big problem in my mind, because it speaks to Apple's design team overlooking basic variance in human anatomy. The experience of wearing these, being constantly reminded that my ears are bigger than what Apple considers “average” takes a bit of the sheen off an otherwise phenomenally executed product.

Lots of criticism has been lobbed Apple’s way in recent years regarding computers. I never pay much attention to these nitpicks. Apple knows how to make computers, and despite not being able to make absolutely everyone happy 100% of the time, the computer business is going to go just fine for Apple for many years to come. Tech is not Apple’s problem.

But if wearable technology becomes a huge part of Apple’s future—and I believe it will—Apple has some design challenges ahead of it. First and foremost, Apple needs to acknowledge that human bodies come in all shapes and sizes. So making one size of any wearable device is never going to fly.

Apple did a better job with Apple Watch, at least, offering two different body sizes and various watch straps that adjust to many different wrists. There are still some bands that I can’t quite get to fit perfectly, and I’m sure even more sizes would be welcome for some. But at least there’s an acknowledgement that not everyone has an equal-sized wrist.[3]

I’ve been hearing rumors that Apple’s next big wearable will be eyeglasses. Think Google Glass, but done by Apple, which could be a compelling product.

But then I think about the last time I went shopping for new glasses. I literally tried on fifty to sixty different frames before I found one I didn’t hate. Even with companies like Warby Parker allowing you to virtually “try on” several pairs, I have yet to find a pair in their collection that looks good on me.

I wonder just how it will be possible for Apple to mass produce glasses that are the right fit for the entire population. And how will they keep enough stock of all the various varieties in a retail store?

Nevermind what the technology can do. If it looks terrible or doesn’t fit properly, people are not going to wear it. And there’s no such thing as one or even ten pairs of glasses that would cover everyone comfortably. So either Apple needs to partner with frame makers to incorporate their technology into existing frames (which is doubtful, given Apple’s tendency to want to control the entire widget), make a product that somehow attaches to any frame (also doubtful, as it would likely be clunky), or be prepared to design and manufacture hundreds of frame designs and build each Apple Glass product to order.

Considering unique prescriptions, it becomes clear that Apple Glasses would have to be made to order for most people, anyway. Is Apple prepared to become experts in creating prescription lenses? Are they prepared for the extra complexities of customer service and regulations surrounding that industry?

To me, the entire tech sector needs to seriously rethink its approach if technology is meant to become wearable. This is new territory. Industrial design is starting to merge with fashion design in a big way.[4] Manufacturing bespoke wearables for the individual instead of one product that fits all is not something Apple or any other computer company has had to do before on a mass scale.

I hope Apple is hiring accordingly. This is a real opportunity to not just innovate in the tech space, but to bring Apple’s skills in mass production to other realms.

Maybe the first generation of AirPods was just a test balloon to see how sales went? If that’s the case, I think by now Apple can justify an expansion into new sizes. I’ll be watching with curiosity this year to see what develops. Getting a few different sizes of AirPods would be a good sign that Apple is getting more serious about wearables in general. And it would mean I could go back to not needing any hacks to enjoy listening to music again.


  1. I actually tried two other silicon sleeves first. The ones that just go over the buds and don’t provide the extra “hook” for the lobe, and the super-thin ones that fit inside the charging case. Neither kept the AirPods in position for me, so they ended up being failed experiments. ↩︎

  2. It is true that while our heads eventually stop growing, our ears continually get bigger as we age. I don’t know whether that applies to the ear canals, however, or just the outer ear. ↩︎

  3. Even my own wrist continuously expands and contracts throughout the course of an average day. I find myself adjusting loop bracelets two or three times daily. And my Link bracelet will go from snug in the morning to loose on my wrist in the evening often. ↩︎

  4. And the fashion world hasn’t even solved these sizing issues to anyone’s satisfaction. Don’t get me started on how “rack” clothes are cut vs. what actually fits most people. ↩︎

Clear and Verifiable

The way in which Aaron Sorkin describes Intention and Obstacle in the early bits of his Masterclass is so simple, so easy to comprehend, and most importantly, so easy to test [1]. In just a few minutes, he offers a simple way to detect whether there is an appropriate level of conflict in any story. You can apply this lesson to any screenplay or script that you read, including your own.

Sadly, that sort of simple clarity is a rare thing these days. I recall when I was getting into coffee, I would hear over and over again about the famous 30-second “bloom.” You wet the ground beans and wait about 30 seconds before pouring in more water. Every expert I read recommended it. The instructions for my Chemex recommended it. I even included it in my long blog post about coffee methodology last year, though I had to confess I had no idea why I was doing it or
whether it made any difference.

And then one day a barista at San Francisco’s Four Barrel Coffee explained it to me. He said carbon dioxide gets trapped in the beans during the roasting process, which gets released when the beans first come in contact with water. You don’t want carbon dioxide trapped in your coffee, because it contributes a sour taste. So you wait about 30 seconds until most of the carbon dioxide is released into the air, rather than into your liquid.

Boom. Simple. Easy to verify online. And easy to test myself with my own coffee, since I now knew what to be looking for (a sour taste) when this step was skipped.

Who knows? Maybe you want your coffee a little sour. In that case, go ahead and skip the bloom, or shorten it a bit. Once you know why you are waiting, you can manipulate that timing to your liking, rather than blindly following the rule for its own sake.

I had never met a barista who didn’t do the 30-second bloom. But I also hadn’t met one who could tell me why it was important until that day.

So much “common practice” in various fields is accepted without question. I think experts are often intentionally ambiguous, as if they are protecting the secrets of a magic trick. And yet, it’s so important for newcomers to learn the why, not just the what.

No matter the field, when you are teaching people new things, try to use clear language that allows the learner to repeat and test concepts in their own work. And encourage them to actually experiment. Ideally, you want your students to surpass your own abilities, and they can’t do that if they haven’t taken those lessons to the lab, so to speak.

You are a technician. And techniques are hard-won over years of practice. You shouldn’t expect others to blindly accept your “rules” just because they work for you.

Your students need to know the why behind the rules before they can start breaking them. Otherwise, they end up breaking rules in a desperate attempt to be different. And that doesn’t elevate anyone’s work.


  1. While I don’t worship at the altar of all things Sorkin, as some do, I have tremendous respect for his talent for words. And now I have a new-gained respect for his ability to articulate his process. ↩︎

More Ups Than Downs

Rumor has it Apple is cooking up a new framework that helps unify the development of macOS and iOS apps. At least, that’s the part of the rumor that makes the most sense, anyway.[1]

Code-named, Marzipan, this new framework would help developers who make either iOS apps or Mac apps to make both using the same basic toolset. Obvious differences between the platforms would necessitate some variation, of course (clicks vs taps, and all that), but the underlying APIs for creating either would be largely the same. And thus, perhaps you could even create (and sell) a single app binary that is capable of running on either platform, if you choose.

Rather than a straight port of iOS’s UIKit to the Mac, as some have requested from Apple for years, Marzipan would more likely be a new framework that replaces both AppKit and UIKit in favor of something more modern and clean.

However they go about it, the million-dollar question is: Would this be a good thing?

Let me start with the short version: Yes. Of course this would be a good thing. There are downsides, to be sure. But to me, the good outweighs the bad here.

Let me start with the downsides.

This will lead to a lot of crappy iOS ports on the Mac

No doubt about it. Thousands of previously iOS-only apps will end up on the Mac barely altered with bad UI on day one. Count on it. Remember how many terrible watchOS apps debuted minutes after watchOS was made available? Apps that had no place on the Watch, that tried to do way too much on the Watch, that didn’t understand the utility of the Watch, and so on? That will absolutely happen on the Mac, too. It will still take time and effort to make a good Mac app, and many developers will not bother. They will try to make a quick buck.

But who cares? The last time I checked, there is already a ton of crap available on the Mac. A few thousand more bad apps will be a blip on the radar.

Here’s the thing: People who care about good software will find the good stuff. People who care to make good software will make the good stuff. There aren’t many people in either group. And there never will be.

Developers who care about making great software keep wanting the majority of people to give a shit. They don’t. Find your little niche and set your business model accordingly.

This will lead to a repeat of iPhone and iPad Universal apps

When Apple made universal storyboards available on iOS, the promise was it would now be easier to make apps that run great on both iPad and iPhone. Looking at the disparity between the number of iPhone apps and iPad apps available, Apple decided getting more apps on iPad was a priority.

The result was a ton of new apps that now run natively on iPad but are little more than “blown up” iPhone apps. They don’t use the extra power and screen real-estate available on iPad in any fundamental way.

There are some apps, however, built with universal storyboards that take full advantage of iPad. The problem here isn’t the tool, but rather the people using the tool. The same will be true for Marzipan apps.

In the hands of lesser developers, any tool will be used to create crap. That’s no reason for the rest of us to keep using clunky tools.

This will negatively impact some businesses

Some developers make iOS and Mac versions of the same app and sell them separately for a one-time upfront price. If Apple makes a “universal” buy once-run-on-any-Apple-device binary possible, the customer expectation is likely to shift, and people will simply expect to have to pay only once.[2]

I don’t have a lot to say to these folks, except you are correct. If you currently sell a paid-up-front app on iOS and Mac, there will be some customer expectation and pressure to make your app universal. And more than likely that will be coupled with the expectation of lower prices, too. There’s not a whole lot you can do about this, except:

  • Don’t go universal: Fantastical has pulled this off for years on iOS, refusing to make the app a single purchase on iPad and iPhone. They get complaints, I’m sure. But they aren’t exactly going out of business over it. And given there are a lot of iOS users who don’t use the Mac, there may be at least a slightly stronger argument for not having to pay extra for a Mac app they will never use. I suspect more developers will go the non-universal route this time around. And given this is not a simple matter of screen size, as it was on the iPad, a port of an iOS app to the Mac, even using Marzipan, is going to take quite a bit of time. It will be a while, in other words, before the pressure from other developers gets extreme to start selling your existing app as universal. So you have time.
  • Get out of the paid-up-front business. Apps like Ulysses have shifted to a subscription model for a reason. They see the future coming. Yes, I know subscriptions aren’t for every app. But two years ago, a word processor would have been on most people’s list of can’t possibly go subscription apps.[3]

Undoubtedly, businesses will fold after Marzipan. And that’s a shame. But many of those businesses are likely going to fail, anyway. Others will adapt. The world has largely moved on from paid-up-front software. We’re long past the point where Apple (or anyone else, for that matter) is going to hold back on anything because it might hurt paid-up-front app makers. Sugar-coating that would be cruel to those who have been and continue to be affected. Better to be honest than spread false hope.

Eventually, UIKit and AppKit will end up like Carbon

It stands to reason that after Marzipan gets released into the wild, both UIKit and AppKit will be on “borrowed time.” Just as Cocoa replaced Carbon, eventually Apple will very likely want all apps to be written using Marzipan.

This is not such a huge deal for small utility apps. But consider an app like Photoshop. Or BBEdit. Those are massive codebases. For any company that’s had a Mac app since the early days of OS X, Marzipan is going to mean a lot of work rewriting bits that are currently working just fine. And that sucks.

Even larger iOS apps, like Procreate or Ulysses, would not be a small conversion job.

Now, very likely, there would be a generous grace period, just as there was with Carbon, where AppKit and UIKit apps could continue to run and be updated. Marzipan will very likely be optional for at least a while. (I’m thinking right up until the entire Mac hardware line goes ARM.) And in the case of macOS, I’m sure AppKit apps would continue to run for a long time, even past the point where Apple stops accepting them in the Mac App Store.

But eventually, Apple will start dropping hints at WWDC: “We believe Marzipan (or whatever the official name will be) is the way to create the best user experiences moving forward.” At which time you’ll know you have a couple of years to get your legacy code converted.

There’s no way around this being a pain in the ass for some developers. In fact, if there’s one group of people who have the biggest reason to gripe about Marzipan, it’s the folks with the largest legacy codebases. But technology marches on. It would be hard to argue that Apple should have allowed Carbon to go on this long.

Another thing to consider: The retirement of Carbon led to new opportunities for a lot of developers. Legacy companies spent years rewriting their Carbon-based apps, which gave small indies the opportunity to start fresh in Cocoa, move faster, and create legitimate competition. [4]

With any luck, Apple will make the translation over to Marzipan as painless as possible. Who knows? Apple isn’t as powerless in this transaction as it was in the Carbon days. So they could tell us to go pound sand, if they wanted to. But I suspect they will want to make this transition smooth.

So that’s the bad news. What do we get in return?

At least a few good iOS devs who have never tried macOS development will likely give it a try, and vice versa

Gus Mueller wrote a piece last week about Marzipan, suggesting that no miracle framework can be a panacea for all the problems associated with porting iOS apps to the Mac. He’s absolutely right. The hardest part of making a Mac app, or any software, for that matter, is never the framework. Anyone can learn to write code that executes. The challenge, as Mueller puts it, is caring enough to do it well.

No framework can make developers care more about making great things.

But speaking as someone who does care, I sure wouldn’t mind if Apple made my life a little easier.

Imagine you’re pushing a rock twice your size up a hill. It’s snowing, and you have no shoes or coat on. Someone is on the other side of the rock pushing in the opposite direction.

If I offered you a pair of shoes, you’re telling me you wouldn’t take them?

There’s no doubt in my mind there are good iOS devs out there who have never ventured over to the Mac because it looks like it would be just a bit more effort than it’s worth. It’s not that they can’t do it because AppKit is some incredibly hard thing that only a rocket scientist can figure out. (I’ve made AppKit apps, so trust me, it’s not rocket science.) But it is yet another thing to learn. In addition to having to sweat the details about the platform, user experience, etc., you also have to learn the differences between an NSButton and a UIButton, NSColor and UIColor, and on and on. I remember when I was going through it, I never once said “This is too hard!” It was more like “Why the heck is this so different?”

Also, there are many cases where the simplest of things take more effort in AppKit than on iOS. And even when something isn’t more effort, just finding answers to basic questions was a chore, because it’s harder to get answers from a web search about AppKit.[5]

A unified API would obliterate these small frustrations. When I want to add a button to a view, I’d add it the same way on macOS as I do on iOS. When I want to specify a color, I’d use the same syntax for both.

If we apply the infamous “aliens landing on Earth” hypothetical to the development of iOS and macOS apps, of course the aliens would think it’s ridiculous this isn’t already the way things work.

And the benefits really could go in both directions. Some macOS devs may just find that once they learn this new framework, suddenly their great Mac apps are just a little bit easier to port over to the iPad.[6]

Regardless of how much junk gets made by others, in the hands of those who care, better tools are still a good thing.

If you care about making great apps, then Marzipan should at least make you excited about a slightly easier path to platforms you haven’t yet explored, or a simplification between the two versions of your apps you already maintain.

A lower barrier to entry for new devs

Marzipan will not only make it easier for an existing iOS dev to move to macOS, and vice versa. It will also be easier for new developers to get started in Apple’s ecosystem. If we’re not talking about UIKit ported to AppKit, but rather a completely new set of APIs, that would mean years of knowledge about how those current frameworks get used would be baked into the new framework. Apple’s engineers are pretty good at this stuff.[7] I’m guessing they know all the pain points for new developers coming to the platform, and they’ll seek to decrease that pain.

More new blood in the ecosystem means more innovation, more creativity, more inclusiveness. It probably also means more terrible apps, but like I said before, the cream that rises to the top will be worth it. As much as the old-timers love their little niche community of app celebrities, the future of the platform depends on all of us getting replaced eventually. Personally, I welcome the possibility of an influx of bright new talent, particularly to the Mac.

Less code is a good thing

While we’re on the subject of making things easier, Marzipan also promises more shared code between iOS and Mac versions of apps. We’ve been able for a long time to share some elements of our apps, models, classes, etc. in the same project file with different targets. With Marzipan, we could end up sharing even more code between platforms. Not all of it, of course. But a lot more of it.

Fewer repeated classes equals less code, which equals easier testing, which equals less room for human error, which equals more-reliable apps.

It also means less duplication of effort. Which is easier to sell to middle managers on a budget.

A unified framework that’s still native

I was a middle manager once. Every year, my boss would bring me into his office and hand me a budget that was invariably 15% smaller than last year’s and tell me to make it work, no matter what I had to do. Same output. Lower cost. That meant giving part-timers fewer hours, not extending contracts, and in some cases, eliminating positions altogether.[8]

That was always my last resort, though. More often than not, I’d look at ways to spend less money on the services we delivered. There are always inefficiencies in any business, and if you put enough pressure on people, they will find them, even if it ends up hurting the product.

Enter our old friend, Write-Once, Run-Anywhere. We had a brief period of bliss with Apple’s push for native iPhone apps back in 2008. But the Dark Lord’s lieutenant has returned, and although he is not yet regained his full strength, his minions are gathering in Mordor.

Slack. Skype. Banking apps—chances are, you are already seeing more cross-platform Electron apps on your Mac and non-native apps on your phone as well. This is a trend. It will continue.

Marzipan probably won’t save us from this nightmare. But if even one of these JavaScript-infused beasts turns out to be an iOS-to-Mac native port on my Mac instead, it will be worth it.

As a consultant, I like the idea of being able to pitch an even slightly less expensive Mac add-on to an existing iOS contract. “Oh, you were going to build a Mac version in Electron? Well, we can make a much richer native experience reusing a lot of our efforts on iOS…” It’s still a tough sell, but it is just a bit easier.

The Mac is less likely to get left out of new API goodies

If Apple only has to maintain one framework for adding new features to iOS and macOS, it’s less likely to leave the Mac out of new APIs. That means no longer waiting a year or more to get the same interesting cool new features we see on iOS.

And given Apple’s tendency to eat its own dog food, I can see this having a very positive effect on the App Store as well. Imagine the App Store app being built using Marzipan, sharing its code between macOS and iOS. Now features like gifting, app previews, review prompting, and other things that have been missing on the Mac App Store for years would actually take effort to exclude from the Mac.[9]

Simplifying to one framework could also improve the speed at which Apple keeps up with its documentation and sample code. Wouldn’t that be a wonderful thing?

The Mac market is far too small compared to iOS to be a top priority for Apple. At least with Marzipan, macOS can maybe tag along with its more popular baby brother on new features.

More options is almost always better than fewer options

People who have been reading me for a long time know that generally I’m a fan of having more options. It’s always better when Apple gives us something than when it takes something away.

Right now, even if I wanted to, I couldn’t sell an iOS app that also runs on the Mac in one simple transaction. At least not easily. Marzipan looks to make that very easy. Even if I never end up selling an app that way, I like having the option. I also like the idea of one button my customers press to download my app on all their devices, Macs included.

Developers are fond of criticizing Apple for all the things we can’t do. They tend to forget that Apple often gives us new things we can do. Sure, there are other things we’d rather they let us do. But I’ll take what I can get.

Conclusion

All of this, of course, is merely speculation on a rumor. But it’s a rumor that makes a whole lot of sense to me. I would not be surprised to hear something official about this from Apple come June in San Jose. I would not be terribly surprised if it came a year or two later. I would be surprised, however, if it never comes to pass.

When you look at all four of Apple’s operating systems (iOS, tvOS, watchOS, and macOS) one of them is clearly not like the others. And that’s inefficient from Apple’s perspective. The benefits to Apple of a unified framework are just too numerous and obvious. So if I had a stake in the macOS or iOS ecosystems (and I do have one in both) I’d be doing some serious planning in the new year, so I can be prepared to reap the benefits, rather than wasting time fearing the negatives.


  1. Count me in with Gruber on doubting that iOS apps are suddenly going to “magically” run on our Macs, unaltered. Anyone who has spent more than five minutes with an app in the Simulator knows this would be a terrible experience for the user, and Apple generally avoids making terrible user experiences, at least on purpose. ↩︎

  2. Or, Apple could force developers to make all apps universal. There’s no good reason to believe this, however. Apple never forced developers to make iOS apps universal for iPad and iPhone. They didn’t have to. The market pressures ensured that 90% of apps went that way. Why risk terrible PR over something that’s likely to happen, regardless? ↩︎

  3. My take has always been the same: If people continuously use your app, they should continuously pay you. It’s not the app they are paying for. It’s what your app does. Some apps people only use once in a blue moon. Charge them once in a blue moon. If you told me a $50 Mac app I only use about once a year is now free to download and $5 per use, or $20 per year for unlimited use, I’d be pretty happy about those two choices. Sure, you’ll make less in the short term from your current customers, but you’ll get a whole new set of customers who wouldn’t pay $50 under any circumstances. And that’s just one example of one of the many different things you could try. (99% of the people I know who argue against subscriptions with me have never tried subscriptions.) ↩︎

  4. Of course, some of those scrappy indies are now the legacy apps that will get ousted by younger competitors this time around. Such is the cycle of tech. ↩︎

  5. This is worth noting. Part of the reason, I’m sure, is sheer numbers. There are a lot more iOS devs. But everyone I’ve talked to who has gone through the transition from UIKit to AppKit has noticed the same thing I did when searching for answers. There’s just not as much available, in terms of tutorials, videos, Stack Overflow answers, etc. about AppKit. Many times, search results for an AppKit API would return results for the equivalent UIKit API instead. Maddening. One long-time Mac dev who shall remain nameless once joked to me that Mac devs have been doing their thing for so long they don’t need tools like Stack Overflow to figure anything out. Mac developers for the most part know what they are doing. He was joking, of course, but not really. And that reveals something that I’ve felt for a long time about at least some of the Mac devs I’ve met. They like that they are a small, elite group. And they want it to stay that way. When iOS happened, they were happy to let the new kids invade that territory, as long as AppKit was there as a barrier to keep the lower-class iOS devs out of their little gated community of artisanal craft app makers. Marzipan, then, probably scares the hell out of a few of the old-school Mac devs. If not for the earlier stated reasons of having to rewrite legacy code, than for this. ↩︎

  6. I’d go as far as saying this should be Apple’s biggest goal in creating Marzipan. If handing iPhone devs a carrot led to dumbed-down iPad apps, perhaps they can offer the same carrot to Mac devs instead and get smartened-up iPad apps? ↩︎

  7. I offer UIKit, as compared to AppKit, as evidence. ↩︎

  8. The easiest way to make a good cut out of my budget would have been to eliminate my position, of course, since I was getting paid a lot more than the part-timers I was having to reduce. Only took my boss about eight years to figure that one out. ↩︎

  9. My personal theory on why the Mac App Store App has been completely neglected in recent years: Apple plans to release a port of the new iOS App Store using Marzipan, and thus hasn’t bothered with improvements to the current app. ↩︎

The Curious Case of the Duplicate Tracks

Over the years, the majority of my complaints about Apple have centered around music. That’s because I love music, and Apple clearly doesn’t always think enough about people outside of its contrived all-in-on-Apple-Music listener when it comes to the iTunes experience.

Today’s complaint actually begins with a recent positive discovery. I finally gave in to the temptation and signed up for a free trial of Apple Music, and it’s really great. The recommendations it makes are often good, or at least not terrible, and I love being able to try out lots of artists that I otherwise would probably not have discovered. I love downloading tracks on my phone as I discover them, and I like listening to them even when I’m offline. So far, so good. I definitely plan to remain a subscriber.

But then I ran into a bit of a snag when it came to the iCloud Music Library. This is the feature that syncs whatever you put on one device with all your iPhones, iPads, Macs, etc. In theory, it’s a great idea. If I discover a track on my iPhone and download it, it’ll be sitting on my Mac next time I might want to listen. And vice versa. On my iPad, I don’t auto-download these tracks, but they show up in my library for streaming if I want them. Perfect.[1]

But after a couple of days of enjoying this new iCloud Library experience, I noticed a problem on my Mac. In iTunes, every track that is available on Apple Music but that I had acquired elsewhere (CD Rip, purchased from another store, etc) was doubled in my iTunes library. Each song would be listed twice, in other words.

In some cases, one version would have a little cloud icon with the down arrow, indicating that it can be downloaded from iTunes, and the other would have a cloud and an X, indicating a track that is from my library, already downloaded, but not from iTunes. On my phone and iPad, these tracks only show up once. But on the Mac, there were two. Right after one another.

In other cases, it would actually download the second copy, so I’d get one track with no icon (downloaded from iTunes) and the other with the X (my original file). All of these files were taking up twice as much space on my hard drive.[2]

File size issues aside, you can see how this would be a problem for someone like me who likes listening to albums. Unless I want to hear each song twice in a row before advancing to the next one, I have to remove all the duplicate tracks from Up Next every time I click on an album. (Even the ones that aren’t yet downloaded just stream when I play the album.)

Well, that’s a strange bug, I thought. Maybe I should throw away the extra downloaded ones and just leave my original tracks. We’re talking about thousands of tracks, so that would be a lot of work. But if it’s just a one-time glitch, so be it.

When I attempted to remove a cloud track however, I got a warning that it would remove the track on my phone as well. That’s not good. I want the track to stay on my iPhone. I just don’t want two copies on my Mac.

The other option, of course, was to erase my copies of the tracks and just leave the cloud versions. Which means if I ever cancel Apple Music, those tracks will likely be gone forever, since I didn’t buy them on iTunes. They would not be part of my purchase history, so they would disappear, along with everything else I try in Apple Music.

This is not an option.

So I found a third alternative: I just turned off iCloud Music Library on my Mac. The duplicates immediately went away, and I was left with my old library intact. I miss out on syncing new tracks that I find on my phone, but those can be found and streamed on my Mac from the recents section of For You. Terrible user experience, but at least there’s a workaround.

Believe it or not, I wasn’t driven to write a long tirade yet. I tweeted something snarky, but then I let it go. Lots of others informed me this has been a known issue for quite a while. Yikes.

And then something happened this week, when one of my favorite bands, Big Big Train, released a pair of new Christmas songs. Only one is available on iTunes, while the other is a special b-side you can only get from their web store. A portion of the proceeds from those songs also gets donated to charity when you buy on their store. So I bought both tracks on their store, of course.

I often buy tracks from indie artists on their own sites, anyway. As an extra sign of support. This is not weird or extremely unusual behavior. It’s pretty common for music fans.

It’s when I tried to listen to these tracks that I found my inspiration for this rant. I could add these two new tracks to my Mac, no problem. But because I didn’t have iCloud Music Library turned on, those tracks were not synced up with my phone. Okay. I can just plug my iPhone into the Mac with a USB cable and drag the new tracks over to my phone, right?

Nope.

Because iCloud Music Library was turned on for the iPhone, I was now no longer able to simply drag and drop files between the Mac and iPhone. iCloud Music Library is an all-or-nothing proposition. The only way to get these two tracks onto my phone would be to either turn off iCloud Music Library on the phone (and thus lose all the Apple Music tracks I’ve downloaded) or turn iCloud Music Library back on for my Mac, and let the tracks sync.

I chose the latter, which, of course, brought back all the duplicate tracks on my Mac as well. So then I had to turn off iCloud Music Library on my Mac after the upload of my new songs made it to my other devices. Fortunately, the two new tracks remained on my phone.

You read that right. Moving forward, whenever I get a new audio track that isn’t from Apple Music, I’ll have to add the track to iTunes, turn on iCloud Music Library on the Mac, let it upload that new track to the cloud and download all these thousands of duplicates, then turn off iCloud Music Library on the Mac to remove all the duplicates.

Lovely.

I purchase the vast majority of my music from the iTunes Music Store. I shouldn’t be punished for occasionally getting tracks from other sources. Especially when those tracks aren’t even available on iTunes.

All of this suggested to me that perhaps no one at Apple has any music that wasn’t downloaded from iTunes? Although that can’t be true. You’d think someone in charge of music over at Apple had listened to music prior to the iTunes Store’s existence, which means they at least have some tracks that were ripped from CDs in the early 2000s. Given this issue is so thoroughly annoying, I would think it would have gotten fixed somewhere in the last year or two once someone noticed, right? It’s simply not possible that no one over there has noticed this problem.

The only other two conclusions I can make is that no one at Apple cares (not likely) or that this duplication of tracks is somehow intended. Which brings me to my favorite question: Why? Why would anyone want to search through their entire library and delete all these duplicate tracks? Or erase their entire music library before signing up for Apple Music, so their library would be fresh and only sourced from Apple?

If the Mac can detect that I have a track in my library that’s from another source but also available on iTunes, why can’t it just mark that track as already downloaded, and then just download a copy to my other devices? Like I said, this works just fine on my iOS devices.[3]

Despite my frequent complaining, iTunes has improved over the years. So many things that used to drive me nuts are better at this point. I’m back to using the built-in iOS Music app again. I recently wrote about drag and drop from iTunes to your iOS devices finally working reliably. I can finally sort albums on my phone by date instead of title. I signed up for Apple Music and I actually like it. Apple is working on making these experiences better. Maybe this duplicates issue is just another item on a long list of things to be fixed, and we’ll eventually see it go away. I have to hope so. It’s one of the few remaining big ticket items that leaves me scratching my head at an otherwise decent music experience.

Progress has been very slow going, though. I’ve already volunteered, if Apple ever wants to take me up on it, to help them find any remaining issues by examining my music library. If they want to find music-lover use cases they probably haven’t considered, my hard drive is full of them. Heck, I’m usually in the Bay Area at least twice a year, anyway. I’d be happy to stop by whenever they want to talk.


  1. I only listen on my iPad occasionally, so streaming-only is just fine there. ↩︎

  2. At least, presumably. I could not find these tracks in Finder anywhere. But if I right click on them, I have the option to “remove download.” And if I go to the View menu and switch to showing Only Downloaded Music, these songs remain. ↩︎

  3. Most of the tracks I have on my phone were dragged over from the same library that’s on my Mac. I have zero duplicates on my phone. ↩︎

Using Tally

I was recently asked on Twitter for practical examples of how I use Tally, made by Greg Pierce of Agile Tortoise. My response is way too long, even for the new 280-character limit, though, so I thought I’d write it up here.

Note: This is not a paid endorsement. I know Greg, and I know he makes great apps. Which is why I downloaded Tally in the first place. But he has never asked me to promote anything of his. I just like talking about great products.

Tally, for those who don’t know, is a simple iOS app for keeping a tally of just about anything. Tap anywhere on the screen to add one to the counter. Couldn’t be easier.

You can run multiple tallies at once, too. And there are other settings inside the app for customizing further. But that’s the basic gist. It’s a very simple app. But it’s this simplicity and malleability that make Tally so valuable to me.

Tally is also one of the few apps with an iOS widget that I actually use. Thanks to the widget (and the very good Apple Watch companion app) I almost never have to actually launch Tally on my iPhone to keep my tallies going.

The obvious use case for an app like Tally is to keep score in games, or count the number of people who enter a room. That sort of thing. But that’s not how I use the app.

Basically, I use Tally to keep track of behaviors I’m curious about tracking, but that I don’t want to get too deep into a rabbit hole about tracking. Make sense?

Let me give you an example. A while back, my doctor asked me to estimate how often per week I eat red meat. I couldn’t really give her an honest answer. I figured it was more than she was going to recommend, regardless, but that didn’t bother me as much as simply not knowing. I had never thought to track my red meat intake before. So I made a tally called Red Meat, and I started tracking it, casually. Every time I ordered a cheeseburger, I’d flick over to Tally on my Apple Watch or on the widget screen and add one to the count. Carne Asada burrito? Add another to the count. And that was it. I wasn’t trying to guilt myself into changing any behavior. I didn’t want to create permanent stats on my red meat intake for the rest of my life. It wasn’t a chore. I was just curious.

The results, of course, surprised me. I was definitely eating red meat more often than I thought I was. Given the health drawbacks of cholesterol, cancer risk, heart problems, etc., it was definitely more than I wanted to be eating. But I didn’t panic. I just kept tracking it, this time setting my sights on reducing that weekly number. Could I do one fewer this week than last week? No pressure. No judgement. Some weeks I’d do better. Others I wouldn’t. Let me just see if I can make different choices on occasion.

Over time, I went from eating red meat more than seven times a week (or roughly once a day) to three or fewer times per week. That’s a big shift, but I did it over a prolonged period, so it barely felt like a change. Months later, I find myself craving red meat less often, so keeping the number down at three or so has become second nature. I can probably stop tracking it at this point, I’ve gotten so consistent at keeping that number down.

And that’s the whole point. There are some things in my life I absolutely want tracked over the long haul, in an app tailored specifically for that thing. My caffeine intake, for instance. My heart rate. My weight. And so on. But for other things, I’m just mildly curious. I suspect I have a habit that isn’t ideal, and so I gather some data to see if my suspicion turns out to be true. If the number makes me concerned, I make small adjustments to my habits, so I can be less concerned.

I didn’t need a red meat tracking app, in other words. I just needed to keep a casual tally for a few months. I needed data, and Tally was the easiest, low-pressure way to gather that data.

The beauty of Tally is that I can use one app to track just about anything. Another thing I started tracking not long after red meat was my alcoholic beverage intake. I never drink myself into a stupor, but I do like a nice glass of wine most nights for dinner. I also mix the occasional cocktail at home, mostly as a hobby. Throw in the occasional social gathering in the evenings, and just how many drinks was I actually having during the average week? Once again, it was more than I thought. So I’ve begun working on reducing that number, too.

This isn’t about scaring myself into making a massive change to my behavior overnight. Experience has shown me that’s a waste of time. If I want to make changes to long-ingrained habits, I know I need to make small adjustments over a long period, until the new habit becomes as natural as the old one once was. Until the old habit seems downright unattractive. It’ll take much longer to accomplish, but it’ll also last much longer.

You can also use Tally with an eye for increasing, rather than decreasing, behaviors, of course. How many times this week did I resist the urge to correct someone on the Internet? How many times did I work on gathering new leads for my consulting business? The possibilities are endless. And it’s so easy to track things, you’re far more likely to do it than with more complicated data entry apps. It only takes a few seconds to pop into the Apple Watch app or flip over to the widget screen on my iPhone, and add one to the count. It’s quicker than checking in on Swarm, or posting a pic to Instagram, for sure.

At the end of the week I reset the count, and I can start fresh. There’s no permanent record on which to judge myself. I don’t even really look at the numbers as the week goes by. I just view each tap as collecting a data point. Nothing more. On Sunday, when I actually look more closely at the numbers, I take a moment to reflect on how I’m doing. If I did better? Great. If I didn’t? No worries. I’ll try to do better next week.

We all want to improve ourselves in some way. I don’t know if this will work for you to help make adjustments in your habits. But it’s sure worked for me. I encourage you to give Tally a try, if you think it may help. It’s free to download and very inexpensive to get all the features unlocked.