And now it’s all this

I just said what I said and it was wrong
Or was taken wrong

New Apple Watches have ears

September 9, 2026 at 10:42 PM by Dr. Drang

Starting about 45 minutes into today’s Apple Event, during the segment on the new Apple Watch, Ron Huang introduced a couple of features of the Series 12 and Ultra 4 that struck me as both disturbing and possibly illegal. They certainly seem at odds with Apple’s commitment to privacy.

First came Live Rewind, a feature that lets you “go back in time” to pick up on something you missed that was said in the past 15 seconds. Here’s how Apple describes it on the website:

Live Rewind catches what you missed. Did someone say something you couldn’t hear in a loud restaurant or share cooking instructions you didn’t quite catch? Just double-click the Digital Crown, and Live Rewind transcribes what was said in the last 15 seconds. You can ask Siri about the content of the transcript or save it to the new Siri app to revisit later.

In the Event, this was illustrated by a waitress going through the restaurant’s specials too quickly for the diners to remember all of them. One of the diners double-clicks the crown on his watch and reads what she said.

It seems like your watch will be listening continuously, keeping the last 15 seconds in a buffer, ready to be transcribed when you ask. That’s fine for you, because you know it’s happening, but what about those around you? Did they agree to this? I doubt wait staff will be upset with their spiel being transcribed, but the idea behind Live Rewind seems to be that everyone and everything near your watch is being recorded for 15 seconds. Surely, some people wouldn’t consent to that if they were asked. Significantly, though, they’re not being asked. I’m sure Apple will argue that there’s no privacy issue because the recordings aren’t being saved. But if there’s a transcription, isn’t that a type of saving?

And then there’s the question of legality. A great variety of law, both in the United States and across the world, concerns the recording of electronic and in-person conversations. I’m sure Apple has considered this, but I have to think some jurisdictions will frown on Live Rewind. If Apple has to defend it, that’s fine. What’s one more squadron of lawyers to Apple? But if an Apple Watch owner has to defend a transcription made innocently—made with Apple’s encouragement, in fact—that seems like an unfair burden. Maybe Apple should indemnify all future Watch buyers from privacy-related legal action.

Right after Live Rewind, we get the introduction of Siri Recap. From the Series 12 web page:

Siri Recap can summarize your chats to refresh your memory. Siri Recap transforms your conversations into high-level notes, so you can stay focused and present. Each Siri Recap includes a title, a summary, and key points that you can review in the Siri app on your Apple Watch or iPhone. You can turn Siri Recap on or off at any time from Control Center or choose where and when it takes notes, such as only at work or never at night.

Siri Recap does a summary, not a transcription, and it’s not automatic the way Live Rewind is, although it does sound as if you can set it up to always record when you’re at a certain place, so that’s kind of automatic. Apple touted Siri Recap’s privacy with three bullet points:

I think Apple is slicing the baloney pretty thin when it says audio isn’t recorded. Surely there’s some recording because summaries require context; they can’t be made on the fly. Maybe a transcription is done in near-real time and the summary is drawn from that. If so, the transcription is a type of recording, albeit one that isn’t stored after the summary is made. As for not identifying the speakers, I don’t see how that matters. Old-fashioned audio recordings don’t identify speakers, either, but they’re still intrusions on the speakers’ privacy if they didn’t give consent.

Apple has always focused on the privacy of its customers: your information is encrypted, your data stays on your device. It’s following that same pattern here, but the privacy concerns of Live Rewind and Siri Recap aren’t limited to the owners of Apple Watches. Apple now needs think about the privacy of non-customers and be able to explain how that’s being protected, too.

And while an argument can be made that textual transcriptions and recaps aren’t as invasive as saved audio recordings, that doesn’t mean they aren’t invasive at all. That little lock animation Apple’s been using to describe its commitment to privacy has been very effective, but its binary nature doesn’t fit when the products start putting privacy on a sliding scale.

---

Web and native apps

August 17, 2026 at 2:19 PM by Dr. Drang

