Christian Selig

Rivian R2 wishes as an R1 owner

Mon, 09 Feb 2026 10:27:44 -0400

After 7 years with a Tesla Model 3, we picked up a gen 2 Rivian R1S in April of 2025. We still have the Model 3 as a second vehicle, but it’s been really cool experiencing a new electric vehicle from a very passionate new company.

2026 is a really exciting time for Rivian, as in the first half of this year they’re launching their R2 vehicle - a smaller, less expensive SUV offering that should have a lot more mass-market appeal.

With a bunch of jourrnalists getting previews of the vehicle today, I thought I’d share what I’m really hoping for in this new vehicle having experienced their existing vehicle for almost a year, and a Tesla for the better part of a decade. None of these are in any particular order.

Better audio

We sprung for the “Premium Audio” package in our R1S and… it’s not premium at all. Whatever system just came with our Model 3 sounds demonstrably better, from where it feels like the sound is coming from (much more expansive) to the bass, the R1S just feels a lot weaker. Honestly for the base audio system it would be probably decent, but for a “Premium Audio” system it just falls short. They have been making it better and better with softwware updates of all things over the course of our vehicle’s life, where it’s noticeable better now than it was at the beginning, a recent update in December basically sounds like they figured out how to turn on the subwoofer in the trunk a little bit, but it’s still just not that much.

With the Tesla sometimes I’d park and finish out a song before leaving the car because it just sounded so good, have never had that happen in the Rivian so I hope they bring some of that experience to the R2 even through another “Premium Audio” package for those who care.

No dual motor EPA shenanigans

So our R1S is dual motor, meaning it has a motor for the front wheels and a separate motor for the back wheels, meaning you get AWD. Rivian allows you to get more range by only using the front motor, turning it into effectively a front wheel drive vehicle and as only one motor is active you get a bit better range (about 10%). Sounds great, right? Choose between more efficient front-wheel drive on trips, but just use AWD around town by default.

Well, the devil is in the details. In order to be able to market this slightly improved range, the EPA requires Rivian to automatically revert back to this front wheel drive/higher efficiency mode after a few hours. Kinda like gas vehicles and how they turn off the engine at traffic lights, and if you disable that it just keeps turning itself back on. So even if it’s the winter and you’re like, “Dang, roads are a little dicey, I want to be in AWD”, if you park the car for awhile and forget to set it to AWD, it just reverts to front wheel drive. It’s like if your iPhone kept reverting to “Low Battery Mode” every 2 hours even after you keep toggling it off so Apple could advertise that model having 10% better battery life.

Note: the vehicle isn’t hard-locked to front wheel drive in this mode, if it slips it alerts you that it’s switching over to AWD (I don’t want to wait for it to slip), and if you floor it on the highway for instance it’ll engage the rear motors for extra grunt, but because it has to link up the rear motors to an already moving system, you can sometimes get a kinda weird clunk feeling as the rear motor connects itself at speed which isn’t very satisfying. It almost feels like a wheel slip in the rain.

This is maddening, and is only the case on their dual motor vehicles. For tri and quad motor vehicles, they just don’t market them as having that extra 10% range, so all the modes are actually sticky! If you say “front wheel drive mode” (they call it “Conserve”) it stays there indefinitely, if you say “AWD mode”, it stays there indefinitely.

Is this dumb? Yes. Do I blame the EPA? Yes. Do I also blame Rivian? Also yes, they’re making this trade off to be able to market extra range.

If Rivian does this same stuff for the R2 dual motor just so they can advertise a few extra miles, I really hope they have a $10 option you can configure when you order called “Give me less marketed range with no actual range decrease but have the vehicle actually do what I tell it to”, but maybe with a catchier title.

Spare compact tire

Our Tesla lacks a spare tire of any sort, instead electing to include a repair method and roadside assistance. A few years back a nasty pothole absolutely destroyed the sidewall of one of our tires on a drive home, and where it was sidewall damage it simply wasn’t repairable, so we had to call Tesla roadside assistance. Unfortuantely Tesla roadside assistance was absolutely useless, taking ages to respond and then ultimately not having any providers in the area, so we just ditched the car and got a ride home with a friend and dealt with it the next day.

After that I was like “I do not want another vehicle without a spare tire on board”.

With our R1S on the other hand, we had another unlucky event where we popped a tire (also the sidewall if you’d believe it, I have some great luck) and sure enough, since we elected to get a compact spare tire it was super easy to deal with, just grab the included jack, throw the compact spare on, then the next day we just slowly drove over to a shop for a new tire. Completely uneventful.

I was worried with the smaller body that you wouldn’t be able to in the R2, but Jerry Rig Everything showed room for a compact spare in the sub trunk, nice!

Digital rear view mirror

I don’t see this in any of the videos so it seems unlikely but I’m holding out hope it’s an option.

Picture this: you approach your vehicle, since it sees it’s your phone it knows who you are, so it positions your seat, steering wheel, mirrors, Apple Music/Spotify account, and temperature preferences. You didn’t have to do a thing, the vehicle is just smart! Except… your spouse is 7 inches shorter than you so when you look in the rear view mirror you’re staring at the back seat.

Is having to adjust your rear view mirror a big deal? No, but having the vehicle do everything else for you almost draws more attention to the final thing it’s missing that you still have to adjust every single time. This is a solved problem in inexpensive vehicles, just have a “digital rear view mirror” that requires no adjusting as it just shows a camera feed of the rear of the vehicle where the mirror is.

Digital rear view mirror in a RAV4 by u/MildSpaghettiSauce

Rivian’s cameras are legitimately so good, that at night it’s easier to use them for side blind spot monitoring when you change lanes than the actual side mirrors, because they let in enough light that you can actually make out details through the pseudo “Night Mode” camera vision that you can’t with the mirrors alone, it’s wild. I want that for the rear view mirror too!

Do you still prefer an analog mirror? That’s totally cool, all the vehicles that offer this let you just toggle back to a good ol’ reflective mirror. No harm no foul.

V2H story

Not a lot of people realize one of the most powerful part of EVs: they’re mobile powerstations that can (theoretically) power your entire home. Take a Tesla Model 3 for instance, it has a 75 kWh battery. Tesla also sells Powerwalls to help you back up your home, each Powerwall is around $6,000 and has 13.5 kWh of battery capacity. Yes, that means your Model 3 is the equivalent of more than 5 Powerwalls, or $33,000 in equivalent batteries.

That’s nuts! Ever have a power outage? With the average home in Canada using about 30 kWh per day, that could power your house through potentially multiple days and genuinely save lives.

My Rivian R1S is a lot better than my Tesla here in that it actually has normal, 120V AC outlets, but they can only output a measly 1.5 kW, so even powering a hungry kettle could result in the breaker tripping. Much better than the max 120W my Tesla can do through a 12V cigarette outlet (good god how is that the best they can do), but it’s still not enough output to power a house effectively.

It’s kinda like being in a drought with a massive water tower, but water only comes out in drips. Better than nothing, but we need output speed too.

The R1 can output much more by pulling DC energy directly from the battery through CCS protocols like the ISO 15118 standard, and sure enough despite Rivian not talnking about it, folks with these systems have been able to connect the R1S directly to their house with the appropriate cable and send up to 24 kW to power their entire home, crazy stuff, hope Rivian talks about this more in the future as clearly the vehicle supports it even if they are quiet about it.

I’m kinda curious what the R2’s story is here. The CEO of Rivian said in an interview (~1:20:20) that the R1 and R2 both have bidirectional EV charging in the realm of 20 kW (which again we’re finally seeing folks be able to take advantage of in the R1 recently), but unlike being limited to 1.5 kW of AC output in the R1, the CEO says the R2 will be able to do “10 or 11 kW”.

That’s massive versus the 1.5 kW the R1 can do, but I’m not sure that made it to production in the end? Doug Demuro showed a Rivian graphic with a V2L adapter (at 26:22) but it’s only listed as 2.4 kW. Still a lot better than 1.5, but a far cry fro the 10 or 11 kW that RJ Scaringe said earlier.

Either way, talk more about this Rivian! This is one of the coolest parts about EVs!

Better suspension

The R1S has a fancy air suspension, so picture a bagpipe over each corner of the vehicle that lets it inflate or deflate to change the height of the vehicle and theoretically make for a cushier ride.

I say theoretically because honestly I find the gen 2 R1S kinda rough suspension wise. Like, hitting the same potholes around where I live in the Tesla Model 3 (with a much simpler coil suspension, no bagpipes) versus the Rivian R1S I honestly find the Tesla makes me wince less. I thought it might have been the massive 22" wheels that came on the Rivian and the correspondingly small sidewall on the tire, but we switched to a 20" wheel for the winter with a much larger sidewall and it’s better but still not great.

Would love to see Rivian tune this so that the R2 is a super smooth ride, I’ve heard the newer Tesla Model Ys are incredible here and also just have a coil suspension like the R2 will have.

Faster charging

Brands love to brag about maximum charge speeds, our Tesla for instance got a software update to enable 250 kW charging, which is super fast. To put that in perspective, most new homes in North America have 200 amp service going into their home, 250 kW is the equivalent of upgrading to 1,000 amp service, and then pouring every drop of that power into your car.

But, while that top speed is impressive, it holds that for like, minutes maybe before crashing down to much slower charging speeds. Our R1S is no different here, with good peak speeds but it doesn’t exactly hold them super well, there’s been tons of reports that the cooling method for the batteries in the R1S is just underwhelming, where the Rivian R1 models have a two battery packs stacked on top of each other with a single liquid cooling plate in the middle (so only the top or the bottom of the battery is touching the cooling surface), and that single plate often seems a little underpowered for cooling such a massive pack quickly. Kinda like thermal throttling in laptops! We typically see around 45 minutes for the battery to charge 10-80% at fast chargers.

The R2 on the other hand appears to be moving to a smarter cooling method where the cooling liquid flows almost through a ribbon, weaving along the sides of each cell in the battery pack, meaning a lot more cooling surface area.

And indeed, this seems to have paid off, with a Rivian employee saying they’re now under 30 minutes for 10-80% on the R2. Class-leading? No, Hyundai is under 20 minutes, but a fair bit better.

And for folks without EV experience, honestly, this is mostly a non-issue. 99.5% of your charging is done at home where speeds don’t matter (it just charges overnight like your phone), it’s only if you’re going on a bit of a roadtrip where this comes into play.

Better USB-C

Okay this isn’t a big deal, but the R1S has a ton of USB-C ports everywhere, like there must be close to a dozen, which is awesome, but if you try to charge a power bank or a laptop or something over USB-C it’s just… not very fast. I haven’t actually measured but I’m assuming they’re only doing 12V (at most) instead of at least 20V which most chargers are at nowadays, which I really hope they improve. My MacBook charges so slow.

Better phone charger

This is the one part of the Rivian that I’m like “how did this even make it out of the factory”. And if you’d believe it the phone charger in my vehicle is the second revision, so this is their attempt at fixing it somehow.

Basically they have a flat little area near the arm rests where you can place one or two phones to have them wirelessly charge. Sounds fine, right?

I haven’t measured it, but from experience I believe the charging “sweet spot” is approximately 4 atoms wide. If the car is in motion at all, it moves from those four atoms and tries super hard to charge it but ultimately cannot, and just making the phone get super hot and lose a bunch of battery life.

One time we went camping and I was like “Okay, the vehicle is not moving, surely I can just set it here while I sleep and it’ll charge”. Nope, somehow even stationary the phone did not charge beyond 20% overnight and was super hot in the morning. What.

They have managed to make a phone charger that is worse than not having one at all. I can’t even place my phone in the arm rest while I drive because it just cooks it, at least if nothing was there it could just be a storage location.

No, mine is not broken, this is a common complaint from just about every Rivian owner, and they need to make this better for the R2. Just hot glue a MagSafe puck in there at minimum.

Better Phone as a Key (PAAK)

Rivian and Tesla do the (honestly very cool thing) where it uses your phone to detect your proximity to the car and lock/unlock it and recognize who the driver is to set preferences. It’s great, no having to carry around bulky car keys (don’t worry, there is a backup little credit card style key you carry in your pocket in case your phone dies or disappears).

Rivian even recently updated theirs to use the first-party “Apple CarKey” functionality so you get bonuses like being able to unlock it for a few hours even after your phone’s battery died, and it uses “Ultra Wide Band” (UWB) so it can position your phone in relation to the car down to the centimeter. Tesla doesn’t do this and has their own proprietary thing that I think is based on Bluetooth but might use a bit of UWB on newer models (not on my car).

But… Tesla’s is still much better. There’s two aspects of nailing good “phone as a key” support: firstly, unlocking the car as you approach (duh), and secondly, knowing who approached the car so you can set their preferences (seat, steering wheel, mirror positions, temperature preferences, music streaming account, etc.)

Unlocking: B+ for Rivian here, sometimes even with the recent update I have to stand by the door for a few seconds and be like “Um, hello” before it sees me there and unlocks. Same phone, walk over to my Tesla, always unlocks instantly even though the Rivian should have a massive advantage with UWB.
Identifying driver: D for Rivian here. Again, with UWB and centimeter-level positioning over the driver in relation to the vehicle Rivian should be able to know exactly who is approaching the driver door when my girlfriend and I (who both have Rivian keys) approach the vehicle, but 95% of the time when my girlfriend is with me (despite her always preferring to be passenger) it always sets her as the driver. Even weirder, sometimes she’ll yell out the window if I’m putting something in the frunk “Oh it actually recognized you this time!” with me set as the profile, but then when I sit down in the seat it reverts to her. What.

Rivian needs to do better here for the R2. The pain is especially compounded by the fact that if you leave in a bit of a rush and somehow don’t realize the driver profile is wrong, Rivian won’t let you change your driver settings unless you slow down to under 3 mph, so you better get ready to pull over and stop the car if you need to adjust something. With Tesla you can always just swap profile and have your steering wheel, seat, mirrors, etc. move to where they should be, and that feels a lot safer than having to muck around with changing things via a touch screen or sit their tweaking controls on the side of the car seat.

Smoother software

Somehow despite my Model 3 being a 2018 model and probably running a Raspberry Pi compared to the hardware Rivian runs, moving around the OS in the Tesla still feels faster. With the Rivian there’s still lag just bouncing around screens with stuff sometimes taking a second or two to show up. I don’t get it.

I really hope this improves on the R2, and thankfully it looks like it does, Doug DeMuro bounces around the R2’s UI here and it’s much faster than my gen 2 R1S with everything loading virtually instantly. Yay.

CarPlay

I’ve never had a vehicle with CarPlay, we rented a vehicle with it and it was kinda neat but Teslas and Rivians already have like every piece of software I’d want when interfacing with a vehcile (good, traffic-based maps and popular music streaming services), so with the exception of Overcast I don’t personally care about CarPlay at all.

That being said, I know a ton of people do so I kinda hope Rivian looks into it even just as a little windowed experience because I think it would make a lot more people interested.

Alexa is so bad

About a month ago at their Autonomy Day Rivian previewed (among many other cool things) their new “Rivian Assistant”.

This is sorely needed, their current system uses Alexa and. it. is. so. bad.

With our Tesla, you can say “Navigate to Blah” and it will just automatically plot it and you’re off to the races.

Best case with Rivian you’re like, “Alexa, navigate to Bob’s Cool Donuts in Dartmouth”, and Alexa is like “Would you like to navigate to Bob’s Cool Donuts, Dartmouth, Nova Scotia”, “Yes” where it repeats literally the only possible match back to you requiring confirmation every time instead of just… taking you there.

A more typical case is “Alexa, navigate to Bob’s Donuts in Dartmouth”, “Would you like directions to Bob’s Donuts in Toledo, Ohio”. No Alexa, I want the one that’s a five minute drive, not the one a three day drive away. “Oh, okay, try being more specific next time”

Better heat pump

They do a decent job isolating the sound from the outside if you’re in the vehicle, but if it’s cold outside and you heat up your Rivian R1S, you can hear that sucker from a full block away in this super high pitched whine. I’ve understandably had multiple people ask “Is it okay?”.

Better time placement

The UX for knowing the current time in the cabin is not great. There is no clock on the main driver instrument display, and it’s in the furthest place possible on the middle display, so it’s not exactly easy to check. There’s tons of space on the driver display so I either wish they shoved it there, or if you put in directions, I wish it showed you the current time there. Right now it just says “ETA 2:58 PM” which if you’ve been driving for 45 minutes and kinda have lost track of time is not particularly helpful, that could be in 5 minutes or in 25 minutes for all I know.

It looks a bit better on the R2 (seen in MKBHD’s video) where they’re placing it on the middle display a lot closer to the driver, but I still wish they just put it on the driver display.

Better second row release

The R1S and many other modern vehicles have really stupid and downright dangerous second row releases, where the main door handles are electric, so it there’s an electrical issue and you need to get out of the vehicle, you obviously need a manual release. On my Tesla, there’s a (shocker) pull handle that is obvious and you can just pull to get out of the vehicle. Easy peasy (don’t worry Tesla has since changed to an inexplicably stupider, hidden design like Rivian)

The R1 is incredibly stupid and you literally have to pop off trim in the rear door to get access to a cable you can yank. Yeah, good luck remembering that in dire circumstances, so I threw one of those window breakers in the back cubby.

The R2 is better here, Jerry Rig Everything shows a little button patch you can pop off much easier to get to the cable, but still, just put the manual release that the front doors have, this is a basic safety feature and should not be complicated.

Smaller

This we know will be the case, with the Rivian R2 being about 2 feet shorter than the R1S.

The R1S is a properly large vehicle, which makes it very capable, but I dunno, I do find myself wishing it was a little smaller quite often, so I honestly think if the R2 is compelling enough I might be trading in my R1.

… Does this sound negative?

Reading it back a bit, this post sounds a wee bit negative even though the intention is just to talk about things I hope they improve.

So just to be totally clear, I love the thing. It’s spacious, incredibly capable, looks great, has amazing range, and is just a lot of fun to drive with a ton of creature comforts that I miss every time I drive the Tesla. But there’s always room for improvement!

I’m so excited

I genuinely think Rivian is doing such cool things, and the company behind it seems to have a real passion for building cool products instead of just sitting on Twitter all day, so I’m super excited to see what this mass-market vehicle does for them and I’m hoping for the best.

Looks like they’re launching in spring (I guessed summer!) with more pricing and configuration details March 12th.

CKSyncEngine questions and answers

Wed, 07 Jan 2026 18:01:47 -0400

I didn't know what to put as a header so here are some iClouds (interesting clouds) in Maine

I’ve had a lot of fun working with CKSyncEngine over the last month or so. I truly think it’s one of the best APIs Apple has built, and they’ve managed to take a very complex topic (cloud syncing) and make it very digestible and easy to integrate, without having to get into the weeds of CKOperation and whatnot like you had to in previous years.

That being said, there’s a fair bit of work you still have to do (through no fault of Apple, it’s just that a lot of cloud sync work is application-specific), such as how to handle conflicts, how to integrate the CKRecords into your flow, responding to errors, etc.

More interesting for a blog post, perhaps, I also had a fair few questions going into it (having very little CloudKit knowledge prior to this), and I thought I’d document those questions and the corresponding answers, as well as general insights I found to potentially save a future CKSyncEngine user some time, as I really couldn’t find easy answers to these anywhere (nor did modern LLMs have any idea).

Apple sample project

When in doubt, it’s always nice to see how Apple does things in their nicely published CKSyncEngine sample project: https://github.com/apple/sample-cloudkit-sync-engine

Other awesome resources are Jordan Morgan’s blog post at Superwall, as well as the awesome work by Pointfree on their SQLiteData library which is open source and integrates CKSyncEngine as the syncing layer.

These are great resources to understand how to implement CKSyncEngine which this article won’t be going over. I want to go over questions and edge cases you may encounter.

Conflict resolution

If you’ve used NSUbiquitousKeyValueStore (my only prior exposure to iCloud), CKSyncEngine is thankfully a lot smarter with conflict resolution (and by “conflict resolution” I mean “what happens when two devices try to save the same piece of data to the cloud”).

With NSUbiquitousKeyValueStore if you had super valuable, years old data stored at key “blah” and you downloaded the app onto a new device and somehow set new data to the key “blah” (for instance, existing data hadn’t been downloaded yet) you would completely blow away the existing “blah” data, potentially jeopardizing years of data. Not great, which made me wary of storing much of value there without a ton of checks.

CKSyncEngine is a lot smarter, where you’re dealing with CKRecords directly (more on that below) and thus can save metadata from them, so if you try to overwrite “blah” and your metadata is not up to date, CKSyncEngine will return a failure with the newest version of that data asking you what you want to do (overwrite your local data with the newer cloud version? tag your version with the newer cloud metadata and re-upload it so it works?), rather than blindly overwriting it. This makes it virtually impossible for a new device to come onto the scene and write “bad data” up, messing up existing data.

(And serverRecordChanged is the error in failedRecordSaves you hook into!)

It does beg the question though, “What do you do when there’s a conflict” and that’s what I alluded to earlier with Apple not being able to do everything for you, and you need to make some decisions here. For me, it depends on the data. For the vast majority of the data, always having the “server version win” is perfectly fine for my use case, so I overwrite the local version with the cloud version.

But there’s some situations where I want to be a little choosier, for instance for integer that can never decrease in value (a good example would be how many times you’ve died in a video game), I have a system where it just chooses the higher value between the cloud version and the local version, and chooses that.

You could write a long blog post just on this though, the important part is to choose the right system for your application. An app that creates a lot of singular data but rarely ever modifies it will need a dramatically different system than one that has a large, single body of data that is frequently being edited on multiple devices concurrently.

And remember that CKSyncEngine being effectively a database means you can store a lot more information than the paltry 1,024 keys/1MB total limit that NSUbiquitousKeyValueStore allows, so you can create a much more robust system that’s appropriate to your app, but not necessarily any more complicated!

Deletion conflict resolution

Note that deletions just fire without any conflict resolution at the CKSyncEngine level; if you say to delete something with recordID "blah", CKSyncEngine will trust you know what you’re doing and just delete it (and not compare metadata or anything as it doesn’t even ask for it).

CKRecord handling

One of the only awkward parts of CKSyncEngine is that it operates through CKRecords, which are quite old a construct (much more Objective-C than Swift) you have to decide how to incorporate that into your existing data store. They’re basically a big old string dictionary of data with some metadata.

For me, I mostly use GRDB (SQLite), and you have a nice, easy, hybrid solution where you have your local records with an extra column called something like cloudKitInfo, which is just the CKRecord distilled down into its pure informational metadata. This strips out all the CKRecord of large image and text data, and you’re basically just getting the bare essentials: the metadata fields like its record change tag for conflict resolution when you upload it

If you don’t save these metadata fields you’re going to have a Very Bad Time™ when you go to upload, as your items being uploaded will have no matching metadata, so CloudKit will think you don’t have the most up to date version of that record and give you a conflict error every time.

So my process generally looks like:

When you get a new CKRecord from iCloud to sync with your local store, you extract all the data you care about from the dictionary fields (e.g.: item.postTitle = ckRecord["postTitle"]) into your local Swift object, and then extract the CloudKit specific metadata.

extension CKRecord {
    func systemFieldsData() -> Data {
        let archiver = NSKeyedArchiver(requiringSecureCoding: true)
        encodeSystemFields(with: archiver)
        archiver.finishEncoding()
        return archiver.encodedData
    }
}

item.cloudKitInfo = ckRecord.systemFieldsData
saveToSQLite(item)

Then, when you go to upload an item after you changed it, you create a CKRecord by initializing it with your existing cloudKitInfo, then set the fields.

let unarchiver = try NSKeyedUnarchiver(forReadingFrom: cloudKitSystemFields)
unarchiver.requiresSecureCoding = true
let restoredRecord = CKRecord(coder: unarchiver)

restoredRecord["postTitle"] = myNewPostTitle

This has the nice effect of letting you do basically everything in Swift, and just tacking on the necessary parts of the CKRecord to make the system work properly, without duplicating the entire CKRecord with all of the heavy data fields it may contain.

Backward/forward compatibility

One big worry I had was what if in version 1.0 of my app I have a structure like the following:

struct IceCream {
    let name: String
    let lastEatenOn: Date
}

And then in version 1.1 of the app I add a new field:

struct IceCream {
    let name: String
    let lastEatenOn: Date
    let tastiness: Float // New!
}

If a user has two devices, one that is updated to version 1.1 and another on 1.0, if I save a new IceCream on version 1.1 of the app with both a name of "chocolate" and a tastiness of 0.95, and sync that back to the device on version 1.0, where they eat the ice cream, then sync that back up, crucially that version of the app doesn’t know about the tastiness variable! So it might effectively sync back up IceCream(name: "chocolate", lastEatenOn: .now), and then when version 1.1 gets that, the tastiness is effectively lost data! Noooooo!

How do we handle this? I dreamt up some complex solutions, but it turns out it’s incredibly easy thanks to the way CKRecord works. CKSyncEngine never documents this anywhere directly, but it obviously uses CloudKit under the hood, and CloudKit has dinstinct saving policies under CKModifyRecordsOperation.RecordSavePolicy documented here. And no matter what policy you choose (we don’t get a choice with CKSyncEngine) all of them detail the same behavior:

CloudKit only saves the fields on CKRecords that you explicitly set. In other words, on version 1.0, when we create our CKRecord that represents our local data, it would look something like this:

let ckRecord = // create CKRecord instance
ckRecord["name"] = "chocolate"
ckRecord["lastEatenOn"] = Date.now

Note that we didn’t set tastiness at all, so when it goes up to iCloud, the tastiness field won’t be touched at all as it’s not present, it will just remain what it was. The only way the tastiness field would get reset is it we explicitly set it to nil.

So when version 1.1 pulls down this change that version 1.0 made, the CKRecord it pulls down will still have the tastiness field intact. It’s essentially a factor that old versions of the app can only touch what fields they know exist, so no harm no foul.

The only catch is you can’t go in the other direction: don’t delete tastiness in verson 1.2 of the app if earlier versions expect it to always exist. Give it some innocent default value.

Enums are bad

Enums are a finite set of values, so unless you’re positive that it will never change, don’t use enums in values meant to be cloud-synced.

Why? Say you have this enum in version 1.0 of your app:

enum IceCreamFlavor {
    case chocolate
    case strawberry
}

And in version 1.1 you add a new flavor:

enum IceCreamFlavor {
    case chocolate
    case strawberry
    case vanilla // New!
}

What happens when version 1.0 has to decode IceCreamFlavor.vanilla? It will have no idea what that case is, and fail to decode, which you could just treat as a nil value, but if you then try to sync that nil value up, you risk overwriting the existing, good value with nil data (unlike the “Backward/forward compatibility case” above where it was a value stored in a different field, this is all operating under the same field/key). Bad.

Instead, just store it as a string, and you could try to initialize an enum of known values with the string’s raw value if you desire.

Multiple CKSyncEngine instances

You have to be really careful with multiple instances of CKSyncEngines.

At a high level in CloudKit you have CKContainer, which houses three CKDatabase instances: a private one (probably most commonly used), a public one, and a shared one.

CKSyncEngine only allows one instance to manage an individual database, so that means it’s totally fine to have separate CKSyncEngine instances for a private and shared database. (Not for the public database however, as CKSyncEngine does not support public databases.)

But you should not have multiple CKSyncEngine instances managing a single private database (I naively tried to do this to have a nice separation of concerns between different types of data in the app). The instances trip over each othre very quickly, with it not being clear which instance receives the sync events.

You can get around this by creating multiple CKContainers, and having a CKSyncEngine per each one, but that feels messy and from what I understand not really how Apple intended containers to be used. Keeping everything under one instance isn’t too bad even with different kinds of data, as you can use different zones or record types to keep things sufficiently separated.

Should you not call CKSyncEngine methods if the user isn’t signed into iCloud?

Apple’s sample project still does! It seems harmless. From my testing, they get enqueued, but are never actioned upon (they never fail unlike normal CKRecordOperations, they just sit waiting forever), and then the queue is wiped when the user signs in.

What happens if they sign out/sign in while your app is quit?

No worries, you get the appropriate accountChange event on the next app launch.

What is the difference between the account change notifications?

You can either get signedIn, signedOut, or switchAccount.

signedIn happens when they had no account and signed into one. signedOut happens when they had an existing account and signed out.

switchAccounts is a “coalescing” one (you won’t get signedIn/signedOut and switchAccounts), where if your app is running/backgrounded you will get signedOut then signedIn if the user changes accounts, and you won’t get a switchAccounts notification. You only get switchAccounts if your app was quit and you relaunch the app at which point you’ll get the switchAccounts notification (but neither of the other two).

How does state serialization work?

Every time anything happens with CKSyncEngine you’re given a stateUpdate event, which you’re expected to persist to disk. This encodes the entirety of your CKSyncEngine’s state into a serialized value, so when the app launches the next time it can start off right where it was.

It’s essentially a super charged git commit tag/checkpoint, so iOS knows where your CKSyncEngine exists in time (does it need to pull down any new changes?) and maintains any pending changes/deletions that might have not completed. If your app crashes part way through applying a change, your app simply will not have been issued the new “save checkpoint” notification, so the next time your app relaunches it will simply be restored to the last CKSyncEngine state you saved and retry.

It also initializes synchronously, so if you had any pending items in your serialized state and you initialize CKSyncEngine, you can view your pending items immediately.

Also note that if you initialize CKSyncEngine without any state serialization, you always get an “account change: signedIn” notification even if the user didn’t explicitly just sign into their iCloud account.

CKSyncEngine re-initialization

Per Apple’s sample project, re-initialize your CKSyncEngine (and delete any old state serialization) when either the user signs out, or switches accounts, but not when they transition from signed out to signed in, presumably because in the latter case there’s nothing really to invalidate in the CKSyncEngine when there is in the other two states.

How does error handling work?

Apple’s sample project indicates that there are a number of transient errors that CKSyncEngine handles automatically for you, like rate limiting issues, no internet connection, iCloud being down, etc. Nice!

.networkFailure, .networkUnavailable, .zoneBusy, .serviceUnavailable, .notAuthenticated, .operationCancelled, .requestRateLimited

In most of these cases it means the item just gets immediately added back to the pending items queue and CloudKit will pause the queue for a certain amount of time before retrying.

Other ones, you do need to handle yourself, even if they seem like they should be automatic. A good example is quotaExceeded which you get if the user ran out of iCloud storage and you tried to save something.

In this case Apple pauses the queue until the user frees up space or buys more (or after several minutes, specified by retryAfterSeconds) but does not add your item back, which seems weird to me, so just add it back. But you also can’t just add it back, as that would put it at the end of the queue, so you have to insert it back at the beginning of the queue so it’s the next item that will be retried (since it just failed). Only, there’s no API for this, so grab all the items in the queue, then empty the queue, then re-add all items back to the queue with your failed item at the front.

For other failures, like quotaExceeded, they’re immediately removed from pending items once they fail, so if you want them to be retried you have to add them back manually.

(Remember, the pending queue survives app restarts as it’s serialized to disk through state serialization, see above.)

Embedding record types into record IDs

A small point worth noting is that weirdly CKSyncEngine does not provide the actual recordType (only the string ID) when requesting the fully built CKRecords (which we need in order to tell which SQLite table the ID belongs to), so we can prepend the table to the beginning of the ID string, for instance IceCream:9arsnt89rna9stda5" so we can discern it at runtime.

Let things be automatic

You can manually pull/push to CKSyncEngine with fetchChanges() and sendChanges() but be careful. You can’t call these inside the CKSyncEngineDelegate methods per CKSyncEngineDelegate documentation:

CKSyncEngine delivers events serially, which means the delegate doesn’t receive the next event until it finishes handling the current one. To maintain this ordering, don’t call sync engine methods from your delegate that may cause the engine to generate additional events. For example, don’t invoke fetchChanges(_:) or sendChanges(_:) from within handleEvent(_:syncEngine:).

You can get stuck in weird, infinite loops. In practice I’ve found CKSyncEngine is really great at queuing up changes almost instantly without you having to babysit it and manually pull/fetch, just let it do its own thing and you should get great performance and not run into infinite loop bugs by trying to do things yourself.

(Also note that the quote is kinda confusing, but it refers to those fetch and send changes methods specifically, adding new items to the queue within the delegate is fine and something Apple does in their sample project.)

Zone deletion reasons

When a “zone was deleted” event occurs, ensure you inspect the reason, of which there are 3:

deleted means we (the programmer) did it programmatically, commonly done as it’s the easiest/quickest way to delete all the records in a zone
purged means the user went through the iOS Settings app and wiped iCloud data for our app, which per Apple’s recommendation means we should delete all local data as well (otherwise it would just sync back up after they explicitly asked for it to be wiped, likely because they were running low on storage), and in the purged case we also delete our local system state serialization change token as it’s no longer valid (this is a full reset).
encryptedDataReset means the user had to reset their encrypted data during account recovery and per Apple’s recommendation we treat this as something the user likely did not want to have to do, so reset/delete our system state serialization token and reupload all their data to minimize data loss.

Responding to account status changes

CloudKit also has a NotificationCenter API for monitoring account changes (Notification.Name.CKAccountChanged) but you don’t really need this at all if you’re using CKSyncEngine, everything comes through the accountChange event that the NotificationCenter API would otherwise provide (just distilled down to signedIn, signedOut, or switchAccounts where the NotificationCenter API is a bit more granular). You can use both, but I haven’t found a need.

Note that you should react appropriately to the kind of account change that occurred. For instance, following Apple’s sample project recommendation, if you receive a notification that they signedOut, that could mean they signed out of their iCloud account to give their sibling an old iPhone to play around with, and they may have private data they don’t want their sibling to have access to, so we should take this as a queue to delete local data (if they want the data back, when they sign back into iCloud it will be re-downloaded).

Also note you can get the status of the user’s iCloud account at any point using try await CKContainer.default().accountStatus().

Batch sizes

CKRecords can be a max size of 1 MB, but also note that uploaded batches are limited to 1 MB in size, so if you enqueue 10 items to be uploaded, each 1 MB, iCloud will upload them in sequential, 1 MB batches (I sort of expected a single, 10 MB upload that included all the records).

So that’s uploads, but conversely on the download size, iCloud is happy to download batches much larger than 1 MB in size! I’ve comfortably seen 100 MB+, which can happen when syncing an initial, large library.

Conclusion

If I think of any more notes I’ll add them, but hopefully a bunch of these things (that I had to find out through trial and error) save some other folks time when implementing CKSyncEngine!

The one software tweak the iPhone Air needs

Fri, 26 Sep 2025 13:38:10 -0300

One trick doctors hate that will make your iPhone… Sorry.

I’ve been loving my iPhone Air. A week in I think it’s my favorite iPhone since the iPhone X.

It has that indescribable feeling that the original MacBook Air had. That, “Wow, computers can be like this?” feeling that’s hard to quantify when you’re just looking at a spec sheet. Picking it up still makes me smile, and I love that the screen is bigger than any iPhone I’ve ever had, while the device overall feels smaller because it’s so thin.

Even the battery has been surprisingly good, I feel like I have more at the end of the day than I did with my 15 Pro that I’m upgrading from, and Apple’s numbers seem to back this up, showing 23 hours of video playback on the 15 Pro and an increase to 27 on the Air.

The only area I’ve kinda been disappointed on is the camera situation. No, not the telephoto, I really never used that personally. And not the ultrawide, for me that just felt too wide. But the ultrawide did allow for awesome macro capabilities that this iPhone Air is sorely lacking. At least currently.

