Last week I had the pleasure of attending Try! Swift Tokyo as a speaker — the 10th edition of one of the best Swift conferences in the world. Between the incredible talks, the hallway conversations, and the energy of being surrounded by passionate developers, it was an experience I won’t forget easily.

I was selected to run a workshop on SwiftUI + Metal. I prepared four hands-on examples designed to give attendees a real feel for what Metal shaders can do — not just “here’s a cool effect”, but a genuine understanding of how it works from the ground up. This post covers the first one: an animated dotted background that reacts to touch.

Why this example?

I wanted to start somewhere that felt magical but stayed focused. The shader is applied to the entire background, and everything — every dot, every animation — is drawn in code on the GPU. There’s no UIKit, no SpriteKit, no assets. Just math.

It supports three modes:

• Glow — dots near your finger grow and brighten
• Attraction — dots pull toward your touch like a magnet
• Repulsion — dots scatter away from wherever you press

Before we start, you can find a deep dive article with interactive examples at metal.graphics/dotted-background-interactive — This medium post highlights the most important parts.

The key ideas

1. Shaders run per pixel, in parallel

A Metal shader isn’t a loop. It’s a function that runs simultaneously for every pixel on screen. Your job is to answer one question for each pixel: what colour should I be?

Color.black
    .colorEffect(
        ShaderLibrary.dottedBackground(
            .boundingRect,
            .float2(touchPosition.x, touchPosition.y),
            .float(Float(mode.rawValue)),
            .float(Float(intensity))
        )
    )

SwiftUI passes your uniforms — canvas size, touch position, mode, intensity — directly to the GPU on every frame.

2. Drawing a circle with SDF

There’s no “draw circle here” API. Instead, for every pixel, you ask: am I inside or outside the circle?

float dist = radius - length(uv - center);
float circle = smoothstep(-0.02, 0.02, dist);

dist is positive inside, negative outside. smoothstep converts that into a smooth 0–1 mask — which gives you antialiased edges.

3. Tiling with fract()

One dot is easy. Four hundred dots is just fract().

float2 cellUV = fract(uv * float2(cols, rows));
float dist = radius - length(cellUV - 0.5);

fract() strips the integer part of a number, leaving only the fractional remainder. Scale UV by 40, take fract, and you get 40 columns each with their own fresh 0–1 coordinate space. The SDF circle runs identically inside every “cell”.

4. Connecting dots to touch with floor()

fract() tells a pixel where it is inside its cell. But to react to touch, each dot needs to know where it sits in world space — so it can measure its distance to your finger.

That’s floor():

float2 scaled = uv * grid;
float2 cellIndex = floor(scaled);
float2 dotWorld = (cellIndex + 0.5) / grid; // dot centre in UV space
float touchDist = length(dotWorld - touchUV);
float influence = 1.0 - smoothstep(0.0, influenceRadius, touchDist);

influence is 1 at the touch, fading smoothly to 0 at the edge of the radius. Feed that into mix() to scale radius and brightness.

5. Moving dots — a coordinate trick

Here’s the part that surprises people: there are no dots to move. A dot isn’t an object. It’s a question asked of every pixel. You can’t push it.

What you can do is shift the dot’s logical center before asking the question:

// Repulsion - push center away
 dotCenter -= dir * (influence * maxDisplacement);
// Attraction - one sign flip
 dotCenter += dir * (influence * maxDisplacement);

The GPU still renders everything in place. But by moving where the dot thinks its center is, the effect looks exactly like motion.

6. Fixing clipping at cell boundaries

One subtle issue: when a dot is displaced far enough, it crosses into a neighbouring cell and gets clipped. The fix is a 3×3 neighbourhood check — for each pixel, evaluate 9 candidate dots and keep the brightest one.

for (int dy = -1; dy <= 1; dy++) {
 for (int dx = -1; dx <= 1; dx++) {
 // evaluate neighbor's dot, keep best result
 }
}

Nine times more math per pixel — but the GPU handles it without breaking a sweat. This is exactly what it’s built for.

The result

A 130-line Metal shader that produces a fully interactive dot field, responsive to touch on iOS and hover on macOS, with three distinct behaviors controlled by a single mode uniform.

The complete shader, all six build steps with interactive previews, and the full SwiftUI wiring are at metal.graphics/dotted-background-interactive

Each step is runnable in the browser — you can move your cursor over the previews to interact with the shader live, and see exactly how each concept layers on top of the last.

If you’re curious about Metal shaders more broadly, the full course is at metal.graphics

I’ve been learning Metal and working on metal.graphics since early last year.

While going through examples, writing content, and experimenting with different effects, I kept running into the same issue over and over: even with SwiftUI previews, the feedback loop when working on Metal shaders is still quite disruptive.

Previews are powerful, and they’ve come a long way, but when you’re fine-tuning shader values or experimenting with animations, the constant reloading adds a ton of friction. And when you’re learning or exploring, that friction adds up quickly.

I am not a 3D expert at all, but I do like to play with 3D tools like Blender or Spline. Blender is an amazing software, and at some point in the past they added a node graph. I did have so much fun playing with it, the realtime and ease of use makes for a great experience. The node editor makes data flow explicit. You’re not just writing code, you’re seeing how values move through operations. That mental model maps very well to how shaders actually work.

The goal was simple: preview and tweak Metal shaders in real time, without constantly rebuilding or switching context. I wanted something where I could focus on the shader itself, not on the mechanics around it.

MetalGraph is my attempt at bringing that kind of experience to Metal.

What MetalGraph is (and isn’t)

MetalGraph is a node graph macOS app where you can design Metal shaders and see the result immediately as you work.

You connect nodes, tweak values, change structure, and the preview updates in real time. The focus is on keeping the feedback loop tight while you’re exploring ideas.

It’s not meant to replace writing Metal code.

The end goal is still to understand what the shader is doing and eventually write or refine the code yourself. The node graph is a way to reason about structure and data flow visually, especially when you’re learning or experimenting.

A simple example

A very basic example might be something like building a radial gradient.

Instead of starting with a full shader function and iterating through rebuilds, you can visually connect:

• a position or UV node
• a distance calculation
• a smoothstep
• a color mix

