DEV Community: Vaibhav Dwivedi

I gave two AI Builders the same brief. None of them won!

Vaibhav Dwivedi — Mon, 20 Jul 2026 16:30:00 +0000

Last month, I spent some time building a small product on the side.

A tool for the people who run hospitality at a Formula 1 race weekend.
The ones tracking VIP guests, paddock access, and a 3 day itinerary for each person across practice, qualifying, and the race.

This is not a toy market.

F1's Paddock Club served 65,000 guests last season at around $7,000 a ticket. That is over $450 million in revenue, growing 10 percent a year.

Behind those numbers, someone is doing real coordination work. That is the user I was designing for.

Before building it myself, I ran an experiment.

The experiment

I wrote one detailed brief. A full handoff doc. Data model, routes, brand, the F1 aesthetic, all of it.

Then I handed the exact same brief to two AI app builders -

@boltnew
@lovable

Same words, same day, no extra steering.

I did not just glance at the previews. I logged into both with a real headless browser and clicked through every screen. Dashboard, guests, itinerary builder, share flow, the public guest page, even invalid links.

What Lovable did

Lovable was the obedient one.

It read the calendar in my doc and got it right. June onward, correct weekend dates, even the new Madrid round.
It stubbed the email sending exactly as asked.
Routes, data model, access-tier badges, CSV import, colour-coded itinerary. All there.
The brand mark was genuinely decent. Strong engineering. It de-risked the boring 70 percent in minutes.

Then I tried to do the one job the whole product exists for.

Give a guest a schedule.

I could not find it.

The flow was buried behind a 2 pixel grey label that said "0 assigned." No guidance, no empty state, nearly invisible. I wrote the spec, and I could not find my own core feature. That is not a nitpick. That is the product failing at the one thing it is for.

What Bolt did

Bolt had better instincts and worse discipline.

Assigning a guest was obvious. The guest showed up as a chip right on the itinerary item, handled inside the form. Exactly the workflow Lovable hid.
Typography was calmer. Title Case, not all caps everywhere.
It showed the full guest link in plaintext instead of hiding it behind a button.

Then I looked at the calendar.

Bolt ignored my doc and invented its own. It put Bahrain as Round 1.

It brought back races that are not on the schedule. For an F1 audience, that is an instant credibility killer. They will clock it in two seconds.

So I had a real trade on my hands.

Lovable: faithful to the data, weak UX.
Bolt: sharp UX, careless with the facts.

Neither was sendable. And here is the part that actually taught me something.

Why were they so similar?

Strip away the calendar bug and the assign flow, and the two apps looked like siblings.

Both defaulted to dark mode. Both used the same font, the same neon red on near-black, the same all-caps labels, the same flat grid of identical cards. Neither had a single image. Two
different companies, two different models, near-identical screens.
That is not a coincidence. That is the brief.

I had over-specified the visuals. Exact hex codes. Exact font. Sharp corners. n every token, you collapse the design space to roughly one answer. The briefdid the "design." The tools just painted it in. The sameness was baked in before either of them started.

One more tell. The headless browser I used had no dark-mode preference set, and both apps still rendered dark anyway. Neither built a light option. They went dark because my brief said near-black background, full stop.

The lesson

Tokens are not design.
A hex code and a font name produce a screen. They do not produce hierarchy, re deliberate choice about what to leave out. My brief specified all the paintand none of the architecture, so both tools defaulted to the same safe admin panel wearing F1 colours.

Real design was the part I never wrote down. Layout. Emphasis. What the eye lands on first. What gets cut.

So I rebuilt it, and the first thing I threw out was my own aesthetic.

Light by default, dark as a choice, not a cage. - Editorial and image-led. Real circuit photography carrying the emotion, not
Space Grotesk for character, Inter to do the quiet reading work. - Red used sparingly as an accent, not a coat of paint.
And I kept the one thing Bolt got right. The discoverable, chip-based way of assigning a guest.

Same problem. Same category of tools. A completely different result. The difference was judgment, not technology.

If you brief an AI tool or a teammate, where is the line between giving enough direction and accidentally handing over the one decision only you should make?