The problem

The iPhone Air’s minimum focus distance is just too short. Don’t get me wrong, it’s a hair better than my 15 Pro’s main sensor, allowing you to get maybe 15% closer to the subject, but it still does that annoying thing where when you want to take a picture of a small object and have it take up the full field of view, it often goes blurry right when you get it framed up.

But then I was like, duh, it’s a 48 MP sensor, so I can zoom into 2x to get twice as close and still get a nice 12 MP photo. So you just pull the phone back a bit, hit 2x, and bam, you have a beautifully framed close shot, that’s actually in focus.

An “easy” solution

Look, I won’t claim camera sensor software is in any way easy, but all the other iPhones do an awesome job of detecting when the main sensor reached its minimum focus distance and then hopping over the the ultrawide to get a nice macro shot that’s still in focus.

I’d love if Apple implemented similar software magic on the Air, where instead of having to manually hit that 2x when it gets blurry, Apple detected you hit the minimum focus distance and instructed you to “back up a bit” and then automatically made it in focus through cropping in on the main sensor.

Would it change the world? No, but it’d take out a manual step I’m finding myself doing somewhat frequently.

Will this level up your macro photography so that you can take pictures of the pollen on the leg of a bee? No, absolutely not. But getting about twice as close to your subject is a massive difference, especially since I find right now the Air’s minimum focus distance is just on the edge of where I want it to be when holding things close.

Hopefully the brilliant folks at Halide, (Not Boring), or Obscura (listed in alphabetical order so I don’t have to rank my friends) can integrate something like this into their awesome apps if Apple themselves do not.

App Clip Local Experiences have consumed my day

Mon, 08 Sep 2025 16:03:58 -0300

Okay, I have to be doing something astronomically stupid, right? This should be working? I’m playing around with an App Clip and want to just run it on the device as a test, but no matter how I set things up nothing ever works. If you see what I’m doing wrong let me know and I’ll update this, and hopefully we can save someone else in the future a few hours of banging their head!

Xcode

App Clips require some setup in App Store Connect, so Apple provides a way when you’re just testing things to side step all that: App Clip Local Experiences

I create a new sample project called IceCreamStore, which has the bundle ID com.christianselig.IceCreamStore. I then go to File > New > Target… > App Clip. I choose the Product Name “IceCreamClip”, and it automatically gets the bundle ID com.christianselig.IceCreamStore.Clip.

I run both the main target and the app clip target on my iOS 18.6 phone and everything shows up perfectly, so let’s go onto actually configuring the Local Experience.

Local Experience setup

I go to Settings.app > Developer > App Clips Testing > Local Experiences > Register Local Experience, and then input the following details:

URL Prefix: https://boop.com/beep/
Bundle ID: com.christianselig.IceCreamStore.Clip (note thne Apple guide above says to use the Clip’s bundle ID, but I have tried both)
Title: Test1
Subtitle: Test2
Action: Open

Upon saving, I then send myself a link to https://boop.com/beep/123 in iMessage, and upon tapping on it… nothing, it just tries to open that URL in Safari rather than in an App Clip (as it presumably should?). Same thing if I paste the URL into Safari’s address bar directly.

I also tried generating an App Clip Code, but upon scanning it with my device I get “No usable data found”.

Help

What’s the deal here, what am I doing wrong? Is my App Store Connect account conspiring against me? I’ve tried on multiple iPhones on both iOS 18 and 26, and the incredible Matt Heaney (wrangler of App Clips) even kindly spent a bunch of time also pulling his hair out over this. We even tried to see if my devices were somehow banned from using App Clips, but nope, production apps using App Clips work fine!

If you figure this out you would be my favorite person. 😛

Update: solution. Sorta?

Okay, seems the solution is two-fold:

Make sure in addition to the main app target being installed, you manually switch to the App Clip target and install that itself directly too
Generate an App Clip Code via the generator CLI (or a nice GUI) and scan that, rather than trying to open from URLs directly

I will say I do love how Apple stuff 99% of the time does “just work”, but dang those times when it doesn’t I really wish they showed some diagnostics I could see as to why.

High quality, low filesize GIFs

Sat, 02 Aug 2025 12:12:53 -0300

While the GIF format is a little on the older side, it’s still a really handy format in 2025 for sharing short clips where an actual video file might have some compatibility issues.

For instance, I find when you just want a short little video on your website, a GIF is still so handy versus a video, where some browsers will refuse to autoplay them, or seem like they’ll autoplay them fine until Low Battery Mode is activated, etc. With GIFs it’s just… easy, and sometimes easy is nice. They’re super handy for showing a screen recording of a cool feature in your app, for instance.

What’s not nice is the size of GIFs. They have a reputation of being absolutely enormous from a filesize perspective, and they often are, but that doesn’t have to be the case, you can be smart about your GIF and optimize its size substantially. Over the years I’ve tried lots of little apps that promise to help to no avail, so I’ve developed a little script to make this easier that I thought might be helpful to share.

Naive approach

Let’s show where GIFs get that bad reputation so we can have a baseline.

We’ll use trusty ol’ ffmpeg (in the age of LLMs it is a super handy utility), which if you don’t have already you can install via brew install ffmpeg. It’s a handy (and in my opinion downright essential) tool for doing just about anything with video.

For a video we’ll use this cute video of some kittens I took at our local animal shelter:

It’s 4K, 30 FPS, 5 seconds long, and thanks to its H265/HEVC video encoding it’s only 19.5 MB. Not bad!

Let’s just chuck it into ffmpeg and tell it to output a GIF and see how it does.

ffmpeg -i kitties.mp4 kitties.gif

Okay, let that run and- oh no.

For your sake I’m not even going to attach the GIF here in case folks are on mobile data, but the resulting file is 409.4MB. Almost half a gigabyte for a 5 second GIF of kittens. We gotta do better.

Better

We can do better.

Let’s throw a bunch of confusing parameters at ffmpeg (that I’ll break down) to make this a bit more manageable.

ffmpeg -i kitties.mp4 -filter_complex "fps=24,scale=iw*sar:ih,scale=1000:-1,split[a][b];[a]palettegen[p];[b][p]paletteuse=dither=floyd_steinberg" kitties2.gif

Okay, lot going on here, let’s break it down.

fps=24: we’re dropping down to 24 fps from 30 fps, many folks upload full YouTube videos at this framerate so it’s more than acceptable for a GIF.
scale=iw*sar:ih: sometimes video files have weird situations where the aspect ratio of each pixel isn’t square, which GIFs don’t like, so this is just a correction step so that doesn’t potentially trip us up
scale=1000:-1: we don’t need our GIF to be 4K, and I’ve found 1,000 pixels across to be a great middle ground for GIFs. The -1 at the end just means scale the height to the appropriate value rather than us having to do the math ourselves.
The rest is related to the color palette, we’re telling ffmpeg to scan the entire video to build an appropriate color palette up, and to use the Floyd-Steinberg algorithm to do so. I find this algorithm gives us the highest quality output (which is also handy for compressing it more in further steps)

This gives us a dang good looking GIF that clocks in at about 10% the file size at 45.8MB.

Link to GIF in lieu of embedding directly

Nice!

Even better

ffmpeg is great, but where it’s geared toward videos it doesn’t do every GIF optimization imaginable. You could stop where we are and be happy, but if you want to shave off a few more megabytes, we can leverage gifsicle, a small command line utility that is built around optimizing GIFs.

We’ll install gifsicle via brew install gifsicle and throw our GIF into it with the following:

gifsicle -O3 --lossy=65 --gamma=1.2 kitties2.gif -o kitties3.gif

So what’s going on here?

O3 is essentially gifsicle’s most efficient mode, doing fancy things like delta frames so changes between frames are stored rather than each frame separately
lossy=65 defines the level of compression, 65 has been a good middle ground for me (200 I believe is the highest compression level)
gamma=1.2 is a bit confusing, but essentially the gamma controls how the lossy parameter reacts to (and thus compresses) colors. 1 will allow it to be quite aggressive with colors, while 2.2 (the default) is much less so. Through trial and error I’ve found 1.2 causes nice compression without much of a loss in quality

The resulting GIF is now 23.8MB, shaving a nice additional 22MB off, so we’re now at a meager 5% of our original filesize.

That’s a lot closer to the 4K, 20MB input, so for a GIF I’ll call that a win. And for something like a simpler screen recording it’ll be even smaller!

Make it easy

Rather than having to remember that command or come back here and copy paste it all the time, add the following to your ~/.zshrc (or create it if you don’t have one already):

gifify() {
    # Defaults
    local lossy=65 fps=24 width=1000 gamma=1.2

    while [[ $# -gt 0 ]]; do
        case "$1" in
            --lossy) lossy="$2"; shift 2 ;;
            --fps)   fps="$2";   shift 2 ;;
            --width) width="$2"; shift 2 ;;
            --gamma) gamma="$2"; shift 2 ;; 
            --help|-h)
              echo "Usage: gifify [--lossy N] [--fps N] [--width N] [--gamma VAL] <input video> <output.gif>"
              echo "Defaults: --lossy 65  --fps 24  --width 1000  --gamma 1.2"
              return 0
              ;;
            --) shift; break ;;
            --*) echo "Unknown option: $1" >&2; return 2 ;;
            *)  break ;;
        esac
    done

    if (( $# < 2 )); then
        echo "Usage: gifify [--lossy N] [--fps N] [--width N] [--gamma VAL] <input video> <output.gif>" >&2
        return 2
    fi

    local in="$1"
    local out="$2"
    local tmp="$(mktemp -t gifify.XXXXXX).gif"
    trap 'rm -f "$tmp"' EXIT

    echo "[gifify] FFmpeg: starting encode → '$in' → temp GIF (fps=${fps}, width=${width})…"
    if ! ffmpeg -hide_banner -loglevel error -nostats -y -i "$in" \
        -filter_complex "fps=${fps},scale=iw*sar:ih,scale=${width}:-1,split[a][b];[a]palettegen[p];[b][p]paletteuse=dither=floyd_steinberg" \
        "$tmp"
    then
        echo "[gifify] FFmpeg failed." >&2
        return 1
    fi

    echo "[gifify] FFmpeg: done. Starting gifsicle (lossy=${lossy}, gamma=${gamma})…"
    if ! gifsicle -O3 --gamma="$gamma" --lossy="$lossy" "$tmp" -o "$out"; then
        echo "[gifify] gifsicle failed." >&2
        return 1
    fi

    local bytes
    bytes=$(stat -f%z "$out" 2>/dev/null || stat -c%s "$out" 2>/dev/null || echo "")
    if [[ -n "$bytes" ]]; then
        local mb
        mb=$(LC_ALL=C printf "%.2f" $(( bytes / 1000000.0 )))
        echo "[gifify] gifsicle: done. Wrote '$out' (${mb} MB)."
    else
        echo "[gifify] gifsicle: done. Wrote '$out'."
    fi
}

This will allow you to easily call it as either gifify <input-filename.mp4> <output-gifname.gif> and default to the values above, or if you want to tweak them you can use any optional parameters with gifify --fps 30 --gamma 1.8 --width 600 --lossy 100 <input-filename.mp4> <output-gifname.gif>.

For instance:

# Using default values we used above
gifify cats.mp4 cats.gif

# Changing the lossiness and gamma
gifify --lossy 30 --gamma 2.2 cats.mp4 cats.gif

Much easier.

May your GIFs be beautiful and efficient.

You should repaste your MacBook (but don't)

Thu, 10 Jul 2025 19:06:19 -0300

My favorite memory of my M1 Pro MacBook Pro was the whole sensation of “holy crap, you never hear the fans in this thing”, which was very novel in 2021.

Four years later, this MacBook Pro is still a delight. It’s the longest I’ve ever owned a laptop, and while I’d love to pick up the new M4 goodness, this dang thing still seems to just shrug at basically anything I throw at it. Video editing, code compiling, CAD models, the works. (My desire to update is helped though by the fact I got the 2TB SSD, 32GB RAM option, and upgrading to those on new MacBooks is still eye wateringly expensive.)

But my MacBook is starting to show its age in one area: it’s not quiet anymore.

If you’re doing anything too intensive like compiling code for awhile, or converting something in Handbrake, the age of the fans being quiet is long past. The fans are properly loud. (And despite having two cats, it’s not them! I clean out the fans pretty regularly.)

Enter the thermal paste

Everyone online seems to point toward one thing: the thermal paste on computers tends to dry up over the years.

What the heck is thermal paste? Well, components on your computer that generate a lot of heat are normally made to touch something like a copper heatsink that is really good at pulling that heat away from it. The issue is, when you press these two metal surfaces against each other, even the best machining isn’t perfect and you there’s microscopic gaps between them meaning there’s just air at those parts, and air is a terrible conductor of heat.

The solution is to put a little bit of thermal paste (basically a special grey toothpaste gunk that is really good at transferring heat) between them, and it fills in any of those microscopic gaps.

The problem with this solution is after hundreds and hundreds of days of intense heat, the paste can dry up into something closer to almost a powder, and it’s not nearly as good at filling in those gaps.

Replacement time

The logic board!

MacBook thermal paste isn’t anything crazy (for the most part, see below), custom PC builders use thermal paste all the time so incredibly performant options are available online. I grabbed a tube of Noctua NT-H2 for about $10 and set to taking apart my MacBook to swap out the aging thermal paste. And thankfully, iFixit has a tremendous, in depth guide on the disassembly required, so I got to it.

Indeed, that grey thermal paste looked quite old, but also above and below it (on the RAM chips) I noticed something that didn’t quite seem like thermal paste, it was far more… grainy almost?

Spottiness is due to half of it being on the heatsink

It turns out, ending with my generation of MacBooks (lucky me!) Apple used a very special kind of thermal compound often called “Carbon Black”, which is basically designed to be able to bridge an even thicker gap than traditional thermal paste. I thought about replacing it, but it seems really hard to come across that special thermal compound (and do not do it with normal thermal paste) and my RAM temperatures always seemed fine (65°C is fine… right?) so I just made sure to not touch that.

For the regular grey thermal paste, I used some cotton swabs and isopropyl alcohol to remove the dried up existing thermal paste, then painted on a bit of the new stuff.

Disaster

To get to the underside of the CPU, you basically need to disassemble the entire MacBook. It’s honestly not that hard, but iFixit warned that the fan cables (which also need to be unclipped) are incredibly delicate. And they’re not wrong, seriously they have the structural integrity of the half-ply toilet paper available at gas stations.

So, wouldn’t you know it, I moved the left fan’s cable a bit too hard and it completely tore in half. Gah.

I found a replacement fan online (yeah you can’t just buy the cable, need a whole new fan) and in the meantime I just kept an eye on my CPU thermals. As long as I wasn’t doing anything too intensive it honestly always stayed around 65° which was warm, but not terrifying (MacBook Airs completely lack a fan, after all).

Take two

A few days later, the fans arrived, and I basically had to redo the entire disassembly process to get to the fans. At least I was a lot faster this time.

The fan was incredibly easy to swap out (hats off there, Apple!) and I screwed everything back together and began reconnecting all the little connectors.

Until I saw it: the tiny (made of the same half ply material as the fan cable) Touch ID sensor cable was inexpicably torn in half, the top half just hanging out. I didn’t even touch this thing really, and I hadn’t even got to the stage of reconnecting it (I was about to!), it comes from underneath the logic board and I guess just the movement of sliding the logic board back in sheared it in half.

Bah. I looked up if I could just grab another replacement cable here, and sure enough you can… but the Touch ID chip is cryptographically paired to your MacBook so you’d have to take it into an Apple Store. Estimates seemed to be in the hundreds of dollars, so if anyone has any experience there let me know, but for now I’m just going to live happily without a Touch ID sensor… or the button because the button also does not work.

RIP little buddy

(And yeah I’m 99.9% sure I can’t solder this back together, there’s a bunch of tiny lanes that make up the cable that you would need experience with proper micro-soldering to do.)

Honestly, the disassembly process for my MacBook was surprisingly friendly and not very difficult, I just really wish they beefed up some of the cables even slightly so they weren’t so delicate.

The results

I was going to cackle if I went through all that just to have identical temperatures as before, but I’m very happy to say they actually improved a fair bit. I ran a Cinebench test before disassembling the MacBook the very first time to establish a baseline:

Max CPU temperature: 102°C
Max fan speed: 6,300 RPM
Cinbench score: 12,252

After the new thermal paste (and the left fan being new):

Max CPU temperature: 96°C
Max fan speed: 4,700 RPM
Cinbench score: 12,316

Now just looking at those scores you might be like… so? But let me tell you, dropping 1,600 RPM on the fan is a noticeable change, it goes from “Oh my god this is annoyingly loud” to “Oh look the fans kicked in”, and despite slower fan speeds there was still a decent drop in CPU temperature! And a 0.5% higher Cinebench score!

But where I also really notice it is in idling: just writing this blog post my CPU was right at 46°C the whole time, where previously my computer idled right aroud 60°C. The whole computer just feels a bit healthier.

So… should you do it?

Honestly, unless you’re very used to working on small, delicate electronics, probably not. But if you do have that experience and are very careful, or have a local repair shop that can do it for a reasonable fee (and your MacBook is a few years old so as to warrant it) it’s honestly a really nice tweak that I feel will hopefully at least get me to the M5 generation.

I do miss Touch ID, though.

A slept on upscaling tool for macOS

Mon, 30 Jun 2025 11:48:17 -0300

I upload YouTube videos from time to time, and a fun comment I often get is “Whoa, this is 8K!”. Even better, I’ve had comments from the like, seven people with 8K TVs that the video looks awesome on their TV.

And you guessed it, I don’t record my videos in 8K! I record them in 4K and upscale them to 8K after the fact.

There’s no shortage of AI video upscaling tools today, but they’re of varying quality, and some are great but quite expensive.

The legendary Finn Voorhees created a really cool tool though, called fx-upscale, that smartly leverages Apple’s built-in MetalFX framework. For the unfamiliar, this library is an extension of Apple’s Metal graphics library, and adds functionality similar to NVIDIA’s DLSS where it intelligently upscales video using machine learning (AI), so rather than just stretching an image, it uses a model to try to infer what the frame would look like at a higher resolution.

It’s primarily geared toward video game use, but Finn’s library shows it does an excellent job for video too.

I think this is a really killer utility, and use it for all my videos. I even have a license for Topaz Video AI, which arguably works better, but takes an order of magnitude longer. For instance my recent 38 minute, 4K video took about an hour to render to 8K via fx-upscale on my M1 Pro MacBook Pro, but would take over 24 hours with Topaz Video AI.

# Install with homebrew
brew install finnvoor/tools/fx-upscale

# Outputs a file named my-video Upscaled.mov
fx-upscale my-video.mov --width 7680 --codec h265

Anyway, just wanted to give a tip toward a really cool tool! Finn’s even got a version in the Mac App Store called Unsqueeze with an actual GUI that’s even easier to use, but I really like the command line version because you get a bit more control over the output.

8K is kinda overkill for most use cases, so to be clear you can go from like, 1080p to 4K as well if you’re so inclined. I just really like 8K for the future proofing of it all, in however many years when 8K TVs are more common I’ll be able to have some of my videos already able to take advantage of that. And it takes long enough to upscale that I’d be surprised to see TVs or YouTube offering that upscaling natively in a way that looks as good given the amount of compute required currently.

Obviously very zoomed in to show the difference easier

If you ask me, for indie creators, even when 8K displays are more common, the future of recording still probably won’t be in native 8K. 4K recording gives so much detail still that have more than enough details to allow AI to do a compelling upscale to 8K. I think for my next camera I’m going to aim for recording in 6K (so I can still reframe in post), and then continue to output the final result in 4K to be AI upscaled. I’m coming for you, Lumix S1ii.

Embedding Godot games in iOS apps is easy now

Sat, 31 May 2025 09:54:14 -0300

Recently there’s been very exciting developments in the Godot game engine, that have allowed really easy and powerful integration into an existing normal iOS or Mac app. I couldn’t find a lot of documentation or discussion about this, so I wanted to shine some light on why this is so cool, and how easy it is to do!

What’s Godot?

For the uninitiated, Godot is an engine for building games, other common ones you might know of are Unity and Unreal Engine.

It’s risen in popularity a lot over the last couple years due to its open nature: it’s completely open source, MIT licensed, and worked on in the open. But beyond that, it’s also a really well made tool for building games with (both 2D and 3D), with a great UI, beautiful iconography, a ton of tutorials and resources, and as a bonus, it’s very lightweight.

I’ve had a lot of fun playing around with it (considering potentially integrating it into Pixel Pals), and while Unity and Unreal Engine are also phenomenal tools, Godot has felt lightweight and approachable in a really nice way. As an analogy, Godot feels closer to Sketch and Figma whereas Unity and Unreal feel more like Photoshop/Illustrator or other kinda bulky Adobe products.

Even Apple has taken interest in it, contributing a substantial pull request for visionOS support in Godot.

Why use it with iOS?

You’ve always been able to build a game in Godot and export it to run on iOS, but recently thanks to advancements in the engine and work by amazing folks like Miguel de Icaza, you can now embed a Godot game in an existing normal SwiftUI or UIKit app just as you would an extra UITextView or ScrollView.

Why is this important? Say you want to build a game or experience, but you don’t want it to feel just like another port, you want it to integrate nicely with iOS and feel at home there through use of some native frameworks and UI here and there to anchor the experience (share sheets, local notifications, a simple SwiftUI sheet for adding a friend, etc.). Historically your options have been very limited or difficult.

You no longer have to have “a Godot game” or “an iOS app”, you can have the best of both worlds. A fun game built entirely in Godot, while having your share sheets, Settings screens, your paywall, home screen widgets, onboarding, iCloud sync, etc. all in native Swift code. Dynamically choosing which tool you want for the job.

(Again, this was technically possible before and with other engines, but was much, much more complicated. Unity’s in particular seems to have been last updated during the first Obama administration.)

And truly, this doesn’t only benefit “game apps”. Heck, if the user is doing something that will take awhile to complete (uploading a video, etc.) you could give them a small game to play in the interim. Or just for some fun you could embed a little side scroller easter egg in one of your Settings screens to delight spelunking users. Be creative!

SpriteKit?

A quick aside. It wouldn’t be an article about game dev on iOS without mentioning SpriteKit, Apple’s native 2D game framework (Apple also has SceneKit for 3D).

SpriteKit is well done, and actually what I built most of Pixel Pals in. But it has a lot of downsides versus a proper, dedicated game engine:

Godot has a wealth of tutorials on YouTube and elsewhere, bustling Discord communities for help, where SpriteKit being a lot more niche can be quite hard to find details on
The obvious one: SpriteKit only works on Apple platforms, so if you want to port your game to Android or Windows you’re probably not going to have a great time, where Godot is fully cross platform
Godot being a full out game engine has a lot more tools for game development than can be handy, from animation tools, to sprite sheet editors, controls that make experimenting a lot easier, handy tools for creating shaders, and so much more than I could hope to go over in this article. If you ever watch a YouTube video of someone building a game in a full engine, the wealth of tools they have for speeding up development is bonkers.
Godot is updated frequently by a large team of employees and volunteers, SpriteKit conversely isn’t exactly one of Apple’s most loved frameworks (I don’t think it’s been mentioned at WWDC in years) and kinda feels like something Apple isn’t interested in putting much more work into. Maybe that’s because it does everything Apple wants and is considered “finished” (if so I think that would be incorrect, see previous point for many things that it would be helpful for SpriteKit to have), but if you were to encounter a weird bug I’d feel much better about the likelihood of it getting fixed in Godot than SpriteKit

I’m a big fan of using the right tool for the job. For iOS apps, most of the time that’s building something incredible in SwiftUI and UIKit. But for building a game, be it small or large, using something purpose built to be incredible at that seems like the play to me, and Godot feels like a great candidate there.

Setup

Simply add the SwiftGodotKit package to your Xcode project by selecting your project in the sidebar, ensuring your project is selected in the new sidebar, selecting the Package Dependencies tab, click the +, then paste the GitHub link.

After adding it, you will also need to select the target that you added it to in the sidebar, select the Build Settings tab, then select “Other Linker Flags” and add -lc++.

Lastly, with that same target, under the General tab add MetalFX.framework to Frameworks, Libraries, and Embedded Content. (Yeah you got me, I don’t know why we have to do that.)

After that, you should be able to import SwiftGodotKit.

Usage

Now we’re ready to use Godot in our iOS app! What excites me most and I want to focus on is embedding an existing Godot game in your iOS app and communicating back and forth with it from your iOS app.

This way, you can do the majority of the game development in Godot without even opening Xcode, and then sprinkle in delightful iOS integration by communicating between iOS and Godot where needed.

To start, we’ll build a very simple game called IceCreamParlor, where we select from a list of ice cream options in SwiftUI, which then gets passed into Godot. Godot will have a button the user can tap to send a message back to SwiftUI with the total amount of ice cream. This will not be an impressive “game” by any stretch of the imagination, but should be easy to set up and understand the concepts so you can apply it to an actual game.

To accomplish our communication, in essence we’ll be recreating iOS’ NotificationCenter to send messages back and forth between Godot and iOS, and like NotificationCenter, we’ll create a simple singleton to accomplish this.

Those messages will be sent via Signals. This is Godot’s system for, well, signaling an event occurred, and can be used to signify everything from a button press, to a player taking damage, to a timer ending. Keeping with the NotificationCenter analogy, this would the be Notification that gets posted (except in Godot, it’s used for everything, where in iOS land you really wouldn’t use NotificationCenter for a button press.)

And similar to Notification that has a userInfo field to provide more information about the notification, Godot signals can also take an argument that provides more information. (For example if the notification was “player took damage” the argument might be an integer that includes how much damage they took.) Like userInfo, this is optional however and you can also fire off a signal with no further information, something like “userUnlockedPro” for when they activate Pro after your SwiftUI paywall.

For our simple example, we’re going to send a “selectedIceCream” signal from iOS to Godot, and a “updatedIceCreamCount” signal from Godot to iOS. The former will have a string argument for which ice cream was selected, and the latter will have an integer argument with the updated count.

Setting up our Godot project

Open Godot.app (available to download from their website) and create a new project, I’ll type in IceCreamParlor, choose the Mobile renderer, then click Create.

Godot defaults to a 3D scene, so I’ll switch to 2D at the top, and then in the left sidebar click 2D Scene to create that as our root node. I’ll right-click the sidebar to add a child node, and select Label. We’ll set the text to the “Ice cream:”. In the right sidebar, we’ll go to Theme Overrides and increase the font size to 80 to make it more visible, and we’ll also rename it in the left sidebar from Label to IceCreamLabel.

We’ll also do the same to add a Button to the scene, which we’ll call UpdateButton and sets its text to “Update Ice Cream Count”.

If you click the Play button in the top right corner of Godot, it will run and you can click the button, but as of now it doesn’t do anything.

We’ll select our root node (Node2D) in the sidebar, right click, and select “Attach Script”. Leave everything as default, and click Create. This will now present us with an area where we can actually code in GDScript, and we can refer to the objects in our scene by prefixing their name with a dollar sign.

Inside our script, we’ll implement the _ready function, which is essentially Godot’s equivalent of viewDidLoad, and inside we’ll connect to our simple signal we discussed earlier. We’ll do this by grabbing a reference to our singleton, then reference the signal we want, then connect to it by passing a function we want to be called when the signal is received. And of course the function takes a String as a parameter because our signal includes what ice cream was selected.

extends Node2D

var ice_cream: Array[String] = []

func _ready() -> void:
    var singleton = Engine.get_singleton("GodotSwiftMessenger")
    singleton.ice_cream_selected.connect(_on_ice_cream_selected_signal_received)

func _on_ice_cream_selected_signal_received(new_ice_cream: String) -> void:
    # We received a signal! Probably should do something…
    pass

Note that we haven’t actually created the singleton yet, but we will shortly. Also note that normally in Godot, you have to declare custom signals like the ones we’re using, but we’re going to declare them in Swift. As long as they’re declared somewhere, Godot is happy!

Let’s also hook up our button by going back to our scene, selecting our button in the canvas, selecting the “Node” tab in the right sidebar, and double-clicking the pressed() option. We can then select that same Node2D script and name the function _on_update_button_pressed to add a function that executes when the button is pressed (fun fact: the button being pressed event is also powered by signals).

func _on_update_button_pressed() -> void:
    pass

Setting up our iOS/Swift project

Let’s jump over to Xcode and create a new SwiftUI project there as well, also calling it IceCreamParlor. We’ll start by adding the Swift package for SwiftGodotKit to Swift Package Manager, and as mentioned above we’ll add -lc++ to our “Other Linker Flags” under “Build Settings”, add MetalFX, then go to ContentView.swift and add import SwiftGodotKit at the top.

From here, let’s create a simple SwiftUI view so we can choose from some ice cream options.

var body: some View {
    HStack {
        Button {
        } label: {
            Text("Chocolate")
        }
        
        Button {
        } label: {
            Text("Strawberry")
        }
        
        Button {
        } label: {
            Text("Vanilla")
        }
    }
    .buttonStyle(.bordered)
}

We’ll also create a new file in Xcode called GodotSwiftMessenger.swift. This will be where we implement our singleton that is akin to NotificationCenter.

import SwiftGodot

@Godot
class GodotSwiftMessenger: Object {
    public static let shared = GodotSwiftMessenger()
    @Signal var iceCreamSelected: SignalWithArguments<String>
    @Signal var iceCreamCountUpdated: SignalWithArguments<Int>
}

We first import SwiftGodot (minus the Kit), essentially because this part is purely about interfacing with Godot through Godot, and doesn’t care about whether or not it’s embedded in an iOS app. For more details on SwiftGodot see its section below.

Then, we annotate our class with the @Godot Swift Macro, which basically just says “Hey make Godot aware that this class exists”. The class is a subclass of Object as everything in Godot needs to inherit from Object, it’s essentially the parent class of everything.

Following that is your bog standard Swift singleton initialization.

Then, with another Swift Macro, we annotate a variable we want to be our signal which signifies that it’s a Signal to Godot. You can either specify its type as Signal or SignalWithArguments<T> depending on whether or not the specific signal also sends any data alongside it. We’ll use that “somethingHappened” signal we mentioned early, which includes a string for more details on what happened.

Note that we used “ice_cream_selected” in Godot but “iceCreamSelected” in Swift, this is because the underscore convention is used in Godot, and SwiftGodotKit will automatically map the camelCase Swift convention to it.

Now we need to tell Godot about this singleton we just made. We want Godot to know about it as soon as possible, otherwise if things aren’t hooked up, Godot might emit a signal that we wouldn’t receive in Swift, or vice-versa.

So, we’ll hook it up very early in our app cycle. In SwiftUI, you might do this in the init of your main App struct as I’ll show below, and in UIKit in applicationDidFinishLaunching.

@main
struct IceCreamParlor: App {
    init() {
        initHookCb = { level in
            guard level == .scene else { return }

            register(type: GodotSwiftMessenger.self)
            Engine.registerSingleton(name: "GodotSwiftMessenger", instance: GodotSwiftMessenger.shared)
        }
    }
    
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

In addition to the boilerplate code Xcode gives us, we’ve added an extra step to the initializer, where we set a callback on initHookCb. This is just a callback that fires as Godot is setup, and it specifies what level of setup has occurred. We want to wait until the level setup is reached, which means the game is ready to go (you could set it up at an even earlier level if you see that as beneficial).

Then, we just tell Godot about this type by calling register, and then we register the singleton itself with a name we want it to be accessible under.

Again, we want to do this early, as if Godot was already setup in our app, and then we set initHookCb, its contents would never fire and thus we wouldn’t register anything. But don’t worry, this hook won’t fire until we first initialize our Godot game in iOS ourself, so as long as this code is called before then, we’re golden.

Lastly, everything is registered in iOS land, but there’s still nothing that emits or receives signals. Let’s change that by going to ContentView.swift, and change our body to the following:

import SwiftUI
import SwiftGodotKit
import SwiftGodot

struct ContentView: View {
    @State var totalIceCream = 0
    @State var godotApp: GodotApp = GodotApp(packFile: "main.pck")
    
    var body: some View {
        VStack {
            GodotAppView()
                .environment(\.godotApp, godotApp)
            
            Text("Total Ice Cream: \(totalIceCream)")
            
            HStack {
                Button {
                    GodotSwiftMessenger.shared.iceCreamSelected.emit("chocolate")
                } label: {
                    Text("Chocolate")
                }
                
                Button {
                    GodotSwiftMessenger.shared.iceCreamSelected.emit("strawberry")
                } label: {
                    Text("Strawberry")
                }
                
                Button {
                    GodotSwiftMessenger.shared.iceCreamSelected.emit("vanilla")
                } label: {
                    Text("Vanilla")
                }
            }
            .buttonStyle(.bordered)
        }
        .onAppear {
            GodotSwiftMessenger.shared.iceCreamCountUpdated.connect { newTotalIceCream in
                totalIceCream = newTotalIceCream
            }
        }
    }
}

There’s quite a bit going on here, but let’s break it down because it’s really quite simple.

We have two new state variables, the first is to keep track of the new ice cream count. Could we just do this ourselves purely in SwiftUI? Totally, but for fun we’re going to be totally relying on Godot to keep us updated there, and we’ll just reflect that in SwiftUI to show the communication. Secondly and more importantly, we need to declare a variable for our actual game file so we can embed it.

We do this embedding at the top of the VStack by creating a GodotAppView, a handy SwiftUI view we can now leverage, and we do so by just setting its environment variable to the game we just declared.

Then, we change our buttons to actually emit the selections via signals, and when the view appears, we make sure we connect to the signal that keeps us updated on the count so we can reflect that in the UI. Note that we don’t also connect to the iceCreamSelected signal, because we don’t care to receive it in SwiftUI, we’re just firing that one off for Godot to handle.

Communicating

Let’s update our gdscript in Godot to take advantage of these changes.

func _on_ice_cream_selected_signal_received(new_ice_cream: String) -> void:
    ice_cream.append(new_ice_cream)
    $IceCreamLabel.text = "Ice creams: " + ", ".join(ice_cream)

func _on_update_button_pressed() -> void:
    var singleton = Engine.get_singleton("GodotSwiftMessenger")
    singleton.ice_cream_count_updated.emit(ice_cream.size())

Not too bad! We now receive the signal from SwiftUI and update our UI and internal state in Godot accordingly, as well as the UI by making our ice cream into a comma separated list. And then when the user taps the update button, we then send (emit) that signal back to SwiftUI with the updated count.

Running

To actually see this live, first make sure you have an actual iOS device plugged in. Unfortunately Godot doesn’t work with the iOS simulator.

Secondly, in Godot, select the Project menu bar item, then Export, then click the Add button and select “iOS”. This will bring you to a screen with a bunch of options, but my understanding is that this is 99% geared toward if you’re building your app entirely in Godot (which we are not): you can plug in all the things you’d otherwise plug into Xcode here instead, and Godot will handle them for you. That doesn’t apply to us, we’re going to do all that normally in Xcode anyway, we just want the juicy game files, so ignore all that and select “Export PCK/ZIP…” at the bottom. It’ll ask you where you want to save it, and I just keep it in the Godot project directory, make sure “Godot Project Pack (*.pck)” is selected in the dropdown, and then save it as main.pck.

That’s our “game” bundled up, as meager as it is!

We’ll then drop that into Xcode, making sure to add it to our target, then we can run it on the device!

Here we’ll see choosing the ice cream flavor at the bottom in SwiftUI beams it into the Godot game that’s just chilling like a SwiftUI view, and then we can tap the update button in Godot land to beam the new count right back to SwiftUI to be displayed.

Not exactly a AAA game but enough to show the basics of communication 😄

Look at you go! Take this as a leaping off point for all the cool SwiftUI and Godot interoperability that you can accomplish, be it tappings a Settings icon in Godot to bring up a beautifully designed, native SwiftUI settings screen, or confirmation to you your game when the user updated to the Pro version of your game through your SwiftUI paywall.

Bonus: SwiftGodot (minus the “Kit”)

An additional fun option (that sits at the heart of SwiftGodotKit) is SwiftGodot, which allows you to actually build your entire Godot game with Swift as the programming language if you so choose. Swift for iOS apps, Swift on the server, Swift for game dev. Swift truly is everywhere.

For me, I’m liking playing around in GDScript, which is Godot’s native programming language, but it’s a really cool option to know about.

Embed size

A fear might be that embedding Godot into your app might bloat the binary and result in an enormous app download size. Godot is very lightweight, adding it to your codebase adds a relatively meager (at least by 2025 standards) 30MB to your binary size. That’s a lot larger than SpriteKit’s 0MB, but for all the benefits Godot offers that’s a pretty compelling trade.

(30MB was measured by handy blog sponsor, Emerge Tools.)

Tips

Logging

If you log something in Godot/GDScript via print("something") that will also print to the Xcode console, handy!

Quickly embedding the pck into iOS

Exporting the pck file from Godot to Xcode is quite a few clicks, so if you’re doing it a lot it would be nice to speed that up. We can use the command line to make this a lot nicer.

Godot.app also has a headless mode you can use by going inside the .app file, then Contents > MacOS > Godot. But typing the full path to that binary is no fun, so let’s symlink the binary to /usr/local/bin.

sudo ln -s "/Applications/Godot.app/Contents/MacOS/Godot" /usr/local/bin/godot

Now we can simply type godot anywhere in the Terminal to either open the Godot app, or we can use godot --headless for some command line goodness.

My favorite way to do this, is to do something like the following within your Godot project directory:

godot --headless --export-pack "iOS" /path/to/xcodeproject/target/main.pck

This will handily export the pck and add it to our Xcode project, overwriting any existing pck file, from which point we can simply compile our iOS app.

Wrapping it up

I really think Godot’s new interoperability with iOS is an incredibly exciting avenue for building games on iOS, be it a full fledged game or a small little easter egg integrated into an existing iOS app, and hats off to all the folks who did the hard work getting it working.

Hopefully this serves as an easy way to get things up and running! It might seem like a lot at first glance, but most of the code shown above is just boilerplate to get an example Godot and iOS project up and running, the actual work to embed a game and communicate across them is so delightfully simple!

(Also big shout out to Chris Backas and Miguel de Icaza for help getting this tutorial off the ground.)

Curing Mac mini M4 fomo with 3D printing

Tue, 12 Nov 2024 18:12:32 -0400

Spoiler: 3D printed! The colored ports really sell the effect

If you’re anything like me, you’ve found the new, tinier Mac mini to be absolutely adorable. But you might also be like me that you either already have an awesome M1 Mac mini that you have no real reason to replace, or the new Mac mini just isn’t something you totally need.

While that logic might be sound, but it doesn’t make you want one any less.

To help cure this FOMO, I made a cute little 3D printable Mac mini that can sit on your desk and be all cute. But then I had an even better idea, the new Mac mini is powerful sure, but it can’t hold snacks. Or a plant. Or your phone. Or pens/pencils. So I also made some versions you can print that add some cute utility to your desk in the form of the new Mac mini. They’re free of course! Just chuck ’em into your (or your friend’s) 3D printer.

It even has all the little details modeled, like the power button, ports (including rear), and fan holes!

They’re pretty easy to print, it’s in separate parts for ease of printing the bottom a different color (black) versus the top, then just put a dab of glue (or just use gravity) to keep them together. If you have a multi-color 3D printer, you can color the ports and power LED to make it look extra cool (or just do it after the fact with paint).

Here are the different options for your desk!

Secret item stash

The possibilities for what you can store on your desk are now truly endless. Individually wrapped mints? Key switches? Screws? Paper clips? Rubber bands? Flash drives?

Download link: https://makerworld.com/en/models/793456

A very green sorta Mac

First carbon neutral Mac is cool and all but what if your Mac mini literally had a plant in it?

Every desk needs a cute little plant.

Download link: https://makerworld.com/en/models/793464

Phone holder

A phone/tablet holder is an essential item on my desk for debugging things, watching a video, or just keeping an eye on an Uber Eats order. Before, guests came over and saw my boring phone stand and judged me, now they come over and think I’m exciting and well-traveled.

You can even charge your phone/tablet in portrait mode by pushing the cable through a tunnel made through the Ethernet port that then snakes up to the surface.

Download link: https://makerworld.com/en/models/793495

Pen holder

The Playdate had the cutest little pen/pencil holder accessory but it unfortunately never shipped and my desk is sad. This will be a nice stand in for your beloved pens, pencils, markers, and Apple Pencils.

Download link: https://makerworld.com/en/models/793470

A solid model

Or if you just want to stare at it without any frills, you can just print the normal model too!

Download link: https://makerworld.com/en/models/793447

Printer recommendation

Whenever I post about 3D printing I understandably get a bunch of “Which 3D printer should I buy??” questions. This isn’t sponsored (I do use affiliate links on this blog when available though), but I’ve found over the last few years the answer has been pretty easy: something from Bambu Lab. Their printers are somehow super easy to use, well designed, and reasonably priced. Prusas are great too, but I think Bambu is hard to beat for the price. Don’t get an Ender.

So if you’re looking for a printer now, Black Friday deals are aplenty so it’s pretty much the best time to pick one up. I’d grab something in their A series if you’re on a budget, or the P1S for a bit more if you can swing it (that’s what I use).

On the other hand if you just want to print one thing now and again, a lot of local libraries are starting to have 3D printers so that might be worth looking into! And online services exist too (eg: JLCPCB and PCBWay), but if you do it with any regularity a 3D printer is a really fun thing to pick up.

Enjoy! ❤️

Learning 3D modeling over the last year has been a ton of fun so I love a good excuse to practice, and shout out to Jerrod Hofferth and his amazing 3D printable Mac mini tower (that you should totally download) for the idea to solve my desire with some 3D printing! Also, the models are almost certainly not accurate down to the micrometer as I don’t actually have one, they’re based off Apple’s measurements as well as measuring screenshots. But it should be close!

If you have a multi-color 3D printer, the linked models have the colors built-in for your ready to go, but if you want to print it in single-colors I also made versions available with the top and bottom separate as well as the logo, so you can print them separately in the individual colors then connect them with a touch of super glue or something.

Introducing Tiny Storage: a small, lightweight UserDefaults replacement

Tue, 08 Oct 2024 14:53:55 -0300

Hey I'm a developer not an artist

Following my last blog post about difficulties surrounding UserDefaults and edge cases that lead to data loss (give it a read if you haven’t, it’s an important precursor to this post!), I wanted to build something small and lightweight that would serve to fix the issues I was encountering with UserDefaults and thus TinyStorage was born! It’s open source so you can use it in your projects too if would like.

GitHub link 🐙

Overview

As mentioned in that blog post, UserDefaults has more and more issues as of late with returning nil data when the device is locked and iOS “prelaunches” your app, leaving me honestly sort of unable to trust what UserDefaults returns. Combined with an API that doesn’t really do a great job of surfacing whether it’s available, you can quite easily find yourself in a situation with difficult to track down bugs and data loss. This library seeks to address that fundamentally by not encrypting the backing file, allowing more reliable access to your saved data (if less secure, so don’t store sensitive data), with some niceties sprinkled on top.

This means it’s great for preferences and collections of data like bird species the user likes, but not for sensitive details. Do not store passwords/keys/tokens/secrets/diary entries/grammy’s spaghetti recipe, anything that could be considered sensitive user information, as it’s not encrypted on the disk. But don’t use UserDefaults for sensitive details either as UserDefaults data is still fully decrypted when the device is locked so long as the user has unlocked the device once after reboot. Instead use Keychain for sensitive data.

As with UserDefaults, TinyStorage is intended to be used with relatively small, non-sensitive values. Don’t store massive databases in TinyStorage as it’s not optimized for that, but it’s plenty fast for retrieving stored Codable types. As a point of reference I’d say keep it under 1 MB.

This reliable storing of small, non-sensitive data (to me) is what UserDefaults was always intended to do well, so this library attempts to realize that vision. It’s pretty simple and just a few hundred lines, far from a marvel of filesystem engineering, but just a nice little utility hopefully!

(Also to be clear, TinyStorage is not a wrapper for UserDefaults, it is a full replacement. It does not interface with the UserDefaults system in any way.)

Features

Reliable access: even on first reboot or in application prewarming states, TinyStorage will read and write data properly
Read and write Swift Codable types easily with the API
Similar to UserDefaults uses an in-memory cache on top of the disk store to increase performance
Thread-safe through an internal DispatchQueue so you can safely read/write across threads without having to coordinate that yourself
Supports storing backing file in shared app container
Uses NSFileCoordinator for coordinating reading/writing to disk so can be used safely across multiple processes at the same time (main target and widget target, for instance)
When using across multiple processes, will automatically detect changes to file on disk and update accordingly
SwiftUI property wrapper for easy use in a SwiftUI hierarchy (Similar to @AppStorage)
Can subscribe to to TinyStorage.didChangeNotification in NotificationCenter, and includes the key that changed in userInfo
Uses OSLog for logging
A function to migrate your UserDefaults instance to TinyStorage

Limitations

Unlike UserDefaults, TinyStorage does not support mixed collections, so if you have a bunch of strings, dates, and integers all in the same array in UserDefaults without boxing them in a shared type, TinyStorage won’t work. Same situation with dictionaries, you can use them fine with TinyStorage but the key and value must both be a Codable type, so you can’t use [String: Any] for instance where each string key could hold a different type of value.

Installation

Simply add a Swift Package Manager dependency for https://github.com/christianselig/TinyStorage.git

Usage

First, either initialize an instance of TinyStorage or create a singleton and choose where you want the file on disk to live. To keep with UserDefaults convention I normally create a singleton for the app container:

extension TinyStorage {
    static let appGroup: TinyStorage = {
        let appGroupID = "group.com.christianselig.example"
        let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: appGroupID)!
        return .init(insideDirectory: containerURL)
    }()
}

(You can store it wherever you see fit though, in URL.documentsDirectory is also an idea for instance!)

Then, decide how you want to reference your keys, similar to UserDefaults you can use raw strings, but I recommend a more strongly-typed approach, where you simply conform a type to TinyStorageKey and return a var rawValue: String and then you can use it as a key for your storage without worrying about typos. If you’re using something like an enum, making it a String enum gives you this for free, so no extra work!

After that you can simply read/write values in and out of your TinyStorge instance:

enum AppStorageKeys: String, TinyStorageKey {
    case likesIceCream
    case pet
    case hasBeatFirstLevel
}

// Read
let pet: Pet? = TinyStorage.appGroup.retrieve(type: Pet.self, forKey: AppStorageKeys.pet)

// Write
TinyStorage.appGroup.store(true, forKey: AppStorageKeys.likesIceCream)

(If you have some really weird type or don’t want to conform to Codable, just convert the type to Data through whichever means you prefer and store that, as Data itself is Codable.)

If you want to use it in SwiftUI and have your view automatically respond to changes for an item in your storage, you can use the @TinyStorageItem property wrapper. Simply specify your storage, the key for the item you want to access, and specify a default value.

@TinyStorageItem(key: AppStorageKey.pet, storage: .appGroup)
var pet: = Pet(name: "Boots", species: .fish, hasLegs: false)

var body: some View {
    Text(pet.name)
}

You can even use Bindings to automatically read/write.

@TinyStorageItem(key: AppStorageKeys.message, storage: .appGroup)
var message: String = ""

var body: some View {
    VStack {
        Text("Stored Value: \(message)")
        TextField("Message", text: $message)
    }
}

It also addresses some of the annoyances of @AppStorage, such as not being able to store collections:

@TinyStorageItem(key: "names", storage: .appGroup)
var names: [String] = []

Or better support for optional values:

@TinyStorageItem(key: "nickname", storage: .appGroup)
var nickname: String? = nil // or "Cool Guy"

You can also migrate from a UserDefaults instance to TinyStorage with a handy helper function:

let keysToMigrate = ["favoriteIceCream", "appFontSize", "useCustomTheme", "lastFetchDate"]
TinyStorage.appGroup.migrate(userDefaults: .standard, keys: keysToMigrate, overwriteIfConflict: true)

(Read the migrate function documentation for more details.)

If you want to migrate multiple keys manually or store a bunch of things at once, rather than a bunch of single store calls you can consolidate them into one call with bulkStore which will only write to disk the once:

let item1 = TinyStorageBulkStoreItem(key: AppGroup.pet, value: pet)
let item2 = TinyStorageBulkStoreItem(key: AppGroup.theme, value: "sunset")

TinyStorage.appGroup.bulkStore(items: [item1, item2])

Hope it’s handy!

If you like it or have any feedback let me know! I’m going to start slowly integrating it into Pixel Pals and hopefully solve a few bugs in the process.

Beware UserDefaults: a tale of hard to find bugs, and lost data

Sat, 05 Oct 2024 15:12:45 -0300

Excuse the alarmist title, but I think it’s justified, as it’s an issue that’s caused me a ton of pain in both support emails and actually tracking it down, so I want to make others aware of it so they don’t similarly burned.

Brief intro

For the uninitiated, UserDefaults (née NSUserDefaults) is the de facto iOS standard for persisting non-sensitive, non-massive data to “disk” (AKA offline). In other words, are you storing some user preferences, maybe your user’s favorite ice cream flavors? UserDefaults is great, and used extensively from virtually every iOS app to Apple sample code. Large amount of data, or sensitive data? Look elsewhere! This is as opposed to just storing it in memory where if the user restarts the app all the data is wiped out.

It’s a really handy tool with a ton of nice, built-in things for you:

No needing to mess with writing to files yourself, and better yet, no need to coordinate when to persist values back to the disk
Easy to share data between your app’s main target and secondary targets (like a widget target)
Automatic serialization and deserialization: just feed in a String, Date, Int, and UserDefaults handles turning it into bytes and back from bytes
Thread-safe!

So it’s no wonder it’s used extensively. But yeah, keep the two limitations in mind that Apple hammers home:

Don’t store sensitive data in UserDefaults, that’s what Keychain is for
Don’t store large amounts of data in UserDefaults, use something like Core Data or Swift Data

Okay, so what’s the problem

Turns out, sometimes you can request your saved data back from UserDefaults and it… just won’t have it! That’s a pretty big issue for a system that’s supposed to reliably store data for you.

This can amount to an even bigger issue that leads to permanent data loss.

Imagine a situation where a user has been meticulously opening your app for 364 days in a row. On day 365, your app promised a cool reward! When the user last closed the app, you stored 364 to UserDefaults.

The user wakes up on day 365, excited for their reward:

App launches
App queries UserDefaults for how many days in a row the user has opened the app
App returns 0 (UserDefaults is mysteriously unavailable so its API returns the default integer value of 0)
It’s a new day, so you increment that value by 1, so that 0 changes to 1
Save that new value back to UserDefaults

Now, instead of your user having a fun celebration, their data has been permanently overwritten and reset! They are having a Sad Day™.

It basically means, if at any point you trust UserDefaults to accurately return your data (which you know, sounds like a fair assumption) you might just get incorrect data, which you then might make worse by overwriting good data with.

And remember, you’re not meant to store sensitive data in UserDefaults, but even if it’s not sensitive data it might be valuable. The user’s day streak above is not sensitive data that would be bad if leaked online like a password, but it is valuable to that user. In fact I’d argue any data persisted to the disk is valuable, otherwise you wouldn’t be saving it. And you should be always be able to trust an API to reliably save your data.

What??? How is this happening? 😵‍💫

As I understand it, there’s basically two systems coming together (and working incorrectly, if you ask me) to cause this:

1. Sensitive data encryption

When using Keychain or files directly, as a developer you can mark data that should be encrypted until the device is unlocked by Face ID/Touch ID/passcode. This way if you’re storing a sensitive data like a token or password on the device, the contents are encrypted and thus unreadable until the device is unlocked.

This meant if the device was still locked, and you, say, had a Lock Screen Widget that performed an API request, you would have to show placeholder data until the user unlocked the device, because the sensitive data, namely the user’s API token, was encrypted and unable to be used by the app to fetch and show data until the user unlocked the device. Not the end of the world, but something to keep in mind for secure data like API tokens, passwords, secrets, etc.

2. Application prewarming

Starting with iOS 15, iOS will sometimes wake up your application early so that when a user launches it down the road it launches even quicker for them, as iOS was able to do some of the heavy lifting early. This is called prewarming. Thankfully per Apple, your application doesn’t fully launch, it’s just some processes required to get your app working (spoiler: this is wrong, see below):

Prewarming executes an app’s launch sequence up until, but not including, when main() calls UIApplicationMain(::::).

Okay, so what happened with these two?

It seems at some point, even though UserDefaults is intended for non-sensitive information, it started getting marked as data that needs to be encrypted and cannot be accessed until the user unlocked their device. I don’t know if it’s because Apple found developers were storing sensitive data in there even when they shouldn’t be, but the result is even if you just store something innocuous like what color scheme the user has set for your app, that theme cannot be accessed until the device is unlocked.

Again, who cares? Users have to unlock the device before launching my app, right? I thought so too! It turns out, even though Apple’s prewarming documentation states otherwise, developers have been reporting for years that that’s just wrong, and your app can effectively be fully launched at any time, including before the device is even unlocked.

Combining this with the previous UserDefaults change, you’re left with the above situation where the app is launched with crucial data just completely unavailable because the device is still locked.

UserDefaults also doesn’t make this clear at all, which it could do by for instance returning nil when trying to access UserDefaults.standard if it’s unavailable. Instead, it just looks like everything is as it should be, except none of your saved keys are available anymore, which can make your app think it’s in a “first launch after install” situation.

The whole point of UserDefaults is that it’s supposed to reliably store simple, non-sensitive data so it can be accessed whenever. The fact that this has now changed drastically, and at the same time your app can be launched effectively whenever, makes for an incredibly confusing, dangerous, and hard to debug situation.

And it’s getting worse with Live Activities

If you use Live Activities at all, the cool new API that puts activities in your Dynamic Island and Lock Screen, it seems if your app has an active Live Activity and the user reboots their device, virtually 100% of the time the above situation will occur where your app is launched in the background without UserDefaults being available to it. That means the next time your user actually launches the app, if at any point during your app launching you trusted the contents of UserDefaults, your app is likely in an incorrect state with incorrect data.

This bit me badly, and I’ve had users email me over time that they’ve experienced data loss, and it’s been incredibly tricky to pinpoint why. It turns out it’s simply because the app started up, assuming UserDefaults would return good data, and when it transparently didn’t, it would ultimately overwrite their good data with the returned bad data.

I’ve talked to a few other developers about this, and they’ve also reported random instances of users being logged out or losing data, and after further experimenting been able to now pinpoint that this is what caused their bug. It happened in past apps to me as well (namely users getting signed out of Apollo due to a key being missing), and I could never figure out why, but this was assuredly it.

If you’ve ever scratched your head at a support email over a user’s app being randomly reset, hopefully this helps!

I don’t like this ☹️

I can’t overstate what a misstep I think this was. Security is always a balance with convenience. Face ID and Touch ID strike this perfectly; they’re both ostensibly less secure per Apple’s own admission than, say, a 20 digit long password, but users are much more likely to adopt biometric security so it’s a massive overall win.

Changing UserDefaults in this way feels more on the side of “Your company’s sysadmin requiring you to change your password every week”: dubious security gains at the cost of user productivity and headaches.

Further, it’s not as if UserDefaults is truly secure with this change. It’s only encrypted between the time the device is rebooted and first unlocked. So sure, if you shut down your phone and someone powers it back up, the name of your pet cow might be knowable to the attacker, but literally any time after you unlock the device after first boot, even if you re-lock it, Mr. Moo will be unencrypted.

Update: After more investigating it seems like this change has been around for years and years, but the results of it have just has gotten more prevalent with things like prewarming and Live Activities.

I mean no shade to the nice folks at Apple working on UserDefaults, I’m sure there’s a lot of legacy considerations to take into account that I cannot fathom that makes this a complex machine. I’m just sad that this lovely, simple API has some really sharp edges in 2024.

But enough moaning, let’s fix it.

Solution 1

Because iOS is now seemingly encrypting UserDefaults, the easiest solution is to check UIApplication.isProtectedDataAvailable and if it returns false, subscribe to NotificationCenter for when protectedDataDidBecomeAvailableNotification is fired. This was previously really useful for knowing when Keychain or locked files were accessible once the device was unlocked, but it now seemingly applies to UserDefaults (despite not being mentioned anywhere in its documentation or UserDefault’s documentation 🙃).

I don’t love this solution, because it effectively makes UserDefaults either an asynchronous API (“Is it available? No? Okay I’ll wait here until it is.”), or one where you can only trust its values sometimes, because unlike the Keychain API for instance, UserDefaults API itself does not expose any information about this when you try to access it when it’s in a locked state.

Further, some developers have reported UserDefaults still being unavailable even once isProtectedDataAvailable returns true, presumably where (for one reason or another) UserDefaults isn’t reading the disk store back into memory even though the file became available.

Further further, UIApplication.isProtectedDataAvailable is just not a great API for this use case. For one, it’s weirdly only available in a main app context, so if you’re executing code from a widget extension and want to check if protected data is available, you’ll have to resort to some other method, like trying to write to disk and read it back. And on top of this, isProtectedDataAvailable returns false when the device is locked, which will cause you to think UserDefaults is also unavailable. But remember, UserDefaults is only unavailable before the first lock upon reboot, any time after that it’s totally accessible, and this API will still return false in those cases as UserDefaults doesn’t follow the strict protection mechanism that that API tracks.

Solution 2

For the mentioned reasons, I don’t really like/trust Solution 1. I want a version of UserDefaults that acts like what it says on the tin: simply, quickly, and reliably retrieve persisted, non-sensitive values. This is easy enough to whip up ourselves, we just want to keep in mind some of the things UserDefaults handles nicely for us, namely thread-safety, shared between targets, and an easy API where it serializes data without us having to worry about writing to disk. Let’s quickly show how we might approach some of this.

UserDefaults is fundamentally just a plist file stored on disk that is read into memory, so let’s create our own file, and instead of marking it as requiring encryption like iOS weirdly does, we’ll say that’s not required:

// Example thing to save
let favoriteIceCream = "chocolate"

// Save to your app's shared container directory so it can be accessed by other targets outside main
let appGroupID = ""

// Get the URL for the shared container
guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: appGroupID) else {
    fatalError("App Groups not set up correctly")
}

// Create the file URL within the shared container
let fileURL = containerURL.appendingPathComponent("Defaults")
    
do {
    let data = favoriteIceCream.data(using: .utf8)
    try data.write(to: fileURL)

    // No encryption please I'm just storing the name of my digital cow Mister Moo
    try FileManager.default.setAttributes([.protectionKey: .none], ofItemAtPath: fileURL.path)
    print("File saved successfully at \(fileURL)")
} catch {
    print("Error saving file: \(error.localizedDescription)")
}

(Note that you could theoretically modify the system UserDefaults file in the same way, but Apple documentation recommends against touching the UserDefaults file directly.)

Next let’s make it thread safe by using a DispatchQueue.

private static let dispatchQueue = DispatchQueue(label: "DefaultsQueue")

func retrieveFavoriteIceCream() -> String? {
   return dispatchQueue.sync { 
      guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "app-group-id") else { return nil }

      let fileURL = containerURL.appendingPathComponent(fileName)
            
      do {
         let data = try Data(contentsOf: fileURL)
         return String(data: data, encoding: .utf8)
      } catch {
         print("Error retrieving file: \(error.localizedDescription)")
         return nil
      }
   }
}

