The Problem

When building card-based UIs in SwiftUI, a common issue occurs where tap gestures extend beyond the visible content, causing unexpected behavior like tapping one UI element accidentally triggers another nearby element.

Understanding SwiftUI’s Hit Testing

SwiftUI determines what gets tapped using a process called hit testing, which has some non-obvious rules:

1. .clipShape() vs Tap Area

// ❌ WRONG: clipShape only clips VISUALS, not tap area
ZStack {
    RoundedRectangle(cornerRadius: 16)
        .fill(Color.blue)
    
    Text("Content")
}
.frame(height: 160)
.clipShape(RoundedRectangle(cornerRadius: 16))  // Only clips visuals!
.onTapGesture { /* This can receive taps from the entire 160pt frame */ }

Problem: The view’s frame (rectangular boundary) remains the tap target, even though visually it’s rounded.

2. .shadow() Extends Tap Area

// ❌ WRONG: Shadow extends the tappable area
VStack { /* content */ }
    .shadow(radius: 4, x: 0, y: 2)  // Shadow pixels become tappable!
    .onTapGesture { }

Problem: SwiftUI considers the shadow part of the view’s bounds, so taps on the shadow (including areas above/below the visible content) register.

3. ZStack with Shapes Forward Taps

// ❌ WRONG: Background shape expands tap area
ZStack {
    RoundedRectangle(cornerRadius: 16)
        .fill(Color.blue)
        .frame(height: 160)  // This shape fills the entire height
    
    VStack { 
        Text("Content")  // This might be shorter
    }
}
.onTapGesture { /* Taps anywhere in 160pt ZStack trigger this */ }

Problem: The RoundedRectangle expands to fill the frame, making the entire ZStack tappable, even where there's no visible content.

4. .onTapGesture vs Button

// ⚠️ CAUTION: onTapGesture responds to taps on entire frame
VStack { /* content */ }
    .frame(height: 160)
    .onTapGesture { }  // Entire 160pt height is tappable


// ✅ BETTER: Button only responds to taps on its content
Button(action: { }) {
    VStack { /* content */ }
        .frame(maxHeight: .infinity)  // Must explicitly fill
}
.frame(height: 160)

Key Difference:

• .onTapGesture makes the entire frame tappable
• Button only makes its visible content tappable (unless you explicitly fill the space)

The Solution: Correct SwiftUI Button Pattern

✅ Pattern 1: Button with Explicit Content Filling

Button(action: {
    print("Card tapped")
}) {
    VStack(spacing: 12) {
        Image("icon")
            .resizable()
            .frame(height: 98)
        
        Text("Title")
            .font(.headline)
    }
    .padding(.horizontal, 16)
    .frame(maxWidth: .infinity, maxHeight: .infinity)  // ← Key: Fill the space
}
.buttonStyle(.plain)  // Remove default button styling
.frame(height: 160)
.background(
    RoundedRectangle(cornerRadius: 16)
        .fill(Color.blue)
)
.clipShape(RoundedRectangle(cornerRadius: 16))

Why this works:

1. ✅ Button content explicitly fills the 160pt height with .frame(maxWidth: .infinity, maxHeight: .infinity)
2. ✅ Background is applied after the button, so it’s decoration, not a separate tappable shape
3. ✅ .clipShape() constrains both visuals AND tap area to the rounded rectangle
4. ✅ .buttonStyle(.plain) removes default button appearance

✅ Pattern 2: Using .contentShape() with .onTapGesture

If you must use .onTapGesture, add .contentShape():

VStack { /* content */ }
    .frame(height: 160)
    .background(Color.blue)
    .clipShape(RoundedRectangle(cornerRadius: 16))
    .contentShape(RoundedRectangle(cornerRadius: 16))  // ← Constrains tap area
    .onTapGesture { }

Why this works: .contentShape() explicitly defines the hit-testing area, overriding the default rectangular frame.

Common Mistakes to Avoid

❌ Mistake 1: ZStack with Competing Tap Targets

// DON'T DO THIS
ZStack {
    RoundedRectangle(cornerRadius: 16)
        .fill(Color.blue)
        .onTapGesture { }  // ← This captures taps for entire ZStack!
    
    Button(action: { }) {
        VStack { /* smaller content */ }
    }
}