Building a $0-marketing app with Claude Fable 5

Vaibhav Dwivedi — Tue, 14 Jul 2026 14:30:00 +0000

UPDATE (July 15): The experiment left the lab as Kokoro is now live on the Japanese App Store: https://apps.apple.com/jp/app/id6788245039. The $0-marketing clock officially starts today; follow-up post with real numbers (good or bad) coming in ~6 weeks.

I ran an experiment: can an AI agent take a product from market research to a submitted App Store app, solo, with a hard $0 marketing budget? Not "cheap marketing." Zero. The app has to be discoverable or die.

This is the build log. The app — こころ (Kokoro), an anonymous AI self-care companion for Japan — is sitting in App Review as I write this, so no revenue numbers yet. What I can share is the method, because the method is the interesting part.

The setup

Everything ran through Claude Code with Fable 5 (Anthropic's new Mythos-class model). Not as a code autocomplete — as the other half of the team. It ran the market research pipeline, made the competitive analysis, wrote the launch plan with kill-gates, built the app, drew the mascot, generated the App Store screenshots, deployed the backend, and drafted the store listing. My job was decisions, accounts, and taste.

The starting point was a research doc with a small tool inside it: a JavaScript scanner that hits Apple's free, public APIs — top-grossing RSS charts (a revenue proxy), the iTunes lookup API (ratings), and the public review feeds. No Sensor Tower subscription. No API keys. Free data that most people don't realize exists.

Research before ideas

The agent re-ran that pipeline fresh across 6 storefronts: 1,798 top-grossing apps, filtered to wellbeing, then mined ~1,000 recent 1–2★ reviews from the interesting targets.

Three findings made every decision downstream:

1. Japan is the emptiest rich market. 24 wellbeing apps in 300 top-grossing slots (US: 118). This matters because a $0 marketing budget has exactly one growth channel: organic App Store search. ASO only works where the keyword space isn't saturated. The market choice wasn't a preference — it was forced by the constraint.

2. Paying users write your spec in their 1-star reviews. Japan's top-grossing CBT app: 38% of recent reviews negative. Verbatim: "the built-in AI feels a generation old — better to talk to free GPT-5.2." Another app's users said ChatGPT was more empathetic than the human counselors they were paying for. A third app's AI reframed a user's abuse story as "maybe the other side had circumstances too." Every one of those reviews became a product rule with a comment in the codebase pointing back to it.

3. Billing rage beats feature requests everywhere. The dominant 1-star theme in every single app we mined — Japan, US, Korea — was billing. Silent ¥19,000 annual renewals. Refusal to refund. Paywalls shoved at users right after emotional intake. Which means the cheapest differentiation available wasn't a feature at all: it was honesty. Pre-renewal notifications (a local push, no server needed), one-tap cancel, promises printed on the paywall itself.

The PM layer: kill-gates, not vibes

The plan isn't "build it and hope." Each stage has a pre-committed kill criterion:

Gate 0 (before any code): does App Store autocomplete prove Japanese users search for this? (It did — including "認知行動療法無料" and competitors' brand names.) Cost of being wrong: 2 hours.
Gate 1 (before launch): do TestFlight testers keep journaling after a week, or drift back to ChatGPT? If they drift, fix the loop before launch — don't launch into a wall.
Gate 2 (launch + 6 weeks): trial→paid ≥ 5%, rating ≥ 4.5. Under 2% after paywall iteration = the market said no, and the pivot (same codebase, different market) is already written down.

Pre-deciding the kill conditions is the discipline part. It's much harder to lie to yourself when past-you already defined failure.

Same logic drove the biggest scope decision: cloud backup with end-to-end encryption is the most expensive remaining feature, so it ships after the gates prove people retain and pay — not before. v1 is honest about it: local-only storage, stated plainly in the privacy policy.

Things the agent did that surprised me

The mascot. It picked a capybara with a yuzu on its head — onsen capybaras are Japan's cultural shorthand for calm. Then it drew the SVG, wrote itself a design guide (geometry recipe, palette tokens, expression rules) so future art stays on-model, and rasterized the app icon with headless Edge because I didn't have proper design tooling installed.
The App Store screenshots are HTML files rendered at 1320×2868 — same pipeline. The letter shown in screenshot #4 is a real output from the production backend, not lorem ipsum.
Live debugging across three ecosystems in one evening: a space in a folder name breaking Xcode builds, Vercel dropping Node 18 while our blog engine emitted syntax removed in Node 22+ (fixed with a pre-build patch that rewrites assert { type: 'json' } to with { type: 'json' } inside node_modules), and Apple's screenshot-slot dimensions. None of these are in a tutorial.
Provider-agnostic AI backend. The app never holds an API key: a Supabase edge function does, and AI_PROVIDER / AI_MODEL env secrets switch every user between Claude and OpenAI models with zero app releases. We switched providers mid-testing with a single dashboard edit.

The stack, for the curious

Expo SDK 57 (React Native), local-first AsyncStorage journal, Supabase Edge Functions as the AI proxy, RevenueCat for IAP (pay-first, no accounts — even payment is anonymous), PostHog for the gate metrics, and the whole build/sign/upload pipeline driven from the terminal via xcodebuild.

Total cash spent: the $99 Apple developer fee. Time: three days from reading the research file to "Waiting for Review."

What I'd tell you to steal

Apple's free APIs are a research goldmine. Top-grossing charts + review feeds = demand proof and a written spec, for free.
Pick the market your constraint forces, not the one you like. $0 marketing chose Japan for us.
Mine 1-star reviews of profitable apps. Angry paying customers are the highest-signal PMs on earth.
Make honesty a feature when the category is dishonest. It's the only differentiation that costs nothing and compounds.
Write your kill criteria before you write code.

The experiment continues — Gate 1 (Japanese TestFlight testers) is next, and the data decides from here. If you want the follow-up when real numbers exist, watch this space.

Built with Claude Code (Fable 5). Decisions, mistakes, and the capybara approval were human.

Spinners in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Tue, 05 Nov 2024 16:43:00 +0000

Day 29: Spinners – Loading Elements in SwiftUI

Let's learn to add loading spinners to your SwiftUI applications.

Spinners provide users with visual feedback while waiting for data to load, enhancing the overall user experience.

Step 1: Using SwiftUI's Built-in ActivityIndicator

SwiftUI provides a built-in ProgressView that you can use as a spinner. Here’s how to implement it in your app.

Basic Spinner Example

import SwiftUI

struct SpinnerExampleView: View {
    @State private var isLoading = false

    var body: some View {
        VStack {
            if isLoading {
                ProgressView("Loading...")
                    .progressViewStyle(CircularProgressViewStyle(tint: .blue)) // Customize color
                    .scaleEffect(1.5) // Adjust size
                    .padding()
            } else {
                Button("Load Data") {
                    loadData()
                }
                .padding()
            }
        }
        .navigationTitle("Spinner Example")
    }

    private func loadData() {
        isLoading = true

        // Simulating a network call
        DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
            isLoading = false // Stop loading after 2 seconds
        }
    }
}

Comments for Customization:

ProgressView("Loading..."): The spinner label that shows while loading. You can customize this text.
.progressViewStyle(CircularProgressViewStyle(tint: .blue)): Sets the color of the spinner.
.scaleEffect(1.5): Adjusts the size of the spinner for better visibility.

How are you going to implement Spinners? Let me know.

Happy coding!

Adding Animations with Lottie in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Mon, 04 Nov 2024 16:30:00 +0000

Day 28: Lottie Animations – Integrating Lottie Animations into Your UI 🎨

Lottie is a powerful library that allows you to use amazing animations that are lightweight and easy to implement.

Let’s get started!

Step 1: Setting Up Lottie

First, you need to add the Lottie framework to your project. You can do this using Swift Package Manager or by manually adding the Lottie files.

Using Swift Package Manager:
- Go to File > Add Packages.
- Search for Lottie or use the URL: https://github.com/airbnb/lottie-ios.
- Add the package to your project.

Step 2: Create a SwiftUI Wrapper for Lottie

Next, you’ll create a SwiftUI wrapper for the Lottie animation view. This allows you to easily use Lottie animations within your SwiftUI views.

import SwiftUI
import Lottie

struct LottieView: UIViewRepresentable {
    var filename: String

    func makeUIView(context: Context) -> UIView {
        let view = UIView(frame: .zero)

        let animationView = LottieAnimationView(name: filename)
        animationView.contentMode = .scaleAspectFit
        animationView.loopMode = .loop
        animationView.play()

        animationView.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(animationView)

        NSLayoutConstraint.activate([
            animationView.widthAnchor.constraint(equalTo: view.widthAnchor),
            animationView.heightAnchor.constraint(equalTo: view.heightAnchor)
        ])

        return view
    }

    func updateUIView(_ uiView: UIView, context: Context) {
        // Update the view if needed
    }
}

Step 3: Using Lottie Animations in Your View

Now that you have your LottieView set up, you can use it in your SwiftUI views.

import SwiftUI

struct AnimationExampleView: View {
    var body: some View {
        VStack {
            Text("Loading...")
                .font(.largeTitle)
                .padding()

            LottieView(filename: "loading_animation", loop: true)
                .frame(width: 200, height: 200)
        }
        .padding()
        .navigationTitle("Lottie Animation Example")
    }
}

Comments for Customization:

LottieView(filename: "loading_animation", loop: true): This instantiates the LottieView with a specific animation file. Replace "loading_animation" with the name of your Lottie animation file (without the .json extension).
frame(width: 200, height: 200): Sets the size of the animation view. Adjust these values to fit your design.

Step 4: Adding Your Animation Files

Make sure to add your Lottie animation files (in JSON format) to your Xcode project. Simply drag and drop the .json files into your project navigator.

That's it. Happy Coding!

Accessibility Features (a11y) in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Sun, 03 Nov 2024 16:30:00 +0000

Day 26: Making Apps Accessible for Users with Disabilities

Today, we’ll explore how to make your SwiftUI applications accessible to users with disabilities.

Ensuring accessibility means that all users can interact with your app effectively and enjoyably.

SwiftUI offers several accessibility modifiers to help improve the usability of your app for all users:

.accessibilityLabel: Provides a descriptive label for UI elements.
.accessibilityValue: Represents the current value of an interactive element.
.accessibilityHint: Offers hints about how to use a UI element.
.accessibilityAction: Allows you to define custom actions for accessibility.

Building an Accessible Form

Let’s create a simple form where users can input their name and age.

import SwiftUI

struct AccessibleFormView: View {
    @State private var name: String = ""
    @State private var age: String = ""

    var body: some View {
        Form {
            Section(header: Text("User Information")
                        .font(.headline)
                        .accessibilityLabel("User Information Section")) {
                TextField("Enter your name", text: $name)
                    .accessibilityLabel("Name")
                    .accessibilityValue(name.isEmpty ? "Empty" : name)
                    .accessibilityHint("Please enter your full name.")

                TextField("Enter your age", text: $age)
                    .keyboardType(.numberPad)
                    .accessibilityLabel("Age")
                    .accessibilityValue(age.isEmpty ? "Empty" : age)
                    .accessibilityHint("Please enter your age as a number.")
            }

            Button(action: submit) {
                Text("Submit")
                    .padding()
                    .frame(maxWidth: .infinity)
                    .background(Color.blue)
                    .foregroundColor(.white)
                    .cornerRadius(8)
            }
            .accessibilityLabel("Submit Button")
            .accessibilityHint("Tap to submit your information.")
        }
        .padding()
        .navigationTitle("Accessibility Form")
    }

    private func submit() {
        // Handle form submission
        print("Name: \(name), Age: \(age)")
    }
}

After implementing accessibility features, it’s essential to test them with VoiceOver on your device.

Navigate through your app and ensure that all elements are announced correctly, and users can interact with them smoothly.

Best Practices for Accessibility

Use Dynamic Type for adjustable text sizes.
Ensure sufficient contrast between text and background colors.
Provide text labels for color-coded information.
Make interactive elements large enough for easy tapping.

Happy Coding!

SplitView in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Sat, 02 Nov 2024 16:32:00 +0000

Day 25: Manifesting a Split View Layout

Welcome to Day 25 of the #30DaysOfSwift series!

Split views allow you to create master-detail interfaces that are perfect for iPad, offering a way to present multiple panes of information side by side.

Step 1: Understanding the Split View Layout

In a split view, you typically have:

A sidebar (or master view) that displays a list of items.
A detail view that shows content based on the selection from the sidebar.

SwiftUI makes it easy to create this kind of layout using NavigationSplitView.

Step 2: Building the Split View

import SwiftUI

struct SplitViewExample: View {
    @State private var selectedItem: String? = "Item 1"
    let items = ["Item 1", "Item 2", "Item 3"]

    var body: some View {
        NavigationSplitView {
            // Sidebar View
            List(items, id: \.self, selection: $selectedItem) { item in
                Text(item)
                    .padding()
                    .frame(maxWidth: .infinity, alignment: .leading)
            }
            .navigationTitle("Sidebar")
        } detail: {
            // Detail View
            if let selectedItem = selectedItem {
                DetailView(selectedItem: selectedItem)
            } else {
                Text("Select an item")
                    .font(.largeTitle)
                    .foregroundColor(.gray)
            }
        }
    }
}

struct DetailView: View {
    let selectedItem: String

    var body: some View {
        VStack {
            Text("Details for \(selectedItem)")
                .font(.largeTitle)
                .padding()

            Spacer()
        }
        .navigationTitle("Detail")
    }
}

How does it works out for you? Share your thoughts below.

Happy Coding!

Forms and Input Handling in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Fri, 01 Nov 2024 16:31:00 +0000

Day 24: Designing Forms and Handling User Input Validation 📋

Let's go to the basics today with by creating forms and handling user input in SwiftUI.

Forms are a core part of many apps for collecting data from users.

Let’s jump in!

Code

SwiftUI provides the Form container, making it easy to create user-friendly input forms.

import SwiftUI

struct UserFormView: View {
    @State private var username = ""
    @State private var email = ""
    @State private var password = ""
    @State private var errorMessage = ""

    var body: some View {
        Form {
            // Username Input
            Section(header: Text("Username")) {
                TextField("Enter your username", text: $username)
                    .autocapitalization(.none)
                    .disableAutocorrection(true)
                    .textFieldStyle(RoundedBorderTextFieldStyle())
            }

            // Email Input
            Section(header: Text("Email")) {
                TextField("Enter your email", text: $email)
                    .autocapitalization(.none)
                    .keyboardType(.emailAddress)
                    .disableAutocorrection(true)
                    .textFieldStyle(RoundedBorderTextFieldStyle())
            }

            // Password Input
            Section(header: Text("Password")) {
                SecureField("Enter your password", text: $password)
                    .textFieldStyle(RoundedBorderTextFieldStyle())
            }

            // Error Message
            if !errorMessage.isEmpty {
                Text(errorMessage)
                    .foregroundColor(.red)
            }

            // Submit Button
            Button(action: {
                validateForm()
            }) {
                Text("Submit")
                    .frame(maxWidth: .infinity)
                    .padding()
                    .background(Color.blue)
                    .foregroundColor(.white)
                    .cornerRadius(8)
            }
        }
        .navigationTitle("User Form")
    }

    // Step 3: Validate the form inputs
    func validateForm() {
        if username.isEmpty || email.isEmpty || password.isEmpty {
            errorMessage = "All fields are required!"
        } else if !email.contains("@") {
            errorMessage = "Invalid email address!"
        } else if password.count < 6 {
            errorMessage = "Password must be at least 6 characters!"
        } else {
            errorMessage = ""
            // Handle successful form submission (e.g., save data)
        }
    }
}

The full series is available on my profile and the components can also be found at shipios.app/components.

Happy Coding!

AVKit Integration in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Thu, 31 Oct 2024 16:38:00 +0000

Day 23: AVKit Integration – Playing Videos and Media in SwiftUI 🎬

Today, we’ll explore how to integrate AVKit into your SwiftUI project.

AVKit is the framework that lets you play videos and audio seamlessly with built-in controls.

Comments for Customization:

player.play(): This starts video playback.
cornerRadius(10): This rounds the corners of the video view, making it visually appealing.
frame(height: 300): The video player is confined to a specific height, ensuring a clean layout.

Here's the code for the implementation shown:

import AVKit
import SwiftUI

struct VideoPlayerView: View {
    private var player = AVPlayer(url: URL(string: "https://www.example.com/samplevideo.mp4")!)

    var body: some View {
        VStack {
            VideoPlayer(player: player)
                .frame(height: 300)
                .cornerRadius(10)

            HStack {
                Button("Play Video") {
                    player.play()
                }
                .font(.headline)
                .foregroundColor(.white)
                .padding()
                .background(Color.blue)
                .cornerRadius(8)

                Button("Pause Video") {
                    player.pause()
                }
                .font(.headline)
                .foregroundColor(.white)
                .padding()
                .background(Color.red)
                .cornerRadius(8)
            }
            .padding(.top, 20)
        }
        .padding()
    }
}

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Welcome to Video Player")
                .font(.largeTitle)
                .padding()

            VideoPlayerView()
        }
    }
}