func save(favoriteIceCream: String) {
   dispatchQueue.sync { 
      guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "app-group-id") else { return }

      let fileURL = containerURL.appendingPathComponent(fileName)

      do {
         let data = favoriteIceCream.data(using: .utf8)
         try data.write(to: fileURL)
         try FileManager.default.setAttributes([.protectionKey: .none], ofItemAtPath: fileURL.path)
         print("File saved successfully at \(fileURL)")
      } catch {
         print("Error saving file: \(error.localizedDescription)")
      }
   }
}

(You probably don’t need a concurrent queue for this, so I didn’t.)

But with that we have to worry about data types, let’s just make it so long as the type conforms to Codable we can save or retrieve it:

func saveCodable(_ codable: Codable, forKey key: String) {
    do {
        let data = try JSONEncoder().encode(codable)
        // Persist raw data bytes to a file like above
    } catch {
        print("Unable to encode \(codable): \(error)")
    }
}

func codable<T: Codable>(forKey key: String, as type: T.Type) -> T? {
    let data = // Fetch raw data from disk as done above
    
    do {
        return try JSONDecoder().decode(T.self, from: data)
    } catch {
        print("Error decoding \(T.self) for key \(key) with error: \(error)")
        return nil
    }
}

// Example usage:
let newFavoriteIceCream = "strawberry"
saveCodable(newFavoriteIceCream, forKey: "favorite-ice-cream")

let savedFavoriteIceCream = codable(forKey: "favorite-ice-cream", as: String.self)

Put those together, wrap it in a nice little library, and bam, you’ve got a UserDefaults replacement that acts as you would expect. In fact if you like the encryption option you can add it back pretty easily (don’t change the file protection attributes) and you could make it clear in the API when the data is inaccessible due to the device being locked, either by throwing an error, making your singleton nil, awaiting until the device is unlocked, etc.

Solution 3

Update! I wrote a little library to kinda wrap all of the above into a handy little tool! It’s called TinyStorage.

End

Maybe this is super obvious to you, but I’ve talked to enough developers where it wasn’t, that I hope in writing this it can save you the many, many hours I spent trying to figure out why once in a blue moon a user would be logged out, or their app state would look like it reset, or worst of all: they lost data.

Juno for YouTube has been removed from the App Store

Tue, 01 Oct 2024 17:44:48 -0300

For those not aware, a few months ago after reaching out to me, YouTube contacted the App Store stating that Juno does not adhere to YouTube guidelines and modifies the website in a way they don’t approve of, and alludes to their trademarks and iconography.

I don’t personally agree with this, as Juno is just a web view, and acts as little more than a browser extension that modifies CSS to make the website and video player look more “visionOS” like. No logos are placed other than those already on the website, and the “for YouTube” suffix is permitted in their branding guidelines. Juno also doesn’t block ads in any capacity, for the curious.

I stated as much to YouTube, they wouldn’t really clarify or budge any, and as a result of both parties not being able to come to a conclusion I received an email a few minutes ago from Apple that Juno has been removed from the App Store.

Juno was a fun hobby project for me to build. As a developer I wanted to get some experience building for the Vision Pro, and as a user I wanted a nice way to watch YouTube on this cool new device. As a result I really enjoyed building Juno, but it was always something I saw as fundamentally an app I built for fun.

Because of that, I have zero desire to spin this into a massive fight (at least more than I’ve fought in emails over the last few months) akin to what happened with Reddit years ago. That’s kind of the opposite of fun. I hope that’s understandable.

For those who have Juno, to my knowledge it should continue to work fine until/unless the YouTube website updates in some fashion that breaks stuff. Sorry it had to end this way, I had some really cool stuff planned for it that I think would have been a lot of fun! It’s been genuinely awesome hearing all the kind words from Vision Pro users who have loved the app.

🫡

Server side Live Activities guide

Mon, 23 Sep 2024 14:02:16 -0300

iOS 17.2 gained the capability to start Live Activities from a server, which is pretty cool and handy! I’ve been playing around with it a bit and found some parts a bit confusing, so I thought I’d do a little write up for future me as well as anyone else who could benefit!

(For the uninitiated, Live Activities are the cool iOS feature that adds a live view of a specific activity to your Dynamic Island (if available) and Lock Screen, for example to see how your Uber Eats order is coming along.)

Overview of starting a Live Activity server-side

It’s pretty straightforward, just a few steps:

Get token

In your AppDelegate’s didFinishLaunching or somewhere very early in the lifecycle, start an async sequence to listen for a pushToStartToken so you can get the token:

Task {
    for await pushToken in Activity<IceCreamWidgetAttributes>.pushToStartTokenUpdates {
        let pushTokenString = pushToken.reduce("") { $0 + String(format: "%02x", $1) }
        print("Our push token is: \(pushTokenString)")
    }
}

Use token to start Live Activity server-side

Now that you have the token, we use that to send a push notification (using APNs) to start the Live Activity on the user’s device. There’s lots of server side libraries for this, or you can just use curl, or you can an online site to test like this one (in the case of the latter where you’re uploading your token to random sites, please create a sample token that you delete afterward).

The key points that differ from sending a “normal” push notification:

Headers

Set your push token to the pushToStartToken you received above
Set the topic to your app’s normal bundle ID with an added suffix of .push-type.liveactivity
Set the priority to 5 for low priority or 10 for a high priority notification (does not seem like any values in between work)
Set apns-push-type to liveactivity

Payload

timestamp field with the current unix timestamp
event field set to start
attributes-type set to the name of your Swift Live Activities attributes struct
attributes with a dictionary representing your Swift Live Activity attributes
content-state with the initial content state as a dictionary, similar to attributes
alert field set with a title and a body (will silently fail if you just set alert to a string like the old days)

Note that you cannot use the old certificate based authentication and instead have to use token based authentication and http2.

Send the http request and it should start the Live Activity on the iOS device! 🎉

Aside

Sending push notifications is kinda complicated, so you likely want a server-side library. I wanted to play around with Node for this for the first time, and in case you go down that path, in September 2024 Node is in a weirdly lacking spot for APNs libraries. The de facto one is abandoned, the community replacement for it doesn’t work with TypeScript, and there’s a third option with TypeScript support but it isn’t super popular and has some issues. I ended up going back to Go, and there’s an excellent APNs library there.

It’s broken on iOS 17

On iOS 17, getting the above push token is really hard (you can seemingly only get it once). I tried for ages to get the token before stumbling upon a thread on the Apple forums where a user said to delete the app, reboot your device, then fresh install it. Sure enough that worked and the token displayed, but if I just rebooted the device, or just reinstalled the app, it wouldn’t. Had to do all of them. And no it didn’t change if I used a release configuration.

I tried this on iOS 17.6.1 (latest iOS 17 release at the time of writing). It does not seem to be an issue at all on iOS 18.

The difficulty in acquiring it makes it incredibly hard to use on iOS 17 if you add in the feature in an update and the user isn’t getting your app from a fresh install, to the extent that I can’t really trust its reliability on iOS 17 as a feature you could advertise, for instance.

John Gruber recently wrote about the Apple Sports app and wondered why its Live Activities feature is iOS 18 only. A reader wrote in to mention the new broadcast push notifications feature requiring iOS 18, and that well may be it, but I’d say it’s equally as likely that it just doesn’t work reliably enough on iOS 17 for even Apple to bother.

Update/end the activity

This part admittedly confused me a bit. The docs state:

Send the push-to-start token to your server and use the pushToStartTokenUpdates sequence to receive token updates. Similar to the update token, update it on your server when needed and invalidate the old token.

While the system starts the new Live Activity and wakes up your app, you receive the push token you use for updates. To update and end the Live Activity on devices that aren’t running iOS 18 or iPadOS 18, use this update push token as if you obtained it by starting a Live Activity from within your app.

I assumed that this all operated through that same pushToStartTokenUpdates, because as soon as you start the activity server-side, your app wakes up, and your pushToStartTokenUpdates async sequence fires again with a “new” token.

However the “new” token is just the same one that you started the activity with, and if you try to end your activity server-side with this token, nothing happens.

Turns out, your pushToStartTokenUpdates is (per the name!) only able to start Live Activities. Not sure why it fires a second time with the same token, but you do want to use that async sequence to monitor for changes to the start token, because it might change and the next time you want to start a new Live Activity you’ll need that token.

To update/end your Live Activity, what you actually want to do is create a separate async sequence to monitor your app for Live Activities that get created, and then monitor its push token:

// Listen for local Live Activity updates
for await activity in Activity<IceCreamWidgetAttributes>.activityUpdates {
    // Upon finding one, listen for its push token (it is not available immediately!)
    Task {
        for await pushToken in activity.pushTokenUpdates {
            let pushTokenString = pushToken.reduce("") { $0 + String(format: "%02x", $1) }
            print("New activity detected with push token: \(pushTokenString)")
        }
    }
}

iOS will also call this async sequence on start of a new Live Activity from a server, and you use that token to update/end it.

I’m not blaming the documentation on this, I understand it as it is written now, but I wanted to clarify in case anyone else gets confused.

Once your server is made aware of this token, you can end your Live Activity server-side with the following changes from the above start considerations:

Payload: event should be end or update
Payload: If ending you might want a dismissal-date unix timestamp. If you don’t set this, iOS will immediately remove the Live Activity from the Dynamic Island but leave it on the Lock Screen for up to four hours. You may want this, but you can control how long it stays there by setting dismissal-date, if you set it to now or in the past it will remove it upon receipt of the notification.
Payload: Send a new content-state if updating (optional if ending, if ending and you want to leave it on the lock screen (see previous point) you can set a content-state which will serve as the final content state for the Live Activity)
Payload: Do not send attributes or attributes-type as these are intended to be immutable through the life of the Live Activity

There’s other interesting ones that you might want to consider but aren’t as important, like stale-date, discussed in the docs.

That’s it!

That should cover most things! I want to thank the incredible Francesc Bruguera for helping me get unstuck a few places.

The Caldera: a sleek split and wireless keyboard

Sat, 20 Jul 2024 05:18:53 -0300

I designed my own keyboard and it’s freely available! I’m calling it the Caldera, and it’s basically my dream wireless split keyboard.

I’ve been using it for months, and I love it.

Video overview

If you’re a visual person, I made a fun little video showcasing the creation process as well as an overview of the keyboard. It serves as a nice tutorial too if you’re even vaguely interested in building your own custom keyboard. I’ve been wanting to make some more videos going forward, and this was a fun way to get into it! If you’d like some more videos on things I’m planning to create, subscribe to my YouTube channel!

Why and how?

I love split keyboards, they’re so nice on your wrists when you type all day and have helped my wrist pain immensely, but none of the existing keyboards were quite what I wanted. They were either wired, had key layouts I didn’t vibe with, or were too “techy” looking. I wanted a layout with all the right keys, a sleek design, and fully wireless with long battery life.

Of course there’s many resources for “building your own keyboard”, but they’re normally just an assembly kit for someone else’s keyboard, letting you change the switches or key caps. I wanted something fully custom, with the keys positioned exactly where I wanted them, and a clean design to boot. That means it needs a custom PCB.

I learned about a cool piece of free, open source software called Ergogen that helps you to build your own completely custom keyboard and I got to work learning it. The process was surprisingly easy, and the video above goes into how to use it from a beginner’s perspective. The video also touches on KiCad, which Ergogen hands off the PCB to, and Fusion 360 which I use to design the case. Then you just have to flash some simple firmware on it from ZMK where you just tell it about your keyboard.

Resources

Everything that I built for this keyboard is available open source on GitHub, from the Ergogen files, to the PCB files, to the 3D printable case files, to the ZMK firmware files. It’s all honestly pretty easy! The 3D printable files specifically can be found here.