This is sacrilegious among some parts of Apple fandom, but I like using web apps. Oh, sure, I can imagine a world in which there’s a carefully crafted Mac app that has all the functions of a website I use but has all the Mac-like interface features I love and isn’t hobbled by a web UI. But I don’t live in that world and don’t expect I ever will.

For example, will the Python Software Foundation ever make a Mac app that includes all the documentation I regularly use? And even if they do, is it likely they’ll put in the effort to make better than just visiting the Python Docs web page? Would that be in keeping with their mission? So instead of waiting around for something that will never happen, I used Unite Pro to make a Python Docs site-specific browser.

Launching it takes me straight to the standard library home page, from which I can quickly jump to the docs of whichever module I’m invoking in my current script. I have similar SSBs for the Matplotlib and Pandas documentation.

You might argue that these SSBs aren’t really web apps, that they’re basically a set of static web pages connected by links. That’s nearly true, but while they don’t have the kind of interaction that you see in, say, Google Sheets, they do have search features that make them more interactive than just a list of links. Regardless of how interactive they are, they serve my needs.

You might also suggest I use Dash, an actual app, instead of an SSB for browsing documentation. It incorporates many many sets of documentation and uses local copies so you don’t have to be online to use it. These are all good points and are why I tried Dash several years ago. It just didn’t fit me, probably because searches in Dash returned too many results across too many libraries. There are probably ways to get it to serve up more focused results, but I didn’t want to become a Dash expert (I’m not Brett Terpstra). I just wanted to see documentation relevant to what I was working on at the time. Initially that meant going to the appropriate website; now it means launching the appropriate SSB.

But I’m not a web app absolutist. I recently ended a web app experiment that’s brought me back to a native app. This was with Mastodon and Mona. When Mona 7 came out at the end of last year, I decided to hold off on buying its Ultra in-app purchase. After all, I thought, Mastodon exists on the web. Does it really need an app?

So I made an SSB with Unite Pro for the Mac and used the free versions of Mona on iOS and iPadOS. Eventually, I felt guilty about using an app without paying the developer, so I did the Add to Home Screen thing on my iPhone and iPad a couple of weeks ago to even things out and use the web on all three platforms. It was terrible.

The biggest problem was the lack of timeline syncing and updating. In theory, this problem should have started when I was using Mona on two devices and an SSB on the third. In practice, it wasn’t so bad because I do almost all of my Mastodon reading and posting on my phone. It was when I started using “web Mastodon” on my phone that I noticed how poorly Mastodon updates the timeline.

On the web, Mastodon puts a link at the top of the page saying there are new posts to load into your timeline. When you tap the link, the new posts load, but your position in the timeline can jump around wildly, and then you have to scroll to get back to where you were. A small annoyance, perhaps, but one that happens again and again every day.

And there’s no syncing between platforms with web Mastodon. This is, as I said, less of a problem for me because I’m mainly reading and posting on my phone, but the scrolling necessary on one device to get to where I had been on another just reminded me of all the scrolling described in the previous paragraph, and it seemed worse.

So I subscribed to Mona Ultra and switched to it on all three platforms. The Mastodon web Home Screen icons are gone from my iPhone and iPad, and the SSB is gone from my Mac. Ultra’s extended settings are nice, and I’m happy to pay for them, but the main advantage is the smoother experience I get with a real app written to use the features of the platform(s) it runs on. In this case, one of those features is iCloud syncing.

(By the way, if you feel tempted to tell me about another Mastodon app, like Ivory, don’t. I know about them—I’m happy with Mona.)

In summary, I don’t have any magic tricks for choosing between web apps and native apps. I just know that it’s worth a little time to try out both and see what fits. Every app and every person is different, and you have to decide from direct experience.

---

Apple Music weirdness

August 15, 2026 at 5:18 PM by Dr. Drang

I was out on a walk yesterday, listening to the ’70s Hits Radio Station on Apple Music, when “Don’t Leave Me This Way” came on. I pulled my phone out of my pocket to look at a text while the song was playing and was surprised at what the Music app told me about the song.