By adjusting parameters like radius or falloff, you immediately see how they affect the final result.

Changing the structure, for example introducing a distortion (noise) or time-based offset, is just as immediate.

That immediacy turned out to be a big deal for me. Even with rough early versions of the app, it made learning and experimentation noticeably faster.

From prototype to something usable

Around July I had something that worked. It was rough, unfinished, but already useful enough that I kept using it for learning and experimentation.

As many of us know, the last 10% of an app is the hardest. Around the same time, we had some intense months at Panels working on other extremely exciting projects, so MetalGraph had to take a back seat for a while.

During the Christmas break, I decided to give it a final push. I cleaned things up, fixed rough edges, and focused on making it usable by others, not just by me.

Current state

MetalGraph is now available on macOS.

I recorded a short overview video where I walk through the app and build a few very simple examples step by step:

The app can be downloaded and used in trial mode. In trial mode you can access all built-in examples and tweak node values, but you can’t add or remove nodes. Unlocking the full version requires purchasing a license.

You can find more details and download the app here:

MetalGraph - Visual Shader Editor for macOS

What’s next

This is still early.

My main goal right now is to get feedback from people who are already working with Metal or learning it. I’m especially interested in whether this kind of visual workflow helps others the same way it helped me.

If you try it and have thoughts, good or bad, I’d love to hear them.

In the past I covered how to create a “simple” refractive glass effect using Metal shaders, as well as how to apply interesting overlay glass effects.

Today we’re going to leave the glass behind and focus instead on the liquid part of it. This is the piece that makes Apple’s glassEffectContainer effect in iOS 26 look alive, organic, and “gooey”.

What’s an SDF?

SDF stands for Signed Distance Function. It’s a way of representing shapes mathematically.

For any point in space (or pixel on screen), an SDF tells you:

• Negative value → you’re inside the shape
• Zero → you’re exactly on the surface
• Positive value → you’re outside the shape

For example, a circle SDF looks like this:

float circleSDF(float2 p, float radius) {
  return length(p) - radius;
}

If p is exactly radius units away from the center, the function returns 0 (on the circle). Inside the circle it returns negative, and outside positive.

Plotting that circle’s raw SDF data produces the following result (see image below). Pixels inside radius are black (negative values) and pixels outside the radius are gray (positive values):

The magic is that you can combine these distance values with simple math (min, max, etc.) to create complex shapes and effects.

Boolean operations

First let’s set the stage. We are going to draw two circles:

[[ stitchable ]] half4 sdfBooleanOps(
    float2 position,
    half4 color,
    float2 size,
    float smoothness // 0=hard, 0.1=smooth
) {
  float2 uv = position / size;
  float2 centered = uv - 0.5;
  // Define two overlapping shapes
  float circle1 = length(centered - float2(-0.1, 0.0)) - 0.15; // Left circle
  float circle2 = length(centered - float2(0.1, 0.0)) - 0.15; // Right circle
  float result = unionSDF(circle1, circle2); // unionSDF is explained below

  // For better visualization, let's mask the 2 shapes, so any values outside the circle are +1 (white) and all values insdide are black (-1). The easiest way to do this is by using step (or smoothStep).  
  result = step(0.1, result);  

  return half4(result, result, result, 1.0);
}

Boolean operations on distance fields

Signed Distance Functions (SDFs) become powerful because you can combine them with boolean operations. The idea is simple: you have two distance fields (d1 and d2), and you define how they interact:

float unionSDF(float d1, float d2) {
  return min(d1, d2); // Closest surface wins
}

float intersectionSDF(float d1, float d2) {
  return max(d1, d2); // Farthest surface wins
}

float differenceSDF(float d1, float d2) {
  return max(d1, -d2); // Remove d2 from d1
}

• Union: two shapes combined into one.
• Intersection: keep only the overlap.
• Difference: subtract one shape from another.

This is the “hard” boolean world. But what makes Apple’s glassContainer so magical is the smooth version.

The magic of SDF: Smooth functions

Take the union, for example. Instead of snapping two shapes together, we can create a gradual blend. This is where smoothUnion comes in:

// Smooth versions for organic blending
float smoothUnion(float d1, float d2, float smoothness) {
  float h = max(smoothness - abs(d1 - d2), 0.0) / smoothness;
  return min(d1, d2) - h * h * smoothness * 0.25;
}

Here’s what’s happening. If the shapes are far apart, it behaves like a normal union. As they get closer, the seam becomes rounded and fluid-like. Last, the smoothness parameter controls how wide that blending region is.

In terms of the maths, the hardest part to digest is “h * h * smoothness * 0.25”. It’s actaully pretty simple, it subtracts a small “smoothing offset” to round the union instead of keeping it sharp. You can play with that value and adjust it to your needs, 0.25 works pretty nicely.

Here is an example of how different values of smoothness affect the 3 boolean operations.

Applying the effect

That’s pretty much it. Once you understand how to blend shapes together, you can apply to any shape.

To master and illustrate those concepts, in full the metal shaders course, there are some interesting examples, like a lava lamp effect, some draggable light balls, and my personal favorite… a dripping goeey button.

Distortion effects are fun. They are a bit limited but you can still get a lot from them. In Metal.graphics chapter 9 (challenge 2), I explored an interactive ripple effect. This is different from Chapter’s 4 because it uses more than one wave and you can tap+drag to keep generating waves. The final result is visually stunning and very satisfying, although arguably not very useful in regular conditions.

One way we can try to make this (or any other shader really) a bit more useful is by using it for transitioning between views/images.

SwiftUI makes creating custom transitions very easy. Buckle up, this post might be long. I will skip some parts for simplicity, you can find the full code for all working examples is in the full downloadable project, along with all other Metal examples.

Let’s build some cool transitions.

In this post I am going to focus on distortion effects. I am not going to touch color effects or layer effects but you can use them as well to build custom transitions.

Initial approach

My initial approach was to repurpose a similar code, adding progress as parameter. At that point I did not fully understand SwiftUI transitions I implemented the following:

extension AnyTransition {
    static func simpleRipple(from point: CGPoint) -> AnyTransition {
        .asymmetric(
            insertion: .init(RippleInsertionTransition(tapLocation: point)),
            removal: .opacity
        )
    }
}

