Objectionable-C

Ask not what Siri can do for you

Thu, 13 Aug 2026 08:00:00 -0800

iOS 27 introduces Siri AI, and Apple’s really excited about it. So excited that your app can get new “Ask Siri” options in UIMenus with no apparent opt out.

It seems like the OS is using some heuristics for choosing when to show this and when not to. I see it in some places in my apps, and not in others.

Kind of odd that there’s not an official way to opt out of these, so I did some digging to find if there’s some way to omit them.

I discovered that these UIActions are a bit odd, they lack a title and have a transient identifier.

However, they are all created using the +_intelligentAssistantActionWithIdentifier:configuration: class method on UIAction.

The injection of these happens via a C function after you’ve been queried for your menu items, so the best way I’ve found thus far to omit them is by swizzling +_intelligentAssistantActionWithIdentifier:configuration: to return nil or to hide it using UIMenuElementAttributesHidden.

Of course swizzling private methods should be done cautiously, but if you feel inclined this is a way to omit those “Ask Siri” entries!

Iconic loading

Fri, 30 Jan 2026 19:00:00 -0800

Showing your app’s icon in your app: seems like something you might want to do right?

Prior to iOS 18‘s introduction of home screen dark mode it was very easy to get your app’s icon, just use +imageNamed:. But in iOS 18 and higher to show your app’s icon you might need to package a separate copy or fetch it from a server just for this purpose.

https://mastodon.social/@kylebshr/112598769741895570

Well, it turns out that there is a place where iOS stashes a copy of your app’s icon that is accessible without these gymnastics. Xcode’s build process has created a separate copy of app icons for years that are embedded as files in your bundle.

These files are placed here presumably to be loaded by the system outside of springboard.

You can find the names of these files by looking at particular keys in your bundle’s infoDictionary.

From there you can enumerate the available files and pick the largest one to show. This is how I’m doing it.

@implementation NSBundle (AppIcon)

- (UIImage *)appIcon
{
 NSDictionary *const bundleIcons = self.infoDictionary[@"CFBundleIcons"];
 NSArray<NSString *> *const imageNames = bundleIcons[@"CFBundlePrimaryIcon"][@"CFBundleIconFiles"];
 UIImage *appIconImage = nil;
 CGFloat maxWidth = 0.0;
 
 for (NSString *const imageName in imageNames) {
 UIImage *const image = [UIImage imageNamed:imageName inBundle:self compatibleWithTraitCollection:nil];
 if (image.size.width > maxWidth) {
 appIconImage = image;
 maxWidth = image.size.width;
 }
 }
 return appIconImage;
}

@end

This even works with iOS 26’s new .icon file format!

Even .icon files are exported to the bundle

I’ve been using this trick in Opener for ages, and we’re now using it in Retro! It could be a good way to slim down your app a tiny bit.

Note: This only applies to your app’s default icon, if you provide alternate icons you’ll still need another way to show them.

Credit to this Stack Overflow answer where I originally got this idea from ages ago.

Ultra memory-friendly thumbnails on iOS

Fri, 08 Aug 2025 05:00:00 -1000

This week Retro has a fresh new look to the Friends widget. Where we used to only show a single post, we now show a grid of recent posts from your friends.

It’s not super well documented, but widgets have size restrictions on the images you can add to timeline entries. This combined with the very low memory limits imposed on iOS extensions (~30MB) has historically made loading images into widgets a bit of a headache. We got crashes while downscaling very often, even when using the efficient CGImageSource thumbnailing methods.

So, how do we go from showing one image per widget to showing a whole grid without blowing up the memory limit?

In the past I’ve heard of the QuickLook framework’s thumbnailing methods being designed explicitly for the low memory requirements of extensions, but nothing I’d worked on had warranted using them. To enable Retro’s grid widget I decided to give them another shot.

Per the docs (here and here), in order to get out-of-process thumbnailing you have to use the -saveBestRepresentationForRequest:toFileAtURL:... method that operates on files. You give it a file, and it hands you a thumbnail file back. I wasn’t expecting this API to work given that I hadn’t heard much about it before, but to my surprise it does exactly what it claims! The widget, even when processing many images, now barely consumes memory where it used to have a nonzero chance of running out.

Before, OOMing

After, comfortably under the memory limit

