I started learning programming back in the early 90s. The World Wide Web had just been introduced, but it would still be a few years before I had access to the internet.

Luckily, books were available, and I spent most of my time reading programming books and manually typing code, one instruction at a time, into the editor. One of the first programming languages I learned was GW BASIC. I still remember creating a simple program that displayed a face that would switch between happy and sad.

A few years later, I finally got access to the internet, and a few years after that, Google arrived. Technology was advancing rapidly, but developers still had to struggle to find and implement solutions.

For example, imagine you were building an application that displayed a map, and you wanted to cluster different markers together. You would have to read documentation, search Stack Overflow, or explore other online resources to figure out how to implement it.

Sometimes, you would find the exact answer you were looking for. Other times, you would find something similar and have to think through how to apply that solution to your particular situation.

Fast forward to today, and AI can generate an entire implementation in just a few seconds. This is great because you save a lot of time and suddenly become a 10X developer. But at the same time, you may not have struggled at all. All it took was a single prompt, and your work was done.

But if AI does all the work, what exactly are we learning?

I have been teaching in one form or another since before 2002, and one thing I strongly believe is that if you are not struggling, you are not learning. This is especially true when you are trying to learn something new.

When I was teaching at a physical campus, I would always tell my students to break down a problem into smaller tasks. For each task, give yourself 15 to 20 minutes of pure struggle before asking for help.

That is when real learning happens.

You might try nine different approaches, and none of them work. Finally, on your tenth attempt, you find a solution. But you did not fail nine times. You discovered nine different approaches that did not work.

As Thomas Edison is often quoted as saying:

I have not failed. I’ve just found 10,000 ways that won’t work.

Today, AI has made it easier than ever to avoid that struggle. Even worse, some developers have stopped reviewing AI generated code. They simply assume that because AI wrote the code and it works, it must be good.

Unfortunately, my experience has been that while AI is very good at generating code, it does not always account for the long term consequences of its decisions. It can produce a working implementation without considering how that implementation will affect the architecture, maintainability, or future development of the application.

Generating code is not the same as engineering software.

So, should we stop using AI?

No.

AI is a powerful technology, but with great power comes great responsibility. We should use AI to enhance and amplify our learning instead of replacing it.

Instead of asking AI to generate the complete solution, ask it to point you toward the documentation for the framework you are trying to learn. You can even explicitly tell AI not to provide a solution, but instead to share relevant code samples from the documentation.

You can also ask for a hint rather than working code. That hint might give you just enough information to investigate further and move one step closer to solving the problem yourself.

There is also an important difference between using AI to become more productive and using AI to become a better programmer.

We often measure the success of AI by how much time it saves us. But when it comes to learning, saving time should not always be the goal. Sometimes, spending an hour understanding a problem is more valuable than solving it in five minutes.

One analogy I find helpful is going to the gym. Imagine hiring a personal trainer, but instead of exercising yourself, you let the trainer lift all the weights while you sit on the sidelines.

No matter how much your trainer exercises, you are not going to lose weight or build muscle. Your trainer might get stronger, but you won’t.

The same idea applies to your brain.

Your brain also needs exercise, and one way to exercise it is by working through problems yourself. You need to think critically about different scenarios, explore possible solutions, and understand how your decisions affect the final implementation.

This does not mean you should struggle with everything. There is a difference between productive struggle and unnecessary frustration. Spending hours dealing with a configuration issue may not teach you much, but spending time understanding why your application has a race condition can make you a better developer.

The goal is not to make programming unnecessarily difficult. The goal is to make sure we are still learning.

The next time you are working on a problem, break it down into smaller tasks. Spend 15 to 20 minutes working through each task before waving the white flag and asking AI for help.

During that time, you can still use AI to look up references, documentation, code samples, or even ask for hints. Just resist the temptation to ask it to generate the complete solution.

Those 15 to 20 minutes might feel frustrating, especially when you know AI could solve the problem in seconds. But that struggle is an investment in yourself.

When I was learning GW BASIC, I spent hours writing simple programs and figuring out why things did not work. Today, AI could generate those same programs in seconds.

But I don’t consider those hours wasted. They taught me how to think, experiment, solve problems, and keep going when things did not work.

I am not suggesting that we should stop using AI or go back to the way we programmed in the 90s. I am suggesting that we should be intentional about how we use AI, especially when our goal is to learn.

There is a great quote that captures this idea perfectly:

“You can outsource your thinking, but you cannot outsource your understanding.”