The full series is available on my profile and the components can also be found at shipios.app/components.

Happy Coding! 🎨

LazyHGrid Grid Layout in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Wed, 30 Oct 2024 16:43:00 +0000

Day 22: Exploring LazyHGrid

Cheers to the Day 22nd of the #30DaysOfSwift series!

Today, we’re diving into SwiftUI's LazyHGrid, an efficient way to display grid-like content in a horizontal scroll view.

Whether you’re building an image gallery, a product list, or a grid-based menu, LazyHGrid helps keep your UI smooth and responsive.

We’ll create a layout with 3 rows and display a series of numbered grid items.

Code Example

import SwiftUI

struct LazyHGridExample: View {
    // Define the grid layout with 3 rows and flexible spacing
    let rows = [GridItem(.fixed(100)), GridItem(.fixed(100)), GridItem(.fixed(100))]

    var body: some View {
        ScrollView(.horizontal) { // Enable horizontal scrolling
            LazyHGrid(rows: rows, spacing: 20) { // Create LazyHGrid with 3 rows
                ForEach(0..<30) { item in
                    // Create grid items with a rounded rectangle
                    RoundedRectangle(cornerRadius: 10)
                        .fill(Color.blue)
                        .frame(width: 100, height: 100) // Fixed size for each grid item
                        .overlay(
                            Text("\(item)")
                                .font(.largeTitle)
                                .foregroundColor(.white) // Display item number on top
                        )
                }
            }
            .padding() // Add padding around the grid
        }
    }
}