If you want this keyboard for yourself, simply take the PCB files (the .zip gerber files on GitHub) and upload them to a PCB manufacturer (like JLCPCB or PCBWay, not sponsored by either), the PCBs will arrive, then it just requires a very beginner level amount of soldering (great first project honestly), some 3D printable cases, some standard keyboard supplies like keys and a controller, and then you just have to flash the firmware and you’ll have a functioning Caldera keyboard, or a basis for you to build your own completely custom keyboard! (It doesn’t have to be a split keyboard either!)

Supplies

Here are all the supplies needed for this project. It seems like a fair bit, but many are just great to have things that you can also use for other projects if you don’t have them already, and the rest are cheap just to grab for this project. None of these are affiliate links.

General tools

Pinecil soldering iron
Bambu Lab P1S printer (can likely also have a friend or local business 3D print the case for you!)
Filament (I used Bambu’s white marble PLA)
Kotto fume extractor (optional but highly suggested, please don’t breathe in solder fumes!)
Solder (I use 0.6mm and recommend lead-free for health and environmental reasons)
Tweezers (idk pick some up at a pharmacy if you don’t have any weirdo)

Keyboard specific things

I get most of these from Typeractive (except the PCB), makes one order easy, and has free shipping (not sponsored).

PCBs (see above)
Choc low profile key switches of your choice (I like Choc Pro Reds personally, Typeractive has them)
nice!nano controller x2 (Typeractive)
Controller hot swap sockets (Typeractive)
PS3 controller replacement battery (Amazon)
Battery input jack (Typeractive)
Diodes (Typeractive)
Reset button (Typeractive)
Kailh Choc hot swap sockets (Typeractive)
Key caps (I like Choc MBK key caps, which Typeractive has)
Battery power switch (Typeractive)
10x M2x3 screws, and 5x M2x4 standoffs for assembling each side of the case (so 20 screws and 10 standoffs in total) (I’d just grab a small kit on Amazon)
(Optional) 6mm (0.24") diameter x 2mm (0.08") height rubber feet for the bottom of the case

Totalling up the cost of the project, I’d estimate you could put this keyboard together for under $200 (talking about consumables, not including tools that you may or may not already have).

Enjoy!

If you build the keyboard or have feedback on my video about building it, I’d love to know! Hit me up on Twitter/X, Mastodon, or Threads! It was a really fun process to learn and was a lot easier than I ever imagined it to be, so I’d definitely encourage you to go out and try if there’s a keyboard you wish existed!

Announcing Juno 2.0

Thu, 27 Jun 2024 10:16:17 -0500

Juno is an app I built for watching YouTube on the Apple Vision Pro, and it’s been such a fun project to build. It’s also been so great hearing how other people have been enjoying Juno since its launch, as well as providing awesome feedback and input to improve it.

Today I’m releasing Juno 2.0, which incorporates a ton of that community feedback, and truly brings the app to the next level through extensive improvements and new features. Using it over the last little while I have had so many moments where I catch myself smiling. Browsing and watching YouTube on visionOS through Juno is honestly just so fun, immersive, and downright futuristic, and I genuinely think the best way to watch your favorite videos.

You can download Juno for YouTube 2.0 for just a fiver (and it’s a free update for existing customers), and unlock an amazing visionOS experience for YouTube.

I think this version really lives up to the 2.0 moniker, so let’s get into all the improvements!

Immersive 360 and 180 degree video (with a Metal twist!)

You can now watch (what I would imagine to be) the internet’s largest source of 360° and 180° immersive video with Juno. Simply tap on the video from YouTube, and Juno will offers to open it in an immersive space, where the video will fully surround you as you watch it. You can soar through volcanoes, experience tours of incredible foreign lands, dive underwater, skydive, pretty much whatever you can imagine, it’s probably out there and now watchable in Juno for visionOS.

The twist is, Juno even takes this a step further, and leverages Apple’s Metal engine to perform advanced AI upscaling and take the existing limitation of 4K video, and upscale it to 6K. This is the same technology that games like No Man’s Sky and Resident Evil Village have recently used to unlock incredible performance on Apple silicon, and with Juno it makes video feel even sharper and more realistic, with over twice the pixels versus 4K.

From a technical perspective, this was a TON of work. As mentioned in previous blog posts, Juno leverages the YouTube website, as Google/YouTube do not give an (official) way to access video feeds directly (as doing so would allow you to circumvent ads and make them angry).

With just the website, and no direct access to the video, creating an immersive experience is incredibly challenging, but using Metal and impressive GPU on the Vision Pro, Juno essentially takes a series of rapid snapshots of the web browser and stitches them together in a video feed, running each frame through Apple’s MetalFX machine learning upscaling engine, and then projecting that frame onto a sphere that surrounds the user.

The result is truly incredible and I’ve seen some really mind-blowing videos. To quote a recent email I got from TestFlight, “I don’t know how you did it, this is ****ing incredible”.

It’s not perfect (it’s capped at 30 fps, which is the normal frame rate for VR videos on YouTube), and there’s bound to be some bugs (please report!). Metal AI upscaling also does not work with all videos (it can introduce some lag for some very “busy” videos), so you can turn it on or off at will in the player.

As mentioned in the last post, Apple’s M2 chip does not have a hardware decoder for the AV1 video codec that YouTube uses for 8K videos so it’s highly likely true 8K YouTube videos will be a ways away for the Vision Pro, and Juno bridges this gap nicely by offering all content in smart-upscaled 6K (which also covers the vast majority of immersive videos that don’t even have an 8K version uploaded).

I do want to take a chance to massively thank everyone who has answered questions on social media or Discord about Metal, RealityKit, and more, without you this never would have been possible. I want to say an extra big thanks to Khaos Tian, Arthur Schiller, and Finn Voorhees, who I truly talked the ears off of, and as a result there’s a findable easter egg in Juno now where the immersive theater is named the KSV Immersive Theater.

New UI

I really wanted to have an app for watching YouTube on visionOS available on the platform for day one, and I put a lot of hours into making that happen. I was admittedly a bit up against the clock however, so I’m glad with this update I was able to take some extra time to really go over the UI with a fine-toothed comb and make some nice improvements, and now Juno feels even more like a beautiful, native visionOS app (even if it’s basically just a very complex browser extension).

With 2.0 Juno now enjoys a beautiful new tab bar, which loads content much faster and keeps them in memory. There’s also a new, beautiful navigation bar with a progressive blur to the content behind it, with a native search bar that allows you to just look at the microphone and talk to quickly search YouTube. It feels awesome, and is in many ways what I always wanted Juno to be from the outset.

New video engine: better video compatibility, and watch history!

Juno 1.0 leveraged Apollo’s code that used the YouTube embed player to play back content. This allowed me to ship quickly, but at the same time had issues such as some video creators disabling playback in the embed player (which would cause Juno to fallback to the website), and other ramifications like not marking that you watched that video in your history.

Juno 2.0 now just uses the website as its video component, as it does with the rest of the app. With that, more videos are able to play back, videos are correctly added to your watch history, and also just greatly simplifies Juno, as Juno is now simply loading the YouTube video URL as a web browser would, and just applying custom CSS and interacting with it through JavaScript to make it feel at home on visionOS.

(And yes, if you’re curious, Juno still does not block ads for reasons of not angering Google, but as it’s just using the website if you have YouTube Premium you will not see any ads in Juno.)

Back button

Yeah, this gets its own category, because it was surprisingly really, really hard! Back in 2004 when both the world and websites were much simpler, you would click a link on a website, and the browser would load a new webpage. Now we got all fancy with JavaScript and whatnot, and websites like YouTube (for good reason, it makes things feel faster), instead of loading a whole new webpage each click, normally just swap out the contents of the current website with JavaScript, and then update the URL to indicate the change.

Cool! That’s great! I’m so happy for you! But that makes a back button a lot more annoying, because now web browsers get confused a lot when you hit back (you didn’t really change a page), and often the browser will update the URL but the page contents will stay the same, and you’re just staring at your screen confused. Twitter, Threads and Mastodon have told me I’m not imagining things and that does happen a lot to other folks.

So Juno has a back button, but also sprinkles some special YouTube magic sauce (do you sprinkle sauce? maybe flakes) where it attempts to detect the web browser being confused, by checking if the HTML of the current webpage is a reasonable match for the current URL. If they don’t match, it means the web browser got confused and just updated the URL without updating the actual page contents, and Juno does a full refresh of the webpage which forces the web browser to refetch the proper contents for the current URL. The system doesn’t have to step in that often (maybe 10% of the time), but when it does, it’s very helpful and I could not ship a half–working back button.

Playlist support

I suppose “playlist support” covers two new features! The first, is that if you select a video from a playlist, for instance a video series a YouTuber made, it will automatically play the next video in the series upon each video ending.

The second aspect would be the new playlists page, rather than just a text menu like in Juno 1.0, you now get access to the full YouTube website playlist view, with rich thumbnails!

Better window resizing

Juno’s always been a pretty smart cookie about window sizing, and automatically adapts the window to the aspect ratio of the video so you don’t get any black bars. But with this update, Juno will also properly manage the size of the window. So if you want to make your window even bigger, Juno will remember that approximate size and adapt the aspect ratio accordingly, so you can keep your ideal video watching experience perfectly intact across a variety of videos.

Juno remembers

Now Juno is much better at remembering your settings between subsequent video watches. In addition to the window sizing mentioned above, Juno will remember features like captions, playback rate, and more.

Select end cards/auto-play

There are two kinds of YouTube users, those who leave “auto-play” enabled (so YouTube will just play the next recommended video automatically after you finish your current one), and folks who have that turned off (YouTube will show a grid of video recommendations to watch next). Juno loves everyone and now supports both of those, so if you have it enabled on the website, Juno will auto-play the next video automatically with its countdown, and if you have that disabled, you can pick from YouTube’s recommended next videos.

Siri integration

This is a really handy one and was very highly requested (for good reason). Now you can just say “Siri, pause”, “Siri, playback speed 2 times”, “Siri jump to 5 minutes and 30 seconds”, etc. and Juno will listen accordingly so you don’t even have to pick up a finger!

Time-linking

If you select a video on the website that’s linked to a specific time (say, 2 minutes and 28 seconds), Juno will incorporate that instead of just playing from the beginning. Same if you drag and drop a YouTube link onto Juno from a friend. On the flip side, if you share a YouTube URL from Juno, it will now embed the current time into the URL so your friend (or enemy? idk) that receives the link doesn’t have to guess what part of the video you were talking about (or worse, manually scrub to it).

You can now properly interact with the YouTube options menus (those vertical ••• menus, for the unaware), so if you want to add a video to a playlist, remove something from your watch history, or anything like that, you’re now easily able to!

Open in Safari

The Share menu for a video (in addition to fixing a potential crash that could occur), now allows you to quickly open a YouTube video in Safari if you so choose, which can be a great way to access features of YouTube that Juno might not offer, like reading comments, for instance.

Bug fixes

Lots of little bug fixes across the board that should make everything operate even smoother. Captions should work more reliably (and tell you in cases where they’re unavailable), drag and drop as well as sharing should no longer crash in weird cases, the double-tap to go forward/back 10 seconds should be faster, seeking should be smoother, among many others!

Misc: disabling spatial audio

A common request has been to be able to disable spatial audio (right now visionOS makes Juno’s audio feel like it’s coming from the window itself, so if it’s beside you, the audio will feel beside you). Some folks don’t love this and wish it just sounded like normal audio. Unfortunately Apple doesn’t expose an API to control this for web views, BUT iOS does have a kinda hidden way to override it. If you bring up the system Control Center and long-press the volume slider, you can disable it there. So that’s a good solution if you’re looking for a way!

Lastly: answering Google/YouTube’s issues with Juno

I’ve said from the initial launch, Juno is built as a web-wrapper for YouTube, akin to a browser extension, and purposefully built with full respect for the YouTube website and experience, and as a result does not block ads in any capacity, nor does it introduce extra functionality like downloading videos offline that could facilitate that. Further, Juno doesn’t even use any YouTube APIs, as it has no need to: it just wraps the website, and uses CSS and JavaScript to style the website and functionality more in line with visionOS. This is in contrast to other third-party tools that for instance scrape the YouTube website for applicable video URLs and use those directly, or those that integrate ad-blocking functionality.

In April, YouTube announced it would be cracking down specifically on ad-blocking third-party apps, and weirdly, Juno got an email at the end of April from YouTube Legal that voiced some concerns. You can view the full contents of their email here: https://christianselig.com/juno-youtube-email-april-26-24.txt

The short of it is that, while no issues with ad-blocking were presented, they did take issue with a few areas, firstly that Juno is in violation of the YouTube API Terms of Service, and secondly that Juno alludes to YouTube trademarks and iconography. Both of these issues were very puzzling.

For the first issue, as I mentioned, Juno makes no use of the YouTube API so it’s unclear to me how it could be in violation of it. Juno operates in much the same way a browser extension would through CSS and JavaScript. Google’s own Chrome both has native support for browser extensions, and even has native features that customize the styling and experience of webpages. They also mentioned they did not like that Juno uses the embed player, despite Google themselves having a library showing this as the preferred way to integrate YouTube videos into apps.

Secondly, for iconography and trademarks, I can only assume YouTube is referring to the YouTube logo present on the YouTube.com homepage that Juno loads. Obviously, as I’m just loading a website, I am not putting that there. For the name, “Juno for YouTube”, YouTube has branding guidelines that specifically permit this: “For example, you cannot call your application “YouTube for Kids” or “YouTube Education”. However, you may reference the fact that your app is for YouTube or works with YouTube by stating that it is a “great app for YouTube” or using other similar language”.

Like I said, from the get-go I’ve wanted be just a well-behaved visionOS wrapper for the website, so in the interest of making YouTube happy, back in April I responded to Google that as Juno does not use any YouTube APIs, I do not see how it could be violating them, however I would be putting an update out to attempt to address concerns. This is that update, and I switched from the embed player to just using styling the website player, I manually removed the YouTube logo from the homepage, and I added “Unofficial” to the subtitle and description of Juno on the App Store.

Now that this update is out, hopefully this appeases Google, as they have also (as of a few days ago) filed a complaint with the App Store directly. I’ll obviously push back, as I believe Juno is just getting caught up in the crosshairs of Google’s targetting of apps that do have ad-blocking, and an app that fundamentally themes a website is nothing new, novel, or insidious.

But, if you’re hoping for a bunch of drama to spin out of this (akin to last year with Reddit), I’m sorry to say I’m not looking to go down that route again. Juno has been a ton of fun to build, a ton of fun to use, and in my opinion a great benefit to both the Vision Pro platform as well as YouTube users, but it’s fundamentally a fun hobby project for me, and if it comes down to fighting a drawn out battle against a giant like Google again… well, that no longer sounds like fun and I’ll happily let Google win, haha. Worst case scenario I’ve had a ton of fun building this, and I got to get my feet wet with visionOS, so it’s all good!

That being said, if Juno does disappear from sale from the App Store, I don’t see any reason to believe that it will cease to work for existing users as it just operates on the website, unless YouTube/Google dramatically rework the website. Again, this wouldn’t seem beneficial to them as Juno is just the website and shows all ads and whatnot. Also this is genuinely not a coy way of saying to get the app before it goes away, it may cease to work and I wouldn’t want anyone buying it going into it with a false belief that it will work forever. But if I had to guess it will work.

Thank you! ❤️

I really hope you enjoy the Juno 2.0 update, I had a lot of fun building it and I’d love to know what you think. If you haven’t checked out Juno yet, you can download it here (if you think you’re going to forget, you can also purchase it from your iPhone or iPad). And if you have checked out Juno, you’re awesome, no doubt very well-read, have incredible taste, and I thank you!

Choosing a travel pack is hard

Sun, 28 Apr 2024 12:49:02 -0300

I love the “carry-on only” traveling style, it’s cheaper and you don’t have to worry about airlines losing your stuff. Outside of requiring a bit more planning, what’s not to love?

Turns out this is a beloved product category with a passionate community behind it, and as a result a lot of manufacturers are making really awesome bags. As a result you see different bags with different strategies, and start to develop a taste for what you want.

These bags are all incredible, but none are a perfect fit for me. I had the flu a few weeks ago and was writing down my thoughts on bags for an easy reference (I kept rediscovering the same bags every few months), but I thought I’d make it into a little blog post in case it was helpful to someone else bag searching. I’ll basically list a popular bag, and my thoughts on it.

What I want

Quick precursor to anyone yet bit by the backpack bug: there’s basically 3 categories of bags. The first, day bags, are normally between 10-20L and intended as a smaller bag to carry a few things at your destination. Every day carry bags (EDC) are normally 20-25L, a bit bigger, and for a short weekend trip, or just a good, general purpose bag that carries a decent amount but isn’t too bulky. The last category is a proper travel backpack, normally 30-45L, whose goal is to hold all your stuff for a decent length trip, while still being small enough to fit the carry-on dimensions for most airlines. 40L is ideal for me, 35L is a bit on the smaller side, and 45L gets me scared with certain airlines.

I’m looking for that last category, a travel backpack, with specific goals:

Not a roller bag, too heavy, less flexible, and those with roller bags are often the first airline employees target when they need to start checking bags. I want a backpack
Not too heavy, ideally 2.5 lb - 3.5 lb (1.1 kg to 1.6 kg) for just the bag. I find beyond this the bag itself starts to have some heft, and it feels largely unnecessary when there’s super well-made bags in that “Goldilocks zone”. My scale is kinda: > 4 lb: why, > 3.5 lb: okay, > 3 lb: good, > 2 lb: dang!, < 2 lb: how. Essentially: my bag with nothing in it should not weigh more than my MacBook Pro.
External water bottle holder. Really don’t get why some manufacturers started putting them inside the bag. At worst it leaks a bit on your expensive stuff, at best it’s much more inconvenient to get at when walking around the airport and takes up space in the interior of your bag
Good laptop storage, with a slot for an iPad too. Not a big fan of laptop storage on the side, when you’re trying to grab your laptop in close quarters and just have the bag between your legs, having to rotate the bag versus just yanking it out from the top is less ideal
Not a zillion compartments. Some love this, which is totally cool obviously, but I like using packing cubes and a tech pouch, so I’d rather just have one massive vacuous main compartment rather than having a bunch of mini-compartments that take up space and add weight that I won’t use
A space to put a small day bag. I love travelling with a good sized travel pack, but having a day bag inside it so when I get to the destination I can leave the hefty bag at the hotel/Airbnb and just carry a light bag. I use the Aer Go Pack 2 for this, which isn’t as packable as some daypacks because I still want something with some laptop padding, so I need an area to slide this in, which is normally pretty easy
Stowable backpack straps. Sometimes you’re just throwing it in the back of a car and driving somewhere, and being able to hide the backpack straps to make it just a sleek little grab bag is super handy
Compression straps on the outside to cinch it down a bit if needed
35L to 40L capacity, I find below that and it’s too small for a decent length trip, and above that you start to get into issues with some airlines deeming it too big a carry-on
Quality back harness system. Be it trekking between two far apart terminals, or a long walk to your hotel at the destination, having the bag be super comfy on your back, with padded straps, a sternum belt, and a hip belt, and ideally load lifters to position the bag on your back, is super awesome
Zip-open suitcase/clamshell opening style. It has to be able to open fully versus a normal backpack that just zips down partway, otherwise it’s a pain to get at anything at the bottom of the bag. Bonus points if it opens horizontally versus vertically which I find just a bit nicer, but not a deal-breaker

What are liters even

One quick note before we start, is that bags are measured in liters (a measurement of volume), but how manufacturers measure their volume is all over the place. Some measure how much the interior will hold, some measure how much space the bag itself takes up, some seem a little disingenuous period. It’s all very hard to tell just based on the listed capacity of the bag.

Shout out to OneBagTravels, far and away my favorite YouTube bag reviewer because he actually stuffs the bags with packing peanuts and measures the resulting capacity rather than just repeating manufacturer claims. I wish every reviewer did this.

Backpacks

Okay, here are a bunch of the bags I’ve encountered, and my notes on why I love them and why I don’t. Again, this is not saying any of these bags are bad, one or more might fit you perfectly, but for my priorities personally they’re all missing something.

I’m putting a ⭐️ beside the ones that I personally like a fair bit, and ✨ for ones I like a bit less but that I think with some modifications from the manufacturer could be awesome, in no particular order. Also note that the vast majority of these I haven’t tried, I’m just trying to summarize other reviews and their specs.

⭐️ Osprey Farpoint

This has been my go-to bag for the better part of a decade, and it’s gone all over the globe with me. I like it a fair bit, but I don’t love it.

Good

40L and holds a ton
Light (my bag weighs 1.32 kg or 2.9 lb)
Despite being light and trekking around the globe with me for ages still almost looks new, so I can safely say this bag is very well made
Super comfortable, robust harness system that you can zip up to completely hide

Bad

The laptop compartment is at the front of the bag, as opposed to close to your back, so the weight balance of the bag isn’t great, and it can be hard to put the laptop in (this has been fixed in a more recent bag revision, though)
The water bottle holders are just… bad, in that they’re both at the front (hard to access when wearing the bag), and hold water bottles so poorly that the bottles almost jump out of the bag
There’s also a lot of dangly clips and straps everywhere
I wish you could hide the hip belt separately since I only use it once in awhile, but you either have to hide all the backpack strap area, or leave it all open
It only zips open like 90% of the way so packing things into the bottom is a bit awkward
The shape when fully packed out is kinda weird and bulges from the center out, kinda looking like a potato chip at the top, would prefer something a bit more boxy

Aer Travel Pack 3

I love Aer bags, so I bought this with high hopes but ultimately returned it.

Good

I love how it looks
Sidewalls are slightly less floppy than my Osprey Farpoint so easier to pack into
Very comfortable harness system (though lacks a hip belt)
Straps are well thought out so it doesn’t dangle a bunch
Zippers feel super premium
Nice, functional boxy shape
Love the front slash pocket for something like a light rain jacket

Bad

It’s really heavy, at 4.1 lb it’s 40% heavier than my Osprey Farpoint and you can really tell. It feels like the difference between a MacBook Air and a MacBook Pro, except it holds less than the Osprey which is already incredibly made so it kinda just feels… over-engineered?
It doesn’t feel like it holds that much, especially compared to the Osprey. On the pack it says a 5L difference but it feels closer to 10L
The water bottle holder is almost criminally bad, it’s on the side at least, but does not do a good job of holding literally any water bottle I own, it falls out super easily. My other two Aer bags, a Go Pack 2 and a Pro Pack 20L, both have infinitely better water bottle holders despite being half the size, I’m so confused
Definitely a neutral for some, but I don’t like the admin/tech compartment. Like I mentioned, I use a tech pouch anyway (so I can easily transfer things to my day bag) and this cuts into the available storage area while also adding a decent amount of weight (it’s a hefty tech compartment, my attempts to measure it with a kitchen scale put it at about 0.4 lb alone). Also losing the admin compartment means less zippers on the outside, which makes it easier to know what to open to get to all your stuff.
Can’t hide the backpack straps at all
Minor one, but the top grab handle is in the middle of the pack, versus closer to one edge, which means if you try to hang it on a hook at a bathroom stall at an airport or something it’s really hard, versus bags like Ospreys that put it closer to one edge so a hook can still reach it
The laptop compartment almost feels too padded to the extent that it’s bulky. I only bring this up because the bag is already heavier than most, and this feels like an area where they unnecessarily added weight. All my other bags protect my laptop beautifully with much less bulk, though probably Aer’s alone could survive an actual fall out of a plane
Inside isn’t super visible, it’s like a dark grey, wish it was more of a light grey like the Aer Pro Pack 20L so you’d get increased contrast against your belongings. The darker it is inside the more it’s like an abyssal void

I’d love to see Aer do what Tortuga did (see below) and release a “Lite” version that cuts a ton of weight off. We’re kinda due for a Travel Pack 4, so maybe?

Evergoods Civic Travel Bag 35

Great, but heavy (4 lb), and can’t stow backpack straps. Love that it just has one, vacuous main compartment though. Very expensive. Props for having a water bottle holder, but minus props for only having a side laptop compartment (and it’s weirdly big), especially for the weight I wish it was a proper, full-zip compartment. Love the look, and love how when packed out it still has a nice shape.

⭐️ Minaal Carry-On 3.0 Bag

This is one of my favorites. Only weighs 3.1 lb, no tech compartment, has a pretty sleek look, and one big main compartment for item storage. I also love how the laptop compartment opens all the way, I think all bags should do this, that means I can easily stash my day bag in there flattened down. Stowable backpack straps too.

On the bad side the water bottle holder looks as bad as Aer’s, it’s very expensive, the inside is black so it’s like a void, and the storage system seems weird. Like, instead of the part closer to your body holding the clothes, it flops open and the floppy part holds the clothes, and it looks quite floppy. Also it looks like the main compartment has packing cube style zippers built into it which take up volume, and again I’d rather just use my own.

I feel like this bag is a small revision away from being perfect. Again we’re due for a Carry-On 4.0 revision, so maybe? I would rank this number 4 currently.

Away Outdoor Convertible Backpack

Pretty good! 45L and 3.3 lb is impressive, wish it was maybe a tad smaller though. Love the nice big bucket to throw everything into, and love that it opens horizontally. No water bottle holder means straight to jail though. Also the harness system seems a little lacking (no load lifters, no hip belt), and I’m not a big fan of side laptop compartments, and this one doesn’t even have an iPad slot in the compartment.

Ablecarry Max

30L is kind of awkward, a large bag for daily use but a bit small for traveling. Love the design visually though. No external water bottle holder.

Tortuga Backpack Pro

Too heavy (4.5 lb!!), not personally a big fan of having a separate tech compartment, price is kinda bonkers. Lacks stowable backpack straps.

⭐️ Tortuga Backpack Lite

Love this one a lot, in my top three. 1lb less weight than the Pro version. Downside is no iPad compartment, which is unfortunate because even just a small piece of fabric separation would have been nice, but they did ditch the admin compartment which is nice. Would have been great if they made the laptop compartment zip all the way open like the Minaal so you could shove a day bag in there easily too. I also wish they would also ditch the dividers in the main compartment which take up space and require you to organize your things within them, rather than just using packing cubes which I’d prefer. Yay you can hide backpack straps, and looks like it has an awesome water bottle holder. Have to knock down a point for being incredibly hard to acquire in Canada for some reason. Looks like a nice functional boxy shape too.

Again, almost perfect, and $100 cheaper than the Pro version at $250. I would rank this number 1 of these bags for me, but still not perfect.

Airback

Kind of a whacky one, uses vacuum compression to suck the bag down, and it at least seems like it relies on that to get the actual quoted 48L capacity? I already compress my clothes a fair bit with a compression packing cube (again shout out to Peak Design), so the big vacuum bag in the center kinda just seems like it would get in the way for me, and I’m not sure how much it holds “normally” without factoring in that it says up to 50% more gear thanks to compression, so that would put it at about 31L? A bit small, and if that’s the case at 3.7 lb the weight is not great. But the water bottle holder and harness system both seem not that great as well. Laptop compartment with separate iPad stash though, just wish the compartment opened up fully. Interesting bag for the right person, but not for me.

Tropicfeel Shell

Really like the design of this one, and it’s on the lighter side at 3.3 lb. Water bottle holder looks good. Seems quite small for its claim of holding 40L, wish a channel would do the ol’ packing peanuts test but I couldn’t find any. It almost seems like it can only store 40L if you open/unroll the top fully but then your stuff is kinda exposed? Can sorta stow backpacks traps with a clever clip-across system. Wish the laptop compartment was fully separate so I could stow my day bag in there separately.

Tom Bihn Synik

No external water bottle holder, a bit small at only 30L. Harness system seems a bit minimal. Not much laptop padding and no iPad slot. Love how vacuous the bucket storage area looks though.

Tom Bihn Aeronaut

This looks pretty nice, uses its size really well at 45L, while still being just under 3 lb in some fabrics. Harness system seems kinda meh, with no hip belt or air channels for breathability. Also no laptop compartment at all is kind of a head scratcher. Tom Bihn’s institutional hatred of easy access to water will also perpetually vex me.

⭐️ Tom Bihn Techonaut

45L, just under 3 lb (impressive). Has a padded laptop compartment, but no iPad compartment which is unfortunate. Seems like Tom Bihn is slowly inching toward a normal water bottle pocket with this one but it’s still (per reviews) annoying to get at. Has a hip belt which is nice, but harness system still seems a little anemic for a 45L bag, would love to at least see load lifters on the backpack straps. You can even stow them! Love the fabric and color options. Honestly with a normal water bottle holder, and a laptop compartment that zipped all the way open with an iPad holder this would be a compelling bag. 45L just feels slightly too big for me, would prefer in the realm of 40L. Also eye-wateringly expensive though at $430.

✨ Pakt

Love the creativity and thought put into this bag, but for me a bit too organization heavy, and as a result also a hefty boy at 4.4 lb for the 45L version, or 4.1 lb for the 35L version. Also very expensive, and the water bottle holder looks dubious. I like that the bag is expandable or has room for a day bag, which would be nice for the 35L version to get a bit more space. Wish it had stowable backpack straps.

Would love to see them produce a slightly more minimal version that’s a bit cheaper, and lighter while still retaining the half-and-half main compartment opening where you can put packing cubes on either side.

Heimplanet Transit Line Travel Pack

34L, okay weight at 3.6 lb. Doesn’t open fully clamshell, only about 2/3 of the way down if you want to open it “normally”, but if you remove the divider between the laptop compartment and main compartment it zips all the way, but then it’s one big compartment shared with the laptop, and the packing part is on the floppy side of the bag.

Topo Designs 40L

I like that the backpack straps are nicely stowable. No iPad holder in laptop compartment, which seems small overall and on the side. Has a tech compartment unfortunately, but I like that the inside is just a big bucket. Water bottle holder is external but looks quite tiny.

Thule Aion

I like this one a fair bit, 40L and a svelte 3.2 lb. I don’t love the exterior material (waxed canvas), and wish they went with something a bit more… normal? It looks like it breaks in weirdly per YouTube reviews. Love how it just has one massive compartment that opens horizontally, but I wish that the compartment on the “ceiling” of the main compartment didn’t have its own volume, which it appears to which can take away from the main “bucket”. Good water bottle holder. Not in love with the horizontal laptop compartment, but at least it has room for an iPad. If it was a fully zip-open compartment I could put a day bag in there too which would be nice, but as-is not sure where I’d put that. Has a nice small admin compartment/pocket thing at the top. Grab handles look pretty meh. No external compression straps which feels like a bit of a miss. No stowable straps.

⭐️ Thule Landmark

40L, 3.2 lb, nice job Thule (same as Aion)! Nicer material than the Aion, but the weird helmet thing at the top is certainly a visual choice, and Pack Hacker still didn’t really find the material that durable. Stowable straps, okay harness system. Big cavernous bucket for storing items, with no other organization which is nice. Laptop storage is on the side (ehh) versus zipping all the way down, but does at least have a place for an iPad. I think a redo of this bag with better materials, getting rid of the funny helmet, and making a proper laptop compartment would make it pretty darn compelling.

REI Rucksafe 40

Pretty impressive bag. 40L, under $200, and 2.85 lb. Has an external water bottle holder. No padded laptop compartment is really meh though, so is the lack of iPad storage. Really don’t like that it zippers all the way open to the extent that the interior would only have 3 walls and stuff then spills out the top, and it also doesn’t zip all the way to the bottom of the bag. No stowable backpack straps.

⭐️ TomToc Navigator 40L

40L, 2.65 lb, and $80 is kinda bonkers. That price is low enough that it’s almost concerning that the construction must be less well-made than other bags, but maybe TomToc just has some magic. OneBagTravels did call the material “mid tier”, which is expected for the price, but dang it makes me wonder what this bag could be like with X-Pac or something fancy. OneBagTravels also with the ol’ packing peanut test managed to fit 35L in before overstuffing it too much, so it might not be 40L exactly. I kinda like the minimal boxy look of it. Water bottle pockets are external and seem okay but decent when combined with the compression straps to really lock it in. Speaking of, compression straps seem solid. Laptop compartment zips all the way open, and has an iPad spot, nice! Harness system seems pretty meh though, no load lifters, no hip belt, no stowable straps, which sucks. Big cavernous main bucket area though which I love, it has the Tom Bihn Techonaut style opening where the zippers are a horseshoe slightly inset from the sides, which allows it to keep its shape nicely when opened up and empty (has a bit of the Minaal situation though where it would be nicer if the inside was a lighter color for better visibility). I would rank this number 3 currently, but would be a firm number 1 if the materials were better, and the harness system was upgraded. Here’s a great review.

Kathmandu Litehaul 38

Hard to tell but looks like the newer bag moved the water bottle holder so it takes up room inside the bag, bleh. Side laptop compartment (eh), with no iPad storage. Nice compression straps. Stowable backpack straps with a great harness system in general. Love how cavernous it is with minimal organization (yay). No real place to stow a daybag, maybe the “ceiling” of the main compartment but the zipper looks a bit small.

Wandrd Prvke 41L

Not a lot of reviews on this one so hard to tell a bunch (most reviews are geared toward it as a camera bag), but looks like a nice bag. 41L (46 with rolltop extended), and a firmly “okay” 3.7 lb. I think I’d prefer to see a less complex version without a rolltop and without the inner division pocket thing in the main compartment. Water bottle holder looks good. Wish laptop compartment was separate so I could shove a day bag in there too but it does have a nice iPad holder. Doesn’t really advertise stowable straps but looks like you could sorta fish the straps underneath the luggage passthrough and it would organize it a bit?

✨ Deuter AViANT Access 38

Great harness system, fully stowable with hip belt and load lifters. Only concern is that it seems really big for a 38L pack, at 22" × 13.25" × 11" (56 × 34 × 28cm), normally 9" is the depth requirement for most airlines in North America. But it weirdly doesn’t seem super thick, maybe that’s just if you over pack it? 3.4 lb is a pretty good weight too. Good compression straps. Side laptop compartment is kinda meh, with no iPad compartment. There’s a weird lip at the top of the bag to prevent rain/theft, and it makes opening the zipper to the main compartment a bit annoying per reviews. Just a big ol’ simple bucket to store things in, which I love! No water bottle holder gets a resounding “boooo”, though.

Timbuk2 Impulse

Love how this looks, love how it’s just a big cavernous compartment. 45L is impressive, 3.7 lb is okay. Side laptop compartment is okay, no iPad storage though. But no external water bottle holder, straight to jail. Stowable straps though!

Timbuk2 Wingman

Also no external water bottle holder, come on Timbuk2! 38L, but a hefty 4 lb. Stowable backpack straps! Side laptop storage, no iPad storage. Love the cavernous inside. This bag confuses me, seems like a heavier version of their Impulse that holds less?

⭐️ Dakine Split Adventure 38L

Confusing one because there’s different versions of this seemingly? From the one I saw, 38L, great size, and at an impressive 2.8 lb. Also love that it looks quite a bit like a backpack so it’s kinda “stealthy” versus some that look like a suitcase strapped to your back. As the name implies, it splits open horizontally into two compartments, the right side has a mesh cover, the left side has two mesh covers as it’s kinda split in two. That’s pretty nice, you can split your packing cubes to either side without much organization being imposed upon you. Wish the interior compression straps were removable though, I find those always just get in the way for me personally. Good water bottle holders, but it seems like a newer version might have got rid of them for side handles? That would be lame, as both are totally possible to have and both are very handy. No lockable zippers is kinda unfortunate. Stowable backpack straps with load lifters, but even though there appears to be a place to hide a hip belt, I don’t see one nor anywhere you could attach one. Laptop compartment opens all the way. Not a ton of reviews on this one but here’s a good one.