Get the book

When building applications, it is common to display a list of items and allow users to sort them based on different criteria. For example, in a hotel booking application, users may want to sort hotels by price or guest ratings.

There are different ways to implement sorting. One approach is to fetch all the records from the server and sort them locally on the client. This works fine for smaller datasets, but as the number of records grows, fetching everything just to sort it is not a good idea. A better approach is to let the server handle sorting and return the results in the requested order.

In this article, we will learn how to implement server-side sorting using Express.js and SwiftUI. We will start by building an API that supports different sorting options through query parameters. Next, we will implement the SwiftUI client using the @Observable macro to manage our hotel data. Finally, we will create a sorting interface that allows users to select, clear, and confirm their sorting preferences.

Let’s get started!

Patterns and Practices for Building Scalable Applications

A practical guide to building SwiftUI apps that stay clean as they grow.

Get the book

Building the Sorting API with Express.js

These days, you have countless options when it comes to implementing a server. Even in the Swift ecosystem, you have frameworks like Vapor and Hummingbird. My personal favorite is Express.js, mainly because I have taught it for a long time and I also enjoy the dynamic nature of JavaScript.

One thing I like about using JavaScript on the server is that I don’t have to create separate DTO objects for every response. I can simply return anonymous objects. I personally like this flexibility.

For our hotel application, we will implement an API endpoint that allows clients to sort hotels based on different criteria, such as price and guest ratings. The client will specify the sorting option using a query string parameter, and the server will be responsible for sorting the results before returning them.

Below, you can find the implementation of the /api/hotels route, which supports different sorting options.

app.get("/api/hotels", (req, res) => {
// get the sort options 
    const { sort } = req.query
    // hotels is a hard-coded list 
    const sortedHotels = sortHotels(hotels, sort)
    res.json(sortedHotels)
})
const sortHotels = (hotels, sort) => {
    switch (sort) {
        case "priceLowToHigh":
            hotels.sort((a, b) => a.price - b.price)
            break
        case "priceHighToLow":
            hotels.sort((a, b) => b.price - a.price)
            break
        case "guestRating":
            hotels.sort((a, b) => b.guestRating - a.guestRating);
            break
    }
    return hotels 
}

The query string parameter determines how the hotels are sorted. For example, http://localhost:8080/api/hotels?sort=priceLowToHigh will return hotels sorted by price in ascending order, from lowest to highest.

Now that our server is working as expected, we can move on to implementing the SwiftUI client.

Building the SwiftUI Hotel App

We will start by implementing our HotelStore, which will be responsible for managing the state of hotels along with the business and domain logic associated with them.

Unlike traditional View Models, you don’t need to create a separate HotelStore for each screen. HotelStore is designed around the bounded context of hotel management and can be shared across multiple screens that work with hotel-related entities and operations.

The implementation of HotelStore is shown below:

@Observable
class HotelStore {
    
    private(set) var hotels: [Hotel] = []
    let httpClient: HTTPClient
    
    init(httpClient: HTTPClient) {
        self.httpClient = httpClient
    }
    
    func loadHotels(sortOption: SortOption? = nil) async throws {
        let resource = Resource(url: Constants.URLs.hotels(sort: sortOption), responseType: [Hotel].self)
        hotels = try await httpClient.fetch(resource: resource)
    }
}

HotelStore has a dependency on HTTPClient, which is responsible for performing network requests. The loadHotels function also accepts an optional SortOption, allowing us to construct the appropriate URL based on the selected sorting option.

The Constants.URLs.hotels function is responsible for constructing the URL with the necessary query string parameters. In a future article, we will extend this function to support filtering and pagination.

Inside our SwiftUI view, we can access HotelStore through the environment.

Another option is to pass HotelStore as a dependency through the initializer. I personally prefer using the environment because I often end up using the same store across multiple screens. Passing the store through the initializer of every screen can become cumbersome.

The implementation of HotelListScreen is shown below:

struct HotelListScreen: View {
    
    @Environment(HotelStore.self) private var hotelStore
    @State private var showSortSheet: Bool = false
    
    @State private var sortOption: SortOption?
    
    var body: some View {
        List {
            
            HStack {
                Spacer()
                Button("Sort") {
                    showSortSheet = true
                }
            }
            
            ForEach(hotelStore.hotels) { hotel in
                HotelCellView(hotel: hotel)
            }
        }
        .sheet(isPresented: $showSortSheet, content: {
            SortView(initialSelection: sortOption, onDone: { option in
                sortOption = option
                Task { await loadHotels() }
            }).presentationDetents([.fraction(0.25)])
        })
        .task {
            await loadHotels()
        }.navigationTitle("Hotels")
    }
    