Fix: Don’t put tappable shapes and buttons as siblings in a ZStack. Make the button the primary view with background as a modifier.

❌ Mistake 2: Shadow Inside Button/Gesture Area

// DON'T DO THIS
Button(action: { }) {
    VStack { /* content */ }
        .shadow(radius: 4, x: 0, y: 2)  // ← Shadow extends tap area
}

Fix: Apply shadow outside the button:

Button(action: { }) {
    VStack { /* content */ }
}
.shadow(radius: 4, x: 0, y: 2)  // ← Shadow is decoration, not part of tap area

❌ Mistake 3: Not Filling Button Content

// DON'T DO THIS
Button(action: { }) {
    VStack { /* 100pt of content */ }
}
.frame(height: 160)  // Button content is 100pt, but frame is 160pt

Problem: The 60pt gap might still respond to taps!

Fix:

Button(action: { }) {
    VStack { /* 100pt of content */ }
        .frame(maxHeight: .infinity)  // Fill the available space
}
.frame(height: 160)

Best Practices Checklist

When creating tappable cards/buttons:

1. ✅ Use Button over .onTapGesture when possible
2. ✅ Make button content fill the frame with .frame(maxWidth: .infinity, maxHeight: .infinity)
3. ✅ Apply backgrounds/borders as modifiers on the button, not as separate ZStack layers
4. ✅ Apply shadows outside the button/gesture
5. ✅ Use .contentShape() if you must use .onTapGesture to explicitly define tap area
6. ✅ Use .buttonStyle(.plain) to remove default button styling
7. ✅ Test tap boundaries in previews with visual debugging (like the red background we used)

Visual Debugging Technique

Add a colored background to see the actual tap area:

Button(action: { }) {
    VStack { /* content */ }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
}
.background(Color.red.opacity(0.3))  // ← See the actual tap area

This reveals mismatches between visual appearance and tap boundaries.

Summary

The core principle: SwiftUI’s tap area = the view’s frame, not its visual appearance. Always explicitly control:

• The content size (with .frame(maxWidth:maxHeight:))
• The tap area (with Button or .contentShape())
• Decoration order (backgrounds, shadows applied as modifiers, not siblings)

Following these patterns prevents ghost taps and ensures users tap exactly what they see.

Lately, I’ve been leaning heavily into .overlay() paired with Rectangle shapes. It’s cleaner, it respects the parent view’s frame, and honestly it’s much more powerful than most people realize. Here are 15 ways I use this combo to keep my SwiftUI code lean.

What’s in this Guide

In this article, we’re going to move beyond simple “borders.” We will explore how the .overlay() + Rectangle combo solves real-world engineering problems:

1. The Tap-Helper: Make tiny icons easy to click without moving your UI.
2. The Dimmer: Fade out the background so your popups actually pop.
3. The Sharp Line: Forget messy dividers; use a 1px rectangle for perfect borders.
4. The Progress Fill: The easiest way to build a loading bar that stays in its lane.
5. The Ghost Box: Hide empty text with “skeleton” blocks while data loads.
6. The Text Guard: Add a quick gradient so white text doesn’t vanish on bright photos.
7. The Glow-Up: Switch on a colored border to show exactly what’s selected.
8. The Tag Pinner: Stick “Sale” or “New” badges onto cards without the headache.
9. The Shimmer: Add that “expensive” moving light effect to loading screens.
10. The Edge Cutter: Mix and match sharp and round corners for a custom look.

1. The Hit-Box (Interaction)

The most common mistake for juniors is making buttons too small. An invisible Rectangle in an overlay creates a perfect tap target.

Image(systemName: "pencil")
    .overlay(
        Rectangle()
            .fill(.black.opacity(0.0001)) 
            .frame(width: 44, height: 44)
    )
    .onTapGesture { print("Tapped!") }

2. The Scrim (Focus)

When a modal appears, you need to dim the background. A Rectangle overlay is the cleanest way to do this.