struct RippleInsertionTransition: Transition {
    var tapLocation: CGPoint
    
    func body(content: Content, phase: TransitionPhase) -> some View {
        // For insertion: phase.value goes -1.0 → 0.0
        // Convert to: 0.0 → 1.0 for reveal progress
        let progress = 1.0 + phase.value
        
        return content
            .visualEffect { content, proxy in
                content.distortionEffect(
                    ShaderLibrary.rippleDistortion(
                        .float2(Float(proxy.size.width), Float(proxy.size.height)),
                        .float(Float(progress)),
                        .float2(Float(tapLocation.x), Float(tapLocation.y))
                    ),
                    maxSampleOffset: CGSize(width: 0, height: 0)
                )
            }
            .clipShape(CircularRevealShape(center: tapLocation, progress: progress))
    }
}

struct CircularRevealShape: Shape {
    var center: CGPoint
    var progress: CGFloat
    
    var animatableData: CGFloat {
        get { progress }
        set { progress = newValue }
    }
    
    func path(in rect: CGRect) -> Path {
        let maxRadius = sqrt(pow(rect.width, 2) + pow(rect.height, 2))
        let currentRadius = progress * maxRadius * 1.4
        
        var path = Path()
        path.addEllipse(in: CGRect(
            x: center.x - currentRadius,
            y: center.y - currentRadius,
            width: currentRadius * 2,
            height: currentRadius * 2
        ))
        return path
    }
}

struct SimpleRippleTestView: View {
    @State private var currentIndex = 0
    @State private var tapLocation: CGPoint = CGPoint(x: 150, y: 150)
    
    let images: [ImageResource] = [.unsplash3, .unsplash4, .unsplash5]
    
    var body: some View {
        ZStack {
            ForEach(images.indices, id: \.self) { index in
                if currentIndex == index {
                    Image(images[index])
                        .resizable()
                        .aspectRatio(contentMode: .fill)
                        .frame(width: 600, height: 300)
                        .transition(.simpleRipple(from: tapLocation))
                        
                }
            }
            Text("Ripple Metal Transition")
                .font(.largeTitle)
                .fontWeight(.black)
                .foregroundStyle(.black)
                .padding()
                .blendMode(.overlay)
                .background(.ultraThinMaterial, in: RoundedRectangle(cornerRadius: 12))
        }
        .onTapGesture { location in
            tapLocation = location
            withAnimation(.easeInOut(duration: 2)) {
                currentIndex = (currentIndex + 1) % images.count
            }
        }
        .clipped()
        .cornerRadius(20)
        .shadow(radius: 10)
    }
}

This works and produces the result I show at the top on the very first video. Let’s analyze what it does and go over some “problems” of this approach.

The ripple transition is made using an asymmetric transition.

.asymmetric(
            insertion: .init(RippleInsertionTransition(tapLocation: point)),
            removal: .opacity
        )

The way asymmetric transitions work on SwiftUI is by defining an insertion transition (“how do we add the new image?”) and a removal transition( “how do we remove the old image?”).

The removal (old image) in this case is using a simple opacity. The insertion is the one using the magic:

return content
            .visualEffect { content, proxy in
                content.distortionEffect(
                    ShaderLibrary.rippleDistortion(
                        .float2(Float(proxy.size.width), Float(proxy.size.height)),
                        .float(Float(progress)),
                        .float2(Float(tapLocation.x), Float(tapLocation.y))
                    ),
                    maxSampleOffset: CGSize(width: 0, height: 0)
                )
            }
            .clipShape(CircularRevealShape(center: tapLocation, progress: progress))

The transition itself is made out of 2 parts. The first part is the ripple effect (made using a distortionEffect) and the second is the clipShape.

SwiftUI (unless told otherwise) places the new image on top of the old one. What the clipShape is doing is masking the top image as the ripple progresses.

This approach visually works because in a 2sec animation is almost impossible to tell the trick, but if we slow it down considerably we see it is not perfect. The ripple has a clean round cut. Ideally it will be really nice to deform the image being removed as well.

A better approach

I honestly couldn’t find a nice way to do a transition without a clipShape that worked the way that I wanted.

Thanks to google, I was able to find this incredibly nice post by Pavel.

https://nerdyak.tech/development/2023/06/16/distortionEffect-with-Metal-shaders-for-better-transitions.html
Please go read it, it is short and sweet. At the very least, please watch the first video.

He provides the code for his amazing transition, but in all honestly I still could not figure out how he made it work. I did not know how to connect the progress with the direction just by looking at the code.

So I made myself a playground. Here is the gist if you are interested.

First, let’s understand the tricky Metal code that happens inside the first if block.

[[ stitchable ]] float2 slideAwayShader(float2 position, float2 size, float time, float direction) {
    float2 c = size/2;
    float2 v = position - c;
    
    float f = (direction > 0 ? position.x : (size.x - position.x) )/size.x;
    
    if ( time > f ) {
        float mul = (time-f)/(1-f);
        return c + v*mul;
    }
    else {
        return float2(-1, -1);
    }
}

Those 2 lines are where the magic happens. The math trick is to move each pixel smoothly from the center of the view back out to its original position (as in squeezing the pixels).

• mul = (time — f) / (1 — f)

Here, f is the moment (between 0 and 1) when this pixel is “allowed” to start moving. Before that, the pixel doesn’t exist. After that, time keeps growing toward 1. This formula maps that time window [f … 1] into a clean [0 … 1] scale. In other words: when time == f, mul = 0; when time == 1, mul = 1. Everything in between gives a smooth fraction.

• return c + v * mul

c is the center point, and v is the vector from the center to the pixel’s original position. So c + v*0 = the center, and c + v*1 = the pixel’s true place. Multiplying v by mul means “slide outward from the center along the line to where the pixel belongs.” As mul goes from 0 to 1, the pixel travels along that line, giving the effect of expanding out from the center column toward the edges.

Understanding the maths and playing with the playground, it was clear a bit more clear that Pavel was using the same shader in an asymmetric transition with:

• insertion (left to right) with progress moving from 0 to 1
• removal (right to left) with progress moving from 1 to 0

Understanding this was key to implement the final transition.

import SwiftUI