    private func loadHotels() async {
        do {
            try await hotelStore.loadHotels(sortOption: sortOption)
        } catch {
            print(error.localizedDescription)
        }
    }
}

You might be wondering why we pass sortOption to the loadHotels function instead of creating a separate function for sorting. You can definitely take that approach, but I personally prefer this design, which is inspired by the Sequelize ORM in JavaScript.

The idea is simple. You can call loadHotels without passing any options to fetch the default set of hotels (limited to 10 records by default), or you can provide options to customize the results. As we add more features, the same function will support sorting, filtering, and pagination without requiring separate functions for each operation.

The user selects the sorting option through SortView. The implementation is shown below:

struct SortView: View {
    
    @State private var selectedSortOption: SortOption?
    @Environment(\.dismiss) private var dismiss
    
    let onDone: (SortOption?) -> Void
    
    init(initialSelection: SortOption? = nil, onDone: @escaping (SortOption?) -> Void) {
        _selectedSortOption = State(initialValue: initialSelection)
        self.onDone = onDone
    }
    
    var body: some View {
        VStack {
            
            HStack {
                Button("Close") {
                    dismiss()
                }
                
                Spacer()
                
                Button("Clear") {
                    selectedSortOption = nil
                }
                
            }.padding([.bottom], 10)
            
            ForEach(SortOption.allCases) { sortOption in
                Button {
                    selectedSortOption = sortOption
                } label: {
                    HStack {
                        Image(systemName: selectedSortOption == sortOption
                              ? "largecircle.fill.circle" : "circle")
Text(sortOption.title)
                    }
                    .frame(maxWidth: .infinity, alignment: .leading)
                    .contentShape(Rectangle())
                }
                .buttonStyle(.plain)
            }
            
            Button("Done") {
                onDone(selectedSortOption)
                dismiss()
                
            }.frame(maxWidth: .infinity, alignment: .leading)
            .padding([.top], 20)
            .buttonStyle(.borderedProminent)
            
        }.padding()
    }
}

The interesting part of this implementation is the use of a closure instead of passing an @Binding from the parent. The main reason I decided not to use @Binding is that I want users to be able to cancel their sorting selections without affecting the currently applied sort option.

If we directly bind the selected sort option to the parent’s state, every selection will immediately update that state, even if the user decides to cancel.

One way to solve this is to introduce a separate draftSortOption in the parent and pass it as a binding to SortView. That approach works perfectly fine, but I prefer a simpler solution.

In our implementation, SortView manages its own temporary selection using @State. When the user taps the Done button, we pass the selected sort option back to the parent through a closure. If the user closes the sheet without tapping Done, the original sort option remains unchanged.

Resources

• Hummingbird Fundamentals — Build REST APIs in Swift
• Full Stack iOS Development Using Swift & Vapor

Conclusion

In this article, we learned how to implement server-side sorting in a SwiftUI application. Instead of fetching all the records and sorting them on the client, we delegated the sorting responsibility to the server. This approach becomes especially useful when working with large datasets.

We also explored how to use @Observable to manage our hotel data and how to build a sorting interface using SwiftUI sheets. One interesting design decision was using a closure instead of @Binding, allowing users to confirm or cancel their selections without immediately updating the parent state.

In the next article, we will extend our implementation to support server-side filtering and pagination. This will allow users to narrow down their search results and load hotels in smaller batches instead of fetching everything at once.

Continue Learning with AzamSharp School

Become an AzamSharp School member and get access to more than 250 hours of practical courses covering SwiftUI, SwiftData, testing, architecture, AI, machine learning, and more.

Your membership also includes access to AzamSharp books, live workshops, office hours, and new content added regularly.

Join AzamSharp School

After many months of writing, researching, testing, and revising, I am excited to announce the release of my new book:

SwiftData Architecture — Patterns and Practices for Building Scalable Applications

SwiftData has quickly become the preferred persistence framework for many Apple developers. It provides a modern API, deep SwiftUI integration, and significantly reduces the amount of boilerplate code required to build data-driven applications.

The demos look great.

The sample applications work perfectly.

Then real-world development begins.

Why I Wrote This Book

Most SwiftData tutorials focus on getting started.

Create a model.

