Tutorial: llmChat SwiftUI

Cover Page

This tutorial can be completed on the iOS simulator.

The front-end work is mostly in writing two new network functions, llmChat(appID:chatt:errMsg:) and llmPrep(appID:chatt:errMsg). We will build on the code base from the first tutorial, llmPrompt.

Expected behavior

Carrying a “conversation” with an LLM:

DISCLAIMER: the video demo shows you one aspect of the app’s behavior. It is not a substitute for the spec. If there are any discrepancies between the demo and this spec, please follow the spec. The spec is the single source of truth. If the spec is ambiguous, please consult the teaching staff for clarification.

Preparing your GitHub repo

In the following, replace /YOUR:TUTORIALS/ with the name of your tutorials folder.

:point_right: Go to the GitHub website to confirm that your folders follow this structure outline:

  reactive
    |-- chatterd
    |-- chatterd.crt
    |-- llmchat
        |-- swiftUIChatter
            |-- swiftUIChatter.xcodeproj
            |-- swiftUIChatter    
    # and other files or folders

/YOUR:TUTORIALS/ folder on your laptop should contain the llmprompt.zip and chatter.zip files in addition.

If the folders in your GitHub repo does not have the above structure, we will not be able to grade your assignment and you will get a ZERO.

appID

Since you will be sharing PostgreSQL database storage with the rest of the class, we need to identify your entries so that we forward only your entries to Ollama during your “conversation.” In your swiftUIChatterApp.swift file, add this appID property to your ChattViewModel:

    let appID = Bundle.main.bundleIdentifier

llmChat(appID:chatt:errMsg:)

In ChattStore.swift, first add the following types outside your ChattStore class:

enum SseEventType { case Error, Message }

struct OllamaMessage: Codable {
    let role: String
    let content: String?
}

struct OllamaRequest: Encodable {
    let appID: String?
    let model: String?
    let messages: [OllamaMessage]
    let stream: Bool
}

struct OllamaResponse: Decodable {
    let model: String
    let message: OllamaMessage
}