struct SimpleSlideAwayRipple: View {
    @State private var currentIndex = 0
    
    let images: [ImageResource] = [.unsplash3, .unsplash4, .unsplash5]
    
    var body: some View {
        VStack(spacing: 20) {
            Text("Slide Away Ripple Transition")
                .font(.largeTitle)
                .fontWeight(.black)
                .foregroundStyle(.black)
            
            ZStack {
                ForEach(images.indices, id: \.self) { index in
                    if currentIndex == index {
                        Image(images[index])
                            .resizable()
                            .aspectRatio(contentMode: .fill)
                            .frame(width: 350, height: 350)
                            .transition(.slideAwayRipple)
                            .onTapGesture {
                                withAnimation(.easeInOut(duration: 3)) {
                                    currentIndex = (currentIndex + 1) % images.count
                                }
                            }
                    }
                }
            }
            .clipShape(RoundedRectangle(cornerRadius: 20))
            .shadow(radius: 10)
            
            Text("Tap to transition")
                .font(.caption)
                .foregroundColor(.secondary)
        }
        .padding()
    }
}

// Slide Away Ripple transition
struct SlideAwayRippleTransition: Transition {
    let direction: Float
    func body(content: Content, phase: TransitionPhase) -> some View {
        let progress = direction == 1
        ? Float(1.0 + phase.value) // -1→0 becomes 0→1 for insertion
        : Float(1.0 - phase.value)
        
        
        return content
            .visualEffect { content, proxy in
                content.distortionEffect(
                    ShaderLibrary.slideAwayRipple(
                        .float2(Float(proxy.size.width), Float(proxy.size.height)),
                        .float(progress),
                        .float(direction)
                    ),
                    maxSampleOffset: CGSize(width: 0, height: 0)
                )
            }
    }
}

extension AnyTransition {
    static var slideAwayRipple: AnyTransition {
        .asymmetric(insertion: .init(SlideAwayRippleTransition(direction: 1)),
                    removal: .init(SlideAwayRippleTransition(direction: -1)))
    }
}

#Preview {
    SimpleSlideAwayRipple()
}

Improving my ripples

Thanks to Pavel’s approach, I was now on my way to improving my ripples, no more masking, no more fading out.

I followed a very similar approach, using direction and progress and the following code did the job.

[[stitchable]] float2 liquidWave(
    float2 position,
    float2 size,
    float progress,  // 0.0 to 2.0 (1.0 = identity)
    float direction
) {
    float2 center = size / 2.0;
    float2 fromCenter = position - center;
    
    // Calculate threshold like slide-away but based on distance from center
    float dist = length(fromCenter) / length(center);
    float f = direction > 0 ? dist : (1.0 - dist);
    
    // Reveal phase: 0 → 1
    if (progress > f) {
        float revealAmount = (progress - f) / (1.0 - f);
        
        // Liquid wave distortion
        float wave1 = sin(position.x * 0.02 + progress * 8.0) * 15.0;
        float wave2 = sin(position.y * 0.03 + progress * 6.0) * 10.0;
        float wave3 = sin(dist * 20.0 - progress * 12.0) * 8.0;
        
        float2 waveOffset = float2(wave1 + wave3, wave2 + wave3) * (1.0 - revealAmount);
        
        return position + waveOffset;
    } else {
        return float2(-1, -1);
    }
}

In this case I did not bother to pass in the tap location, it is always computed from the center, but we get the idea.

Since I was already here, I created a couple more transitions.

That’s all for today. If you create any new transitions, ping me, I’d love to see them!

On my previous post I explored how to create a simple yet convincing glass effect using metal shaders. Let’s keep the glass theme going, it’s Apple’s fault anyway.

I use Eagle app to keep a folder with images for inspiration and ideas I’d like to (some day…) implement. I recently stumbled upon the following image — I am sorry, I don’t know what app is this. If you are reading and you know the app, will appreciate you letting me know so I can properly reference it.

Maximilian Götzfried (ZENTI) Found the app! Find it here -> Photo Editor: AI Photo enhancer

In this post I am going to try to recreate this Laminated Glass effect using metal shaders.

Same as my previous post, this post assumes some basic metal knowledge. I also do not plan to focus on the SwiftUI parts. If you want the full code, it is part of my metal graphics xcode project.

Breaking it down

The effect is actually pretty simple, although it took me a while to understand what it does.

Imagine the background is split into vertical strips (or columns). Each column behaves like a piece magnifying glass that slightly distorts what’s behind it.

So, rather than sampling the layer directly at position.x, we want to sample a wider region and squish it back into the space of that column. This is the trick.

Implementation will then look something like this:

• Divide the view into vertical columns (columnCount)
• For each column, stretch its contents by a stretchFactor (e.g., 1.5 = 150%)
• Sample from that wider region to get the distorted result

To implement this, we need:

• A way to compute which column the current pixel belongs to
• A normalized position inside that column (0…1)
• A stretch-adjusted sampling coordinate

First version (the verbose one)

Here’s the more explicit version, where everything is spelled out step by step:

[[ stitchable ]] half4 verticalGlass(
    float2 position,
    SwiftUI::Layer layer,
    float2 size,
    float columnCount,      // ~20
    float stretchFactor     // 1.5 = 150% width
) {
    float columnWidth = size.x / columnCount;
    int columnIndex = int(position.x / columnWidth);
    float columnStart = float(columnIndex) * columnWidth;
    
    float positionInColumn = (position.x - columnStart) / columnWidth;
    
    float sampleWidth = columnWidth * stretchFactor;
    float sampleStart = columnStart - (sampleWidth - columnWidth) * 0.5;
    
    float sampleX = sampleStart + positionInColumn * sampleWidth;
    float2 samplePos = float2(sampleX, position.y);
    
    return layer.sample(samplePos);
}

As explained above, the main trick here was to calculate sampleX:

float sampleX = sampleStart + positionInColumn * sampleWidth;

Breaking it down:

• positionInColumn is a value from 0 to 1 — it tells us where we are inside the current column.
• sampleWidth is the wider area we want to sample from (due to the stretch).
• sampleStart is where that wider sampling area begins (it’s centered on the original column).
• So, positionInColumn * sampleWidth moves us across the wider region.
• Adding that to sampleStart gives us the final x coordinate to sample from.