I’m pretty sure George Benson never covered “Don’t Leave Me This Way,” but even if he did, that’s not the version I was listening to. It was the version everybody knows by Thelma Houston, with her incredible voice and that fun bass part during the chorus. I’ve been listening to it for 50 years, and it’s unmistakable.

So how did Apple Music get the artist wrong? Is the info provided with the album wrong and Apple is just repeating someone else’s mistake? When I got home, I checked this Heartbreak Hits compilation album on other services. Amazon Music, Spotify, and Tidal all had the album, and they all had the artist listed correctly as Thelma Houston. Only Apple got it wrong.

I don’t think I’ve ever seen mistaken artist attribution like this before, but Apple’s weird choice of album to pluck the song from is very familiar. I listen to a lot of Apple’s Radio Stations and its Essentials and Deep Cuts playlists, and it’s common for a song to be assigned to a compilation album instead of the original source. Even when Apple has the original album in its library. As you might have guessed, I find this annoying.

It’s not exactly wrong to show a song as being on a compilation album; most hit songs have been put on “best of” and other sorts of compilations. But it’s bad scholarship. Yes, if the song was released as a standalone single—as many Beatle songs were—the only album you can assign it to is a compilation, but that’s fairly rare.

If, for example, you look at the Prince Essentials playlist—which you should; it’s fantastic—you’ll see that both “Gett Off” and “1999” are shown as being from his The Hits/The B-Sides album. That’s certainly a fun album to listen to, but neither of those songs “belong” to that album. “Gett Off” is from Diamonds and Pearls, and if I have to tell you where “1999” is from, I don’t know why you’ve read this far.

Apple likes to say that music is part of its DNA. I suggest they schedule some genetic counseling.

---

A planet position widget

August 12, 2026 at 12:16 PM by Dr. Drang

After I learned how to make a Mac widget with TerminalWidget and how to determine the locations of celestial objects with Astropy, the natural thing for me to do was combine the two into a widget that tracks the planets.

I’m using the ancient definition of planet, which includes the Sun and Moon but not anything past Saturn. The numbers are the azimuth and altitude, in that order, and are given to the nearest degree. The idea is to tell me what may be visible and where it is. This particular screenshot was taken just after 10:00 last night; there was no reason to go outside because everything was below the horizon.

I was torn on whether to include the Sun. Few of us need help finding the Sun in the sky, and you can’t see anything other than the Moon when the Sun is up. But I decided to include it anyway, partly for completeness, and partly because the visibility of some bodies depends on their separation from the Sun.

Let’s start with the code that generates the widget’s text. It’s a Python script called planets:

python:
 1:  import astropy.units as u
 2:  from astropy.time import Time
 3:  from astropy.coordinates import get_body, AltAz, EarthLocation
 4:  from subprocess import run
 5:  
 6:  def direction(az):
 7:    'Return a string indication of the azimuth (given in degrees).'
 8:  
 9:    dirs = 'N NNE NE ENE E ESE SE SSE S SSW SW WSW W WNW NW NNW'.split()
10:    i = int(((az + 11.25) % 360) / 22.5)
11:    return dirs[i]
12:  
13:  # Current time in UTC.
14:  ut = Time.now()
15:  
16:  # Observation location.
17:  home = EarthLocation(lat=41.81433*u.deg, lon=-88.07093*u.deg, height=208*u.m)
18:  
19:  # Bodies of interest.
20:  planets = 'Moon Sun Mercury Venus Mars Jupiter Saturn'.split()
21:  
22:  # Current positions of all the bodies.
23:  pos = {}
24:  const = {}
25:  for p in planets:
26:      pos[p] = get_body(p, ut).transform_to(AltAz(obstime=ut, location=home))
27:      const[p] = pos[p].get_constellation()
28:  
29:  # Assemble the results.
30:  output = []
31:  for p in planets:
32:      output.append(f'{p:>8s}: {pos[p].az.value:3.0f} \
33:  {direction(pos[p].az.value):3s} {pos[p].alt.value:3.0f} {const[p]}')
34:  
35:  # Pipe the results through TerminalWidget.
36:  tw = '/Applications/TerminalWidget.app/Contents/MacOS/TerminalWidget\
37:   --target planets --font Menlo --bg eeeeee --fg 000000 --text -'.split()
38:  run(tw, input='\n'.join(output).encode())
39:  
40:  # print('\n'.join(output))