If you’re working in a memory constrained environment like widgets or extensions on iOS I highly recommend checking this out.

July 2026 Update

Paul Haddad reached out to me about using this API. Apparently there’s an undocumented upper limit on the size of thumbnails you can request from QuickLook of around 3.5 MP. If you request a thumbnail that’s too large you’ll get something an error QLThumbnailErrorDomain with code 0 and underlying error code 102. 3.5 MP is plenty for a widget, but might not work for other cases, something to bear in mind!

Trim the Fat: Static file tricks to slim down your app

Fri, 25 Jul 2025 05:00:00 -1000

I care deeply about keeping apps as small as possible. It’s our responsibility as iOS developers to preserve resources on our user’s devices.

I’ve detailed some strategies about compressing files and compressing particular file formats that you can use to reduce your app’s size, but what about files you can’t compress or change the format of? For example: third party libraries often bundle in plists and JSON, and you couldn’t compress those files without forking the library and changing how they’re loaded. Some libraries are closed source so you couldn’t even do this if you wanted to.

Well, it turns out there’s a little slack you can get from these files.

Plists

Plists have several different encodings under the hood: XML, binary, and JSON. Of these, binary often is the most compact and quickest to load, but sometimes the bulkier formats are bundled into your built app instead.

You can use the file command to inspect they underlying types of files. In this case a framework plist was using XML instead of binary

When loading plists the particular encoding doesn’t matter, so we can safely re-encode plists as binary as a build step to save on space. Furthermore, many other formats like .xcprivacy and .strings are actually plists under the hood, and we can re-encode those too.

JSON

The size of JSON files can be easily reduced by stripping out whitespace.

// These are equivalent
{
 "foo": [
 "bar",
 "baz"
 ],
 "xyz": 123
}

{"foo":["bar","baz"],"xyz":123}

For large JSON files this whitespace can be significant. For example: in Opener’s rule set JSON whitespace accounts for 45% of the original file size. We can safely strip out this whitespace as a build step to reduce JSON file size while preserving the original data. Just like plists, there are other formats like .ahap that are just JSON under the hood that we can also tidy up.

Putting it together

Using these strategies I’ve made a couple of scripts you can use to reduce your app’s size, available here. You can add them to your app using a build script step like the following.

if [ "${CONFIGURATION}" = "Release" ]; then

python3 Scripts/plist-minify.py
python3 Scripts/json-minify.py

fi

I only run these for release builds since they slow down the build slightly.

Examples

I use these scripts in all the apps I work on. In Retro they’re currently saving ~400 KB, not too bad for a build step that requires little maintenance!

What’s fun about these scripts is, since they run on fully built apps, you can run them on any app. Here are some other examples for apps I don’t have the source for.

In Cash app they save 333 KB
In Instagram they save 924 KB
In eufy they save 1.2 MB
In Xcode 16.4 they save 40 MB

If you’re looking for some low hanging fruit to reduce your app’s size I recommend trying these out!

Dub Dub Clickbait 2025

Fri, 06 Jun 2025 05:00:00 -0700

This is the least connected I’ve felt to WWDC in years, in fact I booked a flight during the keynote 🙃. That’s not to say my love for Apple has waned, I think maybe the dud that was Apple Intelligence last year just has me less tuned-in as most years. Nonetheless, I’m excited to see what they announce.

There’s always shiny new features during dub dub, but what I really love is quality-of-life refinements to mature APIs that I’ve used for ages. The canonical example I use is when iOS 15 introduced a dedicated image decoding API, or iOS 13’s introduction of first-party animated GIF playback. APIs that make you go “finally!”

A couple years ago I started recording little API wishes I had for Apple to put together a sort of “bingo card” for future WWDCs. I feel like publishing it is a little clickbait-y, but might as well in case it resonates with folks or developers at Apple might see it. Here’s what I’d love to see in no particular order:

Add a built in hex-to-UIColor method
Add a “Toast” UI component
Add images to actions in UIAlertController
Extended swipe to pop navigation controller gestures to full screen easily (like this)
Aesthetic text wrapping (like this)
Easily detect if text in UILabel/UITextView is truncated, provide alternates to fit
Tappable links in UILabel (like this)
Better share/action extension disabling rules
Auto-sizing UISheetPresentationController
Nav bar header customization via appearance proxy
Open up translate sheet to UIKit (like this)
More fine grained control of UIVisualEffectView
Get size of keyboard arbitrarily, without it even being shown
Expose NSDataCompressionAlgorithmBrotli (this)
A better way of creating launch screens (maybe more control over UILaunchScreen)
Make it so wireless debugging can be turned off
Allow typing :emoji-name: to autocomplete emojis in text fields
Allow double tap on hardware action button to trigger a specific action
Add “Unsubscribe” action to email notifications

Your Links, Your Way — Ten Years of Opener

Sun, 01 Jun 2025 13:40:00 -0700

Today Opener turns 10 years old. It’s safe to say Opener is the side project that I’m most proud of, and has had the most success on the App Store. I wanted to take some time to reflect on the past 10 years building it. This blog post won’t be too technical, it’s mostly a collection of little stories and thoughts.

History

Early Inspiration

The idea for Opener came about from a few things:

In my work at Flipboard at the time we were spending a lot of time building out rendering for various different content types. I remember we’d just added support for SoundCloud and we were talking about the possibility of building the SoundCloud waveform in our app and I thought: “This isn’t the best use of our time as a news app. We should really allow people to view this detail in SoundCloud if they want.”
I attended an event at Twitter HQ where they discussed Twitter Cards and how you could include metadata in them so Twitter could open links in your app. I remember thinking it would be cool if that worked everywhere, not just in Twitter.
There was an iOS Workflow (pre-Apple acquisition) / bookmarklet that was floating around that allowed people to open Tweets in Tweetbot and other apps. I remember feeling like I wished this worked for every link and every app.
My friend Jordan Kay tweeted about a Mac app he was working on that would open URLs in native apps named Lattice. (Coincidentally Opener now works great on Macs with Apple Silicon!)

The introduction of app extensions in iOS 8 was the catalyst that made it impossible for me to not build Opener. I saw app extensions as the perfect vessel for this functionality, allowing in-context actions to be taken on links.

Elevator Pitch

The elevator pitch for Opener is as true today as it was in 2015, so I’ll say it again.

People love the apps on their phones, and companies spend millions of dollars developing those apps, yet when you tap links from those companies instead of opening the app it launches a logged out, slow, subpar web experience. What if you could open links directly in apps where you get the best possible experience? That’s what Opener does.

Stories

I remember the week I started Opener. I was in my parents house in Broomfield, Colorado for Easter week when I got the first prototype working. This is the earliest screenshot of it I can find.
I learned a crapload about regular expressions while building Opener since it requires a lot of them. Turns out this is a really useful skill to have, and I’ve used it a bunch of times in my career since.
I clearly remember the day Opener launched, June 1, 2015. It was a Monday and I had my summer intern starting that day, so I wasn’t really thinking about it. I used Buffer to pre-schedule all the posts about the launch, but towards the end of the day a few people I worked with were like “hey, whoa, you launched this today? This is cool.” Over the week a few blogs wrote about it, which made me really happy. At the end of the week our CTO Eric Feng gave me a high five for being “crunched”.
WWDC 2015 was the week after Opener launched. I was terrified when Apple announced universal links in iOS 9, which could effectively replace Opener. As it turned out over time, universal links only really work for first-party apps, and they don’t work that well in general anyway. Opener still serves people very well when they want control over opening links, or when universal links bug out as they’re prone to.
I designed the original icon in code as a UIView, but it wasn’t exactly beautiful. Fortunately I started dating somebody in 2016 (now my wife) who was much better at design than me and she agreed to give the icon an overhaul. The icon she designed is still the one that app uses today!
- Side note: I had hundreds of stickers of the original icon printed and I’ve given away maybe 50 total. If you live and the US and you want one shoot me a DM and I’ll mail it to you.
In iOS 14 Apple limited the number of URL schemes you could include in LSApplicationQueriesSchemes to 50. I was nervous that people might be frustrated that Opener could no longer detect which apps were installed since it supported over 200 apps, so I continued to link Opener with the iOS 14 SDK for almost a whole year. I had a dedicated Mac mini that I kept on the old OS so I could continue to use the old Xcode to build it. Finally, when I looked, it turned out that 95% of links opened in Opener are within its top 50 most popular apps. I released the update that limited the list to 50 and I’ve gotten nearly zero complaints about it since.
The week in 2022 when I was in the hospital after my first child was born I was alerted to the fact that somebody had cloned Opener. I was in an emotional state already, and this made me pissed. Up until this time I’d left Opener’s rule set as open source for people who wanted to contribute, but when reading the source for this clone’s JS I saw it clearly just copied the whole thing. I rapidly made Opener’s rule set private and hardened up security about how the app loads it. Since then a few more clones have popped up, but it seems like they’ve mostly become stale and forgotten.
I sent the source code for Opener to the moon thanks to a kind person on Reddit! Sadly, it didn’t make it and burned up returning to Earth in January 2024. Still cool though.
I applied for and got to attend Apple‘s developer labs for the Vision Pro on the Vision Pro’s launch day to test out Opener! While I was there the cranky engineer running the lab told me that Apple wasn’t going to add an API for detecting if an iPad app is running on Vision Pro. Afterwards I figured out how to detect this anyways and it still seems to be how people do it these days. A few months after the Vision Pro launch I bought and returned one within the two week window to fix a bug one of my users was only encountering on Vision Pro.

