AIApplication: a .NET MAUI chat client for DeepSeek, Doubao and Qwen

One C# codebase, three model providers behind a single chat page

AIApplication is a .NET MAUI application that presents DeepSeek, Doubao and Qwen through one interface. The chat page lives at `Views/AI.xaml` with its code-behind, and the provider calls are collected in `Services/AiApiService.cs`, so switching models is a service concern rather than a per-page concern.

The attachments story is specific about which model supports what. Images are supported by Doubao and Qwen, and text files such as PDF, TXT and JSON can be attached as context. That asymmetry is worth noticing: a provider without vision input will fail or silently ignore an image attachment, so a UI that offers the picker unconditionally needs per-model capability handling somewhere. The repository lists `MediaPicker` for gallery images and `FilePicker` for arbitrary files in its tech stack table, which is how both paths are reached.

The stack is deliberately ordinary. `HttpClient` handles REST calls to the backend, `System.Text.Json` handles serialization, and `Preferences` holds session data locally, meaning login state, user info and an avatar cache. Nothing exotic, which is a positive: the value of this repository is that you can read six small service classes and understand how a MAUI app talks to a server.

The repository is C#, MIT licensed, has no releases published, and its last push was 2026-09-06. There is no homepage set and no topics. That combination, a working-looking app with no release history, is worth weighing against how you plan to depend on it.

The backend you must supply, listed endpoint by endpoint

This is the single most important fact about the project: the server is not in the repository. The README states the app expects a Spring Boot backend and enumerates every endpoint it calls, grouped into four areas.

Authentication is `GET /Users/selectByUsername` and `POST /Users/insertUser`. Chat is the larger group: listing topics by user, inserting topics, incrementing a message count, inserting chat messages, selecting messages by topic, deleting messages by topic, and deleting topics by user. Email verification is `POST /api/v1/email/send-code` and `POST /api/v1/email/verify-code`. Profile and avatar handling covers inserting a profile, selecting by id, uploading via `multipart/form-data`, setting a head image, and downloading by name.

Reading that list tells you the data model without any further explanation. A user owns topics, a topic owns chat messages, and the message count on a topic is incremented by a dedicated endpoint rather than derived from a query. That last detail is a schema choice with real consequences: a stored counter can drift from the actual row count, and nothing in the endpoint list suggests a reconciliation job.

The base URL is a constant, not a setting you edit through the UI. It lives in `Services/ApiConfig.cs` with a placeholder default, and the README tells you to replace it:

public const string BaseUrl = "http://your-server-address:port";

Because the default is a literal placeholder, the app cannot reach anything until you edit that file and rebuild. Combined with the absent server, this is the shortest path from clone to running app and also the main reason the project cannot simply be deployed as-is.

Hardcoded API keys, and the honest security notes attached to them

The README has a section headed Configure API Keys, and it marks the step as important before saying anything else about it. The file `Services/AiApiService.cs` holds the keys as hardcoded constants for demonstration, and the advice is not to commit real keys to GitHub:

private const string DeepSeekApiKey = "your-deepseek-key";
private const string DoubaoApiKey = "your-doubao-key";
private const string QianwenApiKey = "your-qianwen-key";

The suggested alternatives are moving the keys into `appsettings.json` with a configuration builder, or for production using a backend proxy so keys never reach the client. The feature list makes the same point in one line, noting that keys are stored on the client for demonstration and that production should use a backend proxy.

Then there is a security notes section, and it names a second problem that has nothing to do with the keys: passwords are compared as plain text in the current demo backend, with the instruction to always hash them in a real application.

That combination deserves a moment of attention. A hardcoded key in a public repository is a bad practice that at least fails loudly, because anyone can see it and it is expected to be replaced. Plain-text password comparison is worse, because it is a property of a server that does not exist yet, so the flaw gets copied into whatever you build on top. If you take one thing from this repository beyond the view layer, take the hashing note seriously and implement it before writing the Spring Boot side.

Cloning, prerequisites, and one path that will send you looking

The README lists prerequisites before the clone step: the .NET 8 SDK or later, Visual Studio 2022 at 17.8 or newer or VS Code with MAUI workloads, and an Android, iOS, macOS or Windows development environment depending on your target. Since MAUI needs per-platform workloads and SDKs, this is the step where most first attempts actually stop.