As you can see on this gif, the result is pretty good. You can achieve nice effects by tweaking both properties.

Enter Fract

fract(x) = x - floor(x)

A few months ago I only knew that fract gives us the fractional part of a float. Turns out it is incredibly useful when doing shaders, especially when you try to replicate something multiple times.

This is covered in detail in Procedural Patterns chapter from metal.graphics.

In short, let’s say we want to repeat/tile a texture every 100 pixels. We just need to do:

float2 uv = fract(position / 100.0);

For our case, we can rewrite the positionInColumn as:

float positionInColumn = (position.x - columnStart) / columnWidth;

// Rewrite using fract
float positionInColumn = fract(position.x / columnWidth); // 0–1

In fact, fract makes it so easy that we can now apply it to both x and y for a square tiled effect (not just vertical).

One step further

At this point I think we can celebrate 🎉, the effect was successfully replicated. However, I wanted to go one step further and try to apply our learnings from the last post (remember (1 — r²)?).

Basically my plan was to introduce some falloff on the sides of each “vertical” glass, as if each glass was curved. The result is pretty interesting, makes the animation feel more organic, almost like flowing water.

Do you think you can replicate it?

Talking about replicating, I am looking for more stuff to replicate. If you have ideas, send them my way. And thanks for reading.

PS: remember that you can apply visualEffect to whole swiftUI views, not just images. That’s how the header image was made, with visualEffect applied to a ZStack containing an image + text

This post explores how to build a simple but convincing refractive glass material in Metal. It assumes you have some familiarity with fragment shaders and SwiftUI integration. If you’re new to this, I recommend checking out Chapters 1 and 2 of the Metal for SwiftUI course to get up to speed.

Why Glass is difficult

Glass seems simple — it’s just clear. But replicating it requires faking how light bends, how it casts subtle shadows, how it distorts the background, and how it adds depth even while being invisible.

We are going to try to replicate, or get close to it. To achieve it, in this shader we’ll simulate:

• Refraction — light bending through a lens
• Magnification Falloff — a center-focused lens effect
• Shadow & Occlusion — grounding the object in space
• Edge Lighting — simulating the thickness of the material

Let’s walk through each part.

Refraction & Magnification— The Heart of the Illusion

Refraction is what gives glass its identity. When light passes from one medium (air) to another (glass), it bends — this is called Snell’s Law. In shaders, we fake that by offsetting the sample location of the background image.

We’ll render a grayscale preview of the distortion intensity using a parabolic falloff (1 — r²). This simple shader helps to visualize it.

[[stitchable]] half4 refractionVisual(
    float2 position,
    SwiftUI::Layer layer,
    float2 size,
    float2 glassCenter,
    float glassRadius,
    float refraction,
) {
    float2 uv = position / size;
    float2 toCenter = uv - glassCenter;
    float dist = length(toCenter);
    float normalizedDist = dist / glassRadius;

    // Default to background layer
    half4 originalColor = layer.sample(position);
    
    // Outside the glass: return original
    if (normalizedDist > 1.0) {
        return originalColor;
    }

    // Compute distortion strength
    float distortion = 1.0 - normalizedDist * normalizedDist * refraction;

    // Visualize it: brighter = more distortion
    return half4(distortion, distortion, distortion, 1.0);
}

This visualizes how strongly each pixel would be distorted if we applied refraction.

• White = maximum distortion (center)
• Black = zero distortion (edge and outside)

Note that, to be able to sample a certain location, we’ll use the SwiftUI modifier .layerEffect()

To visualize the result, we just need to sample the shifted position.

    float distortion = 1.0 - normalizedDist * normalizedDist;
    float2 offset = toCenter * distortion * refraction;

    return layer.sample(position + offset);

As discussed above, we are using a parabolic falloff “(1 — r²)”, but we could use other curves like “1.0 — pow(normalizedDist, 8.0)” or even “sin(normalizedDist * π)”.

We can even use this same concept to create a magnifying glass that applies full distortion along all the surface and has a tight edge with something like this “float falloff = clamp(distortionAmount * 0.5, 0.0, 0.1)”

I am exploring a combination of these concepts to create a “liquid glass” magnifying glass for Panels.

Adding Shadow & Occlusion

At this point, our glass object bends light convincingly — but it still looks like it’s floating on top of the scene. Now it needs to interact with the light around it. Real transparent objects, like marbles or lenses, don’t just bend light — they also cast subtle shadows. Even a drop of water has a small occlusion halo.

To simulate this, we’ll add a soft, offset shadow just outside the glass radius. This gives depth and spatial context.

• The shadow is not centered — we offset it slightly downward and to the right to simulate a directional light source.
• It only appears outside the glass but within a blur ring.
• We use smoothstep() to create a feathered falloff.

float2 shadowCenter = glassCenter + float2(shadowOffset, shadowOffset);
float2 toShadowCenter = uv - shadowCenter;
float shadowDist = length(toShadowCenter);

float shadowRadius = glassRadius + shadowBlur;
bool insideGlass = (normalizedDist <= 1.0);
bool insideShadow = (shadowDist < shadowRadius);

half4 result = layer.sample(position);

if (!insideGlass && insideShadow) {
    float shadowFalloff = (shadowDist - glassRadius) / shadowBlur;
    float shadowStrength = smoothstep(1.0, 0.0, shadowFalloff);
    result = mix(result, half4(0.0, 0.0, 0.0, 1.0), shadowStrength * 0.05);
}

Something important to note here is that your maxSampleOffset might need to be adjusted (depending on your blurRadius). If you use a .zero offset (or something smaller than your shadow) you will see the shadow cut off.

content.
  layerEffect(ShaderLibrary.glassEffect(…), 
              maxSampleOffset: .init(width: 150, height: 150)
)

Simulating Edge Lighting (Rim Highlight)

Even though glass is transparent, the way it catches light at the edges gives it a sense of form and thickness.

You can see this clearly in the top reference image: a bright rim wraps around the top-left portion of the glass, suggesting curvature.

We’ll simulate this using a rim light effect — a glow that fades in at the very edge of the circle, based on distance to the glass boundary.

This is a simple implementation that creates a ring light:

float edgeThickness = 0.015;
        float edgeDistance = abs(dist - glassRadius);
        float edgeFade = smoothstep(edgeThickness, 0.0, edgeDistance);

        half3 highlightColor = half3(1.1, 1.1, 1.2); // Cool-toned highlight
        result.rgb += edgeFade * highlightColor;

Almost there, now we just need for the highlight to appear at the top left. We can achieve that by modulating the rim strength with a fake light direction.

float edgeThickness = 0.015;
float edgeDistance = abs(dist - glassRadius);
float edgeFade = smoothstep(edgeThickness, 0.0, edgeDistance);

// Add directional lighting
float2 lightDir = normalize(float2(-0.5, -0.8)); // upper-left
float rimBias = dot(normalize(toCenter), lightDir);
rimBias = clamp(rimBias, 0.0, 1.0);

// Modulate edge brightness by light direction
half3 highlightColor = half3(1.1, 1.1, 1.2);
result.rgb += edgeFade * rimBias * highlightColor;

Bonus: Chromatic aberration — Imperfection as Detail

Our glass already refracts, casts shadows, and catches light. But in real life, even high-quality lenses aren’t perfect. At the edges, they often split white light into its component colors — a subtle rainbow fringe. This is called chromatic aberration.

We can simulate it by offsetting each color channel slightly differently when we sample the background. Red shifts one way, blue shifts the other. Green stays put.

// Chromatic aberration strength increases toward the edge
float chromaticStrength = normalizedDist * 0.1;

float2 redOffset = refractedOffset * (1.0 + chromaticStrength);
float2 blueOffset = refractedOffset * (1.0 - chromaticStrength);

// Sample each channel separately
float2 redPos = position - redOffset * size;
float2 bluePos = position - blueOffset * size;

half4 redSample = layer.sample(redPos);
half4 blueSample = layer.sample(bluePos);

// Assign RGB channels separately
refractedColor.r = redSample.r;
refractedColor.b = blueSample.b;

Previous examples used black text — black is the absence of color (0,0,0) so there is no color shift we can do to produce a chromatic aberration. We could potentially add it manually, but for simplicity I decided to use white text.

Wrapping Up

We started with a simple falloff. Then layered in:

• Directional refraction
• Soft shadows
• Edge lighting
• Chromatic aberration

Each step added one piece of physical truth. Combined, they create a shader that feels like glass — even though it’s just a function and a few uniforms.

The full working shader is available in the bonus content of the Metal for SwiftUI course, along with dozens of other examples like holographic stickers, neon signs, and animated waveforms.

Want to build your own custom shaders? The course is completely free, I hope you like it.

Last week we released a new version of Panels, our comic reader for iOS. In this version we introduced a new feature that we like to call Zoom control, which allows you to zoom and move along one page with one finger after long pressing a page.

The idea behind this feature was to improve the reading experience for those users reading comics on iPhone (portrait orientation). In previous versions, to read comics while in portrait mode you’d have to pinch the screen to zoom in and out using two hands, which makes the reading experience tedious and time consuming.

We still think that panel-by-panel navigation is the ideal solution, but it is challenging to implement. This is why we decided to prototype other ideas while we keep working on a panel-by-panel solution.

Prototyping can be a long process. Especially materialising different ideas into something that you can test and feel. This is why solutions like Marvel or Framer, to name a few, are so good. With nearly 0 effort (and 0 code) you can get your idea ready to test.

But, as developers, we like to code. To prove a hypothesis, to check how a new interaction feels, it is easier for us to build it on top of what we already have.

Solution 1: magnifying glass

Our first approach was to build a magnifying glass (similar to the built-in iOS that appears after long pressing on text).

To create a magnifying glass view on iOS you can simply instantiate a view that renders scaled (or zoomed) content from another view.

On our heads, this solution was pretty good, but the main problem we noticed as soon as we tested it on a real device was how uncomfortable it was. Having to drag your finger along the screen was incredibly annoying and, after reading a few pages, the user could get frustrated.

However, the main issue was the fact that you need to reach with your finger all four corners of the device.

Solution 2: magnifying glass + better control

Suddenly I remembered a “hidden” feature of iOS -> force touch the keyboard to move the caret position.

The idea of dragging your finger across the screen was bad, but if there was a small area where the user could control the magnifying glass, with shorter movements, it would solve the problem.

Technically, this iteration was simple to implement. The long gesture recognizer is applied to the small blue view (top bottom). This view is XX times smaller than the page. To calculate the position of the magnifying view, we only need to know the position of the finger in the blue control view, and multiply both x and y values by XX.

This solution was much better but, after playing with it for a while, we realised that not all speech bubbles will fit in the magnifying glass, which makes it difficult to read.

In addition, there was too much focus on the magnifying glass content, preventing the user to read the panel as a whole (text + image). We found ourselves activating and deactivating the magnifying glass all the time. To solve this problem we thought… “let’s make the magnifying glass big… bigger…”.

Solution 3: zooming the whole image + better control

We made the magnifying glass so gigantic that it almost filled the entire screed. We realised that, instead of using a magnifying glass, we could just zoom the whole content.

This was a great improvement. The user was not restricted anymore by a small rounded area, the whole page was zoomed and it could be easily controlled from one corner, with just one finger.

There still were a few problems remaining. How are we going to train our users to long press the bottom-right corner of the screen? We couldn’t leave a red square to showcase the long-press area. And how about the left-handed users?

Solution 4: Final feature

The final solution was to instantiate a control view (red view on the video below) when the long press gesture state was recognized. That way, it doesn’t really matter where the user puts his/her finger, it will always work.

Wrapping up!

As developers, we can also (and should) prototype and try new ideas and interactions. We can do it very quickly (specially with Playgrounds!), it doesn’t need to be production code, and surely we don’t need any external tools. Sometimes is good to start coding even when you don’t know where you will end up.

For this particular case, this feature turned up to be a bit “scary”, because we were unsure how the users would react. We were sceptic the first time we tried it, but it took us just a few seconds to realise it was actually helpful and felt very natural.

And soon after shipping, users started to love it too ❤️

Prototyping with code was originally published in Produkt Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post covers how the iOS team has created and dealt with a UI Framework, its structure and relation with the main project, as well as the benefits and downsides of this decision. Don’t miss the post on the same topic from the android team!