struct ContentView: View {
    var body: some View {
        LazyHGridExample() // Show LazyHGrid layout in the main view
    }
}

@main
struct LazyHGridApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView() // Main content view
        }
    }
}

The full series is available on my profile and the components can also be found at shipios.app/components.

Happy Coding! 🎨

Custom Toggle Button in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Wed, 30 Oct 2024 16:42:00 +0000

Day 21: Custom Toggle Button, anyone? ⚙️

Today, we’re going to create a custom toggle button in SwiftUI.

Implementing a Custom Toggle Button

In this example, we’ll create a visually appealing custom toggle button that switches between on and off states.

Code Example

Here’s how you can implement a custom toggle button in SwiftUI:

import SwiftUI

struct CustomToggle: View {
    @Binding var isOn: Bool // Binding variable for toggle state

        var body: some View {
            HStack {
                Text("Toggle Setting")
                    .foregroundColor(.primary) // Text color
                Spacer()
                // Custom square toggle design
                RoundedRectangle(cornerRadius: 5) // Rounded corners
                    .fill(isOn ? Color.blue : Color.gray) // Toggle color based on state
                    .frame(width: 60, height: 30) // Toggle size
                    .overlay(
                        Rectangle() // Square knob design
                            .fill(Color.white)
                            .frame(width: 26, height: 26)
                            .offset(x: isOn ? 15 : -15) // Move the square based on state
                            .animation(.easeInOut(duration: 0.2), value: isOn) // Animation for smooth transition
                    )
                    .onTapGesture {
                        isOn.toggle() // Toggle the state on tap
                    }
            }
            .padding() // Padding for the entire toggle
        }
    }

