Apple TV+ is launching today. We’ve already heard, and will continue to hear, hot takes on how Apple has far too little content, how the shows are hit or miss, that they can’t possibly compete with Netflix and Disney, and on and on.

But here’s the thing. Apple TV+ itself is not particularly important to Apple’s bottom line. And it doesn’t have to be for a long time.

Take a look at the TV app on your iPhone, iPad, or Apple TV. At first, when I saw the way Apple was mixing and matching all the content from available channels, iTunes rentals, purchases, and streaming services like Prime, I was annoyed. How am I supposed to find shows specific to certain sources in here? And more importantly, how can I tell the difference between what I already have access to with my existing subscriptions, and what is going to require a new subscription or a one-time payment?

And that’s the rub. You can’t easily get a screen with all the content you already have access to. Sure the library tab will show you movies and tv shows you’ve purchased on iTunes. But my HBO subscription? Prime? These are just mixed in with all the rest of the content. You can dig and find HBO specific pages, sure. But they are buried behind multiple layers of UI. And there’s a good reason for that.

The TV app is not an app. It’s a store. And Apple knows a thing or two about running stores. They know the more you walk in and hang out, the more likely you will spend some money while you are in there. If I see a new show that looks compelling from Showtime? I can subscribe right there in app. See a movie that I want to rent? Bam, one click of my remote, and I’m watching it. It’s a smorgasbord of impulse buys.

And Apple gets a cut of just about everything in there.

No wonder Apple is giving away a free year of Apple TV+ to people who purchase new hardware. Right now, they just need to drive people into the app. Apple could probably afford to make Apple TV+ a loss leader permanently, as long as the TV app continues to be the primary place you go to watch content. Sure, it’s important Apple creates some compelling shows to keep you coming. But they can afford to grow their Apple TV+ paying subscriber base relatively slowly. They can play the long game, as they are so good at doing. In the meantime, as long as a percentage of the massive installed user base rents a movie or two or subscribes to a channel every month, that revenue will easily outpace the measly $5 they might get from a couple of million TV+ subscribers in the first year or so.

Compare that to Netflix. Every time I open the Netflix app, I see nothing but content to which I already have access. Netflix will never make any more money with their app from me than what I’m already paying them monthly. And as new services take away non-exclusive content, Netflix is poised to become less—not more—valuable over time.

So while so many will want to focus on whether or not Apple is going to be able to sustain the budgets of multi-million dollar-per-episode shows, keep in mind that there’s a lot more money to be made here than a simple $5 a month subscription to Apple TV+.

TV+ is just one product on the shelf of a much larger store.

I’m thoroughly enjoying using SwiftUI. But like any new API, there are limitations that can at times be maddening.

One issue I ran into while developing the UI for logging custom and favorite items in my RECaf watch app was the lack of any way in SwiftUI to pop back to the root of the navigation stack.

Here’s my scenario: You start with a list, showing items for Custom Entry and Favorites. Tap Favorites, and you are pushed to a list of your favorites. Tap one of the favorites, and you are presented with a confirmation screen, detailing what you are about to log. At the bottom are two buttons. One for completing the log, and the other for canceling.

Because SwiftUI has no function for getting back to the root, I had no way to pop the customer all the way back to the initial list after they canceled or logged. I was stuck hoping that Apple ends up adding this function sooner rather than later. I couldn’t ship this, knowing the customer would have to swipe right several times to get back to the home screen.

But then I remembered, my root SwiftUI view was inside a WKHostingController.

WKHostingController is just a WKInterfaceController that expects a SwiftUI body view. It still retains all the methods of WKInterfaceController, including awakeFromContext.

So what I did was set the hosting controller to listen for a notification indicating a reload was needed. Then, on my Cancel button and on my log confirmation button, I could post that same notification.

And sure enough, the navigation stack pops back to the root.

I’ve seen other workarounds that use more convoluted ways to get SwiftUI to go back one level in the hierarchy, or to dismiss a presented view. But for getting all the way down a long stack in one move, this is going to be my goto. At least until Apple gives us a proper way to pop to root.

Here’s the code for my hostingController:

import SwiftUI


final class NewEntryController: WKHostingController<NewEntry> {
    