The clone instructions are two commands:

git clone https://github.com/Nathan-code-development/AIApplication.git
cd AITools

The clone is straightforward. The `cd` is worth a note: the repository root holds the solution file `AITools.slnx`, and the project itself lives in an `AITools/` subdirectory, so the documented `cd AITools` lands you inside the project folder rather than beside the solution. If you open the solution from the root, the relative paths will not line up with what the README describes.

The build step is not scripted. You open the solution in Visual Studio, pick a target such as an Android emulator or a Windows machine, and press F5. There is no CLI build command in the documentation, no CI workflow in the tree, and no test project. The repository root is just `.gitignore`, `AITools.slnx`, the `AITools/` directory, `LICENSE` and the two READMEs. That is a small, readable repository rather than a maintained application framework.

What lives in the project folder

The documented structure is worth reading because it shows the separation of concerns clearly.

`Models/` holds `AIModel.cs`, the data model for the model square. `Services/` holds six classes with one job each: `AiApiService.cs` for the AI provider calls, `ApiConfig.cs` for the backend URL and JSON options, `AuthService.cs` for login and registration, `ChatApiService.cs` for topics and messages CRUD, `EmailCodeService.cs` for email verification, and `UserProfileService.cs` for profile and avatar management. `Views/` holds eight pages, each as a XAML file with code-behind: the main chat page, an all-topics list, a complete-profile page, a login page, a model detail page, the model square gallery, a profile and settings page, and a register page. Then `App.xaml`, `AppShell.xaml` and a `Resources/` folder for images, styles and fonts.

Six services and eight views for a complete chat application is a lean layout, and the naming makes the surface area obvious without reading any code.

The one feature that stands apart from the chat core is the Model Square. The README describes it as a gallery of 8 popular models, listing Claude, ChatGPT, Gemini, DeepSeek, Qwen, Doubao, Grok and Kimi, each with detailed specifications, a capability radar, pricing and user reviews. Two things follow from that description. The gallery covers far more models than the three the app can actually chat with, so it is a browse surface rather than a selector. And user reviews plus pricing imply data from somewhere other than this repository, and no endpoint for model metadata appears in the backend list, so that data has to come from the server you supply or from something already in the app that the README does not describe.

Who this is for, and where it stops

The clearest use is as a starting point for a multi-model mobile chat client. If you are targeting more than one platform from one codebase and you want attachments, history and authentication already wired to a documented API shape, the MAUI structure here saves real work. The `Preferences`-backed session handling and the `MediaPicker` and `FilePicker` integration are the kind of platform plumbing that is tedious to get right from scratch.

The limits are equally clear. It is not a production service: the keys are constants in source, the password handling in the paired backend is plain text, and the base URL is a compile-time constant rather than a configurable endpoint. Anyone shipping this to users has to solve auth properly, move secrets to a server, and decide what happens when a provider rate-limits or returns an error, none of which the repository addresses.

It is also not a place to look for current model knowledge. The three chat providers and the eight gallery models are a snapshot, and the app has no mechanism described for adding a fourth without writing another branch in `AiApiService.cs`.

The maintenance signal is worth stating plainly. The repository has 0 open issues and its last push was 2026-09-06, with no releases and no version history to pin against. The 1,037 stars reflect interest; the absence of releases and of any documented issue activity is the better guide to whether this will still open after its dependencies move. Treat it as a starting point you own from the first commit.

Editorial conclusion

AIApplication is best read as a UI reference for shipping a multi-model chat app to iOS, Android, macOS and Windows from one C# codebase, because the view layer, the service split and the attachment pickers are all laid out and readable. It is not a deployable product, and the README is honest about why: the backend is Spring Boot and not included, the API keys are hardcoded constants in `Services/AiApiService.cs`, and passwords in the companion backend are compared as plain text. Anyone evaluating it should treat the security notes as a work list rather than a disclaimer. Verify three things before building on it. Confirm the endpoint shapes in the README match a backend you already have, since nothing in this repository implements the server side. Replace `ApiConfig.cs` with your own address and move the three key constants into `appsettings.json` or environment variables. And check that your target platform's MAUI workload is installed, since the prerequisites ask for the .NET 8 SDK and MAUI tooling before the clone step matters at all.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Nathan-code-development/AIApplication on GitHub
4. README