Stats and Factoids

The stat I care most about for Opener is how many links are being opened in it. While I don’t have a 100% accurate picture of this number over the last 10 years, I’ve been able to patch together a pretty good approximation.

8.2 million total links opened

Here are the total copies of Opener sold over the past 10 years.

83,693 total units sold

Here’s the proceeds I’ve made from Opener in this time.

$122,997 total proceeds

A vast majority of the links opened go through the action extension instead of the app itself. I still hold that app extensions are my favorite feature ever added to iOS because of this.

The Future

Opener is feature rich, stable, and capable of meeting my users’ needs. I’m very cautious about not enshittifying it by tacking on unneeded features, and when I do add new features they’re appropriately buried under the app’s core functionality. I plan to be the best platform citizen I can, and to take advantage of new platform features that make sense for Opener as best as I possibly can. I also plan to continue to add support for opening more and more apps over time. This app is a labor of love, and I plan to keep it a well oiled machine for as long as I’m around.

Here’s to the next 10 years!

No-nonsense UISceneDelegate migration reference

Fri, 16 May 2025 05:00:00 -0700

I’ve avoided migrating to using the UIScene-based application lifecycle since it was announced with iOS 13 because:

None of my apps support multiple windows (the main reason for UIScene to exist afaict)
I preferred the older, simpler methods of dealing with app events via UIApplicationDelegate.

I’ve also seen numerous apps break in weird ways due to differences in behavior between UIApplicationDelegate and UISceneDelegate. Most notably, several events that get their own methods in UISceneDelegate are handled completely differently on cold start when a scene is being spun up. This often causes URL handling and shortcut handling to break on cold start. Another common source of issues is that app delegate lifecycle methods (didBecomeActive/didEnterBackground/etc.) are no longer called, even though the notifications for those events are still fired 🤔.

It seems that as of iOS 18.4 Apple is starting to force developers towards using the UIScene-based lifecycle, so I took a stab at porting my apps over.

I’ve created a project named TJSceneDelegate that should more or less acts as a drop in replacement in any app. When installed it forwards all events to UIApplicationDelegate, the thought is that you should then be able to forget about scenes and use the app delegate callbacks like you used to. At the moment I’ve ported all but one of my side projects over to this, and I’m going to migrate the final one soon.

I hope this can serve as a solution or a reference for others migrating to the UIScene-based lifecycle.

Save space using compact fonts

Wed, 30 Apr 2025 05:00:00 -0700

Disclaimer: I’m not a font expert. The strategy pitched in this post may have drawbacks I haven’t yet discovered.

Last week at work we were importing a new font to use in some countries that was rather large. The designer I was working with managed to slim it down a bit, but it still wound up being 14 MB. This got me thinking if there was a way to reduce the size further.

I asked my favorite coding companion AI, Claude, for advice. Claude mentioned trying out the newer font format .woff2, developed by Google for compactness. I initially dismissed this idea thinking that iOS only supports .ttf and .otf, but upon trying it I’ve found that .woff2 does work on iOS!

It’s trivial to convert existing fonts to .woff2 with a tool you can get through homebrew.

# Install Google's woff2 tool
brew install woff2