Rename your llmPrompt(_:errMsg) function and give it the following signature:

    func llmChat(appID: String, chatt: Chatt, errMsg: Binding<String>) async {

Replace llmprompt in apiUrl to llmchat.

Previously we constructed ollamaRequest Swift dictionary and serialize/encode it “manually” into a request body. In this tutorial, we’re going to rely on Swift Codable to do the encoding for us. Replace this block of code:

        let ollamaRequest: [String: Any] = [
            "model": chatt.name as Any,
            "prompt": chatt.message as Any,
            "stream": true
        ]
        guard let requestBody = try? JSONSerialization.data(withJSONObject: ollamaRequest) else {
            errMsg.wrappedValue = "llmPrompt: JSONSerialization error"
            return
        }

with:

        let ollamaRequest = OllamaRequest(
            appID: appID,
            model: chatt.name,
            messages: [OllamaMessage(role: "user", content: chatt.message)],
            stream: true
        )
        guard let requestBody = try? JSONEncoder().encode(ollamaRequest) else {
            errMsg.wrappedValue = "llmChat: JSONEncoder error"
            return
        }

To allow your app to accept SSE stream, replace the following line in the request builder:

        request.setValue("application/*", forHTTPHeaderField: "Accept")

with:

        request.setValue("text/event-streaming", forHTTPHeaderField: "Accept")

Parsing SSE stream

We now parse the incoming SSE stream. Continuing in llmChat(appID:chatt:errMsg:), scroll all the way down to the // streaming NDJSON comment and replace the whole block of code up to, but not including the last (second) catch block, with:

            // streaming SSE
            var sseEvent = SseEventType.Message
            var line = ""
            for try await char in bytes.characters {
                if char != "\n" && char != "\r\n" { // Python eol is "\r\n"
                    line.append(char)
                    continue
                }
                if line.isEmpty {
                    // new SSE event, default to Message
                    // SSE events are delimited by "\n\n"
                    if (sseEvent == .Error) {
                        sseEvent = .Message
                        resChatt.message?.append("\n\n**llmChat Error**: \(errMsg.wrappedValue)\n\n")
                    }
                    continue
                }
              
                // parse SSE line
              
            }
            

The URLSession.shared.bytes(for:) API returns an AsyncSequence. Unfortunately, when looping through an AsyncSequence, the loop automatically skips empty lines, whereas the SSE specification relies on an empty line (caused by two consecutive newlines "\n\n") to indicate the end of an event block. To be able to detect empty lines, we need to re-construct lines from bytes.characters on our own instead. When an empty line is detected, if we are in an Error event block, as set in the next block of code, we report the error on the timeline (we will also pop up an alert dialog box with the erorr message later). Then we reset the event to the default Message event.

If the next line starts with the text event, we’re starting a new event block, otherwise, it’s a data line and we handle (save) it depending on the event it’s associated with. Recall that left unspecified, Message is the default event. Replace the comment, // parse SSE line with the following:

                let parts = line.split(separator: ":", maxSplits: 1, omittingEmptySubsequences: false)
                let event = parts[1].trimmingCharacters(in: .whitespaces)
                if parts[0].starts(with: "event") {
                    if event == "error" {
                        sseEvent = .Error
                    } else if !event.isEmpty && event != "message" {
                        // we only support "error" event,
                        print("LLMCHAT: Unknown event: '\(parts[1])'")
                    }
                } else if parts[0].starts(with: "data") {
                    // not an event line, must be data line;
                    // multiple data lines can belong to the same event
                    let data = Data(event.utf8)
                    do {
                        let ollamaResponse = try JSONDecoder().decode(OllamaResponse.self, from: data)
                        if let token = ollamaResponse.message.content {
                            if sseEvent == .Error {
                                errMsg.wrappedValue += token
                            } else {
                                resChatt.message?.append(token)
                            }
                        }
                    } catch {
                        errMsg.wrappedValue += "\(error)\n\(apiUrl)\n\(String(data: data, encoding: .utf8) ?? "decoding error")"
                    }
                }
                line = ""

Be sure to retain the enclosing catch clause below the for loop.

SubmitButton

Finally, replace your call to llmPrompt(_:errMsg:) in SubmitButton() in the file ContentView.swift with:

                if let appID = vm.appID {
                    await ChattStore.shared.llmChat(
                        appID: appID,
                        chatt: Chatt(name: vm.onTrailingEnd,
                                     message: vm.message),
                        errMsg: Bindable(vm).errMsg)
                }
                

TODO: llmPrep(appID:chatt:errMsg:)

To give instructions to the LLM, we can simply prepend the instructions to a user prompt. With Ollama’s chat API, we can alternatively provide such instructions to the LLM as "system" prompts. A messages array element carrying such instruction will have its "role" set to "system". In the back-end spec, we will create a new API called /llmprep that allows us to send "system" prompts to our chatterd back end. To use this new API, create a new ChattStore method with the following signature:

    func llmPrep(appID: String, chatt: Chatt, errMsg: Binding<String>) async { }

As with the llmChat(appID:chatt:errMsg:) method, post the provided appID and chatt as an OllamaRequest to chatterd. However, instead of "user", set the "role" in the OllamaMessage to "system", and put the instructions stored in the chatt’s message into the corresponding "content" property. We are not expecting any response stream, so set the "stream" field to false.

Target your apiUrl to the URL for /llmprep API.

We’re actually not expecting any specific response from the post to /llmprep. We can leave the Accept HTTP header field to its default value when building the request.

Finally, post the request and process the returning HTTP response. Since we’re not expecting a response stream, use the URLSession.shared.data(for:) API instead of URLSession.shared.bytes(for:) to post the OllamaRequest. See the postChatt(_:errMsg:) method from the Chatter tutorial if you need help with these.

Usage

To use your newly created llmPrep(appID:chatt:errMsg:) method, first add a system prompt property to your ChattViewModel in swiftUIAppChatterApp.swift file, for example:

    let sysmsg = "Start every assistant reply with GO BLUE!!!"

We found that qwen3:0.6b (522 MB storage, 850+ MB RAM) seems to be the smallest Ollama model that can follow system prompt. While you’re updating your ChattViewModel, update its onTrailingEnd property to qwen3:0.6b.

Then add the following initializer to your swiftUIChatterApp structure:

    init() {
        // disable interaction until llmPrep is done
        Task { [self] in
            if let appID = viewModel.appID, !viewModel.sysmsg.isEmpty {
                await ChattStore.shared.llmPrep(
                    appID: appID,
                    chatt: Chatt(name: viewModel.onTrailingEnd, message: viewModel.sysmsg),
                    errMsg: Bindable(viewModel).errMsg)
                viewModel.showError = !viewModel.errMsg.isEmpty
            }
        }
    }

Run and test to verify and debug

You should now be able to run your front end against the provided back end on mada.eecs.umich.edu, by changing the serverUrl property in your ChattStore to mada.eecs.umich.edu. Once you have your back end setup, change serverUrl back to YOUR_SERVER_IP. You will not get full credit if your front end is not set up to work with your back end!

To test your llmPrep(appID:chatt:errMsg:) method against mada.eecs.umich.edu, you can use gemma3 model. To test it against your own back end running on a *-micro instance, use qwen3:0.6b model. Assuming the system prompt is, “Start every assistant reply with GO BLUE!!!”, you should see “GO BLUE!!!” prepended to all responses from the LLM.

The back-end spec provides instructions on testing llmChat’s API and SSE error handling.

Congratulations! You’re done with the front end! (Don’t forget to work on the back end!)

Front-end submission guidelines

We will only grade files committed to the main branch. If you’ve created multiple branches, please merge them all to the main branch for submission.

Push your front-end code to the same GitHub repo you’ve submitted your back-end code:

:point_right: Go to the GitHub website to confirm that your front-end files have been uploaded to your GitHub repo under the folder llmchat. Confirm that your repo has a folder structure outline similar to the following. If your folder structure is not as outlined, our script will not pick up your submission and, further, you may have problems getting started on latter tutorials. There could be other files or folders in your local folder not listed below, don’t delete them. As long as you have installed the course .gitignore as per the instructions in Preparing GitHub for Reactive, only files needed for grading will be pushed to GitHub.

  reactive
    |-- chatterd
    |-- chatterd.crt
    |-- llmchat
        |-- swiftUIChatter
            |-- swiftUIChatter.xcodeproj
            |-- swiftUIChatter    
    # and other files or folders

Verify that your Git repo is set up correctly: on your laptop, grab a new clone of your repo and build and run your submission to make sure that it works. You will get ZERO point if your tutorial doesn’t build, run, or open.

IMPORTANT: If you work in a team, put your team mate’s name and uniqname in your repo’s README.md (click the pencil icon at the upper right corner of the README.md box on your git repo) so that we’d know. Otherwise, we could mistakenly think that you were cheating and accidentally report you to the Honor Council, which would be a hassle to undo. You don’t need a README.md if you work by yourself.

Review your information on the Tutorial and Project Links sheet. If you’ve changed your teaming arrangement from previous tutorial’s, please update your entry. If you’re using a different GitHub repo from previous tutorial’s, invite eecsreactive@umich.edu to your new GitHub repo and update your entry.

References

SSE


Prepared by Xin Jie ‘Joyce’ Liu, Chenglin Li, and Sugih Jamin Last updated: January 15th, 2026