MainContentView()
    .overlay(
        isShowingDimmer ? Rectangle().fill(.black.opacity(0.4)) : nil
    )

3. The Precision Divider (Layout)

Divider() often adds unwanted padding. A 1px Rectangle pinned to the bottom of an overlay gives you total control.

VStack { Text("Item") }
    .overlay(Rectangle().frame(height: 1).foregroundColor(.gray), alignment: .bottom)

4. The Progress Track (Data Visualization)

Using an overlay ensures the “fill” bar never exceeds the size of the “track” bar.

Rectangle()
    .fill(.gray.opacity(0.2))
    .frame(height: 8)
    .overlay(
        GeometryReader { geo in
            Rectangle()
                .fill(.blue)
                .frame(width: geo.size.width * 0.6)
        }, alignment: .leading
    )

5. The Skeleton Loader (Loading States)

Use a Rectangle to "block out" content while data is fetching.

Text("Username")
    .overlay(isLoading ? RoundedRectangle(cornerRadius: 4).fill(.gray.opacity(0.3)) : nil)

6. The Text Protector (Readability)

Protect your text from “busy” image backgrounds with a gradient Rectangle.

Image("bg")
    .overlay(Rectangle().fill(LinearGradient(colors: [.clear, .black], startPoint: .top, endPoint: .bottom)))

7. The State Indicator (Selection)

Instead of changing background colors, use a stroke overlay to show selection clearly.

CardView()
    .overlay(RoundedRectangle(cornerRadius: 12).stroke(isSelected ? .blue : .clear, lineWidth: 2))

8. The Badge Anchor (Information)

Perfect for “New” or “Sale” tags that need to sit on top of a component.

Swift

ProductImage()
    .overlay(Text("NEW").background(Capsule().fill(.red)), alignment: .topTrailing)

9. The Shimmer Effect (Animation)

A sliding gradient Rectangle creates that premium "loading" feel.

Rectangle()
    .fill(.gray.opacity(0.2))
    .overlay(
        Rectangle()
            .fill(LinearGradient(colors: [.clear, .white, .clear], startPoint: .leading, endPoint: .trailing))
            .offset(x: offset)
    ).clipped()

10. The Style Clipper (Modern Design)

Use UnevenRoundedRectangle to create unique UI shapes that stand out.

Rectangle()
    .fill(.blue)
    .overlay(UnevenRoundedRectangle(topLeadingRadius: 20).stroke(.white, lineWidth: 2))

Conclusion

As a junior developer, it’s easy to over-complicate your view hierarchy with nested stacks. Mastering the .overlay() + Rectangle combo allows you to write flatter, more performant code while maintaining precise control over your UI's interaction and state.

Which of these roles are you going to implement in your next project? Let me know in the comments!

Learn how Sendable ensures thread safety in Swift concurrency, when to use it, and how to avoid common pitfalls.Sendable in Swift

Sendable is a protocol introduced in Swift to ensure that types can be safely passed across concurrency domains (e.g., between tasks in Swift concurrency).

1. What Does Sendable Do?

It marks a type as safe to be shared across multiple threads, ensuring no data races in concurrent environments.

2. When to Use It?

• When working with Swift Concurrency (async/await, Task, Actor).
• When a type is used across different isolated execution contexts (like different tasks or actors).

3. Example Usage

✅ Sendable Struct (Automatic Conformance)

Value types (structs, enums) that contain only Sendable types automatically conform to Sendable:

struct User: Sendable {
    let name: String
    let age: Int
}

❌ Non-Sendable Class (Reference Types Need Manual Handling)

Classes do not conform to Sendable by default, because they introduce shared mutable state.

class User { // ❌ Not Sendable
    var name: String
    init(name: String) {
        self.name = name
    }
}

To fix this, either:

1. Make it immutable (final + let properties)
2. Mark it explicitly @unchecked Sendable (⚠️ You promise it's thread-safe)

final class User: @unchecked Sendable {
    let name: String
    init(name: String) {
        self.name = name
    }
}

4. Sendable and Actors

Actors isolate state and are implicitly Sendable, so they can be safely used across threads.

actor Counter {
    private var value = 0
    func increment() { value += 1 }
}

5. Common Errors

If a type is used in an async function or within an actor and is not Sendable, Swift will give an error like:
🚨 "Type 'X' is not Sendable; this is an error in Swift concurrency."

6. Summary

Sendable is a crucial tool for writing safe concurrent code in Swift. By marking types as Sendable, you prevent data races and ensure smooth execution across multiple threads. Structs and enums are usually safe by default, while classes require extra care. Understanding and using Sendable correctly will make your Swift concurrency code more reliable and efficient. 🚀

Follow for more …

Even the most skilled iOS developers can fall into the trap of prioritizing features and design over security. Yet, leaving critical vulnerabilities unchecked can compromise both your app and its users. From mishandling sensitive data to neglecting proper input validation, there are risks that many developers don’t realize they’re overlooking. In this article I will highlight the top seven security risks you’re most likely to miss — and how to address them like a true pro will be coming in future articles. Don’t forget to follow for more.

The Underestimated Importance of HTTPS and App Transport Security

Many developers assume their app is secure if it simply communicates over HTTPS, but App Transport Security (ATS) enforces additional security standards like requiring SSL certificates that meet certain criteria. Skipping ATS or adding too many exceptions can leave your app vulnerable to man-in-the-middle attacks, compromising user data. Always review ATS configurations to make sure your app’s connections are fully secure.

Source: Apple Developer Documentation

The Hidden Risk of Insecure Data Storage

A common mistake developers make is storing sensitive data, like API tokens or user credentials, in UserDefaults. What most don’t realize is that UserDefaults is not encrypted, making it a potential target for attackers. Instead, sensitive data should always be stored in the iOS Keychain, which is designed to store data securely with encryption, even across app restarts.

Source: iOS Security Guide, Apple

The Overlooked Need for Secure Backups

Most developers don’t consider how their app data is handled during backups. By default, data stored in Documents or Cache directories may be included in iCloud backups, potentially exposing sensitive information. Use NSFileProtection to encrypt files on disk, and set the appropriate flags to ensure sensitive data isn’t backed up to iCloud unless it’s necessary for the user.

Source: iOS Security White Paper, Apple

The Overlooked Threat of Jailbroken Devices

Jailbroken devices pose a security risk for your app that often goes unnoticed. By bypassing iOS’s built-in security, these devices can compromise data stored in your app or bypass in-app purchases. Detecting if your app is running on a jailbroken device and limiting its functionality in such cases can prevent many security vulnerabilities from being exploited.

Source: OWASP Mobile Security Project

The Silent Danger of Hard-Coding API Keys

Hard-coding API keys directly into your app’s code may seem convenient, but it’s a major security flaw. When you hard-code keys, they can be easily extracted from your app’s binary by attackers. Instead, use secure methods like storing keys in the Keychain or fetching them dynamically from a secure server, where you can rotate them as needed for added security.

Source: OWASP Mobile Security Guide

The Hidden Vulnerability of Insufficient Input Validation

Even though iOS apps are generally considered secure, attackers can still exploit poorly validated inputs. If your app interacts with APIs or user-generated content, failing to properly validate inputs (like rejecting malformed URLs or restricting field lengths) can open your app to injection attacks. Always sanitize and validate user input on both the client and server sides to avoid this vulnerability.

Source: Apple Developer Documentation

The Risk of Over-Exposing App Permissions

Granting too many permissions to an app — such as access to photos, location, or contacts — without clear purpose not only annoys users but opens potential privacy risks. Many users don’t realize this, but improperly requested permissions can also flag your app for rejection during the App Store review process. Always follow the least privilege principle, requesting only the permissions your app absolutely needs to function.

Source: App Store Review Guidelines

Conclusion

Securing your app doesn’t stop at flawless design and smooth functionality; it requires a vigilant approach to identifying and resolving hidden security risks. By taking the time to address these seven often-overlooked vulnerabilities, you can elevate your app’s security to a professional level. Don’t let these silent threats undermine your hard work — secure your iOS app like a pro and give your users the protection they deserve.

Don’t forget to follow for next coming articles, and check howtoinswift.tech

Question for you: As an iOS Developer, what is the flow you had experienced?