# Convert a font to woff2
woff2_compress [your_font_here]

You’ll then need to update and references to the old font name containing its former file extension, most commonly in the info.plist UIAppFonts field. Once you do this everything should work!

This wound up saving:

10.9 MB on the new font we imported (14.1 MB → 3.2 MB, 78% reduction)
An additional ~800 KB (1.2 MB → ~400 KB, ~65% reduction) in the other fonts we use in Retro.

I also applied this strategy to the font I’m using in Burst saving 71KB, close to 10% of the app’s overall size.

Font savings in Burst

I can’t find definitive documentation of when iOS added support for .woff2, but it’s been supported in Safari since iOS 10. This seems like it could be a reasonable proxy for OS support, and I’ve tested it working as far back as iOS 15.8.4.

If you’re looking for places to reduce your app’s size and you’re using custom fonts, leveraging .woff2 could be a good way to get some savings!

May 2026 Update

Apple is starting to reject apps embedding woff2 fonts claiming they’re unsupported. They seem to be detecting these fonts by inspecting file contents, not just looking for the file extension, so a simple rename will still result in rejection. woff2 files have a predictable prefix, so you can still embed them by manipulating the contents of the bundled file then changing them back and loading at runtime.

Storing custom metadata in PHAssets

Fri, 18 Apr 2025 05:00:00 -0700

PHPhotoLibrary is a powerful resource that lets you interact with one of iOS’ most vital components as a developer. We’re lucky to have it compared with a lot of other OS features that provide little or no developer access.

In the past I’ve wanted to add small bits of custom information to PHAssets, however PHAsset doesn’t provide a way to do this. As a workaround you could add custom Exif or video metadata to the asset at write time, then load the asset, extract that data, and parse it at read time, but that could be relatively slow since fetching PHAsset resource data can be iCloud-backed. Additionally, if downscaled data is returned from PHAsset, that metadata could be stripped. I wanted a quick way to stash a small amount of information in PHAssets.

What I found is PHAssetResource. PHAssetResource can be used when writing PHAssets to add fine-grained file representations of assets, but there’s a field within it that can be used to add arbitrary strings: the originalFilename. You can set the original filename to whatever you’d like like so

PHAssetCreationRequest *creationRequest = [PHAssetCreationRequest creationRequestForAsset];
PHAssetResourceCreationOptions *options = [PHAssetResourceCreationOptions new];
options.originalFilename = /*Filename of your choice, including custom info*/;
[creationRequest addResourceWithType:... data:... options:options];

Note: I recommend using the correct file extension for whatever type your using when setting originalFilename as mismatches can lead the Photos framework to fail.

And you can get the original filename from a PHAsset without loading the entire data from the asset.

for (PHAssetResource *const resource in [PHAssetResource assetResourcesForAsset:asset]) {
 NSString *originalFilename = resource.originalFilename;
 // Use originalFilename
}

PHAssetResource seems to be a part of PHAsset’s metadata, so it doesn’t require an additional load of the full underlying data to retrieve. It’s quick.

Here’s how I’m leveraging this:

Close-up includes IDs in filenames when writing to PHPhotoLibrary so that I can later tell if the photo has already been written and skip re-writing it in certain cases.
Burst includes a hash of the params used to create media in filenames so that I can reuse assets previously saved to the photo library instead of generating new ones.
Retro includes photo IDs in filenames so we can count photos that are uploaded then saved to the local device as “already uploaded” instead of as new assets.

If you’re looking to store a bit of extra info in PHAssets this could be a great way to do it!

Tagged pointer string keys

Mon, 31 Mar 2025 05:00:00 -0700

This blog post by Mike Ash about how tagged pointer strings work in Objective-C is fantastic, one of my favorites. It details under what circumstances NSStrings become tagged pointers instead of full objects. Tagged pointers have performance and space efficiency benefits over full objects by bypassing heap allocations.

After reading this a few years ago I was inspired to find a “nail” for the proverbial “hammer” it discusses: I wanted to find places where I could leverage tagged pointer strings in a substantial way. One or two uses of tagged pointer strings probably doesn’t make a big difference, so I was looking for subsystems where many strings were allocated that I could switch over to tagged pointer strings.