struct ContentView: View {
    @State private var isToggleOn = false // State to manage toggle status

    var body: some View {
        VStack {
            CustomToggle(isOn: $isToggleOn) // Custom toggle instance
            Text(isToggleOn ? "Setting is ON" : "Setting is OFF") // Display current state
                .padding()
        }
        .padding()
    }
}

@main
struct CustomToggleApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView() // Main content view
        }
    }
}

The full series is available on my profile and the components can also be found at shipios.app/components.

Happy Coding! 🎈

Pull-to-Refresh in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Tue, 29 Oct 2024 16:36:00 +0000

Day 20: Adding a Pull-to-Refresh Feature to Your Lists or Views 🔄

Let's implement the pull-to-refresh feature in SwiftUI, a common gesture that enhances user experience by allowing users to refresh content easily.

Implementing Pull-to-Refresh

To add a pull-to-refresh feature, we can use the .refreshable modifier available in SwiftUI. This modifier simplifies the implementation process and allows us to handle the refresh action with minimal code.

Code Example

import SwiftUI

struct ContentView: View {
    @State private var items = ["Item 1", "Item 2", "Item 3"] // Sample data
    @State private var isLoading = false // State to manage loading state

    var body: some View {
        NavigationView {
            List(items, id: \.self) { item in
                Text(item) // Display items in the list
            }
            .navigationTitle("Pull to Refresh")
            .refreshable {
                await loadData() // Call the async function to load data
            }
        }
    }

