Archive for May 9, 2025

Friday, May 9, 2025

Apple Acquires Mayday Labs

Joe Rossignol:

Apple acquired Canadian startup Mayday Labs in April 2024, according to a European Commission listing, spotted by French blog MacGeneration.

[…]

Mayday Labs founder Jeremy Bell confirmed that his company had been acquired in a since-deleted April 2024 blog post, but he did not mention Apple at that time.

[…]

Mayday Labs had developed an AI-powered calendar, task manager, and scheduling assistant for the iPhone, iPad, and Mac. The all-in-one app used AI to automatically schedule your events and tasks at ideal times, and it could learn your scheduling preferences and daily patterns over time to further optimize your calendar.

The Macintosh Repository

Davo:

The Macintosh Repository is a community driven effort to preserve old software from the classic Mac OS era.

It has ~18k entries of software images from floppys & cds, scans, fonts, icons and everything in between.

The Macintosh Repository:

If you’re planning on running the treasures of the past you’ll find here on real old Macintosh hardware from the 90’s, you sir/madame, deserve to win an Internet for doing it THE ONLY CORRECT WAY! But for others, there’s QEMU, a PowerPC emulator capable of (slowly) running Mac OS X 10.5 down to Mac OS 9.1, SheepShaver, a fake PowerPC emulator capable of running Mac OS 9.0.4 down to Mac OS 7.5.2, Basilisk II, a 68040 emulator, capable of running the 68040 version of Mac OS 8.1 down to 7.0. Finally, for everything older than System 7, there’s Mini vMac II (which emulates 68020/color Macs) and Mini vMac which emulates the original B&W 68000 Macs.

Previously:

Update (2025-05-09): Matt Sephton:

Macintosh Repository paywall/request donations for the content they lifted pretty much wholesale from macintoshgarden.org

Mac Themes Garden

Damien Erambert (via Hacker News):

Mac Themes Garden is dedicated to showcasing schemes made for Kaleidoscope and celebrating the customization and expressiveness it enabled on Classic Mac OS.

[…]

What I call “recording” here involves taking “live” screenshots of the themes being used on a Mac OS 9.2 installation running in UTM and combing through each archive to properly record every scheme’s informations (author and release year).

This process is, to put it bluntly, a bit bonkers because it’s mostly manual, but I feel it is worth it.

See also: John Siracusa and GUI Junkie.

NSCache and LRUCache

Christian Tietze:

Is NSCache still a thing we like to use?

I’ve discussed this several times, but I don’t think I ever blogged about it. The problem I have with NSCache is that its eviction strategy is not defined, and it’s definitely not LRU. When I tried to use NSCache, it would destroy the performance of my app because I would fetch objects from the database, put them in the cache, and then find them immediately evicted, with the cache remaining full of older objects that I didn’t care about. I guess it could be useful as a threadsafe dictionary if you know that you won’t be exceeding the capacity. But often when I want a cache it’s because I need to limit the memory consumption, and in that situation NSCache just doesn’t work for me.

I ended up writing my own LRU cache, combining a Swift Dictionary with a linked list that tracks which keys were accessed most recently. Nick Lockwood made an open-source solution called LRUCache, converging on a similar design. (There were some interesting discussions in building it that have unfortunately been deleted.)

The main thing to be aware of if you’re writing your own is that if you let ARC deallocate your linked list nodes automatically it will explode. ARC uses recursion to follow the references, so if your list is too big it will overflow the stack. You can fix this by manually deleting list nodes using a loop. Or, if your list is only used by the cache, you can make the list pointers unowned and let the dictionary do the retaining.

Matthias Maurberger:

Recently, I needed to add caching to one of the iOS apps I’m working on. While researching a few possible ways how to go about this I came across a great article written by John Sundell (a pretty common occurrence when searching for Swift topics on the web, thanks John!). While the basic concept he describes in the article worked quite well for my needs, there was one major problem with the approach: NSCache will drop your objects like hot potatoes as soon as your app gets backgrounded.

[…]

So if you don’t want the system to evict all objects from your cache when your app gets backgrounded, make sure your objects implement the NSDiscardableContent protocol.

Previously:

Copyright © 2000–2025 Michael Tsai.