Image caches commonly use hexadecimal hashes of the image URLs they’re loading as keys at runtime and for filenames when storing on disk. My image cache, TJImageCache, was doing just this. Migrating TJImageCache’s keys to use tagged pointer strings seemed liked the perfect use of this strategy since many cache keys are created and held in memory and the cost of switching to new keys was very low.

The hex strings of common hashes are too long to be tagged pointer strings, commonly 32-64 characters, so I had to come up with a new way of converting hashes into strings. I wanted to generate maximally unique keys that were still tagged pointer strings and also valid, “clean” filenames (meaning there were no .s or spaces in them even though those are valid). Following the guidelines from Mike’s post, it seems like constructing 11 character strings from the following 30 character table creates the most unique key while still being a good filename.

eilotrmapdnsIcufkMShjTRxgC4013

I implemented the following function to create these keys from URL strings

static char *const kHashCharacterTable = "eilotrmapdnsIcufkMShjTRxgC4013";

NSString *TJImageCacheHash(NSString *string)
{
 unsigned char result[CC_SHA256_DIGEST_LENGTH];
 CC_SHA256([string UTF8String], (CC_LONG)string.length, result);
 
 return [NSString stringWithFormat:@"%c%c%c%c%c%c%c%c%c%c%c",
 kHashCharacterTable[result[0] % 30],
 kHashCharacterTable[result[1] % 30],
 kHashCharacterTable[result[2] % 30],
 kHashCharacterTable[result[3] % 30],
 kHashCharacterTable[result[4] % 30],
 kHashCharacterTable[result[5] % 30],
 kHashCharacterTable[result[6] % 30],
 kHashCharacterTable[result[7] % 30],
 kHashCharacterTable[result[8] % 30],
 kHashCharacterTable[result[9] % 30],
 kHashCharacterTable[result[10] % 30]
 ];
}

(Source)

I then plugged this in and voila, tagged pointer strings keys showing in TJImageCache’s internals.

Another place where this strategy could be beneficial is when generating random identifiers. I haven’t done this in any apps in practice, but it could make sense for a logging framework or something that winds up creating a lot of IDs. These IDs certainly aren’t as random as UUIDs (54 bits of entropy versus 122), but they may be good enough depending on your use case.

Is any of this necessary? Definitely not, but hey it feels good to make things a little more efficient. If you look around in your projects you might find uses for tagged pointer strings too!

gzip yer uploads

Mon, 24 Mar 2025 06:00:00 -0700

NSURLSession opaquely handles HTTP negotiations about accepting compressed content and does the decompression (using formats like gzip and brotli) before you receive responses, which is great. Foundation, Apple’s OSes, and the web are doing work that we as developers don’t have to so our users consume less data and have a faster experience. Hooray! I’ve always been impressed that this happens pretty much auto-magically without having to think about it.

However, I had a thought late in 2024 about transmitting data the other way: uploads. While looking I realized there’s not automatic upload compression built into NSURLSession. I’m sure there are good reasons for this, but I figured that some of the APIs I was using could accept compressed uploads. It turns out I was right, Mixpanel and Dropbox both accept compressed data.

Here’s how I’m doing the compression itself

#import <zlib.h>

// Function that gzips data
// Thanks Claude https://tijo.link/BGdVNx
static NSData *_gzipCompressData(NSData *const data, NSError **error) {
 if (!data.length) {
 if (error) {
 *error = [NSError errorWithDomain:@"CompressionErrorDomain" code:1
 userInfo:@{NSLocalizedDescriptionKey: @"Invalid input data"}];
 }
 return nil;
 }
 
 z_stream strm;
 strm.zalloc = Z_NULL;
 strm.zfree = Z_NULL;
 strm.opaque = Z_NULL;
 
 // Initialize deflate with gzip format
 if (deflateInit2(&strm, Z_DEFAULT_COMPRESSION, Z_DEFLATED, 15 + 16, 8, Z_DEFAULT_STRATEGY) != Z_OK) {
 if (error) {
 *error = [NSError errorWithDomain:@"CompressionErrorDomain" code:2
 userInfo:@{NSLocalizedDescriptionKey: @"Failed to initialize compression"}];
 }
 return nil;
 }
 
 // Set up input
 strm.avail_in = (uInt)data.length;
 strm.next_in = (Bytef *)data.bytes;
 
 // Prepare output buffer (compress can increase size)
 NSMutableData *compressedData = [NSMutableData dataWithLength:data.length * 1.1 + 12];
 strm.avail_out = (uInt)compressedData.length;
 strm.next_out = compressedData.mutableBytes;
 
 // Compress
 if (deflate(&strm, Z_FINISH) != Z_STREAM_END) {
 deflateEnd(&strm);
 if (error) {
 *error = [NSError errorWithDomain:@"CompressionErrorDomain" code:3
 userInfo:@{NSLocalizedDescriptionKey: @"Compression failed"}];
 }
 return nil;
 }
 
 // Cleanup and finalize
 [compressedData setLength:strm.total_out];
 deflateEnd(&strm);
 
 return compressedData;
}