About a year ago, the mobile team at Jobandtalent was presented with a huge project. This new project had many new features, screens, interactions… The design team took this opportunity to improve their workflow by introducing atomic design, which defines a blueprint, with buttons, controls, cells, etc. That is, to create new screens they only used existing components and combinations of them.

Based on this concept, the design team at Jobadntalent created their own design system.

We applied the atomic design philosophy in our project by creating new standard components and using them in multiple scenarios. This approach allowed us to write reusable UI code.

VisualKit is Jobandtalent’s UI Framework. In a nutshell, VisualKit is a big modular package of views and controls where each one of them can be easily themed and modified to fit the design, just like playing with Lego.

iOS Architecture: Separating logic from effects

VisualKit Structure

VisualKit contains views and controls, including blank slates, buttons, loaders, segmented controls, switches, cells, etc. All new visual components are created in VisualKit.

Let’s have a look at an example on how we break down a screen into different components.

Forget about the navigation and tab bars, and let’s focus on the main tableView.

Each cell has three different sections:

• Header: contains the avatar, labels, a disclosure and a red dot (optional).
• Special label: we call it ChipView and indicates state. It can be red, green or yellow.
• Information breakdown: contains labels displayed in two columns and multiple rows.

VisualKit declares any view needed from the main project as public.

In the previous case, each individual section, as well as the cell (which is a combination of the 3 sections) will be declared public. This allow us to reuse each section throughout the main project. As shown below, the same cell is used multiple times.

If we make the cell modular, we only need to code it once. We simply need to:

1. Create each individual component (avatar, label, disclosure..)

2. Make the container view capable of rendering itself in different configurations by combining its individual components. StackViews are a great tool for this modular approach.

For example, to create the header, we use a horizontal StackView that contains the red indicator, the avatar, another vertical StackView and the right disclosure. The vertical StackView contains the two main labels.

VisualKit makes the header publicly available and configurable from the main project.

The API for components like the header is very simple and resembles UIKit standard components.

This view is not only ready to be used from the main project, but also from within VisualKit itself to generate more complex views.

There is only one particular property, though, it is worth to pay attention to: style.

Styles: Conforming to Styleable protocol

In VisualKit each view conforms to the following protocol:

It is a simple yet powerful protocol that makes all components behave equally. Furthermore, each component must define its own styles.

For example, our ChipView has three different styles. To make the ChipView conform to our Styleable protocol, we first need to define each style.

We do so by creating a public struct, where we define each aspect to be customised by each style. This same struct will also have different class initializers for the different styles.

The struct initialiser is not publicly available. This restricts anyone from the outside to create and set new styles.

Last, we can extend our chipView to conform to our protocol (Note how we specify the type, in this case, ChipStyle):

This is useful, particularly when all your components conform to the same protocol. Now, from the main project, we can simply do:

And we are done.

Create each component to adapt itself to change between different styles is hard work, but it pays off. Once is set up, it is incredibly easy to create new styles.

The same applies for buttons, cells, and may many other components. It is also useful for UIKit classes like UILabel. Here is an example:

Styles: Colors and Fonts

We created two abstractions over UIColor and UIFont in Visualkit, ColorPalette and FontBook. They are simple but they get the job done.

Let’s start with FontBook. This class manages the full set of fonts available in the Jobandtalent app. We only use the fonts designers have previously defined. Nevertheless, there is a public function that takes a name and a size and returns the correct Font.

To use it, for example, we call FontBook.extralarge

The ColorPalette is, again, a series of defined colors. The problem with colors is the alpha value. Even if your designer uses UIColor.blue there is a wide range of colors that they can choose just by playing with the opacity. This is why all our colors only have seven alpha possibilities + the base color (alpha = 1).

In the project, we only use colors defined inside the ColorPalette like this: view.backgroundColor = ColorPalette.dark.alpha80

Project example

One of the nicest “side effects” of having a separate UI Framework is to reuse it in different projects. We created a new specific project to play with VisualKit.

The example app serves many different purposes:

• To develop our controls outside the main project. VisualKit is all about UI: it is quicker to test controls and see them in action without having to navigate to a specific screen buried in the app. Playgrounds are very useful for that.
• To help the design team validate new components. The app includes Flex, which is awesome for tweaking values in realtime.
• To be used as a “library”. Once the framework started to grow, we needed a quick visual reference to each individual component.

Creating and Working with a framework

Our project already managed dependencies using Cocoapods. Once we decided to create this framework, it made sense to take advantage and develop it as a private pod (check this brilliant guide for more details on how to set it up).

I would like to give you my 2 cents on how easy/hard quick/slow things can become when you move most of your UI classes to an external source:

• Cocoapods is a great tool. For instance, when using developments pods, you are able to modify them within your project. However, every time you create a new file, you need to run pod install and obviously let your team know about it. We do not have it versioned as it is not mature enough, but it is definitely something to consider.
• Public, internal, open and private become more powerful than ever. When working on a project, you hardly ever use public. By default (internal) all files can see each other. When you encapsulate your classes in a framework, only those (classes, functions, protocols) marked as public will be available. This simple fact makes you more aware when designing your classes’ APIs and gives you more power (now you have a three layer access).
• You need to import VisualKit in (mostly) every view controller. We could use the .pch but VisualKit should only be available from the UI Layer. Other internal layers do not need to know or deal with it.

“Opensourcing” VisualKit

Opensourcing VisualKit as it is today would be useless: it is coupled to our app’s design.

However, everytime we create a new component we make it as an isolated instance. From VisualKit, we have already released two components: AnimatedTextInput and CardStackController. We will release new components as soon as they are ready.

Everyone on the iOS team agrees that having VisualKit as a framework was a great decision. It made us work faster and respond quicker to design changes.

Designers and developers working together

We could argue about the usefulness of having these abstractions over colors and fonts, or having styles for each component. Is this worth it? Can’t I just go ahead and do that on the storyboard/xib or in code every time I create a new view?

Obviously you can. But we should be able to respond fast to any design change. Maybe designers want a brighter blue, a new font or a faster animation. It is difficult to foresee what will change in the future, but working alongside designers can help you and save you time.

