In this post I describe a recipe for exposing symbols implemented in Swift to Objective-C through a header file. The symbols supported are:
If you want to go straight to code you can use, check out my github project.
Car Nerd Time!
If you drive a manual transmission car you owe it to yourself to learn the “open palm” technique to eliminate missed shifts, especially during high-performance track driving.
The secret to never missing a shift is to not grip the shifter. If you do, bumps and jostles will easily shift the lever into the wrong position. Keep your palm open and relaxed, and be sure to apply forces only in the directions that result in a proper shift.
The open palm technique involves positioning your hand in various orientations and contacting the shifter only in certain locations that always result in the correct gear selection. After some practice, this will become so natural and subtle that you’d be able to do it without a thought.
Here’s what I mean. For these examples, I assume you’re driving a left-hand-drive car (e.g. US) so you’re using your right hand to shift. I also assume a standard H pattern, not a dogleg.
I find that a small amount of willful belief in magic goes a long way when learning something new.
As an experienced coder, I fall into the trap of prematurely analyzing how something works and constantly peeking under the hood while learning a new library, language, or abstraction. While the desire to disassemble toys to find out how they work is great, it often gets in the way of education.
I often have to force myself to accept magical behavior in order to keep progressing in my studies. Don’t look behind the curtain. Don’t worry too much about how that animation works, or how that sound is generated, or how that data got communicated. That level of curiosity is for later. For now, just accept things at face value—as simply magical—and continue your learning journey.
Remember that your goal is to be a knowledgeable novice at the end of the learning process. Don’t try to be an expert right away.
Don’t let experience get in the way of wonder.
The NSItemProvider class in Foundation is a powerful abstraction for making data available across processes that are otherwise isolated from one another. I hope this post can be a one-stop reference for developers who want a solid understanding how item providers work, and how to use the API in a modern way.
This section provides a history of NSItemProvider and its API surfaces. Feel free to skip it if you’re not interested.
NSItemProvider was introduced in iOS 8.0 to support passing data between an application and extensions. The interface introduced at that time relied heavily on runtime Objective-C introspection, and every extension point specified its own peculiar way in which apps had to provide and receive data.
When Drag and Drop for iOS was introduced in iOS 11.0, a new set of API was introduced on the class to meet new requirements: Swift made it impractical to use Objective-C introspection, and Drag and Drop needed a more consistent and generalized abstraction, since the source and destination processes could be any app or extension.
The introduction of UniformTypeIdentifiers in iOS 16.0 added a further extension to the class which uses UTType instead of String-typed identifiers for data type specifications. Methods to bridge between the Swift Transferable protocol and NSItemProvider were also introduced.
The existence of many historical layers in the NSItemProvider API makes it confusing for the contemporary developer to understand exactly what they need to use in their code. It is my hope that this post can help steer developers toward the best set of API to use in their apps.
NSItemProvider is a data promiseAn NSItemProvider is a promise to provide data. A provider constructs an NSItemProvider object and registers available data. It then passes the item provider to some system API which will make it available to some consumer which will load the data. The provider needs not provide any data up front—data is requested only when a consumer attempts to load it.
This is actually a great way to illustrate how much a billion dollars actually is!
According to Bricklink, a 1×2 Lego tile weighs 0.26 g. If each tile represents a dollar, this set would contain four billion tiles, clocking in at over one million kilograms. Delivering this number of bricks would require 49 standard cargo containers (each nominally rated at 21,600 kg).
Even if each tile represents $100, the largest denomination that US paper money comes in, we would still end up with more than 40 million tiles, weighing more than ten tons. Imagine holding a tiny Lego tile that you can sell for $100, and looking up to see that you have ten tons of it stored in a warehouse. That’s how much $4B is worth.
A billion dollars is an incredibly, mind-blowingly vast sum of wealth for one person to own today; an amount so huge that most people don’t really comprehend how large it is.
And once you realize how much $4B actually is, realize that Bill Gates has 29 times that amount, and Elon Musk has 62 times that amount.
Copyright ©2014–2025 Dave Rahardja. All rights reserved.
Any use of this website’s contents without prior written permission is subject to licensing fees.
You may not use any part of this website for machine training.