Goruck

Totally get why people love this, very iconic design, looks super well built. Just not my style visually, a bit too tactical, and they’re pretty hefty in weight (4.5 lb for the 40L).

Waterfield X Air

Pretty decent weight at 3.6 lb, with a 40L capacity. Water bottle holder looks a little concerning (Aer-TP3-like). Love the yellow interior, but don’t love the inclusion of the front admin compartment personally. Love that it opens horizontally like a suitcase rather than vertically, both are great but horizontal just feels even nicer. Overall not that many reviews of this bag so hard to tell a bunch.

North Face Basecamp 35L

Love the look, but really wish North Face toned down their branding. 3.5 lb and 35L is pretty decent, but the harness system seems kinda meh, no stowable straps, no hip belt. Admin compartment seems to take up a decent amount of volume. Laptop compartment doesn’t seem to have an iPad compartment. Love how it’s just one big compartment. Honestly would be a pretty great bag if it was a hair bigger, had a hip belt, and the laptop compartment opened all the way. Great price too.

✨ North Face Router 40

2.9 lb, nice! Water bottle pockets don’t seem super well reviewed (they’re very big without much stretchiness so lots of water bottles will just fall out). Love the minimal front pocket. Wish it had stowable straps. Compression straps seem awesome. Laptop compartment opens pretty wide, not all the way down, but could probably shove a day bag in there easily, also has room for an iPad. Main compartment doesn’t open all the way which is really unfortunate. I’m almost doubtful it holds a full 40L somehow, wish a YouTuber would do a packing peanut test.

Linus Tech Tips Backpack

Not really a true travel backpack at only 26L, seems more geared as a personal item and seems great at that. Mostly including it here to preempt recommendations for it as a travel bag.

Nomatic Travel Bag

Aesthetics kinda don’t do it for me personally, looks a bit like a cooler which concerns me functionally too as the “hardshell” looking bags are typically the first that airline employees target when force checking bags. Good weight at 3.4 lb though at 40L capacity. No external water bottle holder.

Alpaka Elements Travel Backpack

Kinda seems like an Aer Travel Pack 3 style (even similar price) but slightly lighter (3.5lb versus 3.9lb) and with a better water bottle holder. Wish it ditched the admin compartment and then its 35L size would be pretty compelling. Looks weirdly tall though, I’d add an extra inch to the width, get rid of the admin compartment, and you’d be close to 40L and a hair lighter which would make for an awesome bag. I like that the laptop compartment opens pretty wide, but would be even better if it opened all the way to the bottom.

Peak Design 45L

4.5 lb make it a hefty one (the heaviest on this list?), makes sense given that it’s 45L which is a bit more than I’d want to gamble with on flights. Lots of great touches though, and dang do I love Peak Design’s packing cubes and Peak Design stuff in general, so I so wanted to love this. Probably the most innovative and simple way to hide the backpack straps too, since you can just quickly slide them under the back padding. Wish they did a 40L bag and made it lighter. Just too heavy.

✨ Cotopaxi Allpa 35

3.5 lb, 35L. 42L version also available, and is 4.2 lb. Neither are great weight:capacity ratios, but not terrible. Some organization in the internal compartment, but not so much that it’s forced upon you, I think I could make it work. No big admin compartment either, just a small pouch at the top with some organization, but it’s maybe a bit too big. No external water bottle storage, and only side laptop storage but it does have an iPad compartment. Stowable shoulder straps is nice. Also just love their logo. A bit lighter and a better laptop compartment (zipped open all the way), with proper water bottle storage, and this would be really compelling.

✨ Bellroy Transit Backpack Plus

No external water bottle pocket, straight to jail. Honestly would be a pretty compelling bag if not though, has just one big bucket and 38L. 3.3 lb is impressive. Can’t stow straps either. Doesn’t look like any iPad storage available.

Fjallraven Travel Pack

40L, 3.6 lb, not too heavy! Don’t really like the design visually, and I normally quite like Fjallraven stuff.

✨ Decathlon Forclaz Travel 500

40L, 2.9 lb, well done! Very inexpensive too at about $100, that’s inexpensive enough that I’d honestly start to worry about material choices. Good water bottle holders, interior seems well thought out with some mesh organization but it’s very loosey goosey in a nice way, so you’re not stuck to their organizational system. Nice compression straps. Not a lot of reviews on this one though. No stowable straps from what I can tell, and side laptop compartment with no iPad storage. I like the look of this one visually.

⭐️ Eagle Creek Tour Travel Pack

40L, 2.8 lb (nice!!). Stowable straps (similar to Osprey where it zips, but you can separately stow the hip straps). Nice compression straps. Opens horizontally into a big ol’ bucket, love the water bottle holder. Don’t love how dark the interior is, don’t love how the ceiling of the main compartment seems to have its own volume which takes away from the rest of the main compartment (gimme just a big ol’ bucket), don’t love the compression straps in the interior not being removable (I never use those and they just get in the way), and don’t love the laptop compartment which feels like a bit of an afterthought (no lockable zipper there either even), rain cover seems pretty bulky when stored and doesn’t seem fully removable. But those last things are nitpicks, I think they did a great job with this bag. Pretty great price at around $180 too.

✨ ULA Dragonfly

Holy crap, 1.5 lb. Little on the small side at 30L though for the main interior area per tests like OneBagTravels, wish it was a smidge bigger. Really impressive looking bag given the weight, would love to see a 35-40L version of this bag.

⭐️ Patagonia Black Hole Mini MLC Travel Pack

Well that’s a mouthful of a name! Seems to be just a massive pit that holds a full 30L which is awesome. Looks like an awesome water bottle holder. Don’t love that it has a mesh covering over the interior, so you have to unzip two things to get to it, or leave a thing just in perpetual flapping mode. No load lifters on the back though is kind of a bummer, but it does allow you to hide the backpack straps. Laptop compartment area also zips fully open and has a small iPad area. Wish it had better compression straps though.

2.8 lb makes it even lighter than my Osprey Farpoint, and it even seems to have more side structure for easily packing things in.

If this one was offered in a 35L or a 40L (the 45L is slightly too big and exceeds a lot of carry-on size limits for airlines I use) it’d basically be perfect. I would rank this number 2.

Conclusion

I basically want a combination of the Tortuga Lite, Patagonia, TomToc, and Minaal. I saw a post on Reddit the other day where someone made their own really cool bag from scratch, while that’s undoubtedly an incredible difficult task that kinda sounds fun, maybe I’ll slowly try to learn that!

If you have a bag recommendation that you think I might like and isn’t on this list hit me up on Twitter, Mastodon, or Threads!

A free, 3D printable Meta Quest 3 stand

Mon, 22 Apr 2024 10:47:15 -0300

People were really kind and seemed to enjoy my 3D printable Apple Vision Pro stand, a stand I designed in Fusion 360 with the goal of being visually appealing and compact as it stored the headset vertically so it wouldn’t take up too much space on your desk.

Turns out there were quite a few folks requesting a similar style stand for their Meta Quest 3 so this weekend I set aside a bit of time to design such a variation, and I’m really happy with how it came out.

Download link. It’s completely free to download, and consider giving it a boost by clicking the little purple rocket! It’s like when YouTubers ask you for a like, except in this case boosts give me a small credit toward a 3D printing accessory I’ve had my eyes on.

Changes versus Vision Pro stand

The Meta Quest 3 has quite a few differences versus the Vision Pro so I redesigned the stand in some significant ways to better match the headset:

Spots for docking your controllers in the base. This both acts as a counterweight as the stand no longer has a need for a battery slot like the Vision Pro stand, and serves as a handy place to set your controllers. Set them down and they settle into the carved out grooves very satisfyingly
Top “pringle” that the headset rests on is slightly tweaked in width and height/amplitude to better nestle the Quest 3
So as to easily differentiate it form the Vision Pro stand if you have both side by side, I added a subtle design on the top pringle mimicking the Meta Quest 3’s front sensor array. Fun fact: it’s the exact same size and spacing!
Moved dowel/rod more toward center of stand, which allows for better compatibility with the Quest’s headband style
Removed cable organizer as there are no cables to organize!

As before, you can use any kind of 3/4" (18.5mm) dowel to add a splash of customizability, from walnut to maple to copper to steel, or the download also just includes a 3D printable dowel.

Hope you enjoy it! It’s a lot of fun learning Fusion 360, haha. The base’s size is unchanged from the Vision Pro’s and the pringle is very similar, so if you’re fortunate enough to have both a Vision Pro and Quest 3 both stands should look very nice next to each other.

Qi2 is kinda underwhelming

Sat, 20 Apr 2024 15:46:42 -0300

Using MagSafe for portable battery packs has so many niceties versus Qi1:

Increased communication with the device, allowing for better efficiency due to better thermal management and charging
Easily view the charge percentage of the external battery when first attaching it, and at any other point right from the OS
Reverse-wireless-charging, so if you charge your phone while the pack is attached, the phone will charge up first and then send energy to the battery pack
Magnets for better charging reliability (no vibrating off the small charging zone and waking up to a dead phone) and better efficiency (induction points are perfectly lined up), though this point is almost always mimicked in Qi1 battery packs

Qi2 was supposed to be a glass of ice water to those in hell of Qi1, and I was hyped! Apple stopped making MagSafe battery packs themselves, and their old pack used Lightning instead of the newer USB-C, so I was excited to see third-parties bring MagSafe into the golden age of USB-C.

The reality though is… kinda lame right now with most of those benefits not being a thing?

Precursor: most “MagSafe” batteries are just Qi1

So many magnetic battery pack makers say “MagSafe compatible” on the product page, which leads people to think they’re getting the more efficient charging of MagSafe as well as the extra functionality.

The word “compatible” is doing a lot of heavy lifting there, just indicating that the battery packs have a magnet in them and using just regular Qi1 charging. None of the actual MagSafe benefits are available. This means they’re kinda “dumb” and don’t communicate well with the host device, leading to hotter devices (and thus faster battery degradation) and lower efficiency due to energy loss as heat.

“Just use cables!”

Cables are much more efficient than wireless charging, so this sounds like a great idea until you try it, and going through an airport with cables dangling and potentially snagging on things is so, so much less convenient than just having a slightly thicker phone. I’d take a dip in efficiency for a massive increase in convenience, but if you can deal with cable charging while running around, I tip my hat to you.

That being said, the battery cases of yesteryear were a nice middle ground.

The only Qi2 battery pack is kinda lacking?

Despite being announced last year, there’s still like… only one manufacturer offering Qi2 battery packs: Anker. The rest are still “coming soon”.

Outside of only being offered in bulky sizes, Anker’s offerings seem to miss some of the biggest niceties of MagSafe, presumably through no fault of their own.

Firstly, Qi2 battery packs seemingly don’t even support OS level battery status! I can only assume this is an omission on Apple’s part rather than Anker’s, and is hopefully fixed in the future, but that was one of the aspects of Qi2 I was looking forward to the most. All you get is a slightly larger indicator of the phone’s battery level, but not the pack’s. Being able to easily see the percentage of your battery pack when using the phone and connecting it is super handy.

A minor one, but it also seems to get slightly warmer than Apple’s offering. Qi2 is supposed to also offer 15W of output whereas Apple’s battery was 7.5W, but Max Tech did a thorough review versus Apple’s old pack, and while it’s worth a watch, the tl;dw is that it seems to warm up quickly and slow down pretty considerably as a result (and be no faster than 7.5W).

Lastly, there’s no reverse wireless charging like Apple’s MagSafe pack has, so if you’re charging your iPhone over USB-C and have the pack attached, the pack won’t charge. You’d have to plug the pack itself in, which would transfer more heat to the iPhone rather than the other way around with MagSafe (I’d rather have the cheap battery pack get hotter, rather than the expensive iPhone).

Why Apple’s old pack is actually good

Credit: Apple

Apple’s offering on paper seems pretty great: smaller than the competitors, and integrates perfectly with iOS, meaning you get more intelligent charging and power delivery (and a cooler device), and you can see the status of the battery right in the operating system.

Two issues though: price/availability (at almost twice the competitors’), and the Lightning connector (in our beautiful new USB-C world, I do not want to be carrying a Lightning cable around anymore).

The first one’s indeed tricky. As Apple’s is discontinued, they’re hard to find, and there’s a lot of counterfeit ones online and in local classifieds, so be careful.

For the Lightning issue, the iPhone supports reverse wireless charging (Qi2 does not on iPhones as of April 2024), so if you plug in your USB-C iPhone with the pack still attached, it’ll charge up the battery after it’s done charging up the phone! No Lightning cable needed. In fact, even the new Qi2 batteries don’t support this, they only support plugging in the battery itself which charges the iPhone, which sounds fine, but the battery is the one inductively charging the iPhone, so the iPhone bears the brunt of the heat, rather than the other way around, which is less than ideal for battery health.

Lastly, Apple’s is much thinner than the competitor’s offerings. Which is fine, I don’t need to double my battery life, I just want to extend it when I know I might otherwise be cutting it close by the end of the day.

(Though one bonus for Qi2 battery packs is that they do support wired charging between the battery and iPhone though, unlike Apple’s, which would be a handy feature for charging faster in a pinch, but not a deal-breaker for me.)

“Apple’s battery capacity is so small”

There were some strange musings at the beginning complaining that Apple’s is only 1,500 mAh, while everyone else is 5,000 mAh, and that’s a perfect indication of why mAh is such a terrible unit for measuring batteries (the recent Vision Pro battery size story being another one). Battery capacity is a function of Amp-hours and crucially Voltage (multiply them together to get Watt-hours, an actual measurement of capacity), Apple’s battery uses twice the Voltage (7.6 V versus 3.7 V), so the actual capacities are 11 Watt-hours for Apple’s and 18.5 Watt-hours for others.

Further, if you take the smallest previewed Qi2 case: Belkin’s 5,000 mAh option (available in Australia), it’s 17mm thick, where Apple’s is only 11mm.

So Apple’s battery capacity being 40% smaller than Belkin’s (11 versus 18.5) kinda makes sense when you see that it’s because it’s 35% thinner.

End notes

All in all, maybe someone like Belkin will release their Qi2 and it’ll be faster, more energy dense, less hot than Apple’s, and have USB-C, but even then at least as of April 2024 it will still lack the super handy OS-level battery status, as well as reverse-charging. Maybe Apple will add those in iOS 18 and will be well in the world, or maybe Apple will surprise us all and release a new, USB-C MagSafe battery pack.

(Also, my one criticism of all battery packs is they and the iPhone really need a magnet connection near the bottom too, right now the top-half is secure but the bottom half can just swing around. That part kinda makes me miss old school battery cases.)

Waterfield's weirdly compact Apple Vision Pro Case

Tue, 02 Apr 2024 12:56:46 -0300

Disclosure: Waterfield sent this in exchange for a review. Yeah, that probably colors something on a deep-down, subconscious level, but I won’t say anything that I don’t truly believe.

Unlike a phone or laptop, the Vision Pro is one of those products that is particularly tricky to take around without a case. I’ve got around this by wrapping it in a hoodie and throwing it in my backpack, but I was looking for a more… tidy solution longterm.

Apple’s own case was an obvious option, but the size kinda scared me. I like packing pretty light for trips, and only ever bring one bag, so the thought of half the bag being taken up by a Vision Pro case wasn’t the most alluring, so a compact size was pretty near the top of my list, so when Waterfield announced their case offering and toted its size my ears immediately perked up.

I’ve traveled a bit with it now, and I’ve really come to like it. Here’s my thoughts, plus some questions from folks on Twitter and Mastodon.

Design/build quality

The design is reminiscent of a really well-made lunchbox. It’s sturdy, and the outside feels like that ballistic nylon material that a good backpack is made out of, while the inside is a really soft fleece. The inside houses a second (also fleece-wrapped) case which can house all the Vision Pro accessories and even has individual slots for ZEISS lenses if you have those. In mine I put a charging brick, the polishing cloth, and the headband (note on that below), and spare contact lenses in the ZEISS slots. There’s a separate spot on the “ceiling” of the inner case for the Vision Pro’s external battery.

Everything just fits super snuggly and thoughtfully, which is kinda what I like most about it. So many Vision Pro cases on the market are just versions for other headsets that happen to fit the Vision Pro to different levels of success, and while that’s obviously totally fine, maybe it’s because the Vision Pro was so expensive, but there’s something really nice feeling about a case designed specifically around it. It’s like using a baseball mitt made just for your hand versus borrowing your friend’s: both are cool, one just makes you go oooooo.

(Though the battery fits so snuggly that it’s a bit tricky to get in when you wrap the cable around it. Instead, wrap the cable around your fingers, slide the battery in, and then slide the organized cable on top of the battery.)

The zippers feel great, ~~not YKK~~ (oops, I’ve been told they are YKK, that makes sense given the quality, they just have nice ‘Waterfield’ branding on them) but metal and have a water-resistant coating which I always like to see. It has a grab handle on top, and attachments for shoulder straps that I likely won’t use. Same with the top, it has a little zipper pocket that I’m not sure I’d use beyond the AirTag pocket in it, but you could put something thin up there (like another cord, or a small external battery, or maybe a very small foldable external keyboard), and even if you don’t use it the pocket is pretty flat so you don’t lose any room to it.

I do wish they had more colorways. I’m on Apple’s train and not a big fan of wrapping my devices in dead animals (though Apple’s FineWoven solution there seems to have missed the mark, but Aptera has some really cool plant-based biodegradable leathers for their car), and wish Waterfield had options outside of black and blue for non-leather (that black and white stormtrooper style one looks so cool). That being said the photographs of the blue on their website almost don’t do it justice, it’s a really nice navy in real life with just the right amount of color to be a bit fun. But I still want stormtrooper!

Compactness

Some items you may have around for scale

It’s really compact, there’s honestly not really any room to possibly shrink it further. It’s not tiny per se, but going off numbers from each website, Apple’s Vision Pro case is about 10.9 Liters in volume (0.38 cubic feet), and the Waterfield case is 5.0 Liters (0.18 cubic feet), which is a substantial difference. If you throw it in a 20 Liter everyday carry backpack, you’ve gone from it taking 55% of the interior space to just 25%.

A big part of how they accomplish this is by having you take the headband off which saves a ton of room length-wise versus storing it fully expanded. This is something I was hoping someone would do well before this case was even announced, and it’s plain to see how much room it saves.

The cutely named “Hat Box” that zippers open to add accessories

My idea was just to fold the fabric of the headband in a bit, and when I saw Waterfield required you to actually disconnect the headband I was kind of disappointed because that sounds like a pain. But in all honesty, if you kept the band connected, you would have to bend it more on the side part than I would be personally comfortable to get it as compact (see below, though), and if you only folded in the back part (and not the sides) it would add a decent amount more length to the case. Still a bunch of space savings to be sure, but in my opinion unless you’re putting it in the case every night the compactness this creates is worth the minor inconvenience of disconnecting the headband.

Protectiveness

I was somewhat worried where it’s not an actual hardshell style case like Apple’s or others that it would be more like a tech pouch and not have much protectiveness, but honestly it’s pretty darn sturdy. That’s hard to articulate, but as an example if I put a 20 lb dumbbell on top of it with nothing inside, you can see it doesn’t deform at all. (This does not mean it will survive a 20 lb dumbbell actually dropping on it, to be clear.)

It definitely won’t be as protective as a hardcase, but it’s still pretty darn protective. Mine will always be stored in my backpack but if it were to take a small fall alone I personally wouldn’t worry.

Questions

I asked on Twitter and Mastodon if anyone had any questions about it, and there were some great ones that I thought I’d answer here.

Do you still need Apple’s front cover?

The inside is soft felt so I personally don’t bother, but it does still fit if you’re so inclined.

Do you HAVE to take the headband off to store it?

Technically no, it fits with the band still attached, but to me it’s like that scene in Cinderella when all the stepsisters try to fit in the glass slipper and are shoving their foot in to just barely make it fit. In other words, it seems to put a bit more pressure on the side of the headband than I’d like, but hey, if you want to risk it the $99 to replace the Solo Knit band if I’m right is one of the more affordable Vision Pro accessories. (All this also applies to the Dual Loop band, too.)

Could a cat sleep on it?

If a 20 lb dumbbell doesn’t deform it I think most cats could sleep on it fine, the issue is that it’s kinda small so not the most comfy. My cats stick to sleeping on my backpacks.

Does the battery fit in it? Could it hit the glass?

Yeah, there’s a proper space right above the Vision Pro. If you put it in the intended way (front of Vision Pro in toward the non-zippered edge) the Vision Pro’s front will be toward the front of the case, and the battery in the ceiling will be toward the back of the case, sitting on the storage accessory, so no chance of contact.

Can the battery stay plugged in in the case?

Yeah! I find the standby life of the Vision Pro isn’t the best, and it sometimes gets warm, so I personally would unplug it for travel, but you definitely don’t have to.

Does a Mac mini fit inside?

Nope, just slightly more compact. That would have been cool though.

Can you use it like a lunchbox?

Honestly felt is a pretty effective thermal insulator so probably, but I’d worry about condensation build up.

Ease of zipping/speed of use

I find water-resistant zippers always have a bit more friction than their normal counterparts, so it’s a bit of a two-handed operation to zip open/closed. But I feel like if I was on an airplane, it’d be pretty quick to disconnect the headband, throw it on the pouch, throw in the Vision Pro, zip it up and leave. Not as fast as yeeting your Vision Pro into a backpack if there was like an emergency, but pretty reasonable if you have a second.

What does it carry?

It can carry the Vision Pro, both headbands, polishing cloth, a wall brick, a USB-C cable, ZEISS inserts (or contact lenses), an AirTag, and something small in the top pocket. Here’s what I have in mine.

Conclusion

At $159 for my non-leather version, it’s not cheap (though it’s cheaper than Apple’s own case), but I keep coming back to it reminding me of a really nice backpack. You can go on Amazon and find an obscure brand backpack for super cheap that will absolutely get the job done at the cost of long term confidence, or, if you want to treat yourself you can buy a really quality backpack from a trusted brand with a bunch of delightful touches that make you smile when you use it even years later. Some people get weirdly into nice backpacks, I’m unfortunately one of them.

So all in all, it’s a great example of how something seemingly simple can be elevated by thoughtful design and quality materials.

Non-affiliate link to the Waterfield case

Recreating Apple's beautiful visionOS search bar

Sun, 24 Mar 2024 15:16:12 -0300

Many of Apple’s own visionOS apps, like Music, Safari, and Apple TV, have a handy search bar front and center on the window so you can easily search through your content. Oddly, as of visionOS 1.1, replicating this visually as a developer using SwiftUI or UIKit is not particularly easy due to lack of a direct API, but it’s still totally possible, so let’s explore how.

First let’s get a few ideas out of the way to maybe save you some time.

On the SwiftUI side .searchable() in is an obvious API to try, but even with the placement API, there’s no way to put in the center (by default it’s to the far right, and you can either put it to the far left, or under the navigation bar, by passing different values). With toolbarRole, similar deal, values like .browser will put it to the left instead, but not middle. ToolbarItem(placement: .principal) meets a similar fate, as in visionOS, the principal position is to the left, not center.

Default SwiftUI searchable() position

In UIKit, the situation is similar, where navigationItem.titleView is to the left, not center, on visionOS, and I was unable to find any other APIs that worked here.

You could technically recreate navigation bar UIView/View from scratch, but navigation bars on visionOS have a nice progressive blur background that wouldn’t be fun to recreate, not to mention all the other niceties they have.

All this to say, it’s totally possible there’s a clear API to do it, but I’ve dug around and poked a bunch of different people so it’s well hidden if it does exist! I’m assumning Apple’s using an internal-only API, or at least a custom UI here.

Step 1: Creating a search bar

SwiftUI doesn’t directly have the concept of a search bar view unfortunately, just the .searchable modifier that only takes a few arguments, so… you know…

We’ll create a SwiftUI interface into UIKit’s UISearchBar that allows us to store the typed text and respond when the user hits enter/return.

struct SearchBar: UIViewRepresentable {
    @Binding var text: String
    var onSearchButtonClicked: () -> Void

    func makeUIView(context: Context) -> UISearchBar {
        let searchBar = UISearchBar()
        searchBar.delegate = context.coordinator
        return searchBar
    }

    func updateUIView(_ uiView: UISearchBar, context: Context) {
        uiView.text = text
    }

    func makeCoordinator() -> Coordinator { SearchBarCoordinator(self) }
}

class SearchBarCoordinator: NSObject, UISearchBarDelegate {
    var parent: SearchBar

    init(_ searchBar: SearchBar) {
        self.parent = searchBar
    }

    func searchBar(_ searchBar: UISearchBar, textDidChange searchText: String) {
        parent.text = searchText
    }

    func searchBarSearchButtonClicked(_ searchBar: UISearchBar) {
        parent.onSearchButtonClicked()
        searchBar.resignFirstResponder()
    }
}

Now we can easily use it as so:

struct ContentView: View {
    @State private var searchText = ""

    var body: some View {
        SearchBar(text: $searchText) {
            print("User hit return")
        }
    }
}

Hmm, looks a little off.

Step 2: Positioning

Cool, we have a search bar, how do we position it? Again, tons of ways to do this. Perhaps the “most correct” way would be to completely wrap a UINavigationBar or UIToolbar, add a UISearchBar as a subview and then move it around in layoutSubviews relative to the other bar button items, titles, and whatnot. But that’s probably overkill, and we want a simple SwiftUI solution, so (as the great Drew Olbrick suggested) we can just overlay it on top of our NavigationStack.

NavigationStack {
    Text("Welcome to my cool view")
        .navigationTitle("Search")
    }
}
.overlay(alignment: .top) {
    SearchBar(text: $searchText) {
        print("User hit return")
    }
}

This is actually great, as we get all the niceties of the normal SwiftUI APIs, and the system even appropriately spaces our search bar from the top of the window. Only issue is an obvious one, the width is all wrong. Studying how Apple does it, in the Music and Apple TV app the search bar just stays a stationary width as the window can’t get too narrow, but let’s modify ours slightly a bit so if it does get too narrow, our search bar never takes up more than half the window’s width (Apple’s probably does something similar, but more elegantly), by wrapping things in a GeometryReader. The height is fine to stay as-is.

struct SearchBar: View {
    @Binding var text: String
    var onSearchButtonClicked: () -> Void
    
    var body: some View {
        GeometryReader { proxy in
            InternalSearchBar(text: $text, onSearchButtonClicked: onSearchButtonClicked)
                .frame(width: min(500.0, proxy.size.width / 2.0))
                .frame(maxWidth: .infinity, alignment: .center)
        }
    }
}

struct InternalSearchBar: UIViewRepresentable {
    @Binding var text: String
    var onSearchButtonClicked: () -> Void

    func makeUIView(context: Context) -> UISearchBar {
        let searchBar = UISearchBar()
        searchBar.delegate = context.coordinator
        return searchBar
    }

    func updateUIView(_ uiView: UISearchBar, context: Context) {
        uiView.text = text
    }

    func makeCoordinator() -> SearchBarCoordinator { SearchBarCoordinator(self) }
}

class SearchBarCoordinator: NSObject, UISearchBarDelegate {
    var parent: InternalSearchBar

    init(_ searchBar: InternalSearchBar) {
        self.parent = searchBar
    }

    func searchBar(_ searchBar: UISearchBar, textDidChange searchText: String) {
        parent.text = searchText
    }

    func searchBarSearchButtonClicked(_ searchBar: UISearchBar) {
        parent.onSearchButtonClicked()
        searchBar.resignFirstResponder()
    }
}

Which results in…

Bam.

Step 3: Corner radius

Our corner radius looks different than Apple’s at the top of the article!

One oddity I noticed is different Apple apps on visionOS use different corner radii despite being that same, front and center search bar. (Rounded rectangle: Apple TV, Photos, App Store; circular: Music, Safari) Presumably this is just an oversight, but after poking some Apple folks it seems like the rounded option is the correct one in this case, and I too prefer the look of that, so let’s go with that one.

One issue… The default is a rounded rectangle, not circular/capsule, and API to directly change this (as far as I can tell) is private API. But cornerRadius is just a public API on CALayer, so we just have to find the correct layer(s) and tweak them so they’re circular instead. We can do this by subclassing UISearchBar and monitoring its subviews for any changes to their layer’s corner radius, and changing those layers to our own circular corner radius.

class CircularSearchBar: UISearchBar {
    private var didObserveSubviews = false
    private let desiredCornerRadius = 22.0
    private var observedLayers = NSHashTable<CALayer>.weakObjects()
    
    deinit {
        // We need to manually track and remove CALayers we add observers for, the OS seemingly does not handle this properly for us, perhaps because we're adding observers for sublayers as well and there's timing issues with deinitialization?
        // (Also don't store strong references to layers or we can introduce reference cycles)
        for object in observedLayers.objectEnumerator() {
            guard let layer = object as? CALayer else { continue }
            layer.removeObserver(self, forKeyPath: "cornerRadius")
        }
    }
    
    override func willMove(toWindow newWindow: UIWindow?) {
        super.willMove(toWindow: newWindow)
     
        // Adding to window
        guard !didObserveSubviews else { return }
        didObserveSubviews = true
        observeSubviews(self)
    }
        
    func observeSubviews(_ view: UIView) {
        if !observedLayers.contains(view.layer) {
            view.layer.addObserver(self, forKeyPath: "cornerRadius", options: [.new], context: nil)
            observedLayers.add(view.layer)
        }
        
        view.subviews.forEach { observeSubviews($0) }
    }
        
    override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
        guard keyPath == "cornerRadius" else {
            super.observeValue(forKeyPath: keyPath, of: object, change: change, context: context)
            return
        }
        
        guard let layer = object as? CALayer else { return }
        guard layer.cornerRadius != desiredCornerRadius else { return }
        
        layer.cornerRadius = desiredCornerRadius
    }
}

Which gives us this beautiful, circular result once we replace UISearchBar with CircularSearchBar.

Step 4: Remove hairline

Nooo, what IS that?

Just when you think you’re done, you notice there’s a little hairline border underneath the search bar that looks kinda off in our context. This is also not easily addressable with an API, but we can find it ourselves and hide it. You’d think you’d just find a thin UIView and hide it, but Apple made this one nice and fun by making it a normal sized image view set to an image of a thin line.

Knowing that, we could find the image view and sets its image to nil, or hide it, but through something done behind the scenes those operations seem to be overwritten, however just setting the alpha to 0 also hides it perfectly.

private func hideImageViews(_ view: UIView) {
    if let imageView = view as? UIImageView {
        imageView.alpha = 0.0
    }
    
    view.subviews.forEach { hideImageViews($0) }
}

And add hideImageViews(self) to our willMove(toWindow:) method.

That's it! 🎉

With that, we’re done and we should have nice solution for a search bar that more closely mimics how visionOS shows prominent search bars, at least until Apple hopefully adds a more straightforward way to do this! (FB13696963)

Trials and tribulations of 360° video in Juno

Sun, 25 Feb 2024 21:53:34 -0400

In building Juno, a visionOS app for YouTube, a question that’s come up from users a few times is whether it supports 360° and 180° videos (for the unfamiliar, it’s an immersive video format that fully surrounds you). The short answer is no, it’s sort of a niche feature without much adoption, but for fun I wanted to take the weekend and see what I could come up with. Spoiler: it’s not really possible, but the why is kinda interesting, so I thought I’d write a post talking about it, and why it’s honestly not a big loss at this stage.

How do you even… show a 360° video?

It’s actually a lot easier than you might think. A 360° (or 180°) video isn’t some crazy format in some crazy shape, it’s just a regular, rectangular video file in appearance, but it’s been recorded and stored in that rectangle slightly warped, with the expectation that however you display it will unwarp it.

So how do you display it? Also pretty simply, you just create a hollow sphere, and you tell your graphical engine (in iOS’ case: RealityKit) to stretch the video over the inside of the sphere. Then you put the user at the center of that sphere (or half-sphere, in the case of 180° video), and bam, immersive video.

There’s always a catch

In RealityKit, you get shapes, and you get materials you can texture those shapes with. But you can’t just use anything as a texture, silly. Applying a texture to a complex 3D shape can be a pretty intensive thing to do, so RealityKit basically only wants images, or videos (a bit of an oversimplification but it holds for this example). You can’t, for instance, show a scrolling recipe list or a dynamic map of your city and stretch that over a cube. “Views” in SwiftUI and UIKit (labels, maps, lists, web views, buttons, etc.) are not able to be used as a material (yet?).

This is a big problem for us. If you don’t remember, while Juno obviously shows videos, it uses web views to accomplish this, as it’s the only way YouTube allows developers to show YouTube videos (otherwise you could, say, avoid viewing ads which YouTube doesn’t want), and I don’t want to annoy Google/YouTube.

Web views, while they show a video, are basically a portal into a video watching experience. You’re just able to see the video, you don’t have access to the underlying video directly, so you can’t apply it as a texture with RealityKit. So we can’t show it on a sphere, so we can’t do 360° video.

Unless…

Let’s get inventive

Do I get points for including Vision in an article about Vision Pro

Okay, so we only have access to the video through a web view. We can see the video though, so what if we just continue to use the web player, and as it plays for the user, we took snapshots of each video frame and painted those snapshots over the sphere that surrounds the user. Do it very rapidly, say, 24 times per second, and you effectively have 24 fps video. Like a flip book!

Well, easier said than done! The first big hurdle is that when you take a snapshot of a webview (WKWebView), everything renders into an image perfectly… except the playing video. I assume this is because the video is being hardware decoded in a way that is separate from how iOS performs the capture, so it’s absent. (It’s not because of DRM or anything like that, it also occurs just for local videos on my website.)

This is fixable though, with JavaScript we can draw the HTML video element into a separate canvas, and then snapshot the canvas instead.

const video = document.querySelector('video');
const canvas = document.createElement('canvas');

canvas.width = video.videoWidth;
canvas.height = video.videoHeight;

var ctx = canvas.getContext('2d');
ctx.drawImage(video, 0, 0, canvas.width, canvas.height);

video.style.display = 'none';
document.body.prepend(canvas);

Okay, now we have the video frame visible. How do we capture it? There’s a bunch of different tactics I tried for this, and I couldn’t quite get any of them to be fast enough to be able to simulate 24 FPS (in order to get 24 captured frames per second, each frame capture must be less than 42 ms). But let’s enumerate them from slowest to fastest in taking a snapshot of a 4K video frame (average of 10 runs).

CALayer render(in: CGContext)

Renders a CALayer into a CGImage.

UIGraphicsBeginImageContextWithOptions(webView.bounds.size, true, 0.0)

let context = UIGraphicsGetCurrentContext()!

webView.layer.render(in: context)

let image = UIGraphicsGetImageFromCurrentImageContext()

UIGraphicsEndImageContext()

⏱️ Time: 270 ms

Metal texture

(Code from Chris on StackOverflow)