There’s no shebang line because of how it gets called by launchd, which we’ll get to later.

After planets imports the necessary modules, Lines 6–11 define the direction function, which takes the azimuth and returns a string with the corresponding point of the compass. I have this because 223°, which is how Astropy reports the azimuth, doesn’t immediately say “southwest” to me. The function assumes a 16-point compass, like this one:

Image from Wikipedia.

The points are separated by 22.5°, which is why there’s a division by 22.5 in Line 10. The other parts of Line 10 adjust for the fact that North starts at 348.75° (-11.25°), the azimuth resets at 360°, and the index of a list must be an integer. Astropy may already have a function that does what direction does, but I thought it would be easier (and more fun) to write the function myself than to search through the documentation.

Lines 14 and 17 define the time and place of observation. planets will be run every half hour to update the widget, so what’s being displayed is never more than 30 minutes out of date. The home location you see above is actually the Morton Arboretum; my version of the script uses the latitude and longitude of my house.

Line 20 defines the planets list, and Lines 23–27 create a pair of dictionaries, pos and const, which contain the AltAz position and constellation of each planet. The get_body function (Line 26) gets the position, and the get_constellation function (Line 27) uses that position to figure out the constellation the body is in.

Lines 30–33 create the list of output lines, and Lines 36–38 use the run function of the subprocess module to send the output lines to TerminalWidget. The tw list contains both the full path to the TerminalWidget executable and all the options passed to it. The input parameter to run is the previously defined output, converted to a single string separated by linefeeds and encoded as bytes.

Line 40 is basically a debugging line that I’ve left in for future development. While writing planets, I had Lines 36–38 commented out and Line 40 uncommented so I could see the results immediately in the Terminal.

planets is run by launchd every 30 minutes, on the hour and half-hour, via this launch agent, com.leancrew.planets.plist:

xml:
 1:  <?xml version="1.0" encoding="UTF-8"?>
 2:  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 3:  <plist version="1.0">
 4:  <dict>
 5:    <key>Label</key>
 6:    <string>com.leancrew.planets</string>
 7:    <key>ProgramArguments</key>
 8:    <array>
 9:      <string>/path/to/python</string>
10:      <string>/path/to/planets</string>
11:    </array>
12:    <key>StartCalendarInterval</key>
13:    <array>
14:      <dict>
15:        <key>Minute</key>
16:        <integer>0</integer>
17:      </dict>
18:      <dict>
19:        <key>Minute</key>
20:        <integer>30</integer>
21:      </dict>
22:    </array>
23:  </dict>
24:  </plist>

The first item in the ProgramArguments array is the full path to the Python executable (this is why planets doesn’t need a shebang line), and the second item is the full path to the planets script itself. The schedule for running planets is in the StartCalendarInterval array—whenever the minute is 0 or 30, the script is run.

As I write this, a solar eclipse is nearly underway. Here in the Chicago area, it’s going to be a very partial eclipse—only 1% of the Sun will be blocked. Since 100% of the Sun is being blocked by clouds, I won’t be able to see any of the eclipse. But my planets widget is showing me, more or less, that it’s happening above the clouds.

Rounding the Sun and Moon’s positions to the nearest degree isn’t precise enough to determine an eclipse, but it’s a decent hint.

---

Older posts

Site search

Meta

• drdrang at leancrew
• Blog archive
• RSS feed
• JSON feed
• Mastodon
• GitHub repositories

Recent posts

Credits

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

© 2005–2026, Dr. Drang