More from videah.net
The fresh new videah.net Posted on August 30, 2026 It’s an unfortunate fact of life that every tech-savvy person who writes any kind of long-form content is born with an evil curse that compels them to spend more time coming up with increasingly complex byzantine blogging engines than actually writing any blog posts that use them. It’s been well over a year since my last written post, which means it’s time to deploy the latest iteration! The twist this time is it actually ends up replacing two websites. Yes! My blog and personal site are now one and the same. The old terminal-style site was cool for the time, but I think it’s now a bit overplayed and was very limiting. Who the hell wants to type to navigate a website? Especially on mobile, oh man! The old site and blog are not completely gone! They’re hosted at old.videah.net and old.blog.videah.net respectively, just for preservation purposes. They will no longer be updated. Feel free to look around, if you have any feedback on the new design I’d love to hear it! For fun silly things I recommend checking out my 3D model display or going to the homepage and clicking on my pixel art nose. Out with the Markdown The old blog used Zola to generate HTML from some Markdown. It’s as nice as static Markdown site generators get. But over time I couldn’t escape the feeling that Markdown was leaving something to be desired. I think the simplicity of Markdown ends up getting in its own way a bit. I grew to hate writing Markdown. I found myself repeatedly trying to work around its limitations using Zola’s shortcode system which lets you inject some custom HTML components. These are just hacky macros at the end of the day though, they’re not very ergonomic and you can’t do anything crazy with them. It also just became impossible to maintain because the underlying styling was written in Tailwind. You’re tricked into thinking it is sooo nice and easy to use until you need to make a change 6 months later. This new website on the other hand is written in Typst, a modern markup language intended to replace LaTeX for document writing. I’d used it in the past to write my resume when I was applying for a job so I already had some good experience with it. When I noticed they were adding HTML support as a build target, I got really excited! It’s not fully mature yet but with the help of some plumbing from Rheo I think it’s crossed the threshold as just an all-round better alternative to writing Markdown. How about some examples? I think it would help to show off some of the code powering the site to give you a good idea of what it’s capable of. Starting off simple, the fursona callout box further up the page is a reusable component that I can call anywhere in the document like so: #sticker-callout("poggers", side: "right", flush: true)[ The old site and blog are not completely gone! ] Which I think is just a really nice and simple syntax for that kind of thing. Then consider this snippet of code from /elsewhere that takes a list of my social media accounts and renders them as a list of links: #let accounts = ( ("GitHub", ("https://github.com/videah", "@videah")), ("YouTube", ("https://youtube.com/@videah", "@videah")), ("Bluesky", ("https://bsky.app/profile/videah.net", "@videah.net")), ) #let me-link(url, body) = html.elem("a", attrs: (href: url, rel: "me") )[#body] = Accounts #list(..accounts .pairs() .sorted(key: ((name, _)) => lower(name)) .map(((name, (url, handle))) => [#name: #me-link(url, handle)])) This lets me easily add new handles and have it automatically render a list in alphabetical order. No need to maintain the order manually. This is all done in-line in the Typst document alongside written content. Cool right? We can also pull off some more advanced stuff, like this snippet that helps transform all native emoji to the custom Mutant Standard emoji I use on the site: #let mutant-transform(doc) = { show raw: it => _untransformed(it) show _emoji-re: it => context { let cps = it.text.codepoints().map(c => c.to-unicode()) let key = cps .filter(c => c != 0xFE0F) .map(c => str(c, base: 16)).join("-") if no-emoji-transform.get() or key not in _index.seq { it } else { mutant-emoji(_index.seq.at(key), text: it.text) } } doc } This is great because it means we don’t need to do any JavaScript runtime transformations like Twemoji does, this is all done at compile time! This seems like a lot… is it a lot? The appeal here is Typst can be as simple or complex as I need it to be. I can just write posts normally and reach further down to the more programmatic stuff when I feel like it and have it all work seamlessly in a single plain-text document file. This doesn’t even touch on the future potential this unlocks! Like writing once and having it spit out PDFs and EPUBs alongside the HTML output, which I’ll likely be using in the future for my resume. At the end of the day, I’m hoping this just makes me more likely to write stuff. Or maybe in a year’s time I’ll have moved on to something even more esoteric. Who knows! You can read a little more about the tools powering this site at /colophon. Discuss There’s no comment section here sadly — the UK’s Online Safety Act makes running one on a small personal blog more legal exposure than it’s worth. If you wanna comment on something, try leaving a reply in the Bluesky thread! Discuss on Bluesky →
Attacking My Landlord's Boiler Posted on April 22, 2025 This post is from a legacy version of this blog! No changes have been made to the content in the migration, so things might read weird. Please do your due diligence and check local laws before attempting anything I do in this post. Transmitting radio signals can become legally problematic very quickly, and the band I specifically transmit on here (868Mhz) is illegal in the United States without a license. I’d rather you didn’t have men in suits knocking on your door on my account. You’ve been warned! A little while ago I moved into an apartment to live on my own for the first time. This has given me a decent amount of newfound freedom to sculpt my living environment to my liking, but not enough where I could start knocking down walls. I have a landlord (and a deposit!) to think about, after all. While it isn’t near the level of knocking down walls, I was finding heating my apartment rather frustrating. The boiler’s thermostat installed by my landlord is a single radio-controlled unit that uses a built-in temperature sensor to modulate the heating on and off to meet a target temperature. This presents a few first-world problems: The temperature sensor can only sample a single room in the apartment, which heats unevenly. That room is dependent on the physical proximity of the thermostat’s controls, which can be annoying to use if I might be in bed and the controls are in the living room or vice versa. If I forget to turn the heating off before I leave the apartment, I’m wasting a lot of costly energy. I automate things around my apartment with Home Assistant, and I wanted to be able to do the same here. There are a lot of off-the-shelf solutions for this, obviously, but to get back to the knocking-down-walls comparison, they would require my landlord’s cooperation and likely a visit from an electrician. I don’t want that! Instead, here’s how I figured out how to control my apartment’s heating in a way that leaves no trace using the existing thermostat already fitted by my landlord, and maybe learn a bit about radios along the way. Where Do We Start? I knew that the thermostat communicated with the boiler through some kind of radio protocol. We could try to reverse-engineer the protocol from scratch, but as I’ll get into later, that turns out to be very involved and way beyond my minimal radio skills. I eventually decided it was a lot easier to attempt something called a Replay Attack. This involves cloning the signals sent between the boiler and the thermostat, and then pretending we are the thermostat by re-broadcasting the signals. This way we don’t need to understand the protocol, just replay it. This approach requires some degree of luck and crossing your fingers. Replay attacks can be pretty easily thwarted by using an incrementing counter in the communications to nullify previous signals, ignoring signals with a counter value you’ve already seen. I was lucky the thermostat does not do this—your mileage may vary! Initial Reconnaissance The first thing I did was check to see if there was any information online about my specific thermostat. I came across a listing for the exact model I had, along with a datasheet in the attachments section. The section on RF Communication is exactly what I was looking for: From this, we know the thermostat communicates around the 868Mhz range. The Protocol: Encrypted part was initially a bit concerning, but it turned out to not be a problem. The first issue I’m running into here is that there are shockingly few resources on cloning a 868Mhz signal online. Most beefy resources were about using LoRa/Meshtastic. I would come across a lot of Reddit posts of people trying to do the same thing as me for things like ceiling fans and garage doors, but nobody seemed to have any answers… I suspect this is because unlicensed 868Mhz transmission is illegal in the US and nobody cares about Europe, but who really knows. My life would be so much easier if it were 433Mhz instead, as there is a plethora of consumer-facing tools for communicating on that band. Seeing Signals So without much to go on, I thought the first thing to do would be to actually see the radio packets and inspect them. I’d read about Software-Defined Radios in the past and guessed it’d be my best bet. Most SDRs are really expensive, so I went with the budget RTL-SDR V4 off of AliExpress. (This actually ended up being somewhat unnecessary for reasons we’ll eventually get to!) You might have heard of the infamous Flipper Zero and its ability to clone and replay signals. Maybe you’re like me and consider using it in this situation, but be warned that the Flipper is NOT an SDR. The Flipper is very stingy about what frequencies it can operate on. I found this out the hard way when I borrowed one and assumed all was hopeless when it wouldn’t work. After it arrived, I hooked it up to my laptop with the SDR++ software just to see if it worked and get an initial glimpse of my thermostat yapping. After pressing the thermostat’s buttons a few times, I managed to see the waterfall light up! The “waterfall” at 868Mhz showing long horizontal blips. Ignore the solid vertical line on the waterfall—this is just a common byproduct of using a really cheap SDR, and for me it appears nearby to any frequency I’m inspecting. This step isn’t super important, but we can then try to use the rtl_433 tool (it works on other frequencies despite the name) to see if the thermostat is speaking a known protocol. More obscure devices might not work here! It seems like this thermostat speaks the same protocol as another Honeywell one. The demand attribute sets whether the boiler is on (1) or off (0), and then the boiler responds with an acknowledgement (presumably so the thermostat can determine if it’s out of range). Trying To Yell Back Now that we’ve actually seen the back-and-forth communication, we want to be able to send some packets ourselves and puppeteer the boiler as if we were the thermostat. Using a 868Mhz Challenger Dev Board, first failed attempt… This was the step I got stuck on for months. I was trying the “smart” route of attempting to reverse-engineer and reconstruct the packets by hand using URH and then broadcasting them with very cheap 868Mhz microcontroller boards. I can safely say this was all wayyy outside of my skill set. None of the boards were really designed to talk to anything other than the exact same board, and going any further than that required poking at radio registers in ways I wasn’t comfortable doing. The HackRF The official HackRF One board, going on to spawn many AliExpress clones. I decided to then go for the sledgehammer approach: use a full-blown SDR to just replay the exact same signal without a care for what the signal actually contains. But the cheap RTL-SDR I got earlier only supports receiving, not broadcasting. SDRs that can broadcast are usually hundreds of dollars. I say usuallyyy because one of the most common broadcast-capable SDRs, the HackRF One (usually upwards of $400), had numerous clones available on AliExpress for a fraction of the price—just $40. And then I say haddd because, writing this months later, AliExpress has removed pretty much every listing you could find just searching “HackRF”. From my understanding, they were getting nabbed at customs in a lot of countries that were getting pissy about importing a scawy hacking tool, so they just decided to nuke all the listings rather than deal with it. Newer clones can be bought from here, but they aren’t nearly as cheap as they used to be… There are some obvious ethical (and probably a few technical) problems with cheap clones of what is meant to be open-source hardware, but I figured it’d be fine for my small use case. Please support the original hardware project if it’s within your means to! As I kinda alluded to earlier, this makes the need for the RTL-SDR sort of redundant? But I guess it’s always good to have another SDR just to confirm that we’re not polluting other frequencies. Actually Yelling Back With the HackRF in hand, we can use the hackrf_transfer tool to record signals and, most importantly, replay signals. I perform these commands and then press the appropriate controls on the thermostat to write the signals to individual files: # We set the frequency to 868.3Mhz and the sample rate to 2000000. hackrf_transfer -r turn_off.raw -f 868300000 -s 2000000 hackrf_transfer -r turn_on.raw -f 868300000 -s 2000000 And then we can try and turn the boiler off and on from CLI like this: # We use -a to turn on the amplifier and -x to increase the gain a tad. hackrf_transfer -t turn_off.raw -f 868300000 -s 2000000 -a 1 -x 23 hackrf_transfer -t turn_on.raw -f 868300000 -s 2000000 -a 1 -x 23 After doing this, I could hear the physical relay inside of my boiler turning on and off! Automating The Whole Thing My HackRF clone in a 3D printed case, plugged into the server. I have the HackRF plugged into a powered USB hub connected to my Home Assistant server. I wrote a very basic web server that simply shells out to the transmit commands above in a Docker container. Then with an Average Sensor Plugin and the config YAML below: command_line: - switch: name: Boiler command_on: "curl http://docker-vm:1111/api/on" command_off: "curl http://docker-vm:1111/api/off" sensor: - platform: average name: "Average Temperature" entities: - sensor.bedroom_thermostat_temperature - sensor.kitchen_thermostat_temperature climate: - platform: generic_thermostat name: Boiler Thermostat heater: switch.boiler target_sensor: sensor.average_temperature We have a working controllable thermostat! At this point I was just happy to have the thing working after so many months, so I’ll be the first to admit this setup with Home Assistant is a bit slapdash and could use some cleanup. It’d be better to write a proper plugin and control the radio directly instead of shelling out to the CLI. Relying on curl to heat my apartment is maybe a bit cursed? Was It Worth It? Grafana graph showing the temperatures following the target one. I’ve been using this setup to control the heating of my apartment since the beginning of December and haven’t had any issues since! It’s super convenient to dial in the temperature from my phone, and the automations I have make me feel like this project was really worth the work. I have some basic automations like having the temperature go down when I’m sleeping and then up in the morning in time for me waking up, but I also have it so the heating turns off when I go into town and turns back on when I’m just a few train stops away so my place is nice and toasty for me getting home! The only thing I’m not happy with is needing to use a very powerful and versatile radio like the HackRF for something as simple as a boiler on/off switch. But I’d rather use something overkill and have it work than spend ages trying to force smaller radios to do my bidding. The important thing is I’m not as cold as I used to be! Discuss There’s no comment section here sadly — the UK’s Online Safety Act makes running one on a small personal blog more legal exposure than it’s worth.
My E-Reader Setup Posted on August 10, 2023 This post is from a legacy version of this blog! No changes have been made to the content in the migration, so things might read weird. I bought an e-reader recently, specifically the Kobo Libra 2. I felt like I wasn’t reading books/manga as much as I wanted and I think the convenience of being able to carry my entire library around with me will help with that. I own an iPad Pro but I wanted a device I didn’t need to think about charging that often and wouldn’t give me eye strain. This post is a bundle of notes about my current reading setup. I had owned a Kindle Paperwhite before but it was so locked down that I couldn’t find any joy out of using it since I was forced to use it how Amazon product managers wanted me to. The Libra 2 I spent several hours doing research and I think the Libra 2 is the best device on the market at the moment, at least for my needs. I picked it up in white to try and make an important psychological distiction. I wanted it to differ from every other electronic rectangle I own and treat it more like a nice book rather than a computer that will inevitably make me angry. Which all things considered is quite funny with all the computer nonsense I ended up doing to it. It’s got a 7-inch screen which is a little shy of the perfect Tankōbon volume size, but close enough that manga is comfortable to read. I remember reading somewhere that the screen has one of the best contrast ratios in an e-reader and it is indeed very good. The lineart of Junji Ito’s Uzumaki looks very crisp on this display. Navigation buttons are a dying breed in the e-reader space but I really can’t live without them. Using a touchscreen to navigate is hateful and is really fake skeumorphism. You can pretend all you want but it does not feel like you are flipping a page! Thankfully the Libra 2 has two buttons on the side where you hold it so you can go back and forth with just one hand. I got the very overpriced official SleepCover case in orange. Matches my iPad case. Stops the plastic from making flexing sounds. It can let your e-reader stand upright for some reason. Book Management The only real book management software in town for e-readers is Calibre but it’s stuck in the late 2000′s UNIX school of UI design and I reaaally don’t want to deal with that kind of thing anymore. I want organising my books to feel comfy. I also don’t want it to depend on having my laptop with me, constantly wiring it to my e-reader to sync new books. Calibre on macOS. It is very noisy. It’s not perfect but Calibre-Web works better for me. Despite the confusing name it’s a completely distinct project that just happens to be compatible with Calibre’s database format. I have it hosted on my personal VPS so I can access it anywhere and can give friends access if I need to. It’s not quite Plex for books but it is close. The bootstrap UI is a little dated but it works for what I need. I’m keeping my eye on a relatively new project called Librum that’s in its infancy. If it matures it promises some nice features like syncing reading positions and its own dedicated client. Reader Software The default reader software the Libra 2 comes with is called Nickel and it’s fine. It looks and runs ok enough and the built in Kobo Sync functionality can be tweaked to work with my Calibre-Web instance by replacing the endpoint in a config file, which I have to give Rakuten props for letting you do. But sideloaded files can be very broken. I was half way through a book before I realised Nickel was just throwing all of my notes and highlights into the void whenever I closed it, which was very rude. This is apparently a common problem that’s been around for a while and it seems Rakuten have no plan to fix it anytime soon. I went looking around for some open source alternatives. Most people reach for KOReader. It runs on pretty much everything and is packed with an ungodly amount of features and has a steady community built around it. Comparing library views for KOReader and Plato. But if I’m being honest I just can’t find any enjoyment using it. The user interface just isn’t up to snuff. It feels impossible to navigate and there is no real library view, only a file manager. When I’m holding my e-reader I don’t want to be reminded that it is a computer all the time. It’s meant to be a book! I came across Plato which is made exclusively for Kobo devices and worked on by the guy responsible for bspwm. It’s really fast and responsive, more so than Nickel even. The UI is pretty much exactly what I’m looking for. It’s not nearly as feature complete as KOReader but it’s written in Rust which is a language I feel confident enough in to tweak and implement things to my hearts desire. I’ve already made a small change that got merged upstream too! Syncing Originally I was using Kobo Sync with the endpoint changed to point to my Calibre-Web instance to sync my books wirelessly. But it was buggy and slow and could only pull in KEPUB files. Plato has a built in hook system that lets you run arbitrary binaries when a directory is opened. Using this I wrote a small CLI tool that just pulls every book that hasn’t been downloaded yet from my Calibre-Web instance using the OPDS protocol. I’ve stuck the code for this tool up on my Github if anyone else is interested in using it! In the future I would like to take advantage of this hook system to also sync reading positions and other metadata Plato stores. Tailscale VPN I love plugging as many of my devices into my Tailscale network as I can and I thought it’d be a fun little project to try and get it running on the Libra 2. Someone had already done most of the work by getting it to run on the Kobo Sage. It turns out it’s a little harder for the Libra, I had to spend a ridiculous amount of time compiling some missing kernel modules in a horrendously slow emulated x86 emulator just to get this thing running. The joys of owning an ARM laptop. I think being able to type ping kobo and have it Just Work makes all the hours spent worthwhile though I packaged all the work I done up nicely in an install script so it should be dead easy to get this working on your Libra 2 as well. Tailscale has a built in AirDrop-esque file transfer feature that I find really useful for quickly sending PDFs to my e-reader that I don’t necessarily want to be a permanent part of my library. Sending a PDF remotely with one click with TailDrop. Unfortunately I couldn’t get Tailscale SSH working which was one of the main reasons I attempted this in the first place I’m not sure why but my first guess would be that I need iptable packet filtering but that would require swapping out the whole kernel which I don’t feel comfortable doing at the moment. Maybe some day though. SSH The Libra 2 only has telnet support out of the box behind a developer cheat code (typing devmodeon into the search bar) which is fine because I’d be using it over a Tailscale wireguard connection anyway. My threat model doesn’t exactly involve people bruteforcing telnet over public WiFi just to steal my furry books. But for completions sake I stuck the Dropbear SSH server on mine and then disabled telnet. Storage The Libra 2 has 32gb of internal storage which is pretty huge for books considering how small EPUBs usually are. But I like reading manga which can be pretty hefty. An average volume is 200mb, with stuff like Uzumaki coming in at 800mb. What if I need to store every uncompressed volume of One Piece for offline reading in the event of the apocalypse? Most e-readers treat manga as secondary to books and rarely offer higher storage options or mini-SD card slots anymore. Thankfully the Libra 2 has a mini-SD slot… it’s just an internal one not meant to be user accessable 🫠 Libra 2 internals, SD card highlighted in the red circle. Image taken by MobileRead user ‘supermighty’ This is better than not being able to upgrade the storage at all though and was actually one of the main things that pushed me in the Libra 2′s direction when doing research. Someone on the MobileRead forums replaced the SD card and posted instructions on how to do so. I haven’t done this for mine yet but I plan on giving it a shot and sticking something utterly ridiculous like 512gb or 1tb in there. It seems like a pretty risky/messy mod to do though, the slot and card are caked in waterproofing glue that you’ll need to reapply afterwards if you’re like me and enjoy reading in the bath. Even if this seems excessive it does let me sleep easier at night knowing I can replace the internal storage in the event it somehow fries itself. Dictionary This is a feature I didn’t know I wanted till I used it. It’s a pretty big leg-up over reading physical books when I can easily hold down on a word I’m not sure about. I’m using the ebook-reader-dict project which is based on Wiktionary since that’s the one Plato recommends and is designed to work with. Unfortunately it’s a bit hit or miss. I’m not too happy about the quality of the definitions sometimes, I’ll probably look at alternatives at some point. Plato renders the definitions without any padding which looks a bit weird. I can probably fix this easily in the code later though. Feels good using open source software sometimes. Font For reading, I use the font Atkinson Hyperlegible which you might know from Cohost, but it’s also used by the very blog you’re looking at now! I’ve fallen in love with it as it’s really easy to read even when the text is very small. Very pretty and accessible. Discuss There’s no comment section here sadly — the UK’s Online Safety Act makes running one on a small personal blog more legal exposure than it’s worth.
Web Push Pitfall Posted on March 30, 2023 This post is from a legacy version of this blog! No changes have been made to the content in the migration, so things might read weird. Whilst implementing Web Push notifications for my toy Q&A service curiouswolf I ran into an issue that led to me being stumped for hours. I was successfully receiving notifications from my server when using Chrome, but no matter what Safari was not playing ball. Web Push requires the browser maintainers to run a notification endpoint. For example, when you use Google Chrome and you enable notifications on a page, your encrypted notifications get funneled through a server Google controls. In the case of Safari however, their endpoint was returning BadJwtToken for me despite it being considered valid by Google. The Solution It turns out that Apple (and Mozilla apparently) require you to include a sub claim in your JWT with a method of contact (such as an email) for them to consider it valid. If you are providing an email, the sub claim should be prefixed with mailto: { "sub": "mailto:[email protected]", // <-- The important part "aud": "https://web.push.apple.com", "exp": "1680135079" } The reasoning behind this is to provide the operator of the endpoint with a means of contacting you if there’s an issue. However, this technically goes against the Web Push spec, and it’s frustrating that something like this isn’t spelled out clearly in Apple or Mozilla’s technical documentation. Notice the emphasis on the word MAY Apple quite regularly leave important information out of their docs for web APIs like this, but it’s really messed up that the only place Mozilla talk about this is in a blog post from 2016. Discuss There’s no comment section here sadly — the UK’s Online Safety Act makes running one on a small personal blog more legal exposure than it’s worth.
More in technology
Someone stated in the early days of the war, a feeling that was reciprocated by the soldier in khaki and the sailor in blue, that a mechanical device would be the determining factor in ending the world conflict, favorably, of course, for the United States and her allies. 1 One of my common topics is the history of nuclear weapons. The "atom bomb" is a rich vein of history because its impact has been as much cultural as technical. Dramatic depictions like Christopher Nolan's Oppenheimer have recently enforced, perhaps even revived, the perception of nuclear weapons as an innovation that forever changed warfare. More quietly, historians and strategists tend to wonder if that is still true today, or if it was ever as true as was supposed—the conventional firebombing of Tokyo probably claimed as many victims as the nuclear attacks on Hiroshima and Nagasaki, for example. Besides, it's not unusual to hear people overstate the significance of nuclear weapons to WWII in a way that is obvious with a brief inspection of the timeline. The technology became available only very late in the war, and for that reason if no other, it must have had less of an impact on the outcome than other revolutionary wartime developments like radar. Why is it that radar, a complex technology that fundamentally changed the landscape of aerial combat, seems so pedestrian? Perhaps because the technology has far more non-military applications, and so is more familiar to our everyday lives. Perhaps because the development of radar was scattered between countries and institutions without the involvement of such intriguing figureheads as J. Robert Oppenheimer (although one wonders if this is because we have not looked as close; certainly radar figures like Henry Tizard had colorful lives as well). Perhaps because radar just isn't as exciting: it does not put on anything like the show of a nuclear detonation. Today, we consider another such step in military technology. This is an invention that forever changed the battlefield, and it's one that does put on a show. In fact, that has become the technology's main purpose. From the 1870 siege of Paris to the modern used car lot, searchlights have marked many of history's great conflicts—and great deals. The concept of electric light has been known since the very early 19th century. An electric arc lamp, or at least one of their ancestors, was demonstrated in 1806. Because of the widely known story of Thomas Edison's incandescent lamp, most people know that electric light had a very difficult journey from idea to practical device. That path was not as simple as what we are taught in schools: besides the several other inventors with a good claim to the lightbulb, incandescent lights were just one of a few technologies that developed in parallel. Before controlled incandescence, the principal form of electric light was still an arc. Arc lamps also did not fall to incandescent bulbs as quickly as you might think. Arc lamps remained the preferred choice for very bright, high-CRI lighting into the mid-20th century, and reached what will likely remain their ultimate form in the late 1960s, as the 15 kW Xenon arc lamps used by IMAX projectors. Along the way, arc lamps displaced many of the early forms of artificial lights: Oxy-hydrogen candles, known as "limelights," fell out of theatrical use. "Moonlight towers" began the displacement of gas lights for street lighting. And the military—the military readily adopted this new form of reliable, practical, powerful lighting. Calling In Light The effect of artificial lighting on military tactics could fill a book. I will focus on one narrow part of this story, but it will be helpful to set the stage with a few of the earlier developments. For much of the pre-electricity era of military history, artificial lighting was mostly a disadvantage. Fires, torches, and other practical sources of light were bright enough to reveal one's location but not bright enough to search anyone else out. Ironically, the main interest that military researchers had in light was often to suppress or conceal it. The chemical light technology developed for theaters and displays had promise, though. One of the first recorded uses of a powerful light for a military venture (and, as far as I can tell, the very first recorded use of a searchlight) came in the context of the American Civil War. The Union Navy sought to economically attack the Confederacy by maintaining a persistent blockade on southern ports; the Confederacy sought to maintain trade, often by sending out "blockade runners" under cover of night. A Union ship, perhaps frustrated by firing aimlessly into the dark, improvised: a theatrical light was mounted to a crude reflector, forming the first naval searchlight. It wasn't a very good one, it was dim and unfocused and the sailors struggled even to keep it lit under maritime conditions. It was good enough, though. By first following the sound, and then casting the light, the Union ship was able to engage the Confederate vessel even on a moonless night. Amusingly, while this incident is widely described in histories of military signals and lights, I have found none that state the outcome. Perhaps it was unfavorable to the victors. Electric arc lamps were far more suitable to military use: simpler to operate (although not as simple as we might today expect), more flexible in their placement, and by the end of the Civil War brighter. The 1870 Siege of Paris, part of the Franco-Prussian War, was a bellwether in the history of military aviation. Cut off on the ground, the French made extensive use of balloons (a technology they had pioneered in the 18th century) to move people and mail. In the process, several records for aerial travel were set. The French enjoyed air superiority and had little need for air defense, but the situation on the ground was much more troublesome. Prussian forces mounted lengthy artillery bombardments, causing devastation limited mostly by the range of their cannons. For the soldiers manning Paris's fortifications, it was important not only to keep attackers outside of the city, but to keep them as far away as possible. Paris, not for nothing known as the "City of Light," had seen demonstrations of arc lamps back to 1850. The invention of the arc regulator (which advanced the carbon rods to keep the arc intact) and improved batteries made the lights more practical by 1870, and during the early days of the siege "electricians" were hastily recruited to the city's defense. They manned a variety of arc lamps installed around the city, limiting the cover of darkness for nighttime assaults. At the summit of Montmartre hill, a position with a clear view over one of the most vulnerable parts of the city's defense, they installed one of the most impressive lights ever built. Not only was it larger than the others, it could operate for longer: the power supply was not a battery, but a dynamo powered by a steam engine. Besides that leap into modern design, the Montmartre light also presents an early example of "tipping and cueing" in intelligence gathering. French intelligence agents, having caught wind of a surprise attack, sent a message to Montmartre where the light's skilled operators aimed it by heading and elevation before applying power to catch the enemy in quite a compromising position. A decade later, the military searchlight had become a standard technology. The Royal Navy regularly equipped ships with dynamo-powered, carbon-arc searchlights starting around 1882. They found that, besides their role in aiming weapons, searchlights could be something of a weapon on their own. Aiming searchlights back at coast defense artillery positions not only exposed them to incoming fire, it also dazzled the gunners and frustrated their efforts to accurately aim at the ships. This principle was memorably demonstrated by a 1903 US joint maneuver exercise, in which the Navy's Atlantic Fleet mounted a simulated attack on Long Island Sound. All together, on cue, the ships trained their searchlights on the main defensive battery at Fort Michie. The soldiers at the fort didn't manage a single shot, they were so blinded by the lights—and limited in their ability to even move around the battlements, since they could so plainly be seen (and fired upon). As the military developed searchlights, they were quickly applied to civilian use. Limited availability of electricity, and limited need for such powerful lighting, meant that searchlights wouldn't yet become part of the urban landscape. They were reserved for special events, especially those with an emphasis on technical demonstrations. Of course, such events were bounteous around the turn of the century in the form of various world fairs and expositions. Perhaps the first use of searchlights as a device for entertainment came at the 1893 Chicago World's Fair, which was extensively lit by electricity. A total of 17,000 horsepower of steam engines (so, yes, presumably steam horsepower, a curiously different unit from the one we are familiar with today) powered thousands of arc lights. Most of these were for illuminating the fairgrounds and its many monuments, but some were installed for the sake of light itself. On the roof of the Liberal Arts Building, a searchlight claimed to be the most powerful yet made could light a newspaper well enough to comfortably read at a distance of eight miles. Of course, it was more than just a book light—it was a way to attract attention. Unlike the military context, civilian searchlights were deployed specifically to be seen. Rooftop searchlights became a common feature of large expositions, and by lazily searching the sky they established an atmosphere while guiding curious onlookers to the site of the event. Even this early, it was known that searchlights could be a powerful form of advertising. At the Chicago World's Fair, the upstart Cloud Projector Company demonstrated a searchlight with a lens system that could focus a slide onto the cloud layer. It was literally a cloud projector, in the modern sense, and giant words floating ethereally in the sky announced the fair's upcoming special events. In 1901, the Pan-American Exposition was underway at Niagara. Among the attractions was a demonstration of electrical arcs produced by a 40 kV transformer recently installed at the Niagara Falls power station. Alongside that light show, a second, more controlled form of arc was displayed: searchlights. These were described as an application of military technology, and specifically of military signaling technology. Searchlights were installed atop the "Electric Tower" at the exposition grounds, and at a viewing tower erected at Niagara Falls proper. At night, the two lights—22 miles apart—were each plainly visible from the other tower. The military was, of course, well aware of this potential use and as soon as searchlights had been installed on Navy ships they came into use as a means of communication. Extensive newspaper coverage of the Exposition means that we know more details of these machines. The searchlights used for the tower demonstrations had 30" reflectors, and consumed 80 amps at about 50 volts for 4 kW give or take. This was indeed a very bright light for the time, and at the Exposition, the searchlights were swung around among various targets. "As the beams of the projectors sweep across country," The Virginian-Pilot wrote, "the residents of the villages and country places will enjoy the illumination." Excitement for the lights was such that newspapers throughout the region published Morse code tables, in the hope that anyone in the region could decipher news bulletins that were sent from the signal lights. Watching the Skies Electric light is far from the only invention to make a dual appeal to spectacle and the military. From the Wrights' first controlled flight in 1903, it only took about seven years for the Navy to envision the aircraft carrier. The 1911 Italo-Turkish war featured armed biplanes, and as the hostilities of the First World War opened the US Army flew airplanes into Mexico, in pursuit of Pancho Villa. In 1915, the Austro-Hungarian Aviation Troops bombarded the Serbian city of Kragujevac from biplanes. Serbian soldiers fired on them with small arms, but had no success. A private, though, got a lucky shot with an artillery gun. This was the first instance of ground-air combat, and the first use of air defense. By the latter part of WWI, aircraft were in routine use as both bombers and fighters. One tended to lead to the other: our 1915 takedown notwithstanding, bombers and reconnaissance planes enjoyed almost complete freedom of the skies in the first few years of the war, until Germany's fighters presented meaningful resistance. Ground-based air defense lagged behind, but in an interesting turn of aviation history, the held-over use of tethered balloons as observation posts provided a key motivation for improved anti-air artillery. These balloons were conspicuous and almost defenseless, so ground-based escorts accompanied them. Balloons—and in the case of the Germans, Zeppelins—remained an important part of WWI air units. Besides their ability to hang around for an extended period of time, airships could carry much larger payloads than early bombers. Zeppelins occasionally loomed over London, raining down the era's most sophisticated destruction, from 1915 to 1917. These lumbering vessels had their vulnerabilities, though. Big, slow, and flammable, they were easy to take out with artillery fire if you could spot them. German air raids were conducted at night, and by the end of the war Zeppelins were being painted a non-reflective black. By 1916, a network of 258 searchlights across England hunted the skies for airships. There were as many anti-aircraft guns, using the pencil-beams of the searchlights as aiming guides. Air defense was so new at the time that little military doctrine had developed around it, and Britain's first searchlight units were found in the Royal Engineers. As in France, the searchlight operators were known as electricians, specifically the Electrical Engineers. These units had actually formed prior to the outbreak of WWI, for the purpose of coastal defense. None other than Chief Scout Lieutenant-General Robert Stephenson Smyth Baden-Powell (yes, the 1st Baron Baden-Powell) had improvised the use of a chemical searchlight to keep ships away from a besieged town during the Second Boer War; the Electrical Engineers had relieved the use of chemical lights in South Africa when they arrived with arc lights. By 1914, the Electrical Engineers had six companies in London as part of the Territorial Army. With the outbreak of the World War they were immediately put into service, as were other Anti-Aircraft Searchlight companies across Britain. Soon, other companies were deployed closer to the front in Europe. 1910s carbon arc search lamps were not always easy to operate. Most military searchlights by that time were built on the back of trucks, with combustion engine dynamos as a power supply. A typical WWI searchlight unit had three lights, five trucks, and 28 soldiers. Searchlight units became a natural home for other air defense technologies then under development, so that by the end of the war some units had acoustic reflectors (for detecting aircraft by sound) as well. One of the lessons learned during the First World War was that searchlights were quite flexible. Portable searchlights could be used for air-defense, or could be positioned on a hill to light the battlefield (and even dazzle attackers). A technique called "artificial moonlight" took advantage of the enormous output of carbon arc lamps by pointing a searchlight up at clouds and letting the clouds reflect the light back to earth. This dim illumination could help an infantry unit move at night; commanders had the moon on demand. On the other hand, searchlights were vulnerable. Experiments in mounting searchlights on airships to light the ground were of limited success, the lights made the position of the airship obvious and it would quickly be shot down. Similarly, as air-ground combat techniques evolved, searchlights became the first target for incoming enemy aircraft. Destroying the searchlights meant that anti-air guns were firing blind. Even after the First World War established searchlights as a defensive technology—their sweeping beams portending destruction—the public didn't lose its affection for a bright display. In an apparent homage to the use of arc lamps for both stage plays and film projectors, Hollywood's Egyptian Theater had searchlights atop its facade from its opening day. Perhaps inspired by the 1895 installation of an ex-Chicago World's Fair searchlight in Pasadena, the Egyptian Theater's lights announced premieres by sweeping the sky—promotional searchlights learned from air defense, and ironically, the post-WWI fashion for major events was to aim lights upwards, rather than downwards at terrain as had predominated before the war. Grauman extended the concept to his other theaters, with both permanent and portable lights often used at the Chinese Theater. In 1930, for the opening of Howard Hughes's "Hell's Angels," 200 searchlights lined Hollywood Boulevard. The scene could have easily been mistaken for a major air raid, but instead it became part of Hollywood culture. Three years later, 20th Century Pictures adopted its memorable emblem, surrounded by beams of light. Hollywood's searchlights spread beyond just theaters. In 1931, Fisher Motors De Soto-Plymouth on Hollywood Boulevard opened under sweeping lights. Auto dealerships always wanted attention, and searchlights were the perfect combination of electrical modernity, show business spectacle, and mystery. Synchro Searchlights Searchlight technology advanced incrementally between the First and Second World Wars. Carbon-arc lamps remained the underlying technology, but features like automatic carbon regulators (that "fed" the carbon rods towards the arc as they burned away) and foot switches for easy control became standard. A common searchlight at the beginning of WWII might range from 8 to 24 kW, and by the end of the war the largest units reached over 100 kW. The greater innovation of that war was the integration of searchlights into electromechanical fire control systems. New electrical technology, specifically a clever device called a "synchro" or "selsyn," revolutionized searchlight units. A synchro is a way of electrically transmitting a position. Two devices, similar to AC motors, are coupled by a three-phase circuit such that rotating one will rotate the other in proportion. The two "ends" of the synchro will always have the same relative position, so that by putting a synchro transmitter in one place and a synchro receiver in another, you can remote control the position of a device like a searchlight. Synchros were immediately applied to "distant electric control," still a common term in marine searchlights. One of the main problems with the searchlight has always been its tendency to attract enemy fire. Early searchlights often had two operators sitting on chairs to the back or side, cranking wheels for azimuth and elevation. These two operators were often killed early in the engagement. By the use of distant electric control, a searchlight's operators could hide some distance from the searchlight or even operate it from a fortified position like a bunker. This turned out to be a superior way of using a searchlight anyway: operators directly beside later searchlights were practically blinded by the light reflected back by dust and vapor in the air. An operator some distance to the side had a much easier time seeing what was at the end of the beam. Many US air defense searchlights offered a backup, as well: a control crank at the end of a metal arm, called an extended hand control. Were the electrical control system to fail, a searchlight operator could at least stand ten or so feet off to the side and be that much further from incoming fire. Practical use of searchlights for air defense by WWII required adaptation to the better ground-attack capability of aircraft. Searchlights might be stored in a concrete bunker and rolled out on tracks for use, by soldiers who would quickly retreat from the searchlight to a hidden control point. If the searchlight was struck, the operators at least survived, and a well-equipped unit would have a second light ready to go. The purpose of the concrete searchlight shelters was mostly to ensure that a "spare" searchlight would survive the shrapnel from an attack on the one in use. The synchro could also integrate searchlights with other air defense equipment. Early in WWII, radar had not yet been fielded, and acoustic locators remained the state of the art. But they were now part of a unified system: two operators on a set of acoustic listening horns would spin cranks to adjust horizontal and vertical position until the sound of an airplane's engines was loudest. By synchros, this position was transferred to a searchlight control station. These stations resembled a large pair of binoculars on a sort of articulated mount. The base of the control station had readouts for the azimuth and elevation from the acoustic locator, and the operator started by turning wheels to aim the remote searchlight where the locator indicated an aircraft should be present. Once the aircraft was caught in the beam, the searchlight operator threw a transfer switch that placed the searchlight under control of the synchros in the articulations of the binocular mount. From this point on, they tracked the aircraft through the binoculars, and the searchlight followed automatically. The azimuth and elevation from the binoculars could be sent by yet other synchros to readouts at an anti-air control station or even directly to a firing computer that aimed guns. All of this required adjusting for the different locations of each of these components. A combination of old fashioned fire control techniques (placing each station along a common base line) and analog computers did that trick, already well-established technologies since similar computations were needed to aim guns in consideration of gravity and wind. Speaking of a common baseline, it is also worthwhile to discuss the use of searchlights in coast defense during WWII. For a period of the war, the US feared a naval attack, particularly on the West Coast. Similar systems were widely deployed for firing artillery at attacking ships. A set of observation stations, placed along a common baseline, took azimuth readings to enemy ships. Those readings were reported by messenger, and later transmitted by synchros, to a plotting room where a mechanical and later analog computer determined the position of the ship. Yet other computers, at fire control points, determined how to aim the guns. Because this whole system relied on baseline stations visually spotting ships through theodolites, it was much less effective at night. Searchlights were added to many installations, remote controlled by synchros from the baseline stations. Like the azimuth-indicating spotting scopes, two searchlights trained on a ship from a well-surveyed baseline gave enough information to compute a firing solution. Advancing technology obsoleted the whimsical acoustic locating horns. Infrared heat detectors, looking much like searchlights but operating more or less in reverse, were the first electronic means of detecting aircraft in the night. They soon gave way to the first radar sets. The SCR-268, introduced in 1940, was the US Army's first fielded radar system. Its huge beam antenna had three operators on a bench hanging from the back, spinning cranks to adjust the antenna position until oscilloscopes showed the strongest possible return. The SCR-268 was a drop-in replacement for the acoustic locators in searchlight units, but it was far more effective. Skilled radar operators could place an aircraft accurately enough that it was centered in the searchlight beam before the light was turned on. Besides giving enemy pilots quite a surprise, this gave them little time to evade or return fire before anti-aircraft guns were zeroed in from the searchlight. The British developed a more refined version of the SCR-268 called the Searchlight Control Radar. It is notable for its far more compact design, small enough that its antennas were mounted directly to the searchlight under control. The result is almost cyberpunk, a 1.5 meter light bristling with antennas, operators hanging from the sides. The SLC is said to have raised the chances of spotting an inbound aircraft with the searchlight from 1% to 90%. I put a lot of time into writing this, and I hope that you enjoy reading it. If you can spare a few dollars, consider supporting me on ko-fi. You'll receive an occasional extra, subscribers-only post, and defray the costs of providing artisanal, hand-built world wide web directly from Albuquerque, New Mexico. Consider a typical World War II searchlight, the GE Model 1942, introduced the year that its model number suggests. This 60" searchlight came on a trailer, with a second trailer up to 600 feet away for the 12 kW diesel power plant and the control station up to 300 feet away. What we might now call accessory interfaces allowed the searchlight to receive synchro signals from a locator and send them to a firing computer. These searchlights still required quite a bit of maintenance, and they provided features to ease that work, like a work light inside the searchlight drum for replacing the carbon rods. The Second World War also brought about a renaissance in aerial searchlights. Mostly abandoned in the First World War because of their tendency to attract fire, searchlights returned to aircraft for a decidedly nautical use. Submarines, all diesel-electric during WWII, typically surfaced at night to run their engines and charge their batteries. The first submarine-hunting aircraft used compact carbon arc searchlights to pick submarines out of the dark. The system was remarkably effective, and prompted a change in strategy for diesel submarines, which had to rely on their own anti-aircraft weapons rather than mere stealth. Radar complemented the searchlight, but only for a short time. Radar locators for searchlights were basically an interim measure, making the best use of early radar sets that were sensitive enough to detect aircraft but lacked the spatial resolution to locate them precisely. Radar engineers, especially in Britain, made rapid improvements. For anti-submarine warfare, for example, shortwave radar systems were far more sensitive. It wasn't long before radar could directly guide anti-aircraft weapons, as well. Military searchlights had a role to play all the way through the Korean War, but a much reduced one. Anti-aircraft detection and firing is now firmly the domain of electronic warfare: radio waves, not light beams, search our skies. Surplus Light The declining relevance of searchlights to the military proved an enormous boon to their civilian use. Searchlights were tremendously expensive, so promotional use had been limited to major events like world's fairs. During the war, on the other hand, the Army had built thousands of them. Afterwards, through the War Surplus Administration, it parted with most of them at bargain rates. Entrepreneurial spirits, many of them veterans of the war, purchased secondhand air defense searchlights and offered them for advertising. Just about any auto dealership could afford to hire a searchlight for a sale, and many did. In California, it became traditional for dealerships to bring in searchlights to announce the new model year. There is a bit of moth in every human being, operators of giant searchlights have found. Whenever a searchlight is probing into the night sky, motorists are apt to go blocks, even miles out of their way to track down the source. [^2] Growing up in Portland, I remember seeing strange lights in the sky and searching for their origin. The searchlights utterly fascinated me, even if the source inevitably turned out to be another car lot. In New Mexico, promotional searchlights are rare, although not unheard of. The predominant weather may be a factor, since cloud cover makes searchlights more obvious. But it's mostly a matter of geography: the largest concentration of military searchlights was on the West Coast, and many overseas units were returned to West Coast ports. Los Angeles became the capital of the searchlight because they were cheapest there. There are still WWII military surplus searchlights in promotional use, but far fewer than there once were. Parts are hard to come by, and the operation of carbon arc lamps is a less familiar skill. Most of these searchlights are eighty years old, and built to designs that would have been familiar one hundred years ago. Because of radar's dominance, the military has little need for such powerful lights and no longer buys them in quantity. Promotional searchlights have once again detached themselves from air defense, developing as a separate industry. Modern searchlights use Xenon lamps, similar to carbon arcs in their use of an electrical arc as the light source, but far more refined. The arc is confined in an environment of Xenon gas, which practically eliminates electrode wear. Companies like Luminator make several-kW Xenon searchlights that can be mounted to aircraft, the main remaining use of searchlights for tactical purposes. Promotional systems have become much more specialized: Sky Tracker makes a popular system that mounts four 2 kW or 4 kW Xenon searchlights in the bed of a pickup truck. The four lights are attached to a common cam that rotates them in a "clover leaf" pattern, quite nonsensical for the historic application of air defense. Nonetheless, that clover leaf or vortex pattern is probably what most people now think of when searchlights are mentioned. Fixed searchlights, of the type that graced so many World's Fairs, are now rare. The most famous in the US, if not the world, is the Luxor Sky Beam in Las Vegas. Often said to be the brightest light in the world, the tip of the Luxor pyramid contains 39 7 kW Xenon searchlights for a total of over a quarter of a megawatt, all fixed straight upwards. Even that light may be in its twilight years: since 2008, it has operated at only half power. Today, concerns of light pollution, impact on aviation, and a general sense that auto dealerships should not lay claim to the sky have led to a decline in searchlight advertising. We are perhaps fortunate that the Cloud Projector Company's plans for on-cloud advertising didn't pan out; our present advertising industry is dystopian enough. Still, I am but a moth, or at least I have the impulses of one. There's nothing quite like a searchlight. "The Daily Item," Lynn, Massachusetts, May 7 1919 p. 9. [^2]: "The Plain Dealer," Cleveland, Ohio, July 11 1961 p. 46↩
Here are the Vim forks I know about: Neovim: “a Vim-based text editor engineered for extensibility and usability, to encourage new applications and contributions.” Vim Classic: “a stable, long-term support fork of the ubiquitous text editor, maintained without the assistance of generative AI tools.” EVi: “a hard-fork of Vim v9.1.0 (Jan 2024) before AI was used in the project.” MacVim: “a macOS version of the Vim text editor, providing a graphical user interface for Vim, while tightly integrating with macOS and providing features specific to the platform.” This list doesn’t include Vim-inspired editors like Kakoune, Vim-style plugins for other editors like IdeaVim, or Vim “distributions” like LazyVim. Contact me if you know of other forks!
Thought I’d make a quick blog post about some weird behavior I’m seeing on iOS 27 and Dynamic Island live activities, that I initially thought was restricted to the Duo, but turns out affects everything. Yay. Maybe this post can save some others some time, and hopefully Apple can fix it. Long story short, ever since iOS 16.1 introduced “Live Activities”, where we can display handy little widgets in the Dynamic Island, there’s been a bunch of different configurations for showing things up there: something on the left, the right, when expanded, when two apps are showing things and yours gets a bit smaller, and on the lock screen. One interesting one is if you only need to show a small indicator in the Dynamic Island (screen recording indicator, electric vehicle charging status, etc.) you can do so, which just shows on the left on older iPhones, and on the Duo a single one below the camera cutout. Apple describes how to do this in their developer documentation (emphasis added): If you can’t find a solution to display views for leading and trailing compact presentations with limited width, provide a compact leading presentation that best represents your Live Activity, such as the view you use for the minimal presentation, and an empty view for the trailing compact presentation. The system hides the empty trailing view automatically. Unfortunately, in iOS 27 (and 27.1, and 27.2), this only half works, due to a new addition in iOS 27: isDynamicIslandLimitedInWidth. It’s a variable that basically tells you if the Dynamic Island is even narrower than normal, presumably because they knew the Duo was coming with its vertical Dynamic Island, but also because as of iOS 27, Live Activities now show in the Dynamic Island when the device is in landscape too. So it’s handy to know if you have a bit less space than usual. In this new narrow view however, it seems like they didn’t test all the configurations thoroughly, as if you provide EmptyView for that trailing compact presentation, it’s not empty at all, and in fact enforces a quite large minimum size so the Dynamic Island looks hilariously tall. In other words: The system hides the empty trailing view automatically Left: what it should look like. Right: reality You can imagine this is especially rough on the Duo, where navigation buttons, toolbar buttons, tab bar buttons, etc. are all competing for precious space on the right. But that’s only half true. It displays perfectly fine (hiding it) when isDynamicIslandLimitedInWidth is false (AKA how it always used to be), but in the new cases where it can be true, like the Duo and iPhones in landscape, that’s when it breaks. So tl;dr: In iOS 27, Dynamic Island Live Activities are improperly sized if you use the listed EmptyView configuration and isDynamicIslandLimitedInWidth is true. This makes it especially bad on the Duo, womp womp. Complications Now, you might be saying “That’s weird, I haven’t seen that behavior! This is nothing but hogwash!”. But it is not hogwash, just a little complicated. There’s basically three categories of apps. Apple apps Maps, for instance, displays this single, small Dynamic Island live activity perfectly well and sized, and has been beautifully compiled with the iOS 27.2 SDK. By all accounts it should show this bug, too! Apple apps don’t have to use the same APIs as us normies, so funnily enough through really cool tools like REA we can disassemble the iOS Simulator and see that it’s in fact true, the Apple Maps live activity just completely bypasses WidgetKit and instead just renders plain UIKit through MapsBannerViewController which shows the cute little cyan widget through a ManeuverAccessoryView and then for the hidden trailing view simply returns a DistanceAccessoryView with CGSizeZero, which iOS actually respects, unlike our paltry SwiftUI EmptyView. Third-party apps NOT updated to iOS 27 If your app hasn’t been compiled with any of the iOS 27 SDKs, it only knows about iOS 26, and thus doesn’t know about (or have to worry about) the new, troublesome isDynamicIslandLimitedInWidth property, so it just… displays perfectly well. Here’s the Rivian app, which hasn’t been updated for iOS 27 yet, which shows the Live Activity displaying perfectly sized on the Duo (indicating vehicle charging): (Technical disassembly detail for the nerds: iOS shows the app’s minimal config, a smaller config normally used when multiple apps are in the Dynamic Island together, rather than the normal compact config, so it bypasses this issue entirely.) Developers who updated their apps for iOS 27 Surprise! That picture from before? On the left is just me compiling with the old 26 SDK that works! Unfortunately if you are a good developer who updated their app for iOS 27 and all the new features, you kind of get punished through this bug, because your live activity displays the improperly sized way described above, and you can’t just use raw UIKit like Apple. So you’re kinda stuck where I am: do I ship a weirdly sized Dynamic Island experience for everyone? Do I shove something extraneous in the compactTrailing spot just so it doesn’t look as empty? Do I not update the app at all until Apple fixes this bug? Widgets are techincally a separate extension from your main app, so you could compile them with a different SDK (26) than your main app (27) which fixes this bug, but I’m not sure Apple approves of that. Apple On the bright side hopefully it’s an easy enough fix, treating EmptyView like you used to on iOS 26 and per the documentation (the part that is weirdly right beside the mention of the new API that introduces this craziness in the first place). Radar/feedback assistant ID: FB25301955 Easy reproduction code if you’re curious: import ActivityKit import SwiftUI import WidgetKit struct CircleAttributes: ActivityAttributes { struct ContentState: Codable, Hashable {} } struct BlueCircle: View { var body: some View { Circle() .fill(.blue) .frame(width: 20, height: 20) } } @main struct CircleLiveActivity: Widget { var body: some WidgetConfiguration { ActivityConfiguration(for: CircleAttributes.self) { _ in BlueCircle() } dynamicIsland: { _ in DynamicIsland { DynamicIslandExpandedRegion(.center) { BlueCircle() } } compactLeading: { BlueCircle() } compactTrailing: { EmptyView() // pls respect me } minimal: { BlueCircle() } } } }
Vicky, driving me home from O'Hare, got sixteen dollars for the best conversation I had in months. The last line is hers.