extension UIView {
    func takeTextureSnapshot(device: MTLDevice) -> MTLTexture? {
        let width = Int(bounds.width)
        let height = Int(bounds.height)
        
        if let context = CGContext(data: nil, width: width, height: height,bitsPerComponent: 8, bytesPerRow: 0, space: CGColorSpaceCreateDeviceRGB(), bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue), let data = context.data {
            layer.render(in: context)
            
            let desc = MTLTextureDescriptor.texture2DDescriptor(pixelFormat: .rgba8Unorm, width: width, height: height, mipmapped: false)
            
            if let texture = device.makeTexture(descriptor: desc) {
                texture.replace(region: MTLRegionMake2D(0, 0, width, height), mipmapLevel: 0, withBytes: data, bytesPerRow: context.bytesPerRow)
                return texture
            }
        }
        
        return nil
    }
}

let texture = self.webView.takeTextureSnapshot(device: MTLCreateSystemDefaultDevice()!)

⏱️ Time: 250 ms (I really thought this would be faster, and maybe I’m doing something wrong, or perhaps Metal textures are hyper-efficient once created, but take a bit to create in the first place)

UIView drawHierarchy()

let rendererFormat = UIGraphicsImageRendererFormat.default()
rendererFormat.opaque = true

let renderer = UIGraphicsImageRenderer(size: webView.bounds.size, format: rendererFormat)

let image = renderer.image { context in
    webView.drawHierarchy(in: webView.bounds, afterScreenUpdates: false)
}

⏱️ Time: 150 ms

JavaScript transfer

What if we relied on JavaScript to do all the heavy lifting, and had the canvas write its contents into a base64 string, and then using WebKit messageHandlers, communicate that back to Swift?

const video = document.querySelector('video');
const canvas = document.createElement('canvas');

canvas.width = video.videoWidth;
canvas.height = video.videoHeight;

var ctx = canvas.getContext('2d');
ctx.drawImage(video, 0, 0, canvas.width, canvas.height);

video.style.display = 'none';
document.body.prepend(canvas);

// 🟢 New code
const imageData = canvas.toDataURL('image/jpeg'); 
webkit.messageHandlers.imageHandler.postMessage(imageData);

Then convert that to UIImage.

func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
    if message.name == "imageHandler", let dataURLString = message.body as? String {
        let image = convertToUIImage(dataURLString)
    }
}

private func convertToUIImage(_ dataURLString: String) -> UIImage {
    let dataURL = URL(string: dataURLString)!
    let data = try! Data(contentsOf: dataURL)
    return UIImage(data: data)!
}

⏱️ Time: 130 ms

WKWebView takeSnapshot()

webView.takeSnapshot(with: nil) { image, error in
    self.image = image
}

⏱️ Time: 70 ms

Test results

As you can see, the best of the best got to about 14 frames per second, which isn’t quite up to video playback level. Close, but not quite. I’m out of ideas.

There were some interesting suggestions to use the WebCodecs VideoFrame API, or an OffscreenCanvas, but maybe due to my lack of experience with JavaScript I couldn’t get them meaningfully faster than the above JavaScript code with a normal canvas.

If you have another idea, that you get working, I’d love to hear it.

Why not just get the direct video file then?

There’s two good answers to this question.

First, the obvious one, Google/YouTube doesn’t like this. If you get the direct video URL, you can circumvent ads, which they’re not a fan of. I want Juno to happily exist as an amazing visionOS experience for YouTube, and Google requests you do so through the web player, and I think I can build an awesome app with that so that’s fine by me. 360° video is a small feature and I don’t think it’s worth getting in trouble over.

Secondly, having access to the direct video still wouldn’t do you any good. Why? Codecs.

Battle of the codecs

Quick preamble. For years, pretty much all web video was H264. Easy. It’s a format that compresses video to a smaller file size while still keeping a good amount of detail. The act of uncompressing it is a little intensive (think, unzipping a big zip file), so computers have dedicated chips specifically built to do this mega fast. You can do it without these, purely in software, but it takes longer and consumes more power, so not ideal.

Time went on, videos got bigger, and the search for something that compresses video even better than H264 started (and without licensing fees). The creatively named H265 (aka HEVC) was born, and Apple uses it a bunch (it still has licensing fees, however). Google went in a different direction and developed VP9 and made it royalty-free, though there were still concerns around patents. These formats can produce video files that are half the size of H264 but with the same visual quality.

Apple added an efficient H265 hardware decoder to the iPhone 7 back in 2016, but to my knowledge VP9 decoding is done completely in software to this day and just relies on the raw power and efficiency of Apple’s CPUs.

Google wanted to use their own VP9 format, and for 4K videos and above, only VP9 is available, no H264.

Okay, and?

So if we want to play back a 4K YouTube video on our iOS device, we’re looking at a VP9 video plain and simple. The catch is, you cannot play VP9 videos on iOS unless you’re granted a special entitlement by Apple. The YouTube app has this special entitlement, called com.apple.developer.coremedia.allow-alternate-video-decoder-selection, and so does Safari (and presumably other large video companies like Twitch, Netflix, etc.)

But given that I cannot find any official documentation on that entitlement from Apple, safe to say it’s not an entitlement you or I are going to be able to get, so we cannot play back VP9 video, meaning we cannot play back 4K YouTube videos. Your guess is as good as mine why, maybe it’s very complex to implement if there’s indeed not a native hardware decoder, so Apple doesn’t like giving it out. So if you want 4K YouTube, you’re looking at either a web view or the YouTube app.

Given that no one could agree on a video format, everyone went back to the drawing board, formed a collective group called the Alliance for Open Media (has Google, Apple, Samsung, Netflix, etc.), and authored the AV1 codec, hopefully creating the one video format to rule them all, with no licensing fees and hopefully no patent issues.

Google uses this on YouTube, and Apple even added a hardware decoder for AV1 in their latest A17 and M3 chips. This means on my iPhone 15 Pro I can play back an AV1 video in iOS’ AVPlayer like butter.

Buuuuttttt, the Apple Vision Pro ships with an M2, which has no such hardware decoder.

Why it’s not a big loss

So the tl;dr so far is YouTube uses the VP9 codec for 4K YouTube, and unless you’re special, you can’t playback VP9 video directly, which we need to do to be able to project it onto a sphere. Why not just do 1080p video?

Because even 4K video looks bad in 360 degrees.

Wait, what? Yeah, 4K looks incredible on the big TV in front of you, but you have to remember for 360° video, that same resolution is completely surrounding you. At any given point, the area you’re looking at is a small subset of the full resolution! In other words, the Vision Pro’s resolution is 4K per eye, meaning any area you look can show a 4K image, and when you stretch a 4K video all around you, everywhere you look is not 4K. Almost like the Vision Pro’s resolution per eye drops enormously. If you’re familiar with the pixels per degree (PPD) measurement for VR headsets, 4K immersive video has a quite bad PPD measurement.

To test this further, I downloaded a 4K 360° video and projected it onto a sphere. The video is stretched from my feet to over my head. When I look straight, I’d say I’m looking at maybe 25% of the total height of the video. That means in a 4K video, which is 2,160 pixels tall, I can see maybe 25% of those pixels, or 540 pixels, so it looks a bit better than a 480p video but far from even 720p.

Quick attempted visualization, showing the area you look at with a 4K TV:

Versus the area you look at a 4K 360° video:

So in short, it might be 4K, but it’s stretched over a far more massive area than you’re used to when you think about 4K. Imagine your 4K TV is the size of your wall and you’re watching it from a foot away, it’d be immersive, but much less sharp. That means in reality it only looks a bit better than 480p or so.

So while it’d be cool to have 4K 360° video in Juno, I don’t think it looks good enough that it’s that compelling an experience.

Enter 8K

For the demo videos on the Apple Vision Pro (and the videos they show at the Apple Store), those are recorded in 8K, which gives you twice as many vertical and horizontal pixels to work with, and it levels up the experience a ton. Apple wasn’t flexing here, I’d say 8K is the minimum you want for a compelling, immersive video experience.

Apple's impressive 8K immersive video recording setup

And YouTube does have 8K, 360° videos! They’re rare since the hardware to record that isn’t cheap, but they are available. And pretty cool!

But if I was a betting man, I doubt that’s ever coming to the first generation Vision Pro.

Why? As mentioned 8K video on YouTube is only available in VP9 and AV1. The Vision Pro does not have a hardware AV1 decoder as it has an M2 not an M3, so it would have to do it in software. Testing on my M1 Pro MacBook Pro, which seems to Geekbench similarly to the Vision Pro, trying to playback 8K 360° video in Chrome is quite choppy and absolutely hammers my CPU. Apple’s chips may be powerful enough to grunt through 4K without a hardware decoder, but it doesn’t seem you can brute force 8K without a hardware decoder.

Maybe I’m wrong or missing something, or Google works with Apple and re-encodes their 360° videos in a specific, Vision-Pro-only H265 format, but I’m not too hopeful that this generation of the product, without an M3, will have 8K 360° YouTube playback. That admittedly is an area the Quest 3 has the Vision Pro beat, in that its Qualcomm chip has an AV1 decoder.

Does this mean the Vision Pro is a failure and we’ll never see 8K immersive video? Not at all, you could do it in a different codec, Apple has already shown it’s possible, I’m just not too hopeful for YouTube videos at this stage.

In Conclusion

As a developer, playing back the codec YouTube uses for its 4K video does not appear possible. It also doesn’t seem possible to snapshot frames fast enough to project it in realtime 3D. And even if it was, 4K video does not look too great unfortunately, ideally you want 8K, which seems even less likely.

But dang, it was a fun weekend learning and trying things. If you manage to figure out something that I was unable to, tell me on Mastodon or Twitter, and I’ll name the 3D Theater in Juno after you. 😛 In the meantime, I’m going to finish up Juno 1.2!

Additonal thanks to: Khaos Tian, Arthur Schiller, Drew Olbrich, Seb Vidal, Sanjeet Suhag, Eric Provencher, and others! ❤️

My little Apple Vision Pro stand

Mon, 19 Feb 2024 13:41:49 -0400

I want somewhere to put my Vision Pro when not in use. Many people use the original box, and there’s beautiful stands that exist out there, but I was looking for something more compact and vertical so it would take up less room on my desk.

So I opened Fusion 360 (which I am still very much learning), grabbed my calipers, and set out to design a little stand. There was interest when I showed the first version, so I set out to tidying it up a bit before making it available. Mainly the rod going up to the pringle part was a bit weak, so I ended up beefing up the diameter to 3/4". This also now means you can either 3D print the rod, or pick up a bespoke 3/4" rod of your own in a cool material, like walnut, maple, brass, steel, copper, etc. for pretty cheap from Home Depot or Amazon that is 215 mm in length. Then just use some superglue to bind them.

Anywho, I quite like the end result, it’s compact, seems pretty secure, holds the battery and has a spot for the cable and rubber feet. Mine is printed in marble PLA with a $3 walnut dowel. It’s designed around my 23W light seal, I admittedly don’t know how it works with other sizes.

You can download it on MakerWorld, I like them because I can send the designs to my Bambu printer really easily, and they give free filament with enough downloads, haha. You can also download just the top pringle if you want a lens shield for your bag or something. If you really like the design please give it a Boost on Makerworld too!

For a period of time, if you say the promo code “free free free for me me me” to your computer, the download will be available for free.

I’m unfortunately not assembling/selling this myself, but if you don’t have a 3D printer (I quite like my Bambu P1S, if you’re looking for a suggestion), lots of local libraries have 3D printers nowadays, or you can submit it to sites like PCBWay to have them make it for you. I don’t quite have the expertise/time to manufacture and sell this myself for folks without a 3D printer, but if you the reader would like to on Etsy or something, go for it! (Just maybe link credit back, and if you make a bunch of money donate some to your local animal shelter and I’d be stoked.)

Juno 1.1

Wed, 14 Feb 2024 16:22:25 -0400

If you’re new, Juno is a visionOS app for YouTube!

Juno’s initial launch blew my socks off. It was such a cool feeling to release an app on day one of the Apple Vision Pro’s launch, and having people be so excited about it and have such great feedback made it that much better. After coding like crazy all week to get it submitted, then driving 10 hours to New Hampshire from Canada, sitting down and reading all the comments in my hotel room made me really happy and even more excited to keep building onto the app for this cool new platform.

It was a little brutal though realizing the long drive back I had to finish first before I could get much work done though, but I made it home just in time for a delightful snowstorm!

After that, I got to work, and one week later Juno 1.1 is now available and addresses a bunch of the great feedback given and makes the app that much better. I’ve also got some fun stuff cooking for 1.2 and beyond, being able to actually use it on the device makes building it that much more fun. :)

Here are the changes in 1.1:

Quality options

Juno makes a best guess at what resolution to play back at, and while that’s still present it felt a bit better in the simulator than it did on the real device so a lot of folks requested manual control over the playback quality, and Juno 1.1 adds exactly that! Want 4K? Have at it! 240p aficionado? Got you covered too.

Volume control

Added quicker access to volume controls, so now you can tweak Juno’s volume right from the video player (you can still also change it by reaching up to the top of the device’s dial and then look at the volume icon to adjust). Right now this affects the video player’s volume specifically, not the whole system’s, but I’m looking into how to improve that.

Drag and drop support

If someone sends you a funny YouTube video, just drag and drop the link onto Juno to open it!

Captions/subtitles

Haven’t quite learned Korean yet but still want to know what the person is saying? Or simply want some auto-generated captions for your own language? Juno has you covered now.

URL scheme

If you want to open a video in Juno via Shortcuts or another app, simply change the https:// part of the URL to juno://, so for instance https://www.youtube.com/watch?v=dtp6b76pMak becomes juno://www.youtube.com/watch?v=dtp6b76pMak.

Redesigned end of video screen

When a video ends you can now quickly close the video or restart the video with a friendly little screen.

Even faster video load times

Found an area of my code that I was able to increase the efficiency of substantially and videos should load even faster now! 🏎️

Video player UI improvements

You can now more easily jump between playback speeds
Improved video scrubbing control (volume control also uses it) with a new custom view that expands on selection called JunoSlider (planning to open source soon).
Corner radius is less dramatic during video playback so as to crop out less of the video
When video playback controls fade out, the system ‘grab bar’ now also fades out as it could be distracting to your immersion

Less accidental input

This is a funny one. When designing Juno I had a bunch of fun ideas to make video playback nicer, and most of them went over well!

On the other side, I had the idea to make it so you could “scrub anywhere” on the video screen to go backward and forward in time, a beloved feature in Apollo which worked great in the visionOS simulator with a mouse and keyboard, but on the actual device when you’re pinching and looking around at all sorts of stuff it introduced a lot of accidental input and was much more of a pain than an actual feature. So I nixed this one, and instead made the video scrubber control at the bottom even better.

Another feature similar to that was how on iOS if the video controls are hidden, and you tap the middle of the screen, it assumes you want to pause and does so. I added this to Juno, because it felt great in the simulator, but yeah, same situation where a lot of people thought this was also an annoying bug, and just looking at the pause button is already pretty fast, so not much need for this one.

A better memory

Juno now remembers your playback speed and volume settings from the previous video and automatically applies them.

Bug fixes

In addition to the above there’s also a bunch of bug fixes for things folks with keen eyes were kind enough to point out!

Fixed bug where you could be signed out temporarily if tapping on the Home button
Fixed bug where video controls (like the close button) could disappear sometimes, particularly after resizing
Fixed bug where video title could sometimes be wrong
Fixed bug where you couldn’t tap the video categories at the top of the home page
Fixed bug where video could get cropped down on resize
Fixed bug where video controls would still automatically fade away when paused
Fixed bug where the icon for going forward could be backward
Fixed bug where playback bar could be stretched
Fixed bug where video controls could persist after closing video
A bunch of other smaller fixes and tweaks

Thank You ❤️

The receipt to Juno really has been phenomenal and kind, I really thank you for that, it’s been a ton of fun developing and hearing what you think.

If you’re enjoying the work, leaving a positive review on the App Store would be awesome, and if you haven’t checked it out yet, I’d love if you did and let me know what you think.

I’ve got a bunch of more fun ideas cooking for Juno! Keep the feedback coming!

Download link

juno.vision 🥽

Introducing Juno for Apple Vision Pro

Thu, 01 Feb 2024 22:29:26 -0500

YouTube is probably one of the parts of the internet I consume the most, so I was more than a little sad when YouTube announced that they don’t have plans to build a visionOS app, and disabled the option to load the iPad app. This leaves you with Safari, and the website is okay, but definitely doesn’t feel like a visionOS app. Couple that with visionOS not having the option to add websites to your Home Screen, and YouTube isn’t that convenient on visionOS by default.

Then I remembered for years my old app, Apollo, played back YouTube videos submitted to Reddit pretty well, and I developed a pretty good understanding of how YouTube worked. That sparked the idea to reuse some of Apollo’s code there and build a little YouTube client of my own for visionOS, and after a mad week of coding “Juno for YouTube” is born.

How does it work… technically?

YouTube has a few different APIs.

They have a “Data API” for fetching information (thumbnail, duration, etc.) for a video, that requires an API key, auditing, and you can only call so many times a day. This API doesn’t actually get you the video to play or anything, it’s purely for metadata, and for uploading.

They have private/internal APIs that they get grumpy at you for using because you can circumvent ads. The goal with this app was to not make Google grumpy.

Lastly, they have an embed API that’s pretty powerful, and is what I used in Apollo and now Juno. There’s no API keys, or limits to how many times a day you can call it, as it literally just loads the video in a webview, and provides JavaScript methods to interact with the video, such as pause, play, speed up, etc. It’s really nice, you can play YouTube videos back, and YouTube still gets to show ads (if the user doesn’t have YouTube Premium) and whatnot so no one is grumpy.

This means you can build a fully native visionOS UI that then using JavaScript interacts with the underlying YouTube player, so you get the best of both worlds. Juno even supports detecting aspect ratios of the videos and will resize the window automatically, so ultra-wide 21:9 movie trailers are respected, as are nostalgic 4:3 uploads.

The one downside is that occasionally you’ll get a creator who disabled playback for YouTube embeds. This is rare, especially with videos made in the last few years, but for those Juno will auto-detect that and just load up the normal video website page rather than the fancy player.

What about the browsing itself?

At its core, Juno uses the YouTube website itself. No, not scraped. It presents the website as you would load it, but similar to how browser extensions work, it tweaks the theming of the site through CSS and JavaScript.

That results in:

Tweaking backgrounds so the beautiful glassy look of visionOS shows through. As the great Serenity Caldwell once said, “Opaque windows can feel heavy and constricting, especially at large sizes. Whenever possible, prefer the glass material (which pulls light from people’s surroundings).”
Increasing contrast so items are properly visible
Making buttons like the button to view your subscriptions native UI, and then loading the relevant portions of the website accordingly
You get your full recommendations, subscriptions and whatnot, just as you would on the normal YouTube site or app

It was a lot of work tweaking the CSS to get the YouTube website to something that felt comfortable and at home on visionOS, but I’m really happy with how it turned out. Does it feel like a perfectly native visionOS app? Well no, but it’s a heck of a lot nicer than the website, and to be fair Google apps normally do their own thing rather than use iOS system UI, so not sure we’ll ever fully see that. :)

Does it block ads?

It doesn’t, I don’t think Google would like that, but if you have YouTube Premium you won’t see ads, just like the website. Honestly, YouTube Premium is like one of the most essential subscriptions for me, it’s so handy to never worry about ads and it’s pretty cool in that it also supports the creators substantially more than if you watched ads. So I dunno, if you can afford an expensive Apple Vision Pro, I’d really consider treating yourself to YouTube Premium!

Features

Beautiful translucent visionOS interface
Automatic aspect ratio detection
Speed up or slow down video
Native controls for video playback
Pinch-drag anywhere to scrub through video (an Apollo classic)
Double-pinch either side of the video to jump forward or back 10 seconds in time
Quick launch YouTube from Home Screen
Dim your surroundings to focus on the video
View your recommendations, subscriptions, playlists, etc.
Resizable (while maintaining correct aspect ratio)
Automatic quality selection, should scale up or down based on the size of your window all the way to 4K

Features I’m looking into

This was a bit of a mad dash to get finished in time for the Apple Vision Pro launch, so I’m hoping to add some more things with time.

Ability to see comments (I mean, they’re useful sometimes…)
Maybe select quality directly if interest is there
Caption controls (couldn’t quite get this working in time for 1.0)
More immersive environments
Multiview for multiple videos

If there’s more you’d like to see, let me know!

Can I give feedback?

Yes please, I’d love that! I’ve only been able to develop this in the simulator, which obviously has its limitations, so once I get my hands on a device this Friday I’ll probably have a lot of thoughts on things I want to improve as well. That also means there will probably be some bugs here and there too. But I’d love to hear your experience and feedback with the app, so feel free to reach out to me on Mastodon or Twitter!

Check it out!

It’s available on the App Store for $5! A fun URL to find it is juno.vision No subscriptions or in-app purchases, just a one-time paid up front app like it’s 2008. I considered making it free, or like a buck, but it’s a premium platform, and I think paying a few bucks for a good app is something we should encourage if we want more developers building for this platform.

I think the result is a really comfy way to browse YouTube on visionOS, and having a way to quickly launch YouTube right from your Home Screen is super convenient.

I’m looking forward to doing more with it, and cheers to Matthew Skiles for designing the icon! He actually made some beautiful alternate icons as well, but those apparently aren’t supported in visionOS 1.0.

Download it today!

Autonomous Standing Desk and Chair Review

Tue, 14 Nov 2023 12:42:37 -0400

Autonomous was nice enough to send me one of both their Smart Desk Pro standing desks and ErgoChair Pro chairs in exchange for posting about them on Twitter, and I wanted to cover them in more detail on my blog as well so I could give my full thoughts on them for anyone in the market for a standing desk and chair. I care a lot about a quality, ergonomic desk set up and have tried a lot of different products, so I like to think I have a decent perspective here.

The tl;dr is that they’re both really nice, though they have a few small things I would personally tweak.

Small note: I’m Canadian but I’m putting all the prices in US dollars since most of my readers are American.

The Desk

I’m a programmer and care a lot about the place that I sit and stand at for an inordinate amount of time, so over the years I’ve tried a lot of different products to make my setup more comfortable, inviting, and just more pleasurable to use. That includes a few standing desks.

My first standing desk was the cheapest one I could find on Amazon that had memory presents (trust me, you really want to spend the extra twenty bucks or whatever to not have to hold a button down for awhile and hope you hit the approximate height you like).

I would not recommend this approach. It had a single motor in one of the legs that then twisted a rod that moved the other leg up. This results in a cheaper desk, but a much less reliable one, and I pressed the button one day to find my desk surface at a 45° angle when the motor had an issue getting the other side to cooperate. The desk had a comically short warranty so I was just out of luck and instead of just originally spending a bit more for a quality desk, I was now just doing that anyway but out the cost of an additional desk.

I ended up buying a Jarvis standing desk by Fully after being recommended by a friend, and it’s been great. Both that desk and the Autonomous one are very similar and have dual motors with one per leg. At the time of writing, both have Black Friday sales but the Autonomous desk comes in a fair bit cheaper at $489.00 (with my code “22BFSELIG”) for the Autonomous and $599 for the Jarvis.

I can’t speak to the Jarvis desktops (I bought mine just as the frame itself, as at the time shipping to Canada was very expensive), but I like the white laminate one from Autonomous a lot. I originally thought it would be one of those IKEA style ones that are filled with cardboard, but this sucker is heavy and has nice grommets to route your wires through. Funnily enough those I visually prefer the square corners of the IKEA cardboard edition versus the rounded Autonomous ones, so I ended up using it with the IKEA top.

Autonomous also offers an even cheaper “SmartDesk Core” but it does not offer the height adjustability that the Pro offers so that model was a non-starter for me. In order to have an ergonomic wrist angle with my keyboard I like to put the desk quite low, so make sure you have an idea of where your ideal desk height is and that the desk you buy supports that. I was kinda surprised to see that the Autonomous desk, despite being listed as having a higher minimum height than the Jarvis, actually beats the Jarvis. At the lowest height, the Autonomous desk is 25" off the ground, while the Jarvis sits a quarter inch higher at 25.25".

The Autonomous desk is also noticeably quieter than the Jarvis when in operation. Not to say the Jarvis is loud per se, but the Autonomous is a fair bit less noticeable when going up and down. My initial reaction was that maybe the Autonomous has weaker motors, but if I sit on both desks, both are still easily able to go up and down, and I weight 180 lbs, and I’m not sure anyone’s every day desk has more weight than that on it. They also go up and down at pretty much the exact same speed as far as I can tell.

One area where I will give it to the Jarvis though is I slightly prefer their control system. I imagine it’s to prevent accidental input, but the Autonomous requires you hold down the buttons for a beat before they engage and start moving the desk, while the Jarvis is as soon as you touch it. This is probably a matter of preference, but it also manifests when you’re manually moving the desk with the up and down arrows, and when you reach your setting and release your finger, the Autonomous takes a second before it stops so unless you account for that you typically overshoot your target slightly. I’d love to see a dip switch or something on the controller that would allow you to control this functionality.

Overall, especially with the price advantage, I’d go with the Autonomous desk personally. Pleased as punch, and now I have an extra desk set up in the corner of my office in case I… want to change it up I suppose? Now I finally have a use for that LG Ultrafine 5K that’s been sitting in my closet for two years!

Oh, and get a standing desk mat. This is not negotiable, there’s a reason grocery store employees all use them. Standing for hours on a hard surface is not great for you, and will catch up to you eventually. It will make the standing desk a million times more inviting and comfortable to use, and they’re pretty inexpensive.

The Chair

Standing desks always seem like a slam dunk, “duh” upgrade to people, but chairs seem unfortunately underappreciated. But they shouldn’t be! All the time you’re not standing, you’re sitting, and doing so in a good quality chair will pay dividends in the health of your body over the years.

So naturally, I’ve tried quite a few desk chairs over the years. About seven years ago I went on a quest to get a good quality chair, and tried out all the “greats” of that era. I rented a Herman Miller Embody, a Herman Miller Aeron, a Steelcase Gesture, and a Steelcase Leap. While they were all quality chairs, the Steelcase Leap ended up being my favorite by a fair bit.

Chairs are super personal, and the Leap just seemed to meld with my body the best, so I encourage you to try out chairs in person if possible, or order from a company that allows returns if you’re not satisfied. Seriously, the Herman Miller Embody from what people said sounded like it descended from the heavens, but I just wasn’t a big fan of how it fit against my back despite attempted adjustments. Autonomous seems to fit the bill for allowing to send back if you’re not a fan, though if buying during a sale like Black Friday I would contact them to see if that still applies, as they seem to have an asterisks for sale items.

So basically, take the time to learn the adjustments on the chair, watch a YouTube video or two on proper ergonomics, and adjust the chair to fit you. Just through sheer combinations, the configuration that a chair comes in out of the box is likely not the one that best suits you!

Long story short, the Autonomous ErgoChair Pro (they also have an ErgoChair Plus that seems closer to the Herman Miller Embody style) is a really comfy chair, and I love the red color I ordered it in. Also, between my Leap, my girlfriend’s office chair, and the Autonomous chair, my cat Ruby always chooses the Autonomous to sleep on, so that must mean something (I think it’s the fact it has the widest butt cushion area, which makes it feel a bit like you’re sitting on a throne).

The price difference is pretty substantial too, at the time of writing the ErgoChair Pro is well under half the price of the Steelcase Leap (again, use that 22BFSELIG code to grab an additional 10% off for Black Friday).

She won’t let me sit :(

I’ve been using the Autonomous chair for about a week now at my desk, and while I think it’s a quality chair, I think I still have a slight preference for my Leap. This shouldn’t be super surprising at over double the price, but there’s a few things that push it slightly in the favor of the Leap for me.

For one, the Autonomous chair is very adjustable, but I can’t quite get the lumbar support to a place I like versus the Leap. It’s just slightly more dramatically pushed in on the Autonomous versus the Steelcase, and that is adjustable, but I can’t dial it back enough (the Leap’s lumbar is a lot more adjustable).

I also like on the Leap how when you recline, the seat cushion automatically slides forward a bit with you, so you don’t like slump off the chair as much. I also like that you can choose how far it can recline, so you can allow for a bit of a recline rather than going like super far back. Lastly, the height of the arms on the Leap can go lower than the Autonomous, which is just enough that I can push the Leap under my desk but not the Autonomous. You could always just not install the arms on the Autonomous though if you don’t use them.

All that said, my girlfriend has your generic $70 Staples chair and I gave her the Autonomous to try for a bit, and she really, really liked it. Again, it’s more expensive, so not super surprising, but a quality chair is important. She also really liked that the Autonomous chair has a headrest versus my Steelcase one (you can buy one for the Steelcase, but it costs extra and isn’t nearly as customizable as the Autonomous one) and is now happily using it. See what I mean about personal preference?

I really wish my Leap had the Autonomous’ adjustment for the angle of the seat, though. And I have to admit the Autonomous looks a fair bit cooler than the Steelcase Leap which kinda just looks like your run of the mill corporate America office chair.

Overall

I don’t get sent a lot of free stuff despite loving free stuff, so I was somewhat scared these were going to arrive and I might have to contact Autonomous and be like “ehhhhh, thanks for sending but not a fan”, but I’m delighted that they’re both very nice, price competitive options in the ergonomic desk setup space that I have no issue recommending. And if you do end up going with Autonomous, Black Friday is a great opportunity, and be sure to take 10% off on top of the existing sales with my coupon: 22BFSELIG. (I don’t get any kickback, but you might as well save some extra money! :p)

Seriously, be it these options or something entirely different, do yourself a favor (if you have the means) and treat yourself to a quality desk and chair (and ideally keyboard, mouse, and monitor height). They can make a big difference in your health, especially compounded over years and years and years of heavy use if you’re in a desk-heavy job like programming, design, customer support, etc.

There’s always that adage about treating yourself to quality things if they separate you from the ground, which is normally said in the context of shoes and a mattress, but given that many of us spend as much time at our desk as we do sleeping, I think a quality desk setup easily qualifies as well.

Smart Open Xcode

Wed, 02 Aug 2023 14:58:22 -0300

If you’re like me, you often have multiple versions of Xcode installed. One or two beta versions, a stable version, and maybe another version in case the most recent stable version has something weird about it.

I also really like mapping my Caps Lock key to something more useful, and after reading Brett Terspstra’s excellent article on making a Hyper key many years ago, I’ve gotten used to hitting Caps Lock + X to jump to Xcode thanks to Karabiner Elements and Alfred. It works a lot like Command + Tab, but doesn’t require hitting Tab until you find it. It basically maps Caps Lock to holding down Command, Option, Control, and Shift all at once, a modifier that is very unlikely to conflict with anything else.

Anyway, this setup works by mapping a hotkey to a specific app, which works great 99% of the time, but if you’re working in a beta version of Xcode, and you have that keyboard shortcut mapped to the stable version, it opens the wrong app and can even sometimes get Xcode confused about accessing a file in multiple locations. Not good!

So, we need a smarter version rather than just hardcoding the app. Lots of options exist, like AppleScript (had a small delay though) and Keyboard Maestro, probably Shortcuts too, but I like a little Lua scripting utility called Hammerspoon. Just download it and drop it in your Applications folder.

At that point, we can add a short script to our init.lua file that uses Hammerspoon’s find() API to, well, find the version of Xcode that’s currently running, and open that, rather than a hardcoded one. Nice! (If you keep multiple versions of Xcode open at once, I don’t know what to tell you, weirdo.)

hs.hotkey.bind({"cmd", "alt", "ctrl", "shift"}, "X", function()
    -- Use the bundle ID rather than just 'Xcode' to prevent it from trying to open utility apps like 'Xcodes'
    local xcode = hs.application.find("com.apple.dt.Xcode")
    
    -- If nothing is found then just alert the user to open one, it would be very hard to guess which one they want if none are open!
    if xcode == nil then 
        hs.notify.new({title="Xcode is not open! 🫨", informativeText="Manually launch an Xcode instance and then I’ll be able to work!"}):send()
        return
    end

    --- If not the frontmost app, make it the frontmost! If it already is, hide it (makes it more toggle-y).
    if xcode:isFrontmost() then
        xcode:hide()
    else
        xcode:activate()
    end
end)

Voilà! Works like a charm. Here’s an addition that you can add as well that extends it to Simulators:

hs.hotkey.bind({"cmd", "alt", "ctrl", "shift"}, "A", function()
    -- Use the bundle ID rather than just 'Simulator' to prevent it from trying to open random background processes, and yes 'iphonesimulator' works for iPads as well
    local simulator = hs.application.find("com.apple.iphonesimulator")
    
    -- If nothing is found then just alert the user to open one, it would be very hard to guess which one they want if none are open!
    if simulator == nil then 
        hs.notify.new({title="Simulator is not open! 🫨", informativeText="Run your project in Xcode to launch it in a simulator, then I'll know what to open!"}):send()
        return
    end

    --- If not the frontmost app, make it the frontmost! If it already is, hide it (makes it more toggle-y).
    if simulator:isFrontmost() then
        simulator:hide()
    else
        simulator:activate()
    end
end)

Instant Pan Gesture Interactions

Sat, 13 May 2023 11:45:03 -0300

Apple has a really awesome WWDC 2018 video called Designing Fluid Interfaces, and one of the key takeaways from the videos that one of the presenters, Chan Karunamuni, said is “Look for delays everywhere. Everything needs to respond instantly.” (6:28)

A really great example of this is a scroll view on iOS. If you flick through your contacts and touch your finger to the screen, instantly the scroll view stops and let’s you reposition it. This kind of instantaneous behavior is really important in our own views, interactions, and animations.

Okay, so I was building a view where I wanted this behavior. Basically, you flick a box from the left side of the screen to the right, and as you release your finger it keeps going. Of note though is that you should be able to grab the box while it’s in flight to stop it.

Turns out this is trickier than it seems, as UIPanGestureRecognizer has a small delay in startup where it requires you to move your finger before it recognizes the gesture starting. If you just touch your finger on the moving object, that’s not technically a “pan”, so it ignores you (makes sense), which means the object just keeps moving until you move enough to trigger a “pan”, the result of this is an interaction that doesn’t feel very responsive.

First attempt at a solution

One solution that works in many cases for many people is to implement an “InstantPanGestureRecognizer”, where unlike the normal one, it enters its “began” state as soon as a finger is touched down, allowing you to respond instantly to user input and pause the animation as soon as their finger touches the screen.

Nathan Gitter has an awesome article showing code examples of many of the interactions shown in Apple’s video. It’s an amazing article. He has a section on implementing this custom pan gesture:

class InstantPanGestureRecognizer: UIPanGestureRecognizer {
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent) {
        super.touchesBegan(touches, with: event)
        self.state = .began
    }
}

For awhile this worked, but something changed in a recent version of iOS that effectively broke it. On iPhones it mostly works fine, but on iPads, and on iPhones if the view is near the home indicator at the bottom, there’s a delay in between the state being updated to .began, and the pan gesture handler being notified of the state change. It’s about 0.75 seconds, which is an enormous amount of time for a gesture (on a 120 Hz device, that’s 90 frames rendered before your input is recognized!).

Based on console logs and inspecting the UIGestureRecognizers attached to the app’s UIWindow, it looks like there’s something called a “system gesture gate”, that I’m assuming gates off gestures from conflicting with system ones (particularly on the iPad, which has lots of multitasking gestures), which means ones attached to the app run at a lower priority and could be delayed.

(Note that the preferredScreenEdgesDeferringSystemGestures property does not seem to have an effect here.)

That being said, since the state does update instantly, it’s just the communication of the state change that’s delayed, it’s pretty easy to work around this and still have an InstantPanGestureRecognizer. Add the code for the custom gesture above, but instead of using addTarget(...) to listen for changes to the gesture recognizer, which has a delay in some cases, just jump straight to KVO:

static var gestureContext = 1
    
override func viewDidLoad() {
    super.viewDidLoad()
    
    let panGestureRecognizer = InstantPanGestureRecognizer()
    panGestureRecognizer.addObserver(self, forKeyPath: #keyPath(UIPanGestureRecognizer.state), options: .new, context: &Self.gestureContext)
    view.addGestureRecognizer(panGestureRecognizer)
}

override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
    guard context == &Self.gestureContext else {
        // Be sure to pass on any observes that we didn't explicitly ask for!
        super.observeValue(forKeyPath: keyPath, of: object, change: change, context: context)
        return
    }
    
    guard let panGestureRecognizer = object as? UIPanGestureRecognizer else { return }
    
    switch panGestureRecognizer.state {
    case .began:
        // This is no longer delayed! Stop animation if has not already ended
    case .changed:
        // Update position of object
    case .ended:
        // Continue object's momentum with animation
    }
}

The .began state will now trigger without needing to move your finger first, and without delay on iPads.

But I think there’s an even better solution for some cases, read on!

A solution I like more

While that previous gesture setup works great, especially in the case Nathan Gitter outlined in the aforementioned tutorial, I think there’s one catch that could trip you up in some situations: pan gesture recognizers have a movement delay before starting for a reason. This small delay can be important, because it allows us to have some information about the pan by the time it starts, like which direction the user is moving in.

This movement data can be super handy, for, say, only making the gesture start if it’s moving horizontally. For example, say we have a box inside a scroll view, and we want to let the user pan the box from left to right, but still allow the scroll view to scroll up and down, we could look at our object’s pan gesture and only allow it to start if the movement is horizontal. (If the pan gesture were to start as soon as the user’s finger touches the screen, we won’t be able to know which direction they’re panning in to stop it.)

So while the small delay introduced in a recent OS version on iPads is unfortunate, it gives us an opportunity to look outside of an instant pan gesture recognizer and its limitations.

What would that be? Something that would allow the pan gesture recognizer to operate normally, but have a secondary system that allows us to know as soon as the user touches down on the screen.

There’s a few ways to do this, but since we’re describing an interaction, I think an additional gesture recognizer would work perfectly here. UITapGestureRecognizer immediately comes to mind, but requires the user’s finger to lift up afterward, which rules it out for us (we want to be able to just touch down to pause, then pan around if desired). UILongPressGestureRecognizer could actually work here if we set minimumPressDuration to a super small number, but that feels kinda hacky (it’s not really a long press at that point, is it)?

Okay, so let’s build our own. It’s actually really simple:

class TouchesBeganGestureRecognizer: UIGestureRecognizer {
    override func canPrevent(_ preventedGestureRecognizer: UIGestureRecognizer) -> Bool {
        return false
    }
    
    override func canBePrevented(by preventingGestureRecognizer: UIGestureRecognizer) -> Bool {
        return false
    }
    
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent) {
        super.touchesBegan(touches, with: event)
        
        state = .began
    }
    
    override func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent) {
        super.touchesMoved(touches, with: event)
        
        state = .ended
    }
    
    override func touchesCancelled(_ touches: Set<UITouch>, with event: UIEvent) {
        super.touchesMoved(touches, with: event)
        
        state = .cancelled
    }
    
    override func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent) {
        super.touchesEnded(touches, with: event)
        
        state = .ended
    }
}

We create a custom gesture recognizer that both can’t be prevented by other gesture recognizers, and can’t prevent others (this means it works on top of other gesture recognizers). And as far as states goes, it enters the .began state as soon as the user touches down, but as soon as anything else happens, it ends (there’s no .changed state).

Then we can take this new gesture and add it in addition to our pan gesture. Here’s a simple example showing this, where we use a pan gesture to move a box, when the pan gesture ends the box continues moving in the direction the user threw it, and they can then instantly grab it while it’s in flight to stop it and/or start moving it around again. Note that for sake of keeping the example short, the direction is only left-to-right, and the gesture’s velocity is not calculated into the animation (for the latter Nathan’s article above goes over conserving momentum as well if you’re curious!).

class ViewController: UIViewController {
    let box = UIView(frame: CGRect(x: 0.0, y: 200.0, width: 200.0, height: 200.0))
    var propertyAnimator: UIViewPropertyAnimator?