(You could also use a library like this one if you don’t want to hand write the compression.)

Then, if using a data task:

NSData *compressedData = _gzipCompressData(originalData, &err);
NSURLRequest *request = ...;
[request setValue:@"gzip" forHTTPHeaderField:@"Content-Encoding"];
[request setHTTPBody:compressedData];
// Start a data task using request and an NSURLSession

or an upload task:

NSData *compressedData = _gzipCompressData(originalData, &err);
NSURLRequest *request = ...;
[request setValue:@"gzip" forHTTPHeaderField:@"Content-Encoding"];
[urlSession uploadTaskWithRequest:request fromData:compressedData];

With this you can shave a few percent off your upload sizes saving bandwidth and time!

Here are examples where I’m doing this in TJMixpanelLogger and TJDropbox.

The case for launch xibs

Fri, 21 Mar 2025 06:00:00 -0700

I’m obsessed with keeping apps small, and I recently found an unlikely place to save a couple KB: launch screens. The default on iOS for a while has been to create a launch storyboard for your app, but launch storyboards are bundles that wrap a few files.

The innards of a compiled storyboard

Many launch storyboards don’t use any functionality that isn’t also available in the simpler, older xib format. I copied and pasted the launch screens from within the .storyboard into a freshly made .xib and the results saved 1.2 KB.

Make a new empty xib file with the same filename as your storyboard

Copypasta

Remove the launch screen file extension from your info.plist if there is one

Resulting file size savings

It’s just a couple KB, but in apps that are <2 MB like Opener every KB counts!

You could save even more space by using the relatively new UILaunchScreen info.plist key, but that lacks some of the customizability of launch storyboards/xibs.

Side note: Opener has two launch screens, one for iPhone and one for iPad, so this savings is doubled

Wielding Brotli on iOS

Tue, 18 Mar 2025 05:00:00 -0700

Brotli is a compression format introduced by Google some time ago that is really excellent at compressing text. Brotli is widely supported across the web and has been supported on all of Apple’s platforms since 2017. A lot of the web traffic you receive is probably brotli compressed, but many of the iOS developers I talk to have never heard of it.

Brotli decompression happens automatically when fetching things from the network using NSURLSession, just as it does with gzip. If you were motivated to manually decompress brotli data you could import the Compression framework and write some C code using compression_decode_buffer to do it, but that’s not super approachable. It turns out there’s a simpler way: NSData actually has a hidden enum value that does brotli decompression for you!

NSData *decompressedData = [brotliData decompressedDataUsingAlgorithm:NSDataCompressionAlgorithmZlib + 1 error:nil];

I discovered this in 2023 and have taken advantage of it the reduce the size of bundled assets in many of my apps. Here are some examples:

Opener's rule set JSON file. Original size: 168 KB.

Opener's en localized strings. Original size: 13 KB

I care deeply about conserving storage on my users’ devices, and this has become an excellent tool to use for reducing app size. Hopefully Apple makes this enum value public in the future! (FB16918276)

You can install brotli from homebrew and use it to compress files with ease! I often do this as a build step that applies only to release builds so that I can continue using the original files while debugging the app.

If you’d ever like to compress to brotli within an app, the Compression framework has a method for doing so using COMPRESSION_BROTLI at level 2. If you’d ever like to compress to brotli yourself using level 11 (the highest) there are several open source iOS projects for it. I forked a popular one here and have been using it.

I plan to reference this in future posts about more aggressive app shrinkage ideas in the future. Happy compressing!

Update: Here’s an example of where we’re using this to save some space in Retro.