    override func awake(withContext context: Any?) {
        NotificationCenter.default.addObserver(self, selector: #selector(reloadRoot(notification:)), name: Notification.Name(NotificationKeys.watchReloadNeeded), object: nil)
    }
    
    @objc func reloadRoot(notification: Notification) {
        self.popToRootController()
    }

    override var body: NewEntry {
        NewEntry()
    }

}

I have reached the unfortunate conclusion that RECaf’s watch app will not be able to go fully independent this fall with the release of watchOS 6. While you have always been able to log from your wrist using the app or Siri shortcuts, I was hoping folks who didn’t want to keep RECaf installed on their phones would be able to continue using RECaf on their wrist.

There are simply too many things that can’t be done on watchOS alone at this point, however. So for now, you’ll have to keep that phone app installed.

What’s missing?

• HealthKit queries on watchOS are limited to about 7 or 8 days worth of data. If RECaf does a sample query for all your caffeine, it will only get the last 8 days or so. I need 30 days to calculate your average caffeine intake. I need 60 days to figure out your most frequent sources and amounts and offer those for quick logging. For now I will have to continue calculating this on the phone and sending the data to the watch.
• You can’t subscribe to changes in HealthKit in the background. If you log some caffeine using your phone or with Siri, the watch will have no idea that log happened until the app is launched. That means I can’t update your complication without using direct messaging from the phone to the watch.
• No in-app purchase. You can’t subscribe to RECaf without launching it on your phone. There is no mechanism for purchasing on the watch at this point. I had planned to work around this by having you launch RECaf on your phone just once after installing. That would have been a terrible user experience, but I was willing to accept the trade off before I discovered the other limitations above.

This doesn’t mean RECaf won’t get some great improvements in watchOS 6. I’m working hard on a major update that will make the watch component of RECaf more independent. (You will be able to log all sources, not just your frequent items, for instance.) It just won’t be completely untethered from your phone just yet.

I’m sure Apple is aware of these restrictions and is planning on giving Apple Watch even more power in the coming years. But in the meantime, I suspect fewer apps than you might be hoping will be going fully independent in the short term.

The internal drama explains a lot about Apple’s dilemma. Its one major new product of the post-Jobs era, the Apple Watch, made its debut five years ago. Its iPhone business is faltering, and more recent releases like its wireless AirPods haven’t been enough to shore up falling sales. It hasn’t had a megahit new product since the iPad that started selling in 2010.

via The Wall Street Journal

Every line of that paragraph infuriates me.

Its one major new product of the post-Jobs era, the Apple Watch, made its debut five years ago.

And the iPad debuted 5 years before that. The iPhone was only two years prior, but the iPod was 7 years before that. And the Mac, well that was 17 years prior to that. See a pattern here? Neither do I. Major new products from Apple come out when they are ready. There has never been a period in Apple’s history with hit major new product after major new product.

Its iPhone business is faltering

A 5% decline on 46-million units per quarter now qualifies as “faltering.” Check.

and more recent releases like its wireless AirPods haven’t been enough to shore up falling sales.

AirPods are a legitimate cultural phenomenon. But that doesn’t fit the narrative here, so let’s point out that they’re not expensive enough to make up for “faltering” iPhone sales. Because that won’t directly contradict your point later in the article that iPhone X was too expensive.

It hasn’t had a megahit new product since the iPad that started selling in 2010.

iPad is the fastest-selling consumer electronics gadget of all time. Sure, Apple hasn’t had a hit of that magnitude since. It also never had one of that magnitude prior. And neither has anyone else. What’s your point?

Look, I get it. Jony Ive quits Apple, and you as a journalist see an excellent opportunity to cash in on the sentiment that “things just aren’t as great as they used to be.” So you gather a bunch of disgruntled former Apple employees who haven’t exactly “had a megahit” themselves since they left and cast as negative a picture as you can, so you can generate as many clicks as you can. But don’t expect me to read this drivel and actually believe any of it.

By the end of the piece, I’m supposed to think Apple is doomed because Ive would rather spend time with his ailing father than watch a Lady Gaga concert. (I shit you not.)

But of course, my Twitter timeline is full of Apple fans with malfunctioning keyboards telling me this is a “must read.” So, mission accomplished, I guess?

It’s almost hard to believe I wrote this post about duplicate track issues in iTunes and iCloud Music Library way back in December 2017, and yet, in the shipping version of iTunes today, that bug is still present.

Not a day goes by since I wrote that post (I have the tracking stats to prove it) that at least a few people don’t find my article via a Google search, which means people have been frustrated with this issue and have been looking for solutions for a very long time. Some have even reached out to me to thank me for reassuring them they aren’t crazy.

Imagine how my ears pricked up, then, when rumors started floating around this year that Apple was poised to retire iTunes in the next major version of macOS? While many were frightened Apple was taking away their precious music player of choice, I was elated at the chance of a brand new app which would presumably not elicit this same bug. After all, the rumor originally figured the new Music app would be ported over from its iOS counterpart on the iPad. And the iPad version doesn’t have this bug.

But then Apple announced Music for macOS (which will ship this fall with the Catalina update), and it quickly became apparent that rather than a complete rewrite, the app would simply be iTunes with a new name and a lot of its more bloated features removed.

Happy as I am to see the bloat removed, and as much as I believe strongly that you should not throw away perfectly functioning code for no good reason, the code in iTunes was far from perfectly functioning.

So, the big question: Would this bug still be present in Music, despite all the work Apple had put into rebranding and reworking it?

Luckily, I don’t have to wait until September to find out. I’m an Apple developer, after all, so I get early access to the beta versions of this software.

So I installed Catalina’s beta onto my Mac, fired up Music, turned on the iCloud Music Library feature, and…

Well, at first, the duplicates appeared again. I was despondent. I could not believe Apple didn’t bother addressing this issue after at least one-and-a-half years. (In all likelihood, the bug has been around quite a bit longer than that.)

But then, a few moments later, something wonderful happened. All the duplicate tracks disappeared in an instant. It was if Music caught itself making the same old mistake, and then corrected itself.

As of this writing, the duplicate tracks are still gone. iCloud Music Library is functioning on my Mac as intended. And any new tracks I download are being synced perfectly between my iPhone and Mac.

Fingers crossed that all is well, and we will finally be able to call this bug defeated.

I say will be, of course, because Catalina is not shipping yet. Those of you who are not developers will have to wait to get this fix. And there’s always the chance that the bug will return before shipping. But I highly doubt it. I think there are going to be a lot of happy Music users come fall.