    override func viewDidLoad() {
        super.viewDidLoad()
        
        box.backgroundColor = .systemOrange
        view.addSubview(box)
        
        let panGestureRecognizer = UIPanGestureRecognizer(target: self, action: #selector(panGestureUpdated(panGestureRecognizer:)))
        box.addGestureRecognizer(panGestureRecognizer)
        
        let touchesBeganGestureRecognizer = TouchesBeganGestureRecognizer(target: self, action: #selector(touchesBeganGestureRecognizerUpdated(touchesBeganGestureRecognizer:)))
        box.addGestureRecognizer(touchesBeganGestureRecognizer)
    }
    
    @objc private func panGestureUpdated(panGestureRecognizer: UIPanGestureRecognizer) {
        if panGestureRecognizer.state == .began {
            // Normalize the gesture's starting translation with where the box is at the start
            panGestureRecognizer.setTranslation(CGPoint(x: box.frame.origin.x, y: 0.0), in: box)
        } else if panGestureRecognizer.state == .changed {
            box.frame.origin.x = panGestureRecognizer.translation(in: box).x
        } else if panGestureRecognizer.state == .ended {
            let propertyAnimator = UIViewPropertyAnimator(duration: 1.5, curve: .linear)
            self.propertyAnimator = propertyAnimator
            
            propertyAnimator.addAnimations {
                self.box.frame.origin.x = self.view.bounds.width - self.box.bounds.width
            }
            
            propertyAnimator.addCompletion { position in
                self.propertyAnimator = nil
            }
            
            propertyAnimator.startAnimation()
        }
    }
    
    @objc private func touchesBeganGestureRecognizerUpdated(touchesBeganGestureRecognizer: TouchesBeganGestureRecognizer) {
        guard touchesBeganGestureRecognizer.state == .began else { return }
        guard let propertyAnimator else { return }
        
        propertyAnimator.stopAnimation(true)
        
        self.propertyAnimator = nil
    }
}

There you go! Hopefully that gives you a nice way of making a pan gesture animation feel even more responsive.

First on New Blog

Sat, 28 Jan 2023 17:12:52 -0400

Converted the blog over to a new Hugo theme! Hopefully everything here sorta works. Test post will remove.

This goat’s name is apparently Gubgub, and very cute.

Theming Apps on iOS is Hard

Mon, 07 Feb 2022 12:03:01 -0400

Theming apps (the ability to change up the color scheme for an app from say, a white background with blue links to a light green background with green links) is a pretty common feature across a lot of apps. It’s one of the core features of the new “Twitter Blue” subscription, Tweetbot and Twitterific have had it for awhile, my app Apollo has it (and a significant subset of users use it), and it’s basic table stakes in text editors. When you use the heck out of an app, it’s pretty nice to be able to tweak it in a way that suits you more.

For the longest time, by default, an app had one color scheme. Dark mode didn’t exist at the iOS level, so it was up to apps to have two sets of colors to swap between individually. With iOS 12 Apple made that a lot nicer, and made switching between a light color scheme and a dark color scheme really easy.

The Current Light/Dark Mode System

The current system is great for switching between light mode and dark mode. Each “color” basically has two colors: a light mode version and a dark mode version, and instead of calling it “whiteColor”, the color might be called “backgroundColor”, and have a lightish color for light mode and a darker color for dark mode. You set that on whatever you’re theming, and bam, iOS handles the rest, automatically switching when the iOS system theme changes. Heck, Apple even defines a bunch of built in ones, like “label” and “secondaryLabel”, so you likely don’t even have to define your own colors.

The code defining, say, a custom blue accent/tint color for your app looks basically like:

if lightMode {
    // A rich blue
    return UIColor(hexcode: "007aff") 
} else {
    // A little brighter blue to show up on dark backgrounds
    return UIColor(hexcode: "4BA1FF") 
}

(For a thorough explanation of this system, NSHipster has a great article.)

The Problem

This quickly falls apart when you introduce theming. Maybe blue is a safe bet as your app’s “button color” for 95% of users, but a subset are going to want to make that more personal. Maybe a mint color? A pink! If we’ve learned anything through the craze of app’s like Widgetsmith, people love to make things their own.

But wait, how do we do this when the system is built around only having two options: one for light mode, and one for dark? We might want to have a “Mint” theme, with a delightful green tint instead.

Perhaps something like this?

if lightMode {
    if mintSelected {
        // Minty!
        return UIColor(hexcode: "26C472")
    } else {
        // A rich blue
        return UIColor(hexcode: "007aff")     
    }
} else {
    if mintSelected {
        // Dark mode minty!
        return UIColor(hexcode: "84FFBF")
    } else {
        // A little brighter blue to show up on dark backgrounds
        return UIColor(hexcode: "4BA1FF") 
    }
}

Beautiful! This actually works super well, if we start up our app, iOS will see that mint is selected and choose the mint colors instead.

However, there’s a serious catch. If the app started up in normal (AKA non-minty) mode, and the user selects the mint theme at some point, iOS kinda looks the other way and ignores the change, sticking with blue instead. The conversation kinda goes like:

Me: Hey iOS! The theme is minty now, blue is so last season. Can you update those buttons to mint-colored?

iOS: Well, I asked earlier and you said blue. No take backs. The paint is dry, no updates allowed.

Me: But if the user changes the device theme to dark mode, you’ll happily update the colors! Could you just do that same thing now for me?

iOS: Hard pass.

Me: But the header file for hasDifferentColorAppearanceComparedToTraitCollection even says changes in certain traits could affect the dynamic colors, could you just wrap what those changes call into a general function?

iOS: I said no take backs! But let’s together hope one of the awesome folks who works on me adds that in my next major version!

So what do you do? Have the user force-quit the app and relaunch every time they want to change the theme? That’s not very Apple-y. Reinitialize the app’s view hierarchy? That can mess with lots of things like active keyboards.

Let’s Go Back in Time

Remember how I said in the pre-iOS 12 days, where iOS didn’t even had a dark mode, developers had to get a bit more inventive? Apollo’s theming system was actually written way back then, so I’m pretty familiar with it! Basically how it works is you don’t talk to iOS like above, instead you talk to each view on screen directly. Cut out the middleman!

Leveraging something like NSNotificationCenter (or a more type-safe version via NSHashTable with weak object references) you’d basically go to each view you wanted to color, and say “Hey, you’re blue now, but why don’t you give me your phone number so if anything changes I’ll let you know?” and you’d register that view. Then when the user asked to go to dark mode, you’d quickly phone up all the views in the app and say “Change! Now! Green!” and they would all do that.

The beauty is that when you “phone them up”, you can tell them any color under the sun! You have full control!

Here’s a quick example of what this might look like, somewhat based on how I do it in Apollo:

protocol Themeable: AnyObject {
    func applyTheme(theme: Theme)
}

enum ColorScheme {
    case `default`, pumpkin
}

struct Theme {
    let isLightModeActive: Bool
    let colorScheme: ColorScheme

    var backgroundColor: UIColor {
        switch colorScheme {
            case .default:
                return isForLightMode ? UIColor(hexcode: "ffffff") : UIColor(hexcode: "000000")
            case .pumpkin:
                return isForLightMode ? UIColor(hexcode: "ff6700") : UIColor(hexcode: "733105")
        }
    } 

    // Add more colors for things like tintColor, textColor, separators, inactive states, etc.
}

class ThemeManager: NSObject {
    static let shared = ThemeManager()

    var currentTheme: Theme = // initialize value from UserDefaults or something similar

    private var listeners = NSHashTable<AnyObject>.weakObjects()

    // This would be called by an external event, such as iOS changing or the user selecting a new theme
    func themeChangeDidOccur(toTheme newTheme: Theme) {
        currentTheme = newTheme
        refreshListeners()
    }

    func makeThemeable(_ object: Themeable) {
        listeners.add(object)
        object.applyTheme(theme: currentTheme)
    }

    private func refreshListeners() {
        listenersAllObjects
            .compactMap { $0 as? Themeable }
            .forEach { $0.applyTheme(theme: currentTheme) }
    }
}

// Do this in every view controller/view:
class IceCreamViewController: UIViewController, Themeable {
    let leftBarButtonItem = UIBarButtonItem(title: "Accounts")

    override func viewDidLoad() {
        super.viewDidLoad()
    
        ThemeManager.shared.makeThemeable(self)
    }

    func applyTheme(theme: Theme) {
        // e.g.:
        leftBarButtonItem.tintColor = theme.tintColor
    }
}

So this works but has a lot of downsides. For one, it’s a lot harder. Rather than just setting view.textColor = appTextColor in a single call and have it automatically switch between light and dark mode colors that you defined as needed, you have to set the color, register the view, have a separate theming function, and then go back and talk to that view whenever anything changes. A lot more arduous in comparison.

There’s other aspects to consider as well. Because iOS is smart, when an app goes into the background, iOS quickly takes a screenshot of the app to show up in the app switcher, but it also quickly toggles the app to the opposite theme (so dark mode if the system is in light mode) and takes a screenshot of that as well, so if the system theme changes iOS can instantly update the screenshot in the app switcher.

The result of this is that iOS rapidly asks your app to change its theme twice in a row (to the opposite theme, and then back to the normal), if you don’t do this quickly, you’re in trouble. Indeed, it’s one of my top crashers as of iOS 15, and I assume it’s because I use this old method of talking to every single view to update, and iOS uses a more efficient method under the hood.

You also hit speed bumps you don’t really think of when you start out. For instance, say parts of your app support Markdown rendering where links embedded in a block of text reflect a specific theme’s tint color. When the theme changes, with this system you get that notification, and what do you do? Recompute the NSAttributedString each time you get a theme change? Perhaps only do it the first time, cache the result, and then on theme change iterate over that specific attribute and update only those attributes to the new color. You know what’s a lot nicer than all that rigamarole each time? Just setting the dynamic color in your Markdown renderer/attributed string once, and having iOS handle all the color changes like in the newer solution.

So as you may have guessed I’ve been meaning to update my old system to this newer one. (Wonder why I was writing this blog post?)

(For a thorough writeup on this kind of system, the SoundCloud Developer Blog has a great article, and Joe Fabisevich also has a really cool variation based on Combine.)

SwiftUI

SwiftUI is new and really exciting, and something I’m looking forward to using more in my app. The tricky thing with this antiquated solution is it doesn’t work too well with SwiftUI, subscribing everything into NotificationCenter calls and callbacks isn’t exactly very SwiftUI-esque and ruins a lot of the elegance of creating views in SwiftUI and at best adds a lot of boilerplate.

So if the old system isn’t great, what about the newer, post-iOS 12 dynamic color one? While SwiftUI has its own Color object which unlike UIColor lacks support for custom dynamic colors (I believe) you can initialize a Color object with a UIColor and SwiftUI will dynamically update when light/dark mode changes occur, just like UIKit! Which makes the “newer” solution a lot nicer as it works well in both “worlds”.

What Would be the Perfect Solution from Apple?

The perfect solution would be Apple simply having a method like UIApplication.shared.refreshUserInterfaceStyle() that performs the same thing that occurs when iOS switches from light mode to dark mode. In that situation, there’s a code path/method on iOS that says “Hey app, update all your colors, things have changed”, and simply making it so app developers could call that on their own app would make everything perfect. Theme changes would redraw as requested, no having to force-quit or talk to each and every view manually, and it would work nicely with SwiftUI! (Apple folks: FB9887856)

Hacksville

In the absence of that method (fingers crossed for iOS 16!), can we make our own method that accomplishes effectively the same thing? An app color refresh? Well, there’s a couple ways!

Martin Rechsteiner mentioned a clever way on Twitter, wherein you change the app’s displayed color gamut. Since the color profile of the entire app is changing, iOS will indeed update all the colors. The downside is, well, you’re changing the app’s color gamut from say, P3 to SRGB, which can presumably have some effects on how colors look. It shouldn’t be super obvious, since from what I can tell UIImageViews and whatnot have their embedded color profiles separate from app, so pictures and whatnot should still display correctly. But it’s still suboptimal. You could always immediately switch back to the previous color gamut after, but that has the problems of solution 2.
If you’re in light mode set overrideUserInterfaceStyle to dark mode on the app’s UIWindow, and then change it back (or vice-versa). The downside here, is that if you do it in the same pass of the runloop, colors will update but traitCollectionDidChange does not fire in the relevant view controllers which may be important for things like CALayer updates. You can dispatch it to the next loop with good ol’ DispatchQueue.main.async { ... } on the second call, but then traitCollectionDidChange will be called twice, and unless you do a bit more work the screen will have a quick flash as it jumps between light and dark mode very quickly.

Of the two, I think I prefer the second solution slightly. Even though it calls the method twice, and flashes a bit, you can negate the flash by putting a view overtop the main window (say, a snapshot from immediately before that pleasantly fades to the new theme) and the traitCollectionDidChange being called twice likely isn’t much concern.

Put Those Two Together? PB & J Sandwich?

Another solution would be to take parts of both systems that work and put them together: use dynamic colors for 97% of the heavy lifting, but when a color has to change immediately in response to a user changing themes, then you use the “notify all the views in the app manually” method. This would likely be fine when going into the background and snapshotting, because that would use dynamic colors, and the “notifying all the views” would only occur when the app is in the foreground with the user manually changing the theme.

Still, I don’t really like that we have to have a separate system maintained where we have to keep track of every view in the app that might need a color change, for the 3% of the time the user might change the theme. That’s a lot of boilerplate and excess code for something that could simply be handled by a refresh method on UIApplication. (And yes, you could say “if it’s that rare, just have them force quit the app or something else gross”, but you want the user to be able to quickly preview different themes without a ton of friction in between.)

So all in all, I think I’m going to go with the overrideUserInterfaceStyle kinda hack, and hope iOS 16 sees a proper, built-in way to refresh the app’s colors. But if you have a better solution I’m all ears, hit me up on Twitter!

Table of Contents Selector View

Sun, 25 Apr 2021 21:06:06 -0300

I wrote a new little view for a future version of Apollo that makes some changes to the default iOS version (that seems to be a weird trend in my recent programming, despite me loving built-in components). Here’s some details about it! It’s also available as a library on GitHub if you’re interested!

Are you familiar with UITableView’s sectionIndexTitles API? The little alphabet on the side of some tables for quickly jumping to sections? Here’s a tutorial if you’re unfamiliar.

This is a view very similar to that (very little in the way of originality here, folks) but offers a few nice changes I was looking for, so I thought I’d open source it in case anyone else wanted it too.

Benefits

The UITableView API is great, and you should try to stick with built-in components when you can avoid adding in unnecessary dependencies. That being said, here are the advantages this brought me:

🐇 Symbols support! SF Symbols are so pretty, and sometimes a section in your table doesn’t map nicely to a letter. Maybe you have some quick actions that you could represent with a lightning bolt or bunny!
🌠 Optional overlay support. I really liked on my old iPod nano how when you scrolled really quickly an a big overlay jumped up with the current alphabetical section you were in so you could quickly see where you were. Well, added!
🖐 Delayed gesture activation to reduce gesture conflict. For my app, an issue I had was that I had an optional swipe gesture that could occur from the right side of the screen. Whenever a user activated that gesture, it would also activate the section index titles and jump everywhere. This view requires the user long-press it to begin interacting. No conflicts!
🏛 Not tied to sections. If you have a less straight forward data structure for your table, where maybe you want to be able to jump to multiple specific items within a section, this doesn’t require every index to be a section. Just respond to the delegate and you can do whatever you want.
🏓 Not tied to tables. Heck, you don’t even have to use this with tables at all. If you want to overlay it in the middle of a UIImageView and each index screams a different Celine Dion song, go for it.
🏂 Let’s be honest, a slightly better name. The Apple engineers created a beautiful API but I can never remember what it’s called to Google. sectionIndexTitles doesn’t roll off the tongue.
🌝 Haha moon emoji

How to Install

No package managers here. Just drag and drop TableOfContentsSelector.swift into your Xcode project. You own this code now. You have to raise it as your own.

How to Use

Create your view.

let tableOfContentsSelector = TableOfContentsSelector()

(Optional: set a font. Supports increasing and decreasing font for accessibility purposes)

tableOfContentsSelector.font = UIFont.systemFont(ofSize: 12.0, weight: .semibold) // Default

The table of contents needs to know the height it’s working with in order to lay itself out properly, so let it know what it should be

tableOfContentsSelector.frame.size.height = view.bounds.height

Set up your items. The items in the model are represented by the TableOfContentsItem enum, which supports either a letter (.letter("A")) case or a symbol case (.symbol(name: "symbol-sloth", isCustom: true)), which can also be a custom SF Symbol that you created yourself and imported into your project. As a helper, there’s a variable called TableOfContentsSelector.alphanumericItems that supplies A-Z plus just as the UITableView API does.

let tableOfContentsItems: [TableOfContentsItem] = [
    .symbol(name: "star", isCustom: false),
    .symbol(name: "house", isCustom: false),
    .symbol(name: "symbol-sloth", isCustom: true)
    ] 
    + TableOfContentsSelector.alphanumericItems

tableOfContentsSelector.updateWithItems(tableOfContentsItems)

At this point add it to your subview and position it how you see fit. You can use sizeThatFits to get the proper width as well.

Lastly, implement the delegate methods so you can find out what’s going on.

func viewToShowOverlayIn() -> UIView? {
    return self.view
}

func selectedItem(_ item: TableOfContentsItem) {
    // You probably want to do something with the selection! :D
}

func beganSelection() {}
func endedSelection() {}

That’s it! If you’re curious, internally it’s just a single UILabel with a big ol’ attributed string. Hope you enjoy!

More Efficient/Faster Average Color of Image

Fri, 02 Apr 2021 17:18:46 -0300

Skip to the ‘Juicy Code 🧃’ section if you just want the code and don’t care about the preamble of why you might want this!

Finding the average color of an image is a nice trick to have in your toolbelt for spicing up views. For instance on iOS, it’s used by Apple to make their pretty homescreen widgets where you put the average color of the image behind the text so the text is more readable. Here’s Apple’s News widget, and my Apollo widget, for instance:

Core Image Approach Pitfalls

There’s lots of articles out there on how to do this on iOS, but all of the code I’ve encountered accomplishes it with Core Image. Something like the following makes it really easy:

func coreImageAverageColor() -> UIColor? {
    // Shrink down a bit first
    let aspectRatio = self.size.width / self.size.height
    let resizeSize = CGSize(width: 40.0, height: 40.0 / aspectRatio)
    let renderer = UIGraphicsImageRenderer(size: resizeSize)
    let baseImage = self
    
    let resizedImage = renderer.image { (context) in
        baseImage.draw(in: CGRect(origin: .zero, size: resizeSize))
    }

    // Core Image land!
    guard let inputImage = CIImage(image: resizedImage) else { return nil }
    let extentVector = CIVector(x: inputImage.extent.origin.x, y: inputImage.extent.origin.y, z: inputImage.extent.size.width, w: inputImage.extent.size.height)

    guard let filter = CIFilter(name: "CIAreaAverage", parameters: [kCIInputImageKey: inputImage, kCIInputExtentKey: extentVector]) else { return nil }
    guard let outputImage = filter.outputImage else { return nil }

    var bitmap = [UInt8](repeating: 0, count: 4)
    let context = CIContext(options: [.workingColorSpace: kCFNull as Any])
    context.render(outputImage, toBitmap: &bitmap, rowBytes: 4, bounds: CGRect(x: 0, y: 0, width: 1, height: 1), format: .RGBA8, colorSpace: nil)

    return UIColor(red: CGFloat(bitmap[0]) / 255, green: CGFloat(bitmap[1]) / 255, blue: CGFloat(bitmap[2]) / 255, alpha: CGFloat(bitmap[3]) / 255)
}

Core Image is a great framework capable of some insanely powerful things, but in my experience isn’t optimal for something as simple as finding the average color of an image because it takes up quite a bit more memory and time, things that you don’t have a lot of when creating widgets. That or I don’t know enough about Core Image (it’s a substantial framework!) to figure out how to optimize the above code (which is entirely possible, but hey the other solution is easier to understand, I think).

You have around 30 MB of headroom with widgets, and from my tests the normal Core Image filter way was taking about 5 MB of memory just for the calculation. That’s about 17% of the total memory you get for the entire widget for a single operation, which could really hurt you if you’re up close to the limit. And you don’t want to break that 30MB limit if you can avoid it, from what I can see it seems iOS (understandably) penalizes you for it, and repeated offenses mean your widget doesn’t get updated as often.

I’m no Core Image expert, but I’m guessing since it’s this super powerful GPU-based framework the memory consumption seems inconsequential when you’re doing crazy realtime image filters or something. But who knows, I’m just going off measurements.

You can see in Xcode’s memory debugger very clearly when Core Image kicks in for instance, causing a little spike, and almost more concerning is that it doesn’t seem to normalize back down any time soon.

(That might not be the most egregious example. It can be worse.)

Just Iterating Over Pixels Approach

An easy approach would just be to iterate over every pixel in the image, add up all their colors, then average them. Downside is there could be a lot of pixels (think of a 4K image), but thankfully for us we can just resize the image down a bunch first (fast), and the “gist” of the color information will be preserved and we have a lot less pixels to deal with.

One other catch is that just ‘iterating over the pixels’ isn’t as easy as it sounds when the image you’re dealing with could be in a variety of different formats, (CMYK, RGBA, ARGB, BBQ, etc.). I came across a great answer on StackOverflow that linked to an Apple Technical Q&A that recommended just drawing out the image anew in a standard format you can always trust, so that solves that.

Lastly, there’s some debate over which algorithm is best for averaging out all the colors in an image. Here’s a very interesting blog post that talks about how a sum of squares approach could be considered better. Through a bunch of tests, I see how it could be with approximating a bunch of color blocks of a larger imager, but the ‘simpler’ way by just summing seems to have better color results, and more closely mimics Core Image’s results. The code below includes both options, and I’ll include a comparison table so you can choose for yourself.

The Juicy Code 🧃

Here’s the code I landed on, feel free to change it as you see fit. I like to keep in lots of comments so if I come back to it later I can understand what’s going on, especially when it’s dealing with bitmasking and color profile bit structures and whatnot, which I don’t use often in my day-to-day and requires a bit of a rejogging of the Computer Sciencey part of my brain, and it’s really pretty simple once you read it over.

extension UIImage {
    /// There are two main ways to get the color from an image, just a simple "sum up an average" or by squaring their sums. Each has their advantages, but the 'simple' option *seems* better for average color of entire image and closely mirrors CoreImage. Details: https://sighack.com/post/averaging-rgb-colors-the-right-way
    enum AverageColorAlgorithm {
        case simple
        case squareRoot
    }
    
    func findAverageColor(algorithm: AverageColorAlgorithm = .simple) -> UIColor? {
        guard let cgImage = cgImage else { return nil }
        
        // First, resize the image. We do this for two reasons, 1) less pixels to deal with means faster calculation and a resized image still has the "gist" of the colors, and 2) the image we're dealing with may come in any of a variety of color formats (CMYK, ARGB, RGBA, etc.) which complicates things, and redrawing it normalizes that into a base color format we can deal with.
        // 40x40 is a good size to resize to still preserve quite a bit of detail but not have too many pixels to deal with. Aspect ratio is irrelevant for just finding average color.
        let size = CGSize(width: 40, height: 40)
        
        let width = Int(size.width)
        let height = Int(size.height)
        let totalPixels = width * height
        
        let colorSpace = CGColorSpaceCreateDeviceRGB()
        
        // ARGB format
        let bitmapInfo: UInt32 = CGBitmapInfo.byteOrder32Little.rawValue | CGImageAlphaInfo.premultipliedFirst.rawValue
        
        // 8 bits for each color channel, we're doing ARGB so 32 bits (4 bytes) total, and thus if the image is n pixels wide, and has 4 bytes per pixel, the total bytes per row is 4n. That gives us 2^8 = 256 color variations for each RGB channel or 256 * 256 * 256 = ~16.7M color options in total. That seems like a lot, but lots of HDR movies are in 10 bit, which is (2^10)^3 = 1 billion color options!
        guard let context = CGContext(data: nil, width: width, height: height, bitsPerComponent: 8, bytesPerRow: width * 4, space: colorSpace, bitmapInfo: bitmapInfo) else { return nil }

        // Draw our resized image
        context.draw(cgImage, in: CGRect(origin: .zero, size: size))

        guard let pixelBuffer = context.data else { return nil }
        
        // Bind the pixel buffer's memory location to a pointer we can use/access
        let pointer = pixelBuffer.bindMemory(to: UInt32.self, capacity: width * height)

        // Keep track of total colors (note: we don't care about alpha and will always assume alpha of 1, AKA opaque)
        var totalRed = 0
        var totalBlue = 0
        var totalGreen = 0
        
        // Column of pixels in image
        for x in 0 ..< width {
            // Row of pixels in image
            for y in 0 ..< height {
                // To get the pixel location just think of the image as a grid of pixels, but stored as one long row rather than columns and rows, so for instance to map the pixel from the grid in the 15th row and 3 columns in to our "long row", we'd offset ourselves 15 times the width in pixels of the image, and then offset by the amount of columns
                let pixel = pointer[(y * width) + x]
                
                let r = red(for: pixel)
                let g = green(for: pixel)
                let b = blue(for: pixel)

                switch algorithm {
                case .simple:
                    totalRed += Int(r)
                    totalBlue += Int(b)
                    totalGreen += Int(g)
                case .squareRoot:
                    totalRed += Int(pow(CGFloat(r), CGFloat(2)))
                    totalGreen += Int(pow(CGFloat(g), CGFloat(2)))
                    totalBlue += Int(pow(CGFloat(b), CGFloat(2)))
                }
            }
        }
        
        let averageRed: CGFloat
        let averageGreen: CGFloat
        let averageBlue: CGFloat
        
        switch algorithm {
        case .simple:
            averageRed = CGFloat(totalRed) / CGFloat(totalPixels)
            averageGreen = CGFloat(totalGreen) / CGFloat(totalPixels)
            averageBlue = CGFloat(totalBlue) / CGFloat(totalPixels)
        case .squareRoot:
            averageRed = sqrt(CGFloat(totalRed) / CGFloat(totalPixels))
            averageGreen = sqrt(CGFloat(totalGreen) / CGFloat(totalPixels))
            averageBlue = sqrt(CGFloat(totalBlue) / CGFloat(totalPixels))
        }
        
        // Convert from [0 ... 255] format to the [0 ... 1.0] format UIColor wants
        return UIColor(red: averageRed / 255.0, green: averageGreen / 255.0, blue: averageBlue / 255.0, alpha: 1.0)
    }
    
    private func red(for pixelData: UInt32) -> UInt8 {
        // For a quick primer on bit shifting and what we're doing here, in our ARGB color format image each pixel's colors are stored as a 32 bit integer, with 8 bits per color chanel (A, R, G, and B).
        //
        // So a pure red color would look like this in bits in our format, all red, no blue, no green, and 'who cares' alpha:
        //
        // 11111111 11111111 00000000 00000000
        //  ^alpha   ^red     ^blue    ^green
        //
        // We want to grab only the red channel in this case, we don't care about alpha, blue, or green. So we want to shift the red bits all the way to the right in order to have them in the right position (we're storing colors as 8 bits, so we need the right most 8 bits to be the red). Red is 16 points from the right, so we shift it by 16 (for the other colors, we shift less, as shown below).
        //
        // Just shifting would give us:
        //
        // 00000000 00000000 11111111 11111111
        //  ^alpha   ^red     ^blue    ^green
        //
        // The alpha got pulled over which we don't want or care about, so we need to get rid of it. We can do that with the bitwise AND operator (&) which compares bits and the only keeps a 1 if both bits being compared are 1s. So we're basically using it as a gate to only let the bits we want through. 255 (below) is the value we're using as in binary it's 11111111 (or in 32 bit, it's 00000000 00000000 00000000 11111111) and the result of the bitwise operation is then:
        //
        // 00000000 00000000 11111111 11111111
        // 00000000 00000000 00000000 11111111
        // -----------------------------------
        // 00000000 00000000 00000000 11111111
        //
        // So as you can see, it only keeps the last 8 bits and 0s out the rest, which is what we want! Woohoo! (It isn't too exciting in this scenario, but if it wasn't pure red and was instead a red of value "11010010" for instance, it would also mirror that down)
        return UInt8((pixelData >> 16) & 255)
    }

    private func green(for pixelData: UInt32) -> UInt8 {
        return UInt8((pixelData >> 8) & 255)
    }

    private func blue(for pixelData: UInt32) -> UInt8 {
        return UInt8((pixelData >> 0) & 255)
    }
}

The Results

As you can see, we don’t see any memory spike whatsoever from the call. Yay! If anything, it kinda dips a bit. Did we find the secret to infinte memory?

In terms of speed, it’s also about 4x faster. The Core Image approach takes about 0.41 seconds on a variety of test images, whereas the ‘Just Iterating Over Pixels’ approach (I need a catchier name) only takes 0.09 seconds.

These tests were done on an iPhone 6s, which I like as a test device because it’s the oldest iPhone that still supports iOS 13/14.

Comparison of Colors

Lastly, here’s a quick comparison chart showing the differences between the ‘simple’ summing algorithm, the ‘sum of squares’ algorithm, and the Core Image filter. As you can see, especially for the second flowery image, the ‘simple/sum’ approach seems to have the most desirable results and closely mirrors Core Image.

Okay, that’s all I got! Have fun with colors!

Trials and Tribulations of Making an Interruptable Custom View Controller Transition on iOS

Fri, 19 Feb 2021 15:41:43 -0400

I think it’s safe to say while the iOS custom view controller transition API is a very powerful one, with that power comes a great deal of complexity. It can be tricky, and I’m having one of those days where it’s getting the better of me and I just cannot get it to do what I want it to do, even though what I want it to do seems pretty straightforward. Interruptible/cancellable custom view controller transitions.

What I Want

I built a little library called ChidoriMenu that effectively just reimplements iOS 14’s Pull Down Menus as a custom view controller for added flexibility.

As it always goes, 99% of it went smoothly as could be, but then I was playing around in the Simulator with Apple’s version, and noticed with Apple’s you could tap outside the menu while it was being presented to cancel the presentation and it would smoothly retract. With mine, you have to wait for the animation to finish before dismissing. 0.4 seconds can be a long time. I NEED IT. The fluidity/cancellability of iOS’ animations is one of the most fun parts of the operating system, and a big reason the iPhone X’s swipe up to go home feels so nice.

Here is Apple’s with Toggle Slow Animations enabled to better illustrate how you can interrupt/cancel it.

Mine’s pretty simple. Just a custom view controller presentation that is non-interactive, using an animation controller and a UIPresentationController subclass. You just tap to summon the menu, and tap away to close it, not really anything interactive, and virtually every tutorial on the web about interactive view controller transitions have “the interaction” being driven by something like UIPanGestureRecognizer, so it didn’t seem really needed in this case. So it’s just an animation controller that animates it on and off screen.

Catch #1

Well, how do I make this interruptable? Say I manually set the animation duration to 10 seconds, and then programatically dismiss it 2 seconds after it starts as a test.

let tappedPoint = tapGestureRecognizer.location(in: view)
        
let chidoriMenu = ChidoriMenu(menu: existingMenu, summonPoint: tappedPoint)
present(chidoriMenu, animated: true, completion: nil)

DispatchQueue.main.asyncAfter(deadline: .now() + .seconds(2)) {
    chidoriMenu.dismiss(animated: true, completion: nil)
}

No dice. It queues up the dismissal and it occurs at the 10 second mark, right after the animation concludes. Not exactly interrupting anything.

Okay, let’s see. Bruce Nilo and Michael Turner of the UIKit team did a great talk at WWDC 2016 about view controller transitions and making them interruptible.

The animation is powered by UIViewPropertyAnimator, and they mention in iOS 10 they added a method called interruptibleAnimator(using:context:), wherein you return your animator as a means for the transition to be interruptible. They even state the following at the 25:40 point:

If you do not implement the interaction controller, meaning you only implement a custom animation controller, then you need to implement animateTransition. And you would do so very simply, like this method. You take the interruptible animator that you would return and you would basically tell it to start.

Which sounds great, as mine is just a normal, non-interactive animation controller. Let’s do that!

var animatorForCurrentSession: UIViewPropertyAnimator?
    
func interruptibleAnimator(using transitionContext: UIViewControllerContextTransitioning) -> UIViewImplicitlyAnimating {
    // Required to use the same animator for life of transition, so don't create multiple times
    if let animatorForCurrentSession = animatorForCurrentSession {
        return animatorForCurrentSession
    }
    
    let propertyAnimator = UIViewPropertyAnimator(duration: transitionDuration(using: transitionContext), dampingRatio: 0.75)
    propertyAnimator.isInterruptible = true
    propertyAnimator.isUserInteractionEnabled = true

    // ... animation set up goes here ...
    
    // Animate! 🪄
    propertyAnimator.addAnimations {
        chidoriMenu.view.transform = finalTransform
        chidoriMenu.view.alpha = finalAlpha
    }
    
    propertyAnimator.addCompletion { (position) in
        guard position == .end else { return }
        transitionContext.completeTransition(!transitionContext.transitionWasCancelled)
        self.animatorForCurrentSession = nil
    }
    
    self.animatorForCurrentSession = propertyAnimator
    return propertyAnimator
}

func animateTransition(using transitionContext: UIViewControllerContextTransitioning) {
    let interruptableAnimator = interruptibleAnimator(using: transitionContext)
    
    if type == .presentation {
        if let chidoriMenu: ChidoriMenu = transitionContext.viewController(forKey: UITransitionContextViewControllerKey.to) as? ChidoriMenu {
            transitionContext.containerView.addSubview(chidoriMenu.view)
        }
    }
    
    interruptableAnimator.startAnimation()
}

However, it still doesn’t interrupt it at the 2 second point, still opting to wait until the 10 second point that the animation completes. It calls the method, but it’s still not interruptible. I tried intercepting the dismiss call and calling .isReversed = true manually on the property animator, but it still waits 10 seconds before the completion handler is called.

After that above quote, they then state “However, we kind of advise that you use an interaction controller if you’re going to make it interruptible.” so I’m going to keep that in mind.

Catch #2

Even if the above did work, it has to be powered by a user tapping outside the menu to close it. This is accomplished in my UIPresentationController subclass by adding a tap gesture recognizer to a background view, which then calls dismiss upon being tapped.

override func presentationWillBegin() {
    super.presentationWillBegin()

    darkOverlayView.backgroundColor = UIColor(white: 0.0, alpha: 0.2)
    presentingViewController.view.tintAdjustmentMode = .dimmed
    containerView.addSubview(darkOverlayView)

    tapGestureRecognizer.addTarget(self, action: #selector(tappedDarkOverlayView(tapGestureRecognizer:)))
    darkOverlayView.addGestureRecognizer(tapGestureRecognizer)
}

@objc private func tappedDarkOverlayView(tapGestureRecognizer: UITapGestureRecognizer) {
    presentedViewController.dismiss(animated: true, completion: nil)
}

Problem is, all taps also refuse to be registered until the animation completes. And it’s not an issue with the UITapGestureRecognizer, adding a simple UIButton results in the same behavior where it becomes tappable as soon as the animation ends.

(Note: when switching to an interactive transition below, UIPresentationController becomes freed up and accepts these touches.)

All Signs Point to Interactive

Between the advice of the UIKit engineers in the WWDC video, and the fact it doesn’t seem interactible during the presentation, let’s just bite the bullet and make it an interactive transition. Plus, the WWDC 2013 video on Custom Transitions Using View Controllers states (paraphrasing) “Interactive transitions don’t need to be powered by gestures only, anything iterable works”.

My issue here is, what is iterating? It’s just a “fire and forget” animation from the tap of a button. Essentially the API works by incrementing a “progress” value throughout the animation so the custom transition is aware of where you’re at in the transition. For instance if you’re swiping back to dismiss, it would be a measurement from 0.0 to 1.0 of how close to the left side of the screen you are. There’s many examples online, Apple included, showing how to implement interactive view controllers powered by a UIPanGestureRecognizer, but I’m really having trouble wrapping my head around what is iterating or driving the progress updates here.

The only thing I could really think of was CADisplayLink (which is basically just an NSTimer synchronized with the refresh rate of the screen — 60 times per second typically) that just tracks how long it’s been since the animation started. If it’s a 10 second animation, and 5 seconds have passed, you’re 50% done! Here’s an implementation, after I changed my animation controller to be a subclass of UIPercentDrivenInteractiveTransition rather than NSObject:

var displayLink: CADisplayLink?
var transitionContext: UIViewControllerContextTransitioning?
var presentationAnimationTimeStart: CFTimeInterval?

override func startInteractiveTransition(_ transitionContext: UIViewControllerContextTransitioning) {
    // ...

    self.transitionContext = transitionContext
    self.presentationAnimationTimeStart = CACurrentMediaTime()

    let displayLink = CADisplayLink(target: self, selector: #selector(displayLinkUpdate(displayLink:)))
    self.displayLink = displayLink
    displayLink.add(to: .current, forMode: .common)
}

@objc private func displayLinkUpdate(displayLink: CADisplayLink) {
    let timeSinceAnimationBegan = displayLink.timestamp - presentationAnimationTimeStart
    let progress = CGFloat(timeSinceAnimationBegan / transitionDuration(using: transitionContext))
    self.update(progress) // <-- secret sauce
}

Again, this seems kinda counter intuitive to me. In our case time powers the animation, and we’re trying to shoehorn it into an interactive progress API by measuring time itself. But hey, if it works, it works.

But alas, it doesn’t.

Catch #3

The issue now is that, once the animation starts, it no longer obeys our custom timing curve. Mimicking Apple’s, we want our view controller to present with a subtle little bounce, rather than a boring, linear animation. But using CADisplayLink to power it results in the animation being shown with a linear animation, despite the interruptiblePropertyAnimator we returned looking like this: UIViewPropertyAnimator(duration: transitionDuration(using: transitionContext), dampingRatio: 0.75). See that damping? That’s springy! I even tried really spelling it out to the UIPercentDrivenInteractiveTransition with a self.timingCurve = propertyAnimator.timingParameters. No luck still.

But wait, that’s really weird. I use interactive view controller transitions in Apollo to power the custom navigation controller animations, and I distinctly remember it annoyingly following the animation curve during the interactive transition. I specifically had to program around this, because when you’re actually interactive, say following a user’s finger, you need it to be linear so that it follows the finger predictably.

Okay, so I check out Apollo’s code. Ah ha, I wrote it a few years back, so it uses the older school UIView.animate… rather than UIViewPropertyAnimator. Surely that can’t be it.

… It was it.

UIView.animate(withDuration: transitionDuration(using: transitionContext), delay: 0.0, usingSpringWithDamping: 0.75, initialSpringVelocity: 0, options: [.allowUserInteraction, .beginFromCurrentState]) {
    chidoriMenu.view.transform = finalTransform
    chidoriMenu.view.alpha = finalAlpha
} completion: { (didComplete) in
    if (isPresenting && transitionContext.transitionWasCancelled) || (!isPresenting && !transitionContext.transitionWasCancelled) {
        presentingViewController.view.tintAdjustmentMode = .automatic
    }
    
    transitionContext.completeTransition(!transitionContext.transitionWasCancelled)
}

It works if I use the old school UIView.animate APIs in startInteractiveTransition and remove the interruptibleAnimator method, and CADisplayLink perfectly follows the animation curve. Okay what gives, implementing interruptibleAnimator was supposed to bridge this gap, there’s even a question on StackOverflow about it but I suppose that question doesn’t say anything about animation curves. So, bug maybe?

End Result

So I guess that kinda works? But this all feels so hacky. I don’t like CADisplayLink much here, it seems to have a few jitters when dismissing as opposed to the first solution (only on device, not Simulator), and it would be nice to know how to use it with the newer UIViewPropertyAnimator APIs. I get a general “fragile” feeling with my code here that I don’t really want to ship, so I reverted back to the initial, non-interactive solution. (Additional minor thing that might not even be possible is that Apple’s also allows you to add another one as the existing one is dismissing, which my code doesn’t do and I didn’t even realize was possible.) And worst of all, you ask? CADisplayLink means “Toggle Show Animations” in the Simulator doesn’t work for the animation anymore!

(Maybe I just need to rebuild Apollo in SwiftUI.)

Here’s some gists showing the two final “solutions”:

A Call for Help

If you know your way around the custom view controller transition APIs and have any insight, you’d be my favorite person on the planet. Making animations more interruptible would be a fun skill to learn, I’m just at wit’s end with trying to implement it. I’ve linked the gists in the previous paragraph, and ChidoriMenu in its entirety with the non-interactive implementation is also on GitHub.

I’m curious if there’s a way to implement it without requiring an interactive transition, but if not, it’d be neat to know if it actually does require CADisplayLink, and if it does, it’d be neat to know what I’m still doing wrong in the above code, haha.

DMs are open on my Twitter, feel free to reach out (alternatively my email is me@ my domain name).

Logging information from iOS Widgets

Tue, 01 Dec 2020 16:09:32 -0400

Lately users have been emailing me with a few odd things happening with their Apollo iOS 14 home screen widgets, and some well-placed logs can really help with identifying what’s going wrong. iOS has a sophisticated built in logging mechanism, os_log, and now with SwiftLogger in iOS 14, but unfortunately they don’t provide an easy for users to provide you with the logs so they’re not optimal in this case.

Normally I use CocoaLumberjack for this in Apollo because a logging can be pretty complex and I like to use a battle-tested solution, but for whatever reason I cannot get it working in my Widget Extension. I’ve tried setting it up to log to the shared app group container as well as disabling async logging to no avail.

However this little logging use case in widgets is simple enough that I figure I’ll just whip up a simple little logger (per the suggestion of Brian Mueller), and I thought I’d include it here in case anyone else would benefit from it.

The main gist of it is that it writes to the shared app group container (make sure you have App Groups set up) so both the Widget Extension as well as the main app can access it. It uses just a single file (that is created if it doesn’t exist), and once it gets too long (I defined as 2MB) it trims the the older half of the logs so that the log file doesn’t bloat unnecessarily (it does this by just finding a newline near half point from the Data, rather than reading the entire String into memory). It also automatically capture the line, file, and function the issue occurs in. Per Florian Bürger be careful with using DateFormatter willy-nilly, I’m not encountering any performance issues, but if you encounter any consider caching the DateFormatter instance for reuse.

class WidgetLogger {
    static let fileURL: URL = {
        /// Write to shared app group container so both the widget and the host app can access
        return FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.christianselig.apollo")!.appendingPathComponent("widget.log")
    }()
    
    static func log(_ message: String, file: String = #file, function: String = #function, line: Int = #line) {
        let dateFormatter: DateFormatter = DateFormatter()
        dateFormatter.dateFormat = "MMM d, HH:mm:ss.SSS"
        let dateString = dateFormatter.string(from: Date())
        
        let timestampedMessage = "\(dateString) [\((file as NSString).lastPathComponent)/\(function)/\(line)]: \(message)\n"
        
        guard let messageData = timestampedMessage.data(using: .utf8) else {
            print("Could not encode String to Data.")
            return
        }
        
        if FileManager.default.fileExists(atPath: fileURL.path) {
            do {
                let fileAttributes = try FileManager.default.attributesOfItem(atPath: fileURL.path)
                let twoMegabytes = 2 * 1_024 * 1_024

                // In order to avoid having a log file that is enormous, trim out the oldest entries if file size is larger than 3 MB
                // (Checking file size is more performant than counting total lines each time)
                if let size = fileAttributes[.size] as? Int, size > twoMegabytes {
                    // Find the first newline after the halfway point in the file, and only keep everything past that point to trim the file
                    let logsData = try Data(contentsOf: fileURL, options: .mappedIfSafe)
                    let newlineData = "\n".data(using: .utf8)!
                    let dataSize = logsData.count
                    let halfwayPoint = Int(CGFloat(dataSize) / CGFloat(2.0))
                    
                    guard let range = logsData.range(of: newlineData, options: [], in: halfwayPoint ..< dataSize) else {
                        assertionFailure("A newline should have been found")
                        return
                    }
                    
                    let remainingLogs = logsData.subdata(in: range.endIndex ..< dataSize)
                    try remainingLogs.write(to: fileURL, options: .atomicWrite)
                }
                
                let fileHandle = try FileHandle(forWritingTo: fileURL)
                fileHandle.seekToEndOfFile()
                fileHandle.write(messageData)
                fileHandle.closeFile()
            } catch {
                print("Error trying to write to end of file: \(error)")
            }
        } else {
            do {
                try timestampedMessage.write(to: fileURL, atomically: true, encoding: .utf8)
            } catch {
                print("Error creating file to log to: \(error)")
            }
        }
    }
}

Usage:

WidgetLogger.log("Called getTimeline at \(Date())`)

You can then add a way for the user to email this file to you from within your app, I have a little “Logs” button that they can shoot over as part of troubleshooting. The code for attaching it to MFMailComposeViewController (which might not be the best choice with the iOS 14 feature of setting alternate email clients as the default, since that API doesn’t work with it yet) is:

if let data = try? Data(contentsOf: WidgetLogger.fileURL) {
    let mailViewController = MFMailComposeViewController()
    mailViewController.addAttachmentData(data, mimeType: "text/plain", fileName: WidgetLogger.fileURL.lastPathComponent)
}

Or add it as a file to a UIActivityViewController that they can share:

let activityViewController = UIActivityViewController(activityItems: [WidgetLogger.fileURL], applicationActivities: nil)

Or just make it into a String and do whatever you want with it!

String(contentsOf: WidgetLogger.fileURL, encoding: .utf8)

Anyway, that’s it! Happy logging!

Using PHPickerViewController Images in a Memory-Efficient Way

Sat, 26 Sep 2020 18:43:57 -0300

PHPickerViewController is (in my opinion) one of the more exciting parts of iOS 14. We developers now have a fully-fledged photo picker that we can just use, rather than having to spend a bunch of our time creating our own (much like SFSafariViewController did for developers and having to write in-app web browsers). Similar to SFSafariViewController it also has terrific privacy benefits, in that previously for our custom UIs, in order to show the pictures to choose from, we had to request access to all the user’s photos, which is not something users or developers really wanted to contend with. PHPickerController works differently in that iOS throws up the picker in a separate process, and the host app only sees the pictures that the user gave the app access to, and not a single one more. Much nicer!

(Note we did/still do have UIImagePickerController, but many of us didn’t use it due to the missing functionality like selecting multiple photos that PHPickerController does brilliantly.)

Apollo uses this API in iOS 14 to power its image uploader, so you can upload images directly into your comments or posts.

How to Use

The API is even really nice and simple to integrate. The only hitch I ran into is that the API callback when the user selects the photos provides you with essentially a bunch of objects that wrap NSItemProvider objects, which seemed a little intimidating at first glance versus something “simpler” like a bunch of UIImage objects (but there’s good reason they don’t do the latter).

Presenting the picker in the first place is easy:

var configuration = PHPickerConfiguration()
configuration.selectionLimit = 10
configuration.filter = .images
configuration.preferredAssetRepresentationMode = .current // Don't bother modifying how they're represented since we're just turning them into Data anyway

let picker = PHPickerViewController(configuration: configuration)
picker.delegate = self
present(picker, animated: true, completion: nil)

But acting on the user’s selections is where you can have some trouble:

func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) {
    /// What do I do here?! 👉🥺👈
}

In reality though, it’s not too hard.

What Not to Do

My first swing at bat was… not great. If the user selected a bunch of photos to upload and the images were decently sized (say, straight off a modern iPhone camera) the memory footprint of the app could temporarily swell to multiple gigabytes. Yeah, with a g. Caused some crashing and user confusion, understandably, and was quite silly of me.

At first my naive solution was something along the lines of (simplified):

var images: [UIImage] = []
        
for result in results {
    result.itemProvider.loadObject(ofClass: UIImage.self) { (object, error) in
        guard let image = object as? UIImage else { return }

        guard let resizedImage: UIImage = UIGraphicsImageRenderer(size: CGSize(width: 2_000, height: 2_000)).image { (context) in
            image.draw(in: CGRect(origin: CGPoint.zero, size: newSize))
        } else { return }

        images.append(resizedImage)
    }
}

Long story short, decoding the potentially large image objects into full-fledged UIImage objects, and especially then going and re-drawing them to resize them is a very memory-expensive operation, which is multiplied with each image. Bad. Don’t do this. I know better. You know better.

(If you’re curious for more information, Jordan Morgan has a great overview with his try! Swift NYC talk on The Life of an Image and there’s also an excellent WWDC session from 2018 called Image and Graphics Best Practices that goes even more in depth.)

What You Should Do

It’s a tiny bit longer because we have to dip down into Core Graphics, but don’t fret, it’s really not that bad. I’ll break it down.

let dispatchQueue = DispatchQueue(label: "com.christianselig.Apollo.AlbumImageQueue")
var selectedImageDatas = [Data?](repeating: nil, count: results.count) // Awkwardly named, sure
var totalConversionsCompleted = 0

for (index, result) in results.enumerated() {
    result.itemProvider.loadFileRepresentation(forTypeIdentifier: UTType.image.identifier) { (url, error) in
        guard let url = url else {
            dispatchQueue.sync { totalConversionsCompleted += 1 }
            return
        }
        
        let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary
        
        guard let source = CGImageSourceCreateWithURL(url as CFURL, sourceOptions) else {
            dispatchQueue.sync { totalConversionsCompleted += 1 }
            return
        }
        
        let downsampleOptions = [
            kCGImageSourceCreateThumbnailFromImageAlways: true,
            kCGImageSourceCreateThumbnailWithTransform: true,
            kCGImageSourceThumbnailMaxPixelSize: 2_000,
        ] as CFDictionary

        guard let cgImage = CGImageSourceCreateThumbnailAtIndex(source, 0, downsampleOptions) else {
            dispatchQueue.sync { totalConversionsCompleted += 1 }
            return
        }

        let data = NSMutableData()
        
        guard let imageDestination = CGImageDestinationCreateWithData(data, kUTTypeJPEG, 1, nil) else {
            dispatchQueue.sync { totalConversionsCompleted += 1 }
            return
        }
        
        // Don't compress PNGs, they're too pretty
        let isPNG: Bool = {
            guard let utType = cgImage.utType else { return false }
            return (utType as String) == UTType.png.identifier
        }()

        let destinationProperties = [
            kCGImageDestinationLossyCompressionQuality: isPNG ? 1.0 : 0.75
        ] as CFDictionary

        CGImageDestinationAddImage(imageDestination, cgImage, destinationProperties)
        CGImageDestinationFinalize(imageDestination)
        
        dispatchQueue.sync {
            selectedImageDatas[index] = data as Data
            totalConversionsCompleted += 1
        }
    }
}

Break it Down Now

There’s a bit to unpack here, but I’ll try to hit everything.

The core concept is we’re no longer loading the full UIImage and/or drawing it into a context each time (which can be monstrously large, and why PHPicker doesn’t just give us UIImage objects), especially because in my case I’m just uploading the Data and getting a resulting URL, I don’t ever need the image. But if you do, creating a UIImage from the smaller CGImage will be much better all the same.

Okay! So we start off with a queue, and the data to be collected. loadFileRepresentation fires on an async queue, and the docs don’t mention if it executes serially (in practice, it does, but that could change), so create a queue to ensure you’re not writing to this array of Data across multiple threads. Also note that the array itself is set up in a way that we can maintain the order of the images, otherwise the order the user selected the photos in and the order they’re processed in may not line up 1:1. Lastly we keep a separate counter to know when we’re done.

let dispatchQueue = DispatchQueue(label: "com.christianselig.Apollo.AlbumImageQueue")
var selectedImageDatas = [Data?](repeating: nil, count: results.count) // Awkwardly named, sure
var totalConversionsCompleted = 0

Moving onto the main loop, instead of asking NSItemProvider to serve us up a potentially enormous UIImage, we approach more cautiously by requesting a URL to the image in the tmp directory. More freedom.

result.itemProvider.loadFileRepresentation(forTypeIdentifier: UTType.image.identifier) { (url, error) in

We then go onto create a CGImage but with certain requirements around the image size so as to not create something larger than we need. These Core Graphics functions can seem a little intimidating, but between their names and the corresponding docs they paint a clear picture as to what they’re doing.

let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary

guard let source = CGImageSourceCreateWithURL(url as CFURL, sourceOptions) else {
    dispatchQueue.sync { totalConversionsCompleted += 1 }
    return
}

let downsampleOptions = [
    kCGImageSourceCreateThumbnailFromImageAlways: true,
    kCGImageSourceCreateThumbnailWithTransform: true,
    kCGImageSourceThumbnailMaxPixelSize: 2_000,
] as CFDictionary

guard let cgImage = CGImageSourceCreateThumbnailAtIndex(source, 0, downsampleOptions) else {
    dispatchQueue.sync { totalConversionsCompleted += 1 }
    return
}

Lastly, we convert this into Data with a bit of compression (only if it’s not a PNG though, PNGs are typically screenshots and whatnot, and I personally don’t want to hurt the quality of those).

let data = NSMutableData()

guard let imageDestination = CGImageDestinationCreateWithData(data, kUTTypeJPEG, 1, nil) else {
    dispatchQueue.sync { totalConversionsCompleted += 1 }
    return
}

// Don't compress PNGs, they're too pretty
let isPNG: Bool = {
    guard let utType = cgImage.utType else { return false }
    return (utType as String) == UTType.png.identifier
}()

let destinationProperties = [
    kCGImageDestinationLossyCompressionQuality: isPNG ? 1.0 : 0.75
] as CFDictionary

CGImageDestinationAddImage(imageDestination, cgImage, destinationProperties)
CGImageDestinationFinalize(imageDestination)

Now we have much smaller compressed Data objects kicking around, rather than our previously large UIImage objects, and we can POST those to an API endpoint for upload or whatever you’d like! Thanks to everyone on Twitter who gave me pointers here as well. In the end this went from spiking to in excess of 2GB to a small blip of 30MB for a few seconds.

Adopt this API! It’s great!

Apollo for Reddit 1.9

Sat, 12 Sep 2020 13:58:12 -0300

Apollo 1.9’s a massive update to Apollo that’s taken months and months to complete, but I’m really happy with the result, and it brings together a ton of ideas from the community to make Apollo even nicer to use. The update includes a variety of features around crossposts, flair, new app icons, translation, and quality of life improvements. Thanks to everyone who writes in via email or via the ApolloApp subreddit, your suggestions for what you want to see in Apollo help immensely and really motivate me to keep making Apollo better and better.

Without further ado, here are the changes included in this 1.9 update to Apollo:

Crosspost Viewing

Crossposting (taking an existing post and reposting it to a similar subreddit) has been a big part of Reddit for ages, but recently it became a full-fledged feature where you can see exactly which subreddit it came from, and quickly jump to the original post. Apollo now supports this fully, so you can see the interesting content of the post, but also quickly jump over to read the original discussion! Often it’s like getting two interesting discussions in one!

Crossposting

Similar to being able to view crossposts, you can also easily perform a crosspost if you want as well! Simply select the post you want to crosspost, write a title, select the subreddit to crosspost it to, and bam, you’re off to the races.

Image Flair

Flair is a little “tag” users can add to their usernames in subreddit, and some subreddits even allow small images/icons to be added in addition to text, like the icon for your favorite sports team, or a character from your favorite TV show. Apollo now shows these beautifully!

Setting Your Flair

In addition to being able to view the flair as discussed in the previous item, you can now set your own flair! Simply go to the subreddit of your choosing, and you can choose from a list of customizable flairs so you can add a little personality to your comments, showing which language you’re learning, your username in a video game the subreddit is about, your fitness goals, etc.

View Long Flair

Some users set loooong flair, and as a result it can get off, which can be annoying when you’re trying to figure out what it says. Well be annoyed no longer, for you can simply tap on the long flair to bring up a window that expands it fully!

Find Posts with Same Flair

If the subreddit lets users tag their posts with individual flairs (say, being able to tag whether your question is about a certain character, or a certain topic), you can now simply tap on that flair and Apollo will show you all the other posts in the subreddit that have been tagged with that same flair.

5 (Yeah, Five!) New App Icons!

This update has taken a ton of time to work on, and as a result I was slightly behind in including the Ultra icons I wanted to include, but as a result there’s now a proper Icon Bonanza, with five new icons being included in this update. The first three are Ultra icons, all made by the same incredibly talented designer, Matthew Skiles, who I’ve been a fan of for a long time. I love how these turned out, we have our beloved Apollo mascot reimagined as an angel, a devil, as well as a zany pilot, all in gorgeous, colorful iconography. But those three icons aren’t all! Next up, we have a beautiful new Apollo icon representing the trans pride flag (originally created by Monica Helms), which came out really awesome and is a great addition. And last but not least, our incredible community designer, FutureIncident, makes his second appearance with the Japanese-inspired Apollo-san icon! I love this set of icons so much, it’s going to be really hard to choose.

Easy Language Translation

Reddit is home to a diverse set of communities that have a variety of fascinating conversations, but sometimes it’s tricky to understand what’s being said if the conversation is in a language you’re not familiar with. Heck, you might even have no idea what the language is! Now Apollo will be able to detect if the language of a comment or post is different than the language of your iOS device, and if so, offer to quickly translate it so you can understand the conversation! It is so handy, whether you’re following a fascinating conversation or even trying to learn a new language!

Fast Subreddit Selector

Whethering you’re trying to add a single subreddit to a filter, or adding multiple subreddits at a time to a multireddit, Apollo is now even faster at doing these tasks, with an auto-completing window that makes it super fast to search and add subreddits.

Total Collapsed Comments & Remembering Collapsed Comments

Two handy new additions to collapsing comments in Apollo. The first, Apollo will show you at a glance how many comments are in the collapsed conversation, which can be super handy for viewing a comment thread. The second thing, if you collapse a bunch of comments, and then come back to that same comment section later, Apollo will now remember which comments you had collapsed, and keep them collapsed for you!

New Settings, Filters Tweaks, Bug Fixes, and More!

A bunch of awesome new settings have been added to Apollo, like being able to disable the auto-looping of videos with audio, or being able to make it so translation options always show up. Filtering is also even more powerful, with your filters being able to target flair and links as well (in addition to the title), and fixes a few filtering bugs. Apollo also now shows videos from Reddit’s experimental ‘RPAN’ service, which is essentially a kind of live stream post that you can now view within Apollo. Of course there’s a bunch of other small bug fixes around Apollo, from the occasional account accidentally signing out, to video bugs, to Apollo quitting in the background when it shouldn’t, as well as a bunch of other small tweaks across the app to improve your quality of life while browsing!

Thank You!

I really hope you enjoy the update, thank you for using Apollo! More great things to come!

The Case for Getting Rid of TestFlight Review

Fri, 12 Jun 2020 17:14:26 -0300

I tweeted today about how I think TestFlight review should become a thing of the past and many developers seemed to agree, but some had questions so I wanted to expand on my thoughts a little.

TestFlight’s awesome. But like App Store submissions, TestFlight betas also require a review by Apple. At first blush, such a review sounds sensical. TestFlight can distribute apps to up to 10,000 users. If that were to run completely unchecked you could have potentially mini-App Stores running around with sketchy apps being distributed to lots of people.

But the point I’ll try to make in this article is that the current system TestFlight employs doesn’t do much to prevent this, and further creates a lot of friction for legitimate developers.

The Review Process

For TestFlight, when you submit a new version number, it requires a new review. But new build numbers do not (build numbers are like a secondary ID for a version as it goes through development). For instance, I could push a new version of Apollo to TestFlight, version 1.8 (build number 50) and it would need review, but builds 51, 52, 53, etc. of the same version do not require any review.

The Problem

Do you see the issue here? There’s not really any oversight into what you can change in those new builds. You could completely change your app into something different, upload it under a different build number, and so long as the previous version was approved and you don’t change the version number, you could send the new one out to thousands of people.

Someone looking to distribute, say a console emulator (that Apple doesn’t allow in the App Store), could upload their app as a fun turtle themed calculator app (TurtleCalc™) and get approved on TestFlight, only to update it into that emulator for build 2 and send it out to thousands of people.

As a Developer

On the flip side, for an actual developer with an app on the App Store, it causes a ton of friction, because the other rule of TestFlight is such that once a new version goes live on the App Store, you can’t push any new builds to TestFlight without a new version and starting the review process again.

So if you find a bug in the public version of your app, and want to beta test the fix, you have to wait a day or two for it to be reviewed by Apple before it can even go into beta testing. A 3-lines-of-code bug fix requires re-review, meanwhile, if you’re a bad actor and you just leave the app in TestFlight without ever pushing it to the App Store, you can just update it endlessly without any review whatsoever.

That means as a developer you’re stuck in this gamble of “Should I just release it to the App Store without any testing? It’s just a bug fix after all, what could go wrong?” versus “Should I let it keep crashing and wait for the TestFlight review to occur so I can test this new build first, even if it means crashing for days more?”

In a perfect world, you could push that fix out to testers immediately, validate the fix, then submit it to the App Store.

As a result you have this system that A) doesn’t seem to do anything to stop people submitting nefarious updates but B) introduces a ton of friction to legitimate developers.

“It Serves as an Early Review for the App Store Before Continued Development”

Some argue that it lets you “test the waters” with an app or an update before submitting it to the App Store at large. For instance you have an idea that you’re not sure will get through app review, so you build a quick version of the app, and submit it to TestFlight, and the review will let you know if Apple will approve it.

Unfortunately it doesn’t work like that. Getting through TestFlight review has no bearing on getting through the eventual App Store review. I’ve had builds go through TestFlight review, get the stamp of approval, test it in TestFlight for months, and then when I ultimately submit it the update gets rejected.

TestFlight reviews are not at all an accurate way to gauge what the reviewers will think. It’s far more lax.

It Often Requires Double Review

Even more confusingly, if I decide to take the gamble and just release the bug fix to the App Store and hope all goes well, it’ll goes through a quick review, then it will go live on the App Store.

But if I want the TestFlight users to use that same version that just got approved, they straight up can’t. Even though it went through the more strict public App Store review, the exact same build has to be reviewed separately for TestFlight. This adds a confusing delay for testers (not to mention extra work for Apple) and is very weird.

TestFlight Review Takes Longer than App Store Review

Despite being more lax a review process (as shown above), it takes longer to review. This kinda makes sense, you would hope the majory of staff would be focused on the public App Store review which affects the most users, but it feels bizarre to submit an app to the App Store and TestFlight at the same time (because double review) and the App Store version goes out the same day while the TestFlight version takes a day or two.

This greatly disincentivizes testing builds when the process to actually get them out takes so long.

There’s Already Workarounds

A lot of developers, aware of the above constraints, employ strategies for getting around this process almost completely.

As soon as you submit the version to the App Store, you can immediately submit the same version plus one (so 1.8.3 on the App Store, 1.8.4 on TestFlight) even without any changes (just a bumped version number), get it through review, and then the next time you need to test a beta build you have an approved version you can start shoveling new builds onto.
An even more clever method some employ, is to just have an astronomically high version number only for TestFlight. So if your App Store version is 1.8, your TestFlight version is 1,0000. That way your TestFlight build is always ahead of the App Store version, and once that version gets approved the first time, you can indefinitely add new builds onto it. A lot of developers do this, and it’s clever, but I personally fear angering the App Store folks.

You might be asking, “Okay… why not just do one of those methods then?”. And you totally can, but in neither case is the app actually being reviewed, in the first it’s an identical version that’s tweaked “secretly” later, and in the second it’s a single version that gets tweaked forever. This effectively shows how little the review process actually contributes.

Getting Rid of TestFlight Review Could Speed up Normal Review

If TestFlight review were to go away for the reasons outlined above, all the awesome folks on that team could be relocated to the “normal” App Store team, which could see an even faster review process. The review process is so much better now than it has been in the past, typically under a day (it used to be over a week!), but can you imagine submitting a build and it being available within a few hours being the norm? That would be fantastic!

Solution

I think just getting rid of it completely is fair. As shown, the current process does next to nothing to prevent people from distributing questionable builds, and instead is just a pain for legitimate developers.

Is it possible that behind the scenes Apple re-reviews builds and might yank them if they find out they break their rules, say a game console app that’s been getting new builds but no new reviews from Apple for a year? Totally! And I think that’s the system they should simply extend everywhere.

Do away with the review system all together, and have a random review process that occurs after the fact, every so often, perhaps transparently and based on the amount of testers in the beta (a beta with 8,000 users is more dangerous than one with three people).

So you submit your version, it immediately goes out to all testers, and then a little while after Apple might flag it for random review. If it passes, it’s completely transparent to you. If it gets rejected, it’ll be pulled.

End

TestFlight’s great and I love it, but decreasing friction in beta testing would be a massive help.

Announcing Apollo: a new Reddit app for iPhone

Fri, 30 Jan 2015 19:38:21 -0300

I’m really excited to unveil a project I’ve been working on for the last year or so. It’s called Apollo and it’s a new Reddit app for iPhone.

I’ve been a Reddit user for about four years now, and the site is a constant source of interesting discussion, hilarity and news for me every day. I’ve never been completely happy with the current Reddit apps out there today, so I set out to scratch an itch and build the best Reddit experience on the iPhone that I could. And I’m really proud of the result.

Apollo went through a really long design phase, and I sweated every detail. Last Spring I was lucky enough to get an offer to work at Apple as an intern for the summer, which meant no time for developing apps for a few months. But after that summer, I learned so much from so many smart people, had a really cool new language to experiment with and my motivation to build something incredible had never been higher.

Since then I’ve been working super hard to build this app, and today I’m finally at a stage where I can comfortably announce it. It’s not available yet, and won’t be for a little while yet, but it’s getting close and I’d love to have some input. (I made a Reddit thread here) I’ll also be launching a public beta in the coming weeks, so keep an eye out for that if you want to get an early look at what’s to come.

I really put an emphasis on making Apollo feel at home on the iPhone with a super comfortable browsing experience. It has beautiful, large images, smooth gestures, really nicely organized comments and I baked in a lot of the great features that iOS 8 brought about. There’s a ton more as well. I also made sure that it took advantage of as many of Reddit’s great features as possible.

From a technical standpoint, it’s built for the most part in Swift. I’ve been really happy with the language so far (bar a few issuse) and it was awesome to build an app with it.

I’ve made a page where you can find out more about it, and if you’d like sign up to be notified when it’s released: https://apolloapp.io

I’d love to hear input. You can reach me on Twitter, post in the Reddit thread or email me if you’d like. I’ll also be posting updates on my dribbble page.

Can’t wait to share more in the coming weeks!