The Hidden Rules Behind 3D Assets for Apple Platforms
I come from code. But I have always been curious about the other side: why things are designed the way they are, and what technical reasons sit behind those decisions.
Most of the time, that question leads me to interfaces, to frameworks, to the logic underneath a product. This time it led me somewhere different. To geometry. To file formats. To the invisible rules that determine whether a 3D object looks right when it lands on an Apple ecosystem.
When you work with 3D content on Apple platforms, everything goes through USDZ. It is Apple’s preferred format for AR, Quick Look, and visionOS. A single file that carries geometry, materials, and scale information, and is supposed to just work across iPhone, Mac, and Vision Pro.
Except there are rules. Rules about how the geometry is structured, how materials are defined, how the file is oriented in space. Rules that are not obvious from the outside, and that the device does not explain when something goes wrong.
There is a gap between building a 3D model and having it look right on an Apple ecosystem. That gap has rules. Most of them are invisible until something breaks.
This article is about finding those rules the hard way.
The Model
Before the experiments, I needed something to work with. I built a simple low-poly pumpkin in Blender. Two objects, a body and a stem, 556 triangles total, solid orange and brown colors, exported as USDZ.
I kept it simple on purpose. When you are trying to understand why something behaves a certain way, a complex model adds too many variables. A simple one lets you isolate the cause.
This was my starting point:
- Triangles: 556
- File size: 24.95 KB
- Materials: solid orange body, dark brown stem
Experiment 1: Decimate
Every 3D model is made of triangles. Thousands of them, sometimes millions. Each triangle is a small flat surface, and together they form the shape of the object. The more triangles a model has, the more detail it can hold, but also the heavier the file and the more work it takes to render on a device.
When I started thinking about optimization, the first question that came to mind was simple: what happens if I just reduce the number of triangles?
Blender has a tool called Decimate that does exactly this. You give it a ratio, and it removes triangles automatically to hit that target. I set it to 0.5, cutting the triangle count roughly in half.
The numbers looked good:
- Triangles: 292 (47% fewer)
- File size: 16.8 KB (33% smaller)
The model did not.
The pumpkin ridges were gone. The organic shape that made it recognizable as a pumpkin was completely lost. What was left was an orange blob.
Here is why. Decimate does not know what the model is supposed to look like. It has no concept of which edges are important and which ones are just filling space. It removes triangles based on mathematical criteria, not visual ones. So it cuts the ridges just as easily as it cuts the flat areas, because from a purely geometric standpoint, a ridge is just a cluster of triangles with sharp angles between them.
This is the first hidden rule: optimization has to be shape-aware. Reducing triangle count is a valid goal, but a tool that does it blindly will always sacrifice the features that make the object recognizable. You have to decide which parts of the geometry matter and protect them.
Experiment 2: Smooth Shading
After the first experiment, I had a different question. The baseline model had a faceted, angular look because of flat shading. Every triangle was rendered as a separate flat surface, with visible edges between them. It looked like a low-poly object, which it was.
But I started wondering: does it have to look that way? And more importantly, does changing that require adding more triangles?
The answer to both questions surprised me.
Smooth shading is a technique that changes how light is calculated across a surface. Instead of treating each triangle as a flat face with its own lighting, it blends the lighting between adjacent triangles so the surface appears curved, even when the underlying geometry is still angular. No new triangles are added. The shape does not change at all. Only the way the surface interacts with light changes.
Get Fatima Shekarabi’s stories in your inbox
Join Medium for free to get updates from this writer.
I applied smooth shading with an Edge Split modifier set to a 30-degree threshold. The threshold controls which edges stay sharp and which ones blend. Anything sharper than 30 degrees would be kept as a hard edge, and everything else would smooth out.
- Triangles: 556 (unchanged)
- File size: 28.3 KB (slightly larger, because of additional normal data)
The surface looked smoother. The ridges held, though softer than in the flat-shaded version.
This is the second hidden rule: shading is a technical decision, not just a visual preference. The same geometry can look completely different depending on how normals are calculated. And the threshold you choose for edge splitting directly controls which features of the model stay defined and which ones disappear into the smoothed surface. Getting it wrong does not break the model. It just quietly removes the detail you were trying to keep.
Experiment 3: Axis Orientation
This one caught me off guard more than any other.
Blender uses Z as its up axis. If you build a model in Blender and it is standing upright, that means it is aligned along the Z axis. RealityKit, the framework that powers 3D content on Apple platforms, uses Y as its up axis instead.
This difference exists because different software and industries have different conventions. There is no universal standard. Most 3D tools handle the conversion automatically when you export. I wanted to see what happens when they do not, so I exported one version without correcting the axis.
- File size: 28.4 KB (same as before)
- In Quick Look on Mac: the pumpkin appeared flattened and compressed, as if it had been squashed from above
There was no error. No warning. The file opened without any indication that something was wrong. Quick Look just rendered the model with the wrong proportions, silently.
This is the third hidden rule, and arguably the most dangerous one: axis errors are invisible at the source and only show up on the target platform. A model that looks perfectly correct in Blender can look completely wrong in Quick Look, on iPhone, or on Vision Pro, and nothing in the export process will tell you why. The distortion is not dramatic enough to look like a crash. It just looks like something is slightly off, which can be very hard to trace back to its cause.
Experiment 4: Material vs No Material
For the last experiment, I wanted to test something more practical. There is a common assumption in 3D optimization that materials and colors add significant weight to a file. If that were true, removing them or simplifying them would be one of the first things you would do to reduce file size.
I exported two versions of the same model. One with the orange and brown solid color materials assigned. One with no materials at all.
- With material: 25.0 KB
- Without material: 24.2 KB
- Difference: 0.8 KB
Almost nothing. The assumption was wrong, at least for solid colors.
But the no-material version had a surprise waiting in Quick Look.
The model appeared bright magenta with vertical stripes across the surface. Not a style. An error color. In graphics rendering, magenta is the standard fallback that most engines use when they encounter a texture or material they cannot process. It is the visual equivalent of a 404.
After investigating, the cause turned out to be a small file inside the USDZ archive. A 465-byte EXR texture that Blender had quietly added from the scene’s World lighting setup, completely unrelated to the pumpkin itself. Quick Look cannot read the EXR format. So instead of ignoring it, it showed the error color.
The export that looked empty was not empty.
This is the fourth hidden rule: solid color materials have almost no impact on USDZ file size. Textures are the real driver of file size, specifically their resolution and format. And an export without materials in Blender is not a clean slate. The scene environment can silently add data to the file that has nothing to do with your model, and on Apple platforms that hidden data can cause errors that look completely unrelated to their actual cause.
What I Learned
Four experiments. Four rules, each hiding in a different layer of the pipeline.
Geometry reduction has to be intentional, not automatic. Shading is a technical decision that changes what the model looks like without changing its structure. Axis errors are silent and only appear on the target platform. And an export that looks empty might be carrying hidden data.
None of this is written in a single place. It becomes clear when you test things deliberately and pay attention to what breaks and why.
That is what I was looking for when I started this. Not just how to build a 3D asset, but why the decisions behind it matter.