    func loadData() async {
        isLoading = true // Set loading state
        // Simulate network delay
        try? await Task.sleep(nanoseconds: 2 * 1_000_000_000) // Wait for 2 seconds
        // Update items with new data
        items.append("Item \(items.count + 1)") // Add a new item for demonstration
        isLoading = false // Reset loading state
    }
}

@main
struct PullToRefreshApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView() // Main content view
        }
    }
}

The full series is available on my profile and the components can also be found at shipios.app/components.

Happy Coding! 🎊

Progress Bars in iOS 18 - #30DaysOfSwift

Vaibhav Dwivedi — Mon, 28 Oct 2024 16:30:00 +0000

Day 19: Tell Your Users About The Progress ⏳

Welcome to Day 19 of the #30DaysOfSwift series!

Learn today about how to implement progress bar in your SwiftUI app.

Why Use Progress Indicators?

User Feedback: They inform users that a task is in progress, improving the overall user experience.
Task Transparency: Users can gauge how long they might need to wait, which can reduce frustration.
Modern UI: Adding progress indicators enhances the aesthetics and functionality of your app.

Example Use Case: Implementing a Progress Bar

In this example, we’ll create a simple progress bar that updates as a task progresses.

import SwiftUI

struct ContentView: View {
    @State private var progress = 0.0 // State variable to track progress

    var body: some View {
        VStack {
            ProgressView("Loading...", value: progress, total: 100) // Progress bar
                .progressViewStyle(LinearProgressViewStyle()) // Style of the progress bar
                .padding()

            Button("Start Loading") {
                startLoading() // Start the loading process
            }
            .padding()
        }
        .padding()
    }

    func startLoading() {
        progress = 0.0 // Reset progress
        for i in 1...100 {
            DispatchQueue.main.asyncAfter(deadline: .now() + Double(i) * 0.1) {
                progress = Double(i) // Update progress
            }
        }
    }
}

@main
struct ProgressIndicatorApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView() // Main content view
        }
    }
}

Now it’s your turn! Try adding progress indicators to your app to keep users informed during loading processes!

P.S. Check out full series at shipios.app/componenets

Happy Coding! 🎉