Create a query.

Save some data.

Everything works.

But once your application starts growing, new challenges emerge:

• How should you structure your application?
• How do you test SwiftData applications?
• How do dynamic queries work?
• When should you use external storage?
• How do you debug SwiftData problems?
• What happens when CloudKit synchronization enters the picture?
• How do you handle large datasets efficiently
• Can you build your own custom data store?

These are the questions I encountered while building real applications and experimenting extensively with SwiftData.

This book is my attempt to answer those questions.

What’s Inside

The book covers a wide range of SwiftData topics, including:

SwiftData Architecture

Learn practical approaches for organizing SwiftData applications without introducing unnecessary complexity.

Debugging SwiftData

Discover techniques for inspecting your data store, understanding generated schemas, and troubleshooting common issues.

Dynamic Queries

Learn how to build applications that support searching, filtering, and sorting while working within SwiftData’s query system.

CloudKit Synchronization

Explore common CloudKit challenges and practical solutions for building synchronized applications.

Performance Optimization

Learn techniques for handling large datasets using fetch limits, pagination strategies, external storage, and background operations.

Custom Data Stores

One of my favorite chapters covers building a custom SwiftData data store from scratch. This helps developers understand how SwiftData works under the hood while opening possibilities for alternative storage implementations.

New SwiftData Features

The book also covers many of the latest SwiftData capabilities, including:

• Sectioned Queries
• ResultsObserver
• HistoryObserver
• Codable Attributes
• Compound Predicates
• Improved Preview Support

Who Is This Book For?

This book is designed for developers who have already used SwiftData and want to move beyond the basics.

If you have built a few SwiftData applications and started asking questions like:

“How do I structure this for production?”

or

“What happens when this app grows?”

then this book was written for you.

A Practical Book

My goal was not to create a reference manual.

Apple’s documentation already does an excellent job of explaining APIs.

Instead, I wanted to focus on practical techniques, lessons learned, tradeoffs, and real-world scenarios that developers encounter while building applications.

Many examples in the book are inspired by actual problems I have encountered while teaching, consulting, and building applications.

Thank You

Writing a technical book is a much larger undertaking than most people realize.

It involves researching APIs, building sample applications, testing code across multiple releases, revising chapters, and constantly updating content as the framework evolves.

I am grateful to everyone who provided feedback, reviewed early drafts, reported issues, and encouraged me throughout the process.

I hope this book helps developers build better SwiftData applications and avoid some of the mistakes I made along the way.

Learn More

You can learn more about the book here:

https://azamsharp.school/swiftdata-architecture.html

I am excited to see what you build with SwiftData.

Last year, I released five different apps on the App Store. Four of them were vibe coded, meaning I wrote very little code myself and let AI generate most of the implementation.

The apps look good. They work. They even make a small amount of revenue.

But if you ask me detailed questions about the codebase, I honestly would not be able to answer them confidently. The main reason is simple. I did not write most of the code. I only verified that the final result behaved the way I expected.

For small micro apps, this honestly feels fine. My apps do one thing, do it reasonably well, and stay relatively simple.

But what happens when this approach scales to large applications?

Every single day I hear the same thing from developers:

“We have not written a single line of code in months.” “Coding is dead.” “No one writes code anymore.”

Some developers even take pride in saying they no longer review the generated code. And honestly, I understand why. How do you realistically review thousands of lines of AI generated code every single day?

That is the part that scares me.

We are slowly moving toward a world where developers no longer truly understand their own codebases. In many cases, they do not even understand the domain they are building for. Requirements go into an AI tool on one side, and a working application comes out on the other.

Everything becomes optimized for speed.

But nobody is thinking deeply about what happens six months later when the system becomes harder to maintain, harder to debug, and harder to trust.

And where does responsibility fit into all of this?

Are developers still willing to stand behind the code that ships to production? Are we sure that feature actually needed 10,000 lines of generated code? Maybe the same thing could have been implemented with one tenth of the code and much better clarity.

Programming is not like learning how to ride a bike. It is not a skill you learn once and keep forever. Programming requires constant practice. If you stop thinking deeply about architecture, debugging, problem solving, and code design, those skills slowly fade away.

And no, this is not an anti AI post.

I use AI every single day. It has become part of my workflow. But I still use it like an instructor, not like a replacement for thinking. I want to understand what is happening underneath the surface.

AI can absolutely make us faster.

But faster without understanding is a dangerous combination.

We are definitely living in strange times.