Our solution tries to mimic our designers approach. We create screens in a very similar way as they do. If they update the color palette, we can update it too and everything will “react” to this change. It shouldn’t be a hassle for developers to introduce a new font across the app.

Working alongside designers helped us understand their design process. In turn, designers also learnt from us, finding new solutions to overcome technical restrictions.

As a final note, it might not be a developer’s job to be part of early design decisions. It is usually managed by the project managers and designers. However, during this time I have experienced that being part of that process as early as possible, will really help your team.

Thanks to Luis Recuenco, Daniel García, Rubén Mendez, Rafa Aguilar, Xavier Jurado, Pol Quintana, Daniel Martín, Alexis Santos, Isaac Roldán, Andrés Brun and Ramón Argüello for contributing and making this possible.

— — — — — — — — — — — — — — — — — — — — — — — — —

Bonus: Playgrounds!

I love playgrounds, and live updates give us superpowers. I use them all the time when creating a new component for VisualKit.

Here is a simple template I use to start a new Playground.

I have speed-recorded myself creating a new component. You can find it here. I believe it is a good example of a VisualKit component (atom), that we have reused multiple times as part of other views (molecules).

Working with a design system

We are hiring!

If you want to know more about how is work at Jobandtalent you can read the first impressions of some of our teammates on this blog post or visit our twitter.

VisualKit: UI Framework was originally published in Job&Talent Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few days ago I bought an iPhone 6S. I was super impressed with its new 3D touch and I could not wait to start experimenting.

Peek & pop is a great feature to include in an app. The downside: we don’t have much control over it. We can only add a preview and a few actions — iOS manages the rest.

Since I discovered 3D Touch, I have been thinking about new ways of interacting with the content. Peek & pop is a great interaction; but what I really want is to create my own controls.

We need to take into account that, because 3D touch is only available in iPhone 6S and 6S Plus, no action should be completed just by using this feature. The user should be able to achieve any action without using 3D touch (just like peek & pop does), and 3D touch should only provide an extra level of interaction.

Accessing force property

The new force property can be found in UITouch class. To get the user touch we should override touches methods (touchesBegan, touchesMoved, touchesEnded), either subclassing (e.g. UIView, UIButton; see example 1) or creating a gesture recognizer (see below; used in examples 2 and 3).

The force value goes from 0.0 to 6.667. For further details, I extremely recommend Exploring Apple’s 3D Touch post.

Example 1: Force Button

Force Button is a subclass of UIButton that modifies its shadow based on the input force (as seen in the top video).

The above function modifies the button shadow based on input force. You can find another example on how to modify the button scale while its being pressed here.

This button uses 3D touch only for visual purposes, it does not add any extra feature. It might be nice to add an extra event (e.g. UIControlEvents.ForceMaxInside) to add a taget action once the user has pressed the button to its maximum force.

Example 2: Zooming

We are all used to pinch to zoom in and out, it feels natural. However, sometimes it is tricky to use 2 fingers while holding the device with 1 hand. Google maps app tries to solve this issue by using a doble-tap-longPress-drag gesture (which feels weird if you are not use to it).

Using ForceGestureRecognizer (see code above), it is really easy to zoom in and out while dragging your finger. If you have an iPhone 6S give it a go, it feels great.

To achieve this effect, I simply apply a CATransform3D scale to the imageView layer. By doing this, the image scales from its center. To move the image under my finger (zooming to an specific area) I need to update the anchorPoint based on the finger’s location.

Example 3: Controlling animations

The last interaction I am proposing for the 3D touch is to control an animation. To be honest, I haven’t found any interesting use for this interaction (other than being great for fine-tunning), but I would like to mention it (someone might find it useful).

Here is a quick video of an animation being controlled with 3D touch.

These are just a few examples of new ways of interaction that 3D Touch brings to designers and developers. I hope I have convinced you to try 3D Touch.

I would like to finish by recommending FlexMonkey’s bog, and specially his latest post: 3D Retouch, where he uses 3D Touch to modify the intensity of filters.

Find the whole project in github.

Special thanks to @pivalue

3D Force Touch: beyond peek & pop was originally published in Produkt Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the trickiest features we encountered while developing Thoughts was to recreate Apple’s scrolling view capabilities (some of them).

Whilst Panning and Zooming can be defined by using gesture recognizers, combining the two was far more complicated. Zooming into a specific point (e.g. middle of your fingers) involves not only zooming but shifting the content. Nevertheless, my favourite part of all was to replicate the rubber band behaviour.

The maths behind it

The Control Centre is a perfect rubber band interaction example.

By interacting with the Control Centre behaviour, the first mathematical function that came to my mind was the square root. However… it didn’t feel right, and not as natural as Apple’s. Here is when Swift (and specially playgrounds) became very useful.

After a few tests, the best strategy was to use log10 — it mimics quite closely Apple’s built-in behaviour.

I tried multiple logarithmic functions, including the neperian, but log10 was the most optimal.

The GIF below illustrates the comparison between square root, log10 and a function involving a power of 4. This last function works very well and, depending on the exponent, the ‘rubber’ effect becomes more/less elastic (that is, the distance gets longer/shorter). However, the downside of using this function is that there is a maximum value you shouldn’t cross (otherwise, the movement gets reversed).

Using this behaviour in ‘real life’ interactions

Replicating Apple’s scroll view will not be necessary on a standard app; we did it for Thoughts to create its infinite canvas. However, some situations (like the example below) can require a rubber band effect where there is no scroll view involved.

To showcase one of the above functions, I have included the following example in the project.

The green view is located using Autolayout and has a PanGestureRecognizer attached to it that calls the following method:

Where the last part of it, the logConstraintValueForYPoisition, takes care of applying the rubber band effect after the view exceeds the vertical limit using a log10 function. Tip: I like to use log10 from 1 to X (0.x values grow massively quick).

In this example, animateViewBackToLimit() is implemented using a simple UIView animation block to keep the project simple, however I am not a big fan of them.

Find the project in GitHub

One last word

UIAttachmentBehaviour can also be used in some situations involving rubber band behaviour. This is only another tool to add in your toolbox ☺

PS: this is the first time I have published Swift code. I would really appreciate if you can help me to improve it in any way.