When I started out, I decided to make an application that was really worth trying. I designed a database structure and a system architecture that I meant to be perfect. But for my first frontend (tbh not only the frontend), I was struggling. I am no designer myself and couldn’t really create a smooth user flow, so I used AI to help me with that. After I was done, I wasn’t very happy with either the scalability or the look and feel. I had used Ionic, a web framework that ran in a WebView on the device. The touch inputs didn’t feel instant or responsive enough, and for what was basically a simple CRUD app, it felt a little bit sluggish (or maybe that’s just me).

So, in my second semester, I focused on refining that whole experience and making it better in every way.

The Rewrite: Embracing Kotlin Multiplatform

I decided on a new frontend framework: Kotlin Multiplatform (KMP), which allows you to build apps for nearly any platform using a shared codebase. I also added new features, like self-hosted AI solutions to generate content and a posibility to choose your current Gym.

Implementing my app with Kotlin was challenging because it was a completely new programming language to me. After learning the fundamentals and coding on my own for the first week, I brought in some AI coding agents to help speed up the process. At first, I used a local model called qwen3-coder:30b, which I quantized to run on constrained hardware. My setup was a Mac Book Air M1 from the USTP rental service running OMLX (which was especially built for Macs to take advantage of their unified memory). Running in my IDE was the open-source AI code agent Continue, which allowed me to implement MCP servers and feed code context from my project to the model. Later I learned that this extention or IDE whatever you wanna call it, is no longer being developed and was acquired by Cursor.

After I sadly had to return the rental Mac (originally i wanted to use it for building the App for IOS as well but just failed to finish the App in time ) , I switched to Claude Code. For me, it was essential to double-check Claude’s work and architectural decisions. Honestly, I was a little bit shocked by some of the choices it made, like trying to store API keys or passwords in plain text just somewhere in the Code! To be fair, I wasn’t using their frontier model to avoid spending too many tokens (as I argued a lot with it during the development process), but still. However, it was particularly handy for creating the frontend layer with Jetpack Compose, thanks to the vast documentation available for Android’s UI framework.

To avoid hallucinations and provide the model with up-to-date documentation, I added an MCP Server called Context7. It allowed me to filter exactly what documentation the model received and what it had access to … a really handy tool.

Frontend Challenges: Caching, Offline Sync, and Navigation

The hardest part of my frontend implementation was the caching logic. I wanted the app to always instantly display the relevant information you need in the moment. To achieve this, I decided to cache the first 10 items of every category (e.g., Templates, Trainings, UserData).

All of this is stored in a Key-Value database called KStore, a small library that works great for simple data storage on Android and iOS devices. The absolute hardest part was defining the behavior for when I saved something offline, ensuring that the moment I got back online, it would post to the backend so the two storages would “sync” up again. We now have a (mostly) robust network-first cache strategy with offline fallbacks.

I also completely revamped the app’s navigation and UI architecture using Compose Multiplatform:

• Two-Level Navigation: We have an outer navigation graph for the Auth-Flow (Login/Register) and an inner graph wrapped in a Scaffold for the main tabs. This allows for a persistent BottomBar that stays visible while you switch tabs.

• Profile Dialog: Instead of routing to a new screen, the user profile opens as a clean Dialog Card over the current screen, making it feel much faster.

• Security: Tokens are stored securely using KVault (Keychain for iOS, EncryptedSharedPreferences for Android).

• Dependency Injection: I used Koin to keep the architecture clean (MVVM), allowing the UI to remain logic-free.

The Backend: Keeping it Clean & Adding a Scraping Service

For my backend (a self-hosted NestJS API), I tried to make major improvements to security and code cleanliness. Most of my backend wasn’t even touched by AI … I mean aside from a few MongoDB queries … they’re just really weird to write ok? … so I could assure everything was up to my expectations.

For extended features, I added a custom scraping service using a separate Python server. It scrapes all the fitness studios listed on my gym’s website and writes everything about their equipment directly into my database. It’s scheduled to run on startup and then one time per Month (don’t want to get accused of creating to much net traffic for them). I deployed this service in a separate Docker container within the same Docker network to ensure minimal downtime in case the scraper ever crashes.

Building a Local AI Agent for Training Templates

Having the exact context of my gym’s equipment in the database was especially helpful for my next big feature: Local AI Training Template generation.

To be honest, I initially wanted to use the MCP server I had programmed earlier for this task. But by the time I got to implementing the AI feature, I realized that Ollama doesn’t actually support MCP natively because it lacks an MCP client.

So, I built an Agentic loop directly in my NestJS backend to act as a middleman between Ollama and my server. I could have gone the route of calling my MCP server through my backend and called it a day. But after a short “question battle” with Claude Code, I decided that wasn’t feasible due to the unnecessary network requests I could save by just implementing the agent loop directly in the backend.

My custom MCP Server now exists on its own and isn’t connected to anything just yet. But building it was a fantastic learning experience regarding how these systems work. It lays the groundwork for future implementations, as I eventually plan to integrate external MCP-capable AI tools like Claude or ChatGPT.

Technical Deep Dive: Gymetrics Feature List

For those interested in the exact tech stack and architectural decisions, here is a breakdown of what’s running under the hood:

The Stack

• Frontend: Kotlin Multiplatform, Compose Multiplatform (Shared UI), targeting Android (first priority) and iOS.
• Backend: Self-hosted NestJS API with Dockerized microservices.
• Auth: Short-lived Bearer tokens + Refresh tokens.

Core Implementations

• Ktor Client & Auto-Refresh: Centralized HTTP client handling JSON serialization, timeouts, and dynamic base URLs. Used the Ktor Auth plugin to automatically attach tokens and trigger a silent refresh route (POST /auth/refresh) on 401 errors.
• Offline-First Capabilities: Built a custom ConnectivityObserver that tracks network state app-wide. The app displays an offline badge in the TopBar and handles offline Auth checks by optimistically trusting the securely stored token.
• App-Wide Theming: Implemented a custom GymetricsTheme wrapper around MaterialTheme, featuring a sleek, app-wide dark mode and adaptive Android icons.
• State Management & DI: Strict MVVM architecture. State is handled via sealed interfaces and exhaustive when statements (Idle/Loading/Success/Error). Dependency Injection is handled entirely by Koin (using appModule, single, and viewModelOf).

It’s been a massive journey from a simple Ionic prototype to a fully-fledged, offline-capable KMP application with agentic AI workflows. It started as a way to replace a spreadsheet, but it taught me modern mobile architecture, backend, and how to effectively wrangle AI coding assistants.

The post Gymetrics: A Self-Hostable Fitness App with Kotlin Multiplatform, NestJS, and Dockerization appeared first on Mobile USTP MKL.

Many mobile apps look simple until they must preserve an unfinished edit, work offline, survive a crash, and reconcile changes from two devices. Then “save and sync” becomes an architecture, and a promise to the user.

An offline-first iOS app treats its local store as the immediate source of truth. User actions update it first; synchronization is separate and retryable. State boundaries must be explicit, writes safe, conflicts explainable, and the interface honest about data stored only locally.

This article follows that model from SwiftUI state through persistence, autosave, change tracking, conflicts, and failure UX.

1. Why Offline-First Still Matters

In 2026, fast networks are common, reliable connectivity is not. A phone can enter a tunnel, encounter a captive portal, or lose authentication. A request may reach the server even when its response never reaches the client.

Offline-first begins with a rule: the user performs the app’s core work against local data. The app records the intent durably and synchronizes later. A task app should not discard a completed task because the server timed out.

This is different from caching. A cache is usually disposable and can be reconstructed from an authoritative source. Offline-created user data cannot. If deleting the local copy would destroy information that exists nowhere else, it is not “just a cache.”

Reachability is not permission to write. Network status can help decide when to attempt synchronization, but it cannot prove that the next request will succeed. Foundation can wait through URLSessionConfiguration.waitsForConnectivity, but the durable queue, not a green icon, is what makes a write reliable (Apple: waitsForConnectivity).

The useful mental model is:

1. accept the user’s action
2. validate it locally
3. commit it locally
4. render the committed result
5. enqueue synchronization
6. retry safely until the server acknowledges it

The network path affects step five, not the validity of steps one through four.

2. Local State Is Not Temporary State

SwiftUI makes state easy to declare, which can make unlike kinds of state look deceptively similar. A robust app distinguishes at least three layers.

View state exists only to present or control the current interface: whether a sheet is open, which tab is selected, a search field’s draft text, or the expansion state of a disclosure group. @State is often appropriate because SwiftUI owns that value for the lifetime of the view identity.

Domain state represents meaningful work: a document title, completed task, or pending deletion. It must not depend on whether a view exists. Observation and @Observable help present domain objects, but observability is not persistence.

Persistent application state has crossed a durability boundary. It has been written to a file or store that can be reconstructed after relaunch. SwiftData’s ModelContainer and ModelContext, a Core Data persistent container, or a purpose-built SQLite layer live here.

The distinction matters during editing. Binding a field directly to a persistent model saves half-finished values. That may suit notes, but not a bank transfer or an object whose fields must remain consistent. In those cases, edit a draft, validate it, and commit the complete change in one transaction.

A practical dependency direction is:

SwiftUI view → use case / repository → local store
                                 sync outbox

Views request operations such as completeTask; they do not decide how JSON is replaced or CloudKit records are merged. This makes offline behavior testable without UI or a real server.

3. Choosing a Persistence Strategy

Choose the smallest persistence mechanism that preserves the data’s structure, query needs, migrations, and ownership.

UserDefaults is for small preferences such as sort order or a dismissed onboarding flag. It is not a document database or an outbox.

JSON or property-list files suit small, document-shaped datasets loaded and replaced as a unit. They are transparent and exportable. Once the app needs indexed queries, relationships, concurrent writers, or a large sync log, one JSON file becomes an improvised database.

SwiftData is a natural high-level choice for many new Apple-platform apps. It integrates persistent models with Swift and SwiftUI queries. Its main context supports autosave in app configurations, manually created contexts do not inherit that behavior. Design schema migrations before a model rename ships (Apple: Dive deeper into SwiftData, Apple: schema migration).

Core Data remains strong for mature apps, complex graphs, and established migration plans. NSPersistentContainerencapsulates the stack, while persistent history can expose transactions made elsewhere. SwiftData is not merely “Core Data with nicer syntax”. Evaluate requirements instead of choosing by age.

SQLite fits explicit schemas, specialized indexes, predictable SQL, or tight transaction control. An atomic commit makes all transaction changes visible or none. Write-ahead logging can let readers continue during writes, though checkpointing and durability settings still matter (SQLite: Atomic Commit, SQLite: WAL).

4. Autosave and Data Integrity

Autosave is a user-experience policy, not an integrity mechanism. It answers when the app attempts to persist, not whether a multi-part change is valid, atomic, or recoverable.

For free-form text, saving after every keystroke wastes work. A short debounce coalesces edits, but creates a window where input exists only in memory. Flush critical drafts when editing ends and when the scene changes phase.

For files, write to an auxiliary file and replace the original only after success. Foundation’s atomic option follows this approach (Apple: NSData.WritingOptions.atomic). Keep a last known-good version when corruption is costly, a backup matters only if restore is tested.

For database persistence, group invariant-related changes in one transaction. Creating an order and decrementing inventory in separate saves exposes an impossible intermediate state after a crash. Transaction boundaries should follow domain meaning, not screen layout.

Every model needs a migration story. Use stable identifiers independent of local row IDs, version schemas, and test upgrades from every supported release. Never answer migration failure by silently deleting the user’s store.

Treat storage errors as first-class outcomes. Disk space can run out, encoding can fail, and validation can reject a save. try? context.save() may create a quiet interface while hiding that data was never durable.

5. Sync Is a Trust Problem

Synchronization is often drawn as two arrows between phone and cloud. Inside are duplicate requests, reordering, partial failure, concurrent edits, deletion, and expired authentication.

A trustworthy design separates local durability from remote synchronization. Each mutation creates the domain change and an outbox entry in one transaction. A worker sends operations, records acknowledgements, applies remote changes, and retries with backoff. After a crash, the outbox still exists.

Each operation should be idempotent. Give it a stable operation ID so a server can recognize a retry. If the server receives the request but the client loses the response, retrying must not create a duplicate object or repeat a payment.

Timestamps are weak ordering mechanisms because device clocks differ. Prefer server revisions, advancing change tokens, or per-record versions. SwiftData History exposes chronological transactions and explicitly supports remote sync and out-of-process changes (Apple: SwiftData history, Apple: time-based changes).

HTTP offers concurrency semantics: the server returns an ETag, and the client sends If-Match when updating. If the resource changed, the precondition fails instead of overwriting newer data (RFC 9110). CloudKit similarly gives CKRecord a change tag for synchronization (Apple: CKRecord).

The app should model sync state explicitly, for example:

enum SyncState: Equatable {
    case localOnly
    case queued
    case syncing
    case synced(revision: String)
    case conflict
    case blocked(reason: BlockReason)
}

Do not infer sync from the absence of an error. A request that has not started is not synchronized, and expired authentication differs from a timeout.

6. Conflict Handling and External Sources

Conflict policy must be defined per entity and sometimes per field. “Last write wins” is simple, but it can silently erase work and becomes especially unsafe when “last” depends on device clocks.

Some data merges automatically: independent fields can merge separately and tag sets may use union semantics. Collaborative text needs a purpose-built algorithm such as a CRDT. It should not be improvised from updatedAt.

Other conflicts need a human. Preserve both versions, show meaningful differences, and offer “Your edit from 10:42” versus “Edit from iPad at 10:45,” not merely “local” and “remote.”

Deletions deserve their own model. If a deleted record vanishes immediately, another offline device may later re-upload it. A tombstone—an identifier, deletion revision, and retention period—allows deletion to propagate. Purge it only after the system’s synchronization window and device assumptions make resurrection acceptably unlikely.

External sources also need ownership rules:

• Read-only reference data: cache locally, display its age, and replace it from the source. Never upload it as if the user authored it
• Imported data: record provenance and the external identifier. Decide whether import creates an owned snapshot or maintains a live link
• Locally editable mirrors: keep the source version alongside pending local changes. Rebase or surface a conflict when the source changes
• External deletion: distinguish “no longer available upstream” from “user deleted locally.” Preserve local notes or derived records when policy allows

CloudKit subscriptions can signal record creation, modification, and deletion, but they only trigger fetching. They do not replace a durable local store or change token (Apple: CKRecordZoneSubscription).

7. UX for Failure

Offline-first UX should communicate consequences, not infrastructure. Users need three answers: Is my work saved here? Is it available elsewhere? Do I need to act?

Use calm, specific status language:

• Saved on this iPhone — the local transaction committed
• Waiting to sync — no action is normally required
• Syncing… — work is in progress
• Couldn’t sync. We’ll retry. — the failure is transient
• Sign in to continue syncing — user action is required
• Two versions need your review — silent merging would risk data loss

Avoid blocking alerts for routine failures. Prefer inline status, a persistent account banner, or sync-details screen. Reserve modal interruption for unsafe actions or imminent data loss.

Optimistic UI is appropriate only after the local commit succeeds. If a user marks a task complete, the interface can update immediately because the durable local state already represents that action. If the save fails, keep the draft visible, explain that it is not yet stored, and offer a retry or export path.

Expose “last synchronized” and pending changes when consequential. Never show a cloud checkmark merely because the device has connectivity. Do not encode sync state only in color. Provide text for VoiceOver.

Test sequences, not isolated errors: edit offline, terminate, relaunch, edit elsewhere, reconnect, receive a conflict, lose connectivity during resolution, and retry. Also test duplicate responses, full storage, corruption, external deletion, and schema upgrades with a non-empty outbox.

8. Conclusion

Good offline-first architecture is mostly invisible. The app opens with useful data, accepts work immediately, survives interruption, and later converges without surprises. Achieving that experience requires more than adding a cache or calling save() from SwiftUI.

Separate view state from durable domain state. Choose persistence by data shape and guarantees. Make writes atomic at meaningful boundaries. Track mutations with stable identities and versions. Treat sync as a retryable state machine, not a request callback. Define ownership, deletion, and conflict policies before the edge cases arrive. Above all, tell the truth in the interface about what is saved locally and what has reached another device.

Users rarely praise an app for its outbox, migration plan, or tombstones. They simply decide that the app feels dependable. That judgment is the real product of an offline-first design.

Sources and Further Reading

• Apple, Dive deeper into SwiftData (WWDC23).
• Apple, Track model changes with SwiftData history (WWDC24).
• Apple, SwiftData: Dive into inheritance and schema migration (WWDC25).
• Apple, Fetching and filtering time-based model changes.
• Apple, NSPersistentContainer.
• Apple, NSData.WritingOptions.atomic.
• Apple, URLSessionConfiguration.waitsForConnectivity.
• Apple, CKRecord and CKRecordZoneSubscription.
• SQLite, Atomic Commit in SQLite and Write-Ahead Logging.
• IETF, RFC 9110: HTTP Semantics.

The post Designing Offline-First iOS Apps: Local State, Persistence, and Sync Without Losing User Trust appeared first on Mobile USTP MKL.

The app is still in development, and many of its final ideas are intentionally not public yet. For that reason, this article does not reveal the complete product concept or all planned functionality. Instead, it focuses on the development process so far: how the project evolved from a SwiftUI interface prototype into a more structured iOS application with custom data models, persistent storage, reusable components, and first steps toward external calendar integration.

At the beginning, the project was mostly visual and exploratory. The first question was not “Which database should this use?” or “How should synchronization work?” but “What should this feel like on a phone?” Since the app is meant to be used frequently and quickly, the interface had to be approachable without becoming decorative for its own sake. SwiftUI was a natural choice because it allowed fast iteration on layout, navigation, state, and component structure. Early work focused on core screens: a home view, overview pages, detail pages, and small reusable interface elements that could later become the visual language of the app.

One of the first lessons was that a planning app becomes complex faster than expected. Even if the user-facing idea sounds simple, the underlying structures are not. A calendar item is not just a title and a date. It may have a start and end time, an all-day state, a location, notes, tags, a source, an editability status, and possibly a connection to another system. A task is also more than a checkbox. It can belong to a list, have a due date, include notes, be marked as important, be connected to a reminder, or later need rules for rescheduling. Reminders introduce yet another rhythm, because they are not exactly tasks and not exactly events. They sit somewhere between intention and interruption.

Because of that, the project moved relatively early from screen-building into model-building. Separate structures were created for calendars, events, lists, tasks, reminders, external sources, and calendar connections. This was an important shift. Instead of letting the UI define the data informally, the data model started to define what the interface could reliably express. Each object needed an identity, needed to be encodable, and needed to be flexible enough for future features without becoming vague. This part of the process was less visually exciting than building screens, but it made the rest of the application much more stable.

The central data layer became an observable store that holds the current calendars, events, lists, tasks, reminders, and external connections. This store is used throughout the SwiftUI views via environment injection, which keeps the individual screens relatively focused. A home screen can ask for visible calendars, upcoming events, or incomplete tasks without owning all the logic itself. Detail pages can receive a selected object and rely on shared update and delete methods. This architecture is still lightweight, but it creates a clear boundary between application state and presentation.

A useful turning point was implementing filtering and derived data. Once there were multiple entities in the store, the app needed answers to questions such as: Which events belong to this calendar? Which tasks belong to this list? Which events are upcoming? Which tasks are incomplete and still relevant? These may sound like small helper functions, but they changed how the app could be built. Instead of each screen duplicating filtering code, the store became the place where the application’s understanding of its data lived. That made the UI easier to read and helped reduce inconsistencies between screens.

Another major step was persistence. In early prototypes, sample data is enough. It helps with layout and gives the app something to display. But a planning app cannot remain a prototype for long if data disappears every time it restarts. The current version stores a snapshot of the application data as JSON in the app’s documents directory. The snapshot includes the core collections and can be loaded again when the app starts. The saving process also keeps a backup file, so the app has a fallback if the primary file cannot be read.

This persistence system is intentionally simple. It is not yet a large database layer, and that is partly deliberate. At this stage, JSON-based persistence makes the app easier to inspect, debug, and evolve. The project is still changing, and a lighter storage approach gives more freedom while the domain model continues to settle. At the same time, the persistence layer is separated from the store, so replacing or extending it later would not require rewriting the entire UI. This is one of the recurring themes of the project: avoid overengineering too early, but create enough structure that future changes do not become painful.

Autosave introduced its own design questions. A planning app should not require the user to manually save after every small change. The current approach listens for changes across the main collections and saves the current snapshot after a short debounce. This means the app can react naturally to edits while avoiding excessive file writes. It also means the development process had to account for state changes that are not user edits, such as loading persisted data at launch. Small flags and guard conditions became necessary to prevent the app from immediately saving over freshly loaded state or treating internal setup as user activity.

The interface also evolved significantly during this phase. The app now has a clearer structure of pages and components: overview views, detail views, card components, a navigation bar, headers, picker panels, floating action controls, and shared form elements. This componentization was not just about cleaner code. It also helped the app develop a consistent interaction style. Planning tools can easily become cluttered because they contain many object types and many possible actions. Reusable components make it easier to keep the experience predictable.

One example is the creation flow. Adding something new should not feel like entering a completely different app. The current implementation uses a shared sheet for creating or editing different item types. It supports modes for events, tasks, and reminders, with separate draft objects and validation. This draft-based approach is important because forms are temporary by nature. A user can open a sheet, make changes, switch context, cancel, or save. Keeping draft state separate from the saved model avoids accidental writes and makes validation clearer.

The form system also revealed how much detail is hidden inside “simple” input. Dates, times, optional fields, associations with calendars or lists, tags, icons, and reminder relationships all require careful handling. If these concerns are spread directly across the view code, the form quickly becomes difficult to maintain. By separating drafts, form rows, picker state, and saving logic, the app gained a structure that can grow without turning every new field into a cascade of fragile changes.

Design-wise, the project has been moving toward a custom visual identity rather than relying entirely on default iOS components. Custom fonts, color assets, icons, rounded shapes, and card components give the app a more personal tone. This is not only aesthetic. For a planning tool, visual hierarchy matters. The user should be able to distinguish calendars, lists, upcoming items, actions, and details quickly. Colors and cards are not decoration here; they carry information and help reduce cognitive load.

At the same time, building a custom interface in SwiftUI requires restraint. It is tempting to make every component unique, especially in a project that has a strong visual direction. But the more custom the interface becomes, the more responsibility the developer takes on for spacing, accessibility, responsiveness, and consistency. This has been one of the practical challenges of the project: finding the balance between a distinctive interface and a maintainable one. The current component structure is an attempt to make that balance explicit.

The most technically demanding part so far has been external calendar integration. Local planning data is one thing; synchronizing with external systems is another. The app now contains service layers for Apple Calendar and Google Calendar, as well as a synchronization service that imports events into the app’s own model. This required thinking about authorization, external identifiers, read-only versus editable sources, date ranges, mapping between API objects and local models, and what should happen when external events change or disappear.

Apple Calendar integration uses EventKit and must deal with platform-specific permission states. On newer iOS versions, access levels are more precise, so the app has to request and verify the correct kind of calendar access. The service can list available calendars and load events within a selected time range. These events are then mapped into the app’s internal event model, preserving information such as title, location, notes, URL, start and end date, all-day status, external identity, and sync metadata.

Google Calendar integration is different because it goes through Google Sign-In and web API requests. This required handling OAuth scopes, restoring previous sign-in sessions, refreshing access tokens, making authenticated requests, decoding calendar lists and event responses, and converting Google’s date formats into local date values. All-day events need special handling because calendar APIs often represent them differently from timed events. These are the kinds of details that are easy to underestimate before implementation begins.

The synchronization layer sits above the individual provider services. It loops through configured external calendar connections, loads events for each connection, imports them, tracks which external IDs were seen, updates sync timestamps, and reports failures. The store then upserts imported events instead of blindly appending them. This prevents duplicates and creates a place to handle conflicts. If a local event has pending changes and an external version arrives, the app can mark the situation as a conflict rather than silently overwriting data. Even though the full synchronization story is not finished, the current structure already reflects a key principle: user data should be treated carefully.

This was one of the biggest conceptual lessons of the project. Synchronization is not just a technical feature. It is a trust feature. If users put their plans into an app, they need confidence that the app will not lose, duplicate, or unexpectedly modify important information. That means the code has to represent uncertainty. It needs states such as local-only, synced, pending local changes, conflict, or deleted externally. These states are not glamorous, but they are what make the difference between a demo and a tool people might rely on.

Another lesson was that the app’s “domain” became clearer through implementation. At first, calendars, lists, tasks, and reminders may seem like familiar categories. But once they are modeled together, their relationships become more interesting. Some items belong to collections. Some can be associated with time. Some can be completed, others can only pass. Some are imported from outside and should not be edited locally. Some may later need richer rules. The development process has therefore been partly technical and partly analytical: understanding what each object means in the system.

The current prototype also includes several navigation paths: a home view with upcoming information, calendar overviews and detail views, list overviews and detail views, event and task detail screens, and setup flows. This breadth created a new kind of challenge. Once the app had more than one or two screens, consistency became harder. A change in the model might affect a card, a detail page, a form, and a preview all at once. This is where reusable view components started to pay off. They made the app feel less like a set of separate screens and more like one coherent product.

The project is still in an active development stage. There are visible signs of ongoing refactoring: components have been moved into clearer folders, global elements have been separated from list-specific and calendar-specific components, and some older file paths are being replaced by a more organized structure. This is a normal and healthy part of development. Early prototypes often grow organically. At some point, the structure has to catch up with the idea. The important part is not to make the architecture perfect immediately, but to keep improving it when the project’s shape becomes clearer.

Looking back, the development so far can be described in phases. The first phase was interface exploration: building enough screens to understand the experience. The second phase was domain modeling: defining the objects the app actually needs. The third phase was state and persistence: making the app remember and update data reliably. The fourth phase was integration: connecting the local world of the app with external calendar systems. The current phase is consolidation: refining components, improving flows, reducing duplication, and preparing the project for more advanced behavior.

For a student or early-stage software project, this progression is valuable because it shows how practical software development rarely follows a perfectly linear plan. The app did not begin with a complete architecture diagram and then simply fill in the pieces. Instead, each implementation step revealed the next architectural need. A form revealed the need for drafts. External calendars revealed the need for source metadata and sync states. Autosave revealed the need to distinguish loading from editing. Reusable cards revealed the need for stronger model relationships. The architecture emerged through contact with the problem.

There is also a broader lesson about building products that are not ready to be fully disclosed. It can be difficult to talk about a project publicly when the most exciting parts are still private. But not every development story has to reveal the final product. It is possible to discuss the engineering process, the technical decisions, the mistakes avoided, and the problems encountered without giving away the complete concept. In some ways, this is more useful for an informatics audience. The real value is not only in what the app will eventually do, but in how the system is being shaped to make that possible.

The next steps will likely focus on stability, refinement, and careful expansion. The persistence system will need to remain reliable as the data model grows. Synchronization will need more testing, especially around conflicts and edge cases. The interface will need continued polishing across different device sizes and user scenarios. Some flows that currently exist as early implementations will need to become more robust. And as the app moves closer to a publishable version, privacy, permissions, error handling, and user trust will become even more important.

What makes this project interesting is that it sits at the intersection of design, data modeling, and everyday behavior. A planning app is not just a technical container for events and tasks. It is a tool that asks to be invited into a user’s routine. That creates a high bar: the app has to be useful without being noisy, structured without being rigid, and personal without becoming confusing. Reaching that balance takes iteration.

So far, the development has already moved beyond a simple prototype. The app has a working SwiftUI foundation, a growing design system, structured models, persistent local data, reusable creation flows, and initial external calendar synchronization. More importantly, it has a clearer sense of direction. The final product is not ready to be revealed yet, but the development process has already shown what kind of challenge this is: not merely building screens, but building a coherent planning environment one careful layer at a time.

The post Building a Personal Planning App: From Interface Idea to Data-Driven iOS Prototype appeared first on Mobile USTP MKL.

Im Semester habe ich mich im wesentlichen darauf fokussiert, Community Features, wie Sterne-Bewertungen und Kommentier- bzw. Antwortfunktion, in meine Nativescript-App zu integrieren und deutlich mehr Zeit in Bugfixing zu investieren. Nebenbei wurde stellenweise das Design weiter optimiert, sowie das Fehlerhandling überarbeitet. Zur Abrundung wurde im Projektabschnitt eine exportierbare Einkaufliste für Zutaten, die der/die User:in braucht, um die Rezepte nachzumachen, integriert.

Neuerungen seit dem letzten Semester

• Filteroptionen in der Rezeptliste

Der größte strukturelle Umbau fand in der Rezeptliste statt. Bisher wurden die Rezepte einfach als rohe Liste angezeigt, ohne Möglichkeit zur Filterung. Jetzt gibt es eine eigene Suchleiste mit Autocomplete-Vorschlägen der gefilterten Drinks, eine alphabetische Sortierung mit Drink-Nummer pro Karte, sowie einen Toggle-Filter für Signature Drinks.

• Kommentar-Sektion bei den Recipes

Das Herzstück des Projektes war die Erweiterung, dass jedes Rezept nun eine vollwertige Community-Section hat. User:innen können Kommentare mit Sternebewertung hinterlassen, auf Kommentare anderer antworten und eigene Kommentare wieder löschen. Die Bewertungen fließen in eine Durchschnittsbewertung ein, die prominent im Header der Rezeptkarte angezeigt wird. Die gesamte Kommunikation läuft in Echtzeit über WebSockets.

• Benötigte Zutaten einer Einkaufsliste hinzufügen

Bisher wurden alle nicht angegebenen Zutaten bei der Hauptsuche automatisch gesammelt und global in meinem Code zwischengespeichert. Das wurde grundlegend über ein Einkaufslisten-Feature überarbeitet: Pro Rezept kann der/die Nutzer:in nun selbst entscheiden, ob er/sie die fehlenden Zutaten zur Einkaufsliste hinzufügen möchte. Fehlende Zutaten werden in der Zutatenliste farblich in Orange hervorgehoben. Ein einzelner Button pro Rezept überträgt dann gezielt nur die fehlenden Zutaten in die Einkaufsliste. Die Einkaufsliste selbst unterstützt den Export als PDF über den nativen Android PrintManager sowie im CSV-Format.

Neben diesen Änderungen konnten viele Bugs behoben werden. Speziell einige Bugs, die die Funktionalität rund um die Erstellung von “Signature Drinks” (anlegen/löschen) als auch den Umgang mit gekennzeichneten Favoriten-Rezepten, eingeschränkt haben, existieren nicht mehr.

Technischer Part

Der Großteil an Technologien ist gleich geblieben. Im Frontend setze ich weiterhin auf NativeScript Angular bzw. Tailwind für das Design und im Backend SpringBoot. Das Backend habe ich dieses Semester erstmalig über den Online-Service Railway gehostet. Dazugekommen sind vor allem die WebSocket-Bibliothek @stomp/stompjs im Frontend sowie die entsprechende Spring WebSocket-Abhängigkeit im Backend.

Für die Kommentar-Funktion war von Anfang an klar, dass klassische HTTP-Requests nicht ausreichen , sonst wäre ein ständiges manuelles Aktualisieren notwendig gewesen, um neue Kommentare zu sehen. Die Wahl fiel auf WebSockets mit STOMP, einem einfachen Messaging-Protokoll das auf WebSocket aufsetzt und ein Publish-Subscribe-Modell ermöglicht. Im Spring Boot Backend wird dabei ein Message-Broker konfiguriert der eingehende Nachrichten an alle Subscriber des jeweiligen Rezept-Topics weiterleitet. Jedes Rezept hat seinen eigenen Kanal, zum Beispiel /topic/recipe/42/comments. Nur Nutzer:innen die gerade dieses Rezept offen haben, empfangen die Kommentar, die zu diesem Rezept abgegeben wurden. Der Controller nimmt neue Kommentare entgegen, speichert sie und schickt sie sofort an alle aktiven Subscriber:

@MessageMapping("/comments/create")
public void createComment(CreateCommentRequestDto request, Principal principal) {
    User author = userRepository.findByUsername(principal.getName())...;
    CommentResponseDto saved = commentService.createComment(request, author);
    messagingTemplate.convertAndSend(
        "/topic/recipe/" + request.getRecipeId() + "/comments", 
        saved
    );
}

Im Frontend übernimmt ein dedizierter CommentWebSocketService die gesamte Verbindungslogik. Er verwendet die @stomp/stompjs Bibliothek, schickt den JWT-Token beim Verbindungsaufbau mit und subscribt auf den zum Rezept passenden Topic-Kanal:

this.stompClient = new Client({
    webSocketFactory: () => new WebSocket(`wss://...railway.app/ws`),
    connectHeaders: { Authorization: `Bearer ${this.authToken}` },
    reconnectDelay: 5000,
});
 
this.stompClient.onConnect = () => {
    this.stompClient.subscribe(
        `/topic/recipe/${this.recipeId}/comments`,
        (message) => {
            const comment = JSON.parse(message.body);
            onCommentReceived(comment);
        }
    );
};

Herausforderungen & Learning(s) daraus

Die größte Herausforderung des Semesters waren eindeutig die WebSockets. Theoretisch klingt es simpel (Verbindung öffnen und Nachrichten empfangen), jedoch in der Praxis gab es einige Hürden. Zuerst die Authentifizierung: anders als bei normalen HTTP-Requests musste der JWT-Token über die STOMP connectHeaders mitgeschickt und im Backend extra validiert werden. Dann das Problem mit inaktiven Verbindungen, denn ohne der sogenannten “Heartbeat-Konfiguration” auf beiden Seiten kamen Nachrichten irgendwann einfach nicht mehr an (Fehlermeldungen wurden nicht geworfen). Zu guter Letzt das Aufräumen der Verbindungen, denn ohne explizites disconnect() blieben im Hintergrund immer mehr aktive Verbindungen offen.

Was das Aufräumen so schwierig gemacht hat, war der Pager, mit dem man zwischen den Rezepten swipen kann. NativeScript’s Pager-Komponente erstellt alle Rezept-Items gleichzeitig beim Laden, bei 14 Rezepten also sofort 14 WebSocket-Verbindungen und 14 HTTP-Requests, obwohl der/die Nutzer:in nur ein einziges Rezept sieht. Noch dazu wird ngOnDestroy beim Wischen zwischen den Items nicht zuverlässig aufgerufen, weil der Pager seine Views intern recycelt statt sie wirklich zu zerstören. Dadurch hat die Cleanup-Logik nie gefeuert.

Die Lösung war letztlich ein Umdenken: statt auf ngOnDestroy zu vertrauen, steuert jetzt ein Flag, ob die Kommentar-Sektion überhaupt gerendert wird. Sobald der Nutzer wegwischt, verschwindet die Komponente via *ngIf aus dem DOM, damit das Cleanup zuverlässig durchläuft. Das wesentliche Learning dabei, war ein gut ausgebautes Debugging zu haben.

Fazit und zukünftige TODOs

In diesem Projektabschnitt konnte ich mich erstmalig herausfordernd damit befassen, wie WebSockets technisch umgesetzt werden. Das war gleichzeitig eines der interessantesten und aufwändigsten Themen des Semesters. Die vielen Debugging-Sessions haben mich aber auch am meisten weitergebracht. Rückblickend bin ich sehr zufrieden damit, was ich mir vorgenommen hatte auch tatsächlich vollständig umgesetzt zu haben. Gerade das Bugfixing war diesmal besonders aufwändig, hat aber mit großem Erfolg geendet und manche Features meiner App brauchbarer gemacht.

An diesen Dingen sollte nun weitergearbeitet werden: Performance-seitig gibt es noch Luft nach oben, sowohl beim initialen Laden als auch bei den Screen-Wechseln merkt man stellenweise noch Verzögerungen die es zu optimieren gilt. Auch das Design ist noch nicht wirklich durchgängig einheitlich, was ich in einem nächsten Schritt konsequenter angehen möchte. Dazu kommt, dass ich bisher kaum echtes User-Feedback eingeholt habe, das soll sich ändern. Auf technischer Seite fehlen noch automatisierte Tests, die zur noch besseren Stabilität der App beitragen sollen. Schlussendlich wäre das große Ziel die App veröffentlichen zu können.

Beitragsbild: dieses wurde mittels Einsatz von KI erzeugt

The post Projekt WS25 | MixMatch (Fortsetzung) appeared first on Mobile USTP MKL.

Worum es in der App geht

Im Kern funktioniert Timelapse wie ein visuelles Tagebuch:

• Nutzer:innen legen Projekte an (z. B. „Daily Selfie“ oder „Zimmerpflanze“).
• Die App erinnert regelmäßig daran, neue Fotos aufzunehmen.
• Alle Bilder werden zeitlich geordnet, mit Datum und optionalen Kommentaren gespeichert.
• Auf einer kompakten Übersicht sieht man, wann man etwas aufgenommen hat, welche Tage besonders wichtig waren und wie sich das Projekt über Wochen und Monate entwickelt.
• Aus dieser Sammlung erzeugt Timelapse auf Knopfdruck ein Zeitraffervideo, das die Geschichte des Projekts in wenigen Sekunden erzählt.

Zentrale Funktionen in Kürze

• Projektorganisation: Mehrere parallele Timelapse-Projekte mit Titel, Beschreibung und individuellen Einstellungen.
• Visuelle Timeline: Eine kombinierte Wochen- und Listenansicht zeigt, welche Tage schon dokumentiert sind und welche Lücken es noch gibt.
• Erinnerungen: Konfigurierbare Benachrichtigungen, damit die tägliche Aufnahme zur Routine wird und die Timeline nicht abreißt.
• Favoriten & Notizen: Einzelne Tage können hervorgehoben und mit kurzen Kommentaren versehen werden – etwa um Meilensteine oder besondere Momente zu markieren.
• Automatische Video-Montage: Die App erstellt aus den Bildern ein Video, berücksichtigt Ausrichtung, Datum, optionales Wasserzeichen und Kommentare und bietet Konfigurationsmöglichkeiten für Qualität oder Textstil.

Technologie-Stack

Die App ist als native Android-Anwendung mit Jetpack Compose umgesetzt und nutzt moderne Android-APIs sowie eine klare Schichtung zwischen UI, Logik und Medienverarbeitung.

• UI: Jetpack Compose + Material 3
  • Alle Screens (Projektliste, Details, Dialoge, Konfiguration) sind vollständig in Compose realisiert.
  • Material-3-Komponenten wie LargeFlexibleTopAppBar, Listen, Cards und Dialoge sorgen für ein konsistentes Look & Feel.
  • Ein zentrales TimelapseTheme verwaltet App-Theme (Light/Dark), Seed-Farbe und den Palette-Stil.
• Material 3 Expressive & Material You
  • Die App nutzt Material 3 Expressive, um eine lebendige, charakterstarke Farb- und Typografie-Sprache umzusetzen – passend zu einer App, die persönliche Veränderungen dokumentiert.
  • Über einen integrierten Color Picker wählen Nutzer:innen eine eigene Akzentfarbe.
  • Aus dieser Seed-Farbe wird mit Material You ein komplettes Farbschema generiert, das sich konsistent über die gesamte App zieht.
  • Dadurch wirkt Timelapse auf jedem Gerät persönlich, bleibt aber immer klar strukturiert und gut lesbar – unabhängig davon, ob Light- oder Dark-Mode aktiv ist.
• Video-Montage & Bildverarbeitung
  • Die Montage-Logik läuft in einem eigenen Modul:
  • Bilder werden anhand ihrer EXIF-Daten korrekt ausgerichtet.
  • Ein Canvas setzt die Frames zusammen, ergänzt Texte (Datum, Kommentare, Wasserzeichen) und kümmert sich um Hintergrundfarbe und Zensurflächen.
  • Ein Muxer erzeugt daraus ein MP4-Video, gesteuert über Kotlin Flows, die den Fortschritt an die UI melden.
  • So entsteht aus einer losen Sammlung von Bildern ein stimmiges Timelapse-Video, ohne dass externe Tools nötig sind.

Material 3 Expressive & Material You im Einsatz

Ein großer Fokus des Projekts lag auf einer modernen, adaptiven UI, die sich nach den Nutzer:innen richtet:

• Dynamische Farbwelten
  • Durch den Seed-Color-Ansatz wirkt die App nicht wie ein statisch durchgestyltes Produkt, sondern wie ein Rahmen, der sich der jeweiligen Geschichte anpasst.
  • Projekte mit emotionalem Kontext (z. B. Schwangerschaft, Beziehungen, erste Wohnung) profitieren von den kräftigen, expressiven Paletten, die Material 3 bereitstellt.
• Einheitliche, weiche Formsprache
  • Großzügige Rundungen (z. B. extra große Card-Shapes in Dialogen), expressive Typografie und bewusst eingesetzte Icons unterstützen den Tagebuch-Charakter der App.
  • Die App verzichtet auf überladene UI-Elemente und setzt auf Ruhe, Klarheit und Fokus – wichtig, wenn man sich über Monate immer wieder mit derselben Oberfläche beschäftigt.
• Konsistentes Theming
  • Alle Bausteine – von Erfassungsdialogs über Erinnerungs-Settings bis hin zu Fortschrittsanzeigen bei Scans und Montage – hängen am gleichen Theme.
  • Änderungen an Theme, Palette oder Seed-Farbe greifen sofort durch, ohne dass einzelne Screens speziell angepasst werden müssen.

Herausforderungen & Learnings

• Balance zwischen Einfachheit und Kontrolle
  • Nutzer:innen sollen einerseits „einfach nur“ ein Timelapse-Video erstellen können, andererseits genug Einstellmöglichkeiten für Qualität, Text, Stabilisierung und Privatsphäre haben.
  • Ein wichtiger Lernpunkt war, die Komplexität hinter klaren Dialogen und wenigen, gut erklärten Optionen zu verstecken.
• Stabile, angenehme Timelapse-Videos
  • Kleine Fehler bei Skalierung oder Matrix-Transformation führen schnell zu Sprüngen oder abgeschnittenen Bereichen – hier war viel Feintuning nötig.
• Durchgängiges Theming mit Material 3 / Material You
  • Seed-Farben, dynamische Paletten und unterschiedliche Palettenstile (z. B. Expressive) lassen sich mächtig kombinieren – aber nur, wenn das Theming-Konzept von Anfang an klar definiert ist.
  • Die wichtigste Erkenntnis: Ein zentrales Theme-Objekt vereinfacht langfristig alle Entscheidungen rund um Farben, Typografie und Component-Styling.

Fazit

Timelapse war für mich ein Projekt, in dem sich User Experience, modernes Android-Design und Medienverarbeitung sehr gut ergänzt haben. Die App zeigt, wie sich mit Jetpack Compose, Material 3 Expressive und Material You eine Oberfläche bauen lässt, die technisch anspruchsvolle Abläufe (zB. Videomontage) hinter einem einfachen, persönlichen Nutzungserlebnis versteckt. Besonders spannend war zu sehen, wie stark sich die Wahrnehmung der App ändert, wenn man eine eigene Farbwelt definieren kann und diese sich konsequent durch alle Screens zieht. In zukünftigen Schritten möchte ich die App um Themen wie Musik, Export-Presets und umfangreichere Sharing-Optionen erweitern – immer mit dem Ziel, den Kern beizubehalten: Veränderung sichtbar machen, ohne dass sich der Aufwand danach anfühlt.

The post Projekt | Timelapse Android App appeared first on Mobile USTP MKL.

Aufgabenstellung

Die einzige Vorgabe war, dass das Projekt eine technische Herausforderung beinhalten muss. Nachdem wir drei Ideen gesammelt hatten, entschieden wir uns dazu, eine App zu entwickeln, die Menschen motiviert, die Zeit wieder mehr mit ihren Liebsten zu genießen, ohne auf das Handy zu schauen. Die technische Herausforderung lag hierbei vor allem in der Verbindung zwischen den Geräten durch Bluetooth, aber auch in der Erstellung einer nativen, production-ready App.

MVP

Anfangs wurde von uns selbst ein MVP mit den grundlegendsten Funktionen definiert. Dazu zählte, sich als User einloggen bzw. registrieren und Sessions starten zu können, in der das Handy nicht verwendet werden sollte. Weiters ist es wichtig, die Verbindung zwischen den Geräten (egal ob NFC, BLE etc.) herzustellen und aufrechtzuerhalten. Die App sollte erkennen, wenn jemand das Handy verwendet, und das den anderen Geräten mitteilen. Wir hatten die Idee, dass die User*innen mehrere Modi spielen können, wobei nur der “Bill Splitter” zum MVP zählt. Dabei sollte man einen Rechnungsbetrag eingeben können und die App zeigt an, wer wie viel schlussendlich zahlen muss, basierend darauf, wie oft jeweils das Handy verwendet wurde. Die App sollte grundsätzlich nativ auf beiden Plattformen (iOS und Android) entwickelt werden und am Ende production-ready sein. Zudem hatten wir uns vorgenommen, eine CI/CD-Pipeline fürs Backend aufzusetzen und eine Website mit rechtlichen Informationen und Links zur App zu entwickeln. Die Website spielt vor allem für die Releases in den Stores eine Rolle.

Nice To Have

Als “Nice To Have” hatten wir uns primär die Erweiterung um 2 zusätzliche Modi vorgenommen: Beim Modus “Pot Lock” legen die Spieler*innen anfänglich fest, welcher Betrag pro Person in einen virtuellen Topf gegeben werden soll, und ab welcher Handynutzungsgrenze (“Threshold”) man seinen Einsatz verliert. Am Schluss teilen sich die Personen, die den Threshold nicht überschritten haben, den Topf. Beim Modus “Group Jar” legt die Gruppe einen Preis pro Handynutzung fest und am Ende der Session sagt die App, wer wie viel insgesamt in die Gruppenkasse zahlen muss.

Weitere Nice-To-Haves waren die Möglichkeit, dass Spieler*innen auch mittendrin einer Session beitreten können (falls jemand sich z. B. verspätet), dass sie sich nach einem Disconnect wieder reconnecten können und dass sie auch früher die Session verlassen können (falls jemand z. B. schon früher nach Hause gehen muss). Abgesehen davon wollten wir, dass die App auch komplett offline funktioniert, damit man sie auch in einer Keller-Bar mit schlechtem Empfang nutzen kann. Zusätzlich wollten wir die App zumindest in einem Store veröffentlichen.

Weiters hatten wir viele coole Ideen, die App durch Features wie Mini Games, einer KI-Funktion zum Rechnung-Scannen (für den Modus “Bill Splitter”), einer History, einem Streak, einer Realtime Abstimmung (für Notfallsituationen, in denen die Handynutzung toleriert wird), einem SSO-Login und einer direkten Zahlung in der App bzw. einer Importfunktion in eine App wie Splitwise oder Tricount zu erweitern, allerdings blieb dafür leider keine Zeit mehr – zumindest in diesem Semester.

Verwendete Technologien

App

Die Apps wurden jeweils nativ, in Swift für iOS und Kotlin für Android geschrieben, um Erfahrung im Bereich der nativen App-Entwicklung zu sammeln.

Website

Die Website wurde mit Next.js, einem React-basierten Framework entwickelt. Für das Styling wurde Tailwind CSS verwendet und für eine typsichere Entwicklung haben wir uns für TypeScript entschieden. Wir verwenden eine klassisch komponentenbasierte Architektur mit wiederverwendbaren Komponenten. Für die Containerisierung verwenden wir Docker.

Projektablauf

Die Arbeit am Semesterprojekt wurde in Sprints aufgeteilt (die an Masterklassen-Einheiten orientiert waren, wobei wir intern auch hin und wieder Meetings dazwischen hatten, wenn der Abstand zwischen den Masterklassen Einheiten zu lange war).

Als Projektmanagement-Tool und zum Verwalten des Backlogs wurde die Software “Linear” verwendet: vor jedem Sprint definierten wir, wer an welchen Tickets arbeitet und teilten diese im Team auf.

Das Endprodukt

Wir haben die MVP Funktionalitäten und Nice-To-Haves wie beschrieben umgesetzt, mit den folgenden kleinen Anpassungen: Unsere App funktioniert komplett offline mit Bluetooth LE und die Session ID wird über das Scannen eines QR-Codes unter den Spieler*innen ausgetauscht. Das Backend hatten wir zwar anfänglich aufgesetzt, es wird momentan allerdings nicht benötigt. Zusätzlich zu den 3 Modi gibt es nun auch einen vierten Modus, das “Basic Leaderboard”, mit welchem sich User*innen ihre eigenen Regeln festlegen können. Weiters implementierten wir einen Solomodus, sodass die App nicht nur in der Gruppe, sondern auch alleine (z. B. beim Lernen) verwendet werden kann. Außerdem setzten wir eine coole CI/CD Pipeline für unsere Website auf und veröffentlichten unsere App in nicht nur einem, sondern in beiden Stores (Apple App Store, Google Play Store).

Link zum iOS App Store-Eintrag

Link zum Android App Store-Eintrag

Beim ersten Öffnen der App wird man durch ein Onboarding geleitet, in welchem die App kurz vorgestellt wird. Hierbei muss man auch einen Namen angeben, welcher innerhalb der App für einen selbst verwendet werden soll. Schließlich landet man am Homescreen (Abb. 3, links). Über das Profil-Icon rechts oben hat man die Möglichkeit, den festgelegten Namen zu ändern. Über den Button “Start New Session” startet man eine neue Gruppensession und kommt zum New Session Screen (Abb. 3, Mitte) – diesen Button muss allerdings nur eine Person in der Gruppe klicken. Alle anderen klicken auf “Join Session”, welcher die Kamera öffnet, um den generierten QR-Code zu scannen, welcher einen dann auch zum New Session Screen weiterleitet. Der Button “Go Solo” führt zum Solomodus, welcher weiter unten genauer beschrieben wird.

Am New Session Screen werden die aktuellen Teilnehmer*innen und der ausgewählte Modus angezeigt. Der “Host” der Session (die Person, die auf “Start New Session” geklickt hat) hat zudem die Möglichkeit, den Modus auszuwählen (Abb. 3, rechts) und notwendige Einstellungen vorzunehmen (z. B. den Preis pro Nutzung für den Group Jar Modus zu setzen).

Wie angekündigt, gibt es auch einen Solomodus. Mit dem Klick auf “Go Solo” am Home Screen kommt man zum New Focus Session Screen (Abb. 4, links), welcher wie ein Group Jar Modus funktioniert – man muss also den Preis pro Nutzung festlegen. Während der Session (Focus Session Screen, Abb. 4, rechts) sieht man die gesamte Nutzungsanzahl und wie viel Geld man sich in das eigene Sparschwein zahlen müssen wird.

Ein weiteres spannendes Feature ist das Starten des Solomodus durch das Ablegen des Handys auf eine bestimmte Stelle. Wir stellen uns den Ablauf für User*innen folgendermaßen vor:

1. User*in setzt sich an den Schreibtisch.
2. User*in legt das Handy auf eine Ablagefläche.
3. bHere App öffnet sich und Solomodus wird automatisch gestartet.

Technisch funktioniert es mit einem NFC-Tag, der einen Deeplink enthält. Für die Projektevernissage 2026 haben wir 100 Tags (NTAG215) bestellt, beschrieben und hergeschenkt. Das Feature haben wir aktuell nur für Android implementiert.

Die App ist auf beiden Plattformen sowohl in Light Mode, als auch in Dark Mode, verfügbar.

Feedback und Verbesserungsmöglichkeiten

Durch die Teilnahme an der Projektvernissage konnten wir wertvolles User-Feedback für potentielle zukünftige Erweiterungen und Verbesserungen der App sammeln: der wohl größte Pain Point der aktuellen Lösung ist die Latenz des implementierten BLE-Mesh. Vor allem bei Sessions mit einer hohen Teilnehmeranzahl kann es aktuell bis zu mehreren Minuten dauern, bis alle Daten zwischen allen Geräten ausgetauscht wurden. Sollte das Projekt noch weiterentwickelt werden, wäre das wohl eines der ersten Tickets, das umgesetzt werden müsste.

Fazit aller Teilnehmer*innen

Im folgenden Abschnitt möchten wir noch unser Fazit und unsere Erfahrungen teilen, die wir im Zuge dieses Semestergruppenprojekts sammeln konnten.

David

Die Arbeit an bHere war für mich eine intensive und lehrreiche Erfahrung. Technisch gesehen war die Implementierung der Bluetooth-Low-Energy-Kommunikation sicherlich die größte Hürde. Es hat einige Iterationen und Research gebraucht, weshalb ich umso stolzer bin, dass wir schlussendlich ein funktionierendes BLE-Mesh auf die Beine stellen konnten.

Eine wichtige Lektion war für mich die Herausforderung der parallelen Entwicklung auf zwei Plattformen. Es zeigte sich schnell: Wenn Details nicht vorab klar definiert sind, kann es passieren, dass sie auf iOS und Android unterschiedlich umgesetzt werden. Das führte dazu, dass die letzten Wochen und Tage vor der Abgabe besonders intensiv waren, da wir viele dieser kleinen Unstimmigkeiten noch angleichen mussten. Auch den Prozess der Veröffentlichung hatte ich unterschätzt – insbesondere die Vorbereitung des Store-Eintrags und die zwingende 14-tägige Testphase im Google Play Store benötigen mehr Vorlaufzeit, als man zu Beginn vermuten würde.

Andreas

Anders als bei der einwöchigen WildWeek, die wir im Laufe des 2. Semesters hatten, wurden wir in diesem Semester in einem technisch herausfordernden Semesterprojekt auf die Probe gestellt. Dies forderte ein hohes Maß an Eigenverantwortung und gute Teamkommunikation. Insbesondere, weil wir die App bhere auf zwei Plattformen (Android und iOS) gleichzeitig aufgebaut haben. Die Tatsache, dass wir uns nicht wie in der WildWeek auf direkten Wege schnell austauschen konnten, machte das Projekt umso lehrreicher, weil es auch nebenbei die heutige Home Office Arbeitsweise gut widerspiegelt hat.

Persönlich habe ich mich speziell im Bereich der Android App Entwicklung einbringen können. Dort war ich mit einigen Kollegen an der Gestaltung der UI unserer Screens dran. Neben dem Entwicklungs-Part habe ich auch an der Gestaltung unseres App-Logos beigetragen und fürs Marketing die Bierdeckeln designed, welche wir dann als Merch an die Interessent:innen verteilt haben. Ich fand die Tasks sehr abwechslungsreich und konnte mich erstmals tiefgründig mit der Programmiersprache Kotlin auseinandersetzen. Erste wirkliche Programmiererfahrung von Apps hatte ich damals noch mit Java.

Rückblickend betrachtet bin ich froh gewesen, mit unserem Team eine solch innovative App auf die Beine gestellt zu haben. Die Umsetzung hat gezeigt, dass wir mit vielen guten Ideen und einigem Kreativitätsvermögen, auch technisch herausfordernde Anforderungen meistern können. Nichtsdestotrotz ist zu erwähnen, dass der Weg dorthin nicht immer einfach war. Durch die Parallelentwicklung (Android/iOS) mussten wir ständig so up-to-date sein, dass auf beiden Systemen ein ziemlich einheitliches Design und verhalten aufgebaut werden konnte. Außerdem waren zahlreiche Testläufe nötig, bis wir eine stabile, plattformübergreifende Lösung gefunden hatten, um zwischen allen Endgeräten ein BLE-Mesh aufzubauen, über das die Kommunikation schließlich zuverlässig stattfinden konnte.

Felix

Dieses Gruppen-Semesterprojekt war für mich eine sehr spannende Herausforderung, weil wir in einem großen Team eine komplette App für iOS und Android entwickelt haben und diese dann auch veröffentlicht haben. Im Vergleich zu der Wild Programming Week war es finde ich viel anstrengender, weil wir einfach über einen langen Zeitraum uns immer koordinieren mussten. Aber im Großen und Ganzen hat alles gut funktioniert.

Zum Start haben wir zuerst ein Backend entwickelt für User Anmeldung, was dann aber nicht verwendet wurde, weil wir die App offline verwenden wollten, das war anfangs frustrierend, weil dabei Zeit draufgegangen ist, aber natürlich verständlich. Dann habe ich auch ziemlich am Anfang eine Website entwickelt, die, wie ich finde, sehr gut geworden ist. Ansonsten habe ich im Android Team und beim Merch für die Projekte Vernissage geholfen. Das fand ich am spannendsten, da ich Kotlin besser kennenlernen konnte.

Das gesamte Projekt hat mir sehr gut gefallen, vor allem weil es ein sehr reales und arbeitsnahes Projekt war. Wir waren ein gutes Team und haben gute Meetings abgehalten. Es hat alles gut funktioniert, wenn auch nicht ohne Schwierigkeiten.

Caroline

Im Vergleich zur Extreme Programming Week im 2. Semester hatten wir diesmal mehr Zeit fürs Einarbeiten und Ausprobieren, wobei die Entwicklung einer nativen App auf zwei unterschiedlichen Plattformen dafür neue Herausforderungen mit sich brachte. Ich habe hauptsächlich gemeinsam mit Katharina an der iOS-Version gearbeitet, was im Pair-Programming sehr gut funktioniert hat. Besonders hilfreich war dabei, dass sie bereits mehr Erfahrung mit Swift hatte, wodurch ich mich trotz anfänglicher Unsicherheiten schnell einarbeiten konnte.

Eine der größten Herausforderungen war die Umsetzung der Bluetooth-Low-Energy-Kommunikation. Da es auf iOS im Wesentlichen nur Core Bluetooth gibt, mussten wir viele Teile selbst erarbeiten. Zunächst mussten wir die Grundlagen von BLE verstehen und verschiedene Ansätze ausprobieren, bis wir zu einer funktionierenden Lösung kamen, die über mehrere Geräte hinweg funktioniert. Besonders hilfreich war Davids erste Umsetzung eines Meshs auf Android, auch wenn die Übertragung der Logik auf iOS aufgrund plattformspezifischer Unterschiede nicht einfach war.

Zusätzlich haben wir die iOS-Version der App im App Store veröffentlicht, was für mich eine neue und spannende Erfahrung war. Dabei habe ich einen Einblick in den Release-Prozess sowie die dafür notwendigen Schritte und Anforderungen von Apple bekommen.

Insgesamt hat mir das Projekt nochmal gezeigt, wie wichtig klare Absprachen im Team sowie ein möglichst fertiges und einheitliches Design zu Beginn eines Projekts sind. Fehlende oder unklare Definitionen führen später nämlich zu Mehraufwand und Inkonsistenzen zwischen den Plattformen. Rückblickend war das Projekt jedoch sehr lehrreich und hat mir sowohl technisch als auch im Bereich Teamarbeit wertvolle Erfahrungen gebracht.

Sebastian

Auch wenn wir im zweiten Semester die Wild Programming Week hatten, in welcher wir eine App innerhalb einer Woche entwickeln mussten, war dieses Semesterprojekt doch noch einmal ein ganz neues Erlebnis. Eine App über ein ganzes Semester zu entwickeln hat das Ganze leichter wie auch schwerer gestaltet. 

Durch den Zeitrahmen hatten wir um einiges mehr Zeit zu entwickeln, nicht wie in der Wild Week. Aber auch durch diesen größeren Zeitrahmen wurde es schwerer, da es zum einen natürlich den Projektumfang erhöht hat. Gleichzeitig war es auch um einiges schwerer, den nötigen Arbeitsaufwand einzuschätzen, wodurch man zum Beispiel zu Beginn die Arbeitspakete zu klein für einen Sprint geschätzt hat. 

Ich war vor allem mit UI Umsetzungen auf Android, zusammen mit der Implementierung der Nutzungserkennung zuständig. Bei der UI Umsetzung der die größte Herausforderung die Abstimmung zwischen Android und iOS. Zwar sind beide Plattformen von der gleichen Basis ausgegangen, auf beiden gab es aber kleiner Änderungen, welche dafür gesorgt haben, dass das Design nicht komplett einstimmig waren und hat extra Arbeit gegen Ende benötigt zum Anpassen.

Im Ganzen war es aber wieder ein gutes Erlebnis, mit einem tollen Team. Das ganze kam mit wichtigen Erfahrungen, wie Programmiersprachen Erlernung, App Store Einrichtungen und auch das erneute zeigen, wie wichtig gute Kommunikation und Abstimmung ist, um extra Arbeit zu vermeiden. Ich wäre jederzeit bereit, noch ein Projekt mit diesem Team zu machen.

Jan

Es war sehr nett, mit allen Studienkollegen der Masterklasse ein Projekt umzusetzen. Spannend war, wie sich jeder mit seinen Stärken eingebracht hat. Gerne hätte ich noch mehr an diesem Projekt gearbeitet und dafür auf andere Lehrveranstaltungen verzichtet.

Das Projekt hat sich im Laufe der Zeit in eine spannende Richtung entwickelt. Features, die wir anfangs eingeplant hatten, haben sich bei genauerer Betrachtung als nicht wichtig oder sogar als störend erwiesen und wurden daher gestrichen. Ich bin beispielsweise sehr froh über die Entscheidung, dass die App zu 100% offline funktioniert und es kein Backend gibt. Das ermöglicht den flexiblen Einsatz der App, zum Beispiel in Kellerlokalen ohne Mobilfunk, und hat den Vorteil, dass User ohne lästige Account-Erstellung direkt loslegen können. Für uns als Team bedeutet der Wegfall eines Backends, dass wir die Applikation kostengünstiger und mit weniger Aufwand betreiben können.

Wir können stolz darauf sein, dass wir eine neuartige und wirklich nützliche Applikation geschaffen haben, die ausreichend stabil läuft. Natürlich sehen wir noch einige offene Themen, die wir gerne angehen würden. Schade, dass wir vorerst kaum Zeit mehr für bHere haben werden, da wir uns nun auf unsere Masterarbeiten konzentrieren müssen.

Katharina

Das Projekt “bHere” war für mich eine besonders wertvolle Erfahrung. In meiner Rolle als Projektleiterin übernahm ich die Moderation der Sprint-Meetings, repräsentierte die Gruppe gegenüber unseren Stakeholdern (unseren Masterklassenleitern) und behielt den Gesamtüberblick über Fortschritt und offene Punkte.

Zusätzlich war ich gemeinsam mit Caro für die iOS-Entwicklung verantwortlich. Wir haben intensiv im Pair Programming gearbeitet und unsere Zusammenarbeit war dabei sehr produktiv. Besonders spannend war die Integration der BLE-Funktionalität – dank Davids Vorarbeit konnten wir diese auch erfolgreich in die iOS-App einbinden. Die BLE-Kommunikation auch plattformübergreifend zwischen iOS und Android zum Laufen zu bringen, stellte allerdings eine technische Herausforderung dar, da sich insbesondere das Debugging der Verbindung als nicht so trivial erwies.

Zeitlich war das Semester ebenfalls herausfordernder als gedacht. Im Vergleich zur “Wild Week” erforderte dieses Semestergruppenprojekt ein noch höheres Maß an Eigenorganisation und Abstimmung. Gerade gegen Ende kamen viele Aufgaben parallel zusammen, wodurch Priorisierung und Struktur besonders wichtig wurden. Für zukünftige Projekte nehme ich außerdem mit, wie wichtig ein frühzeitig klar definiertes und abgestimmtes Design ist, um plattformübergreifend noch effizienter arbeiten zu können.

Ein besonderes Highlight war für mich die erstmalige App-Einreichung im App Store. Der umfangreiche Einreichungsprozess hat uns auf der Zielgeraden noch einmal intensiv gefordert, ich konnte daraus aber auch sehr viel lernen.

Insgesamt habe ich sehr viel Arbeit und Engagement in dieses Projekt investiert – sowohl in die technische Umsetzung der iOS-App, als auch in die Organisation und Qualitätssicherung des ganzen Projekts. Umso stolzer bin ich auf das entstandene Produkt und auf das, was wir als Team erreicht haben. 

Matthias

Das Projekt hat mir einen spannenden Einblick gegeben, wie komplex die Entwicklung einer mobilen App werden kann, wenn sie plattformübergreifend funktionieren und gleichzeitig komplett offline nutzbar sein soll. Besonders spannend fand ich es, gemeinsam im Team einen Lösungsansatz für unser Bluetooth-Mesh-System zu suchen. Vor allem, weil es für unseren Anwendungsfall keine bestehende Lösung gab. Ich habe dabei auch versucht, ein eigenes Konzept zu entwickeln. Dieses war zwar noch nicht vollständig ausgereift und hätte mehr Zeit benötigt, hat mir aber geholfen, die technischen Herausforderungen besser zu verstehen und viel von den Lösungsansätzen der anderen im Team zu lernen.

Intensiver beschäftigt habe ich mich mit der Umsetzung der Nutzungserkennung unter iOS. Ziel war es, das Verhalten der App während der Nutzung besser nachvollziehen und entsprechende Daten erfassen zu können. Dabei musste darauf geachtet werden, dass möglichst ähnliche Informationen wie auf Android gesammelt werden, damit die Nutzung plattformübergreifend vergleichbar bleibt. Dadurch konnte ich mich stärker mit dem Verhalten von Apps unter iOS auseinandersetzen und besser verstehen, wie Apps im Hintergrund arbeiten und wie solche Informationen sinnvoll für die Weiterentwicklung eines Produkts genutzt werden können.

Außerdem hatte ich die Möglichkeit, den Prozess rund um die Veröffentlichung der App im Apple App Store aus nächster Nähe mitzuerleben. Es war spannend zu sehen, welche Schritte und Anforderungen notwendig sind, bis eine App tatsächlich eingereicht und veröffentlicht werden kann.

Mit am meisten Spaß haben mir die Diskussionen rund um die User Experience der App gemacht. In den Meetings habe ich gemerkt, dass mich dieser Bereich besonders interessiert und ich mich dort auch am besten einbringen kann. Die Kombination aus technischen Überlegungen und der Frage, wie sich eine App für Nutzer:innen möglichst intuitiv bedienen lässt, fand ich besonders spannend.

Während des Projekts bin ich mit vielen neuen Themen in Berührung gekommen und konnte dabei viel lernen, sowohl technisch als auch in der Zusammenarbeit im Team. Gleichzeitig war die Arbeit durch die vielen gemeinsamen Lösungsansätze sehr motivierend, wodurch das Lernen fast nebenbei passiert ist.

The post Projekt | bHere – not on your phone appeared first on Mobile USTP MKL.

Nativescript – eine kurze Vorstellung

Mit NativeScript, das 2015 auf den Markt kam, wurde ein Framework präsentiert, das plattformübergreifende mobile Apps ermöglicht und zugleich direkten Zugriff auf die nativen Funktionen von Android und iOS bietet. Seit dessen Einführung wird es kontinuierlich weiterentwickelt und hat sich zu einer stabilen Lösung für die App-Entwicklung etabliert. NativeScript erlaubt es, Apps mit bekannten Web-Technologien wie JavaScript, TypeScript, Angular oder Vue.js zu erstellen, wodurch der Einstieg für Web-Entwickler besonders einfach ist. Gleichzeitig werden die UI-Komponenten direkt nativ gerendert, was eine nahezu maximale Leistung gewährleistet. Ein Großteil des Codes kann zwischen Android und iOS weiterverwendet werden, wodurch Entwicklungszeit und -kosten reduziert werden. Damit kombiniert NativeScript die Vorteile plattformübergreifender Entwicklung mit direktem API-Zugriff und nativer Performance.

Mit diesem Wissen im Gepäck gelang es mir meine Erstentwicklung als reine WebApp in Angular ohne grundlegenden Neuanfang im nativen Bereich durchführen. Das hat mir die Möglichkeit eröffnet viele Teile der ursprünglichen Angular-Programmierung in eine App zu übertragen, auch wenn dies mit einer gewissen Komplexität einherging.

Von einer Web-App zu einer nativen App

Der Wechsel von der ursprünglichen Angular Web-App zu einer nativen App mit NativeScript stellte einen entscheidenden Entwicklungsschritt dar. Während die erste Version ausschließlich im Browser funktionierte und auf klassische Web-Komponenten ausgelegt war, verlagerte sich der Fokus nun auf die mobile Nutzung, native Performance und eine tiefere Integration in die jeweilige Plattform. Diese Veränderung erforderte nicht nur technisches Know-how, sondern auch ein grundlegendes Umdenken im App-Design. Die Benutzeroberfläche musste für mobile Endgeräte neu konzipiert werden, denn alleine responsive Layouts reichten nicht mehr aus. Stattdessen waren eine intuitive Navigation, Gestensteuerung und schnelle Ladezeiten gefragt. Technisch konnten viele Angular-Module und Services zwar grundsätzlich übernommen werden, jedoch waren umfangreiche Anpassungen notwendig, insbesondere beim Routing, der Datenbindung und dem Zugriff auf systemnahe Funktionen wie dem Dateispeicher.

Optimierter Suchalgorithmus

Der ursprüngliche Suchalgorithmus stellte einen klaren Engpass dar, da jede Filteranfrage direkt an die externe API gesendet wurde. Das führte zu langen Ladezeiten und unnötiger Netzwerklast.

Mit dem neuen, optimierten Ansatz werden die Rezeptdaten nun beim Start der Anwendung automatisch aus der API geladen und in die lokale Datenbank geschrieben. Die Suche erfolgt anschließend vollständig serverseitig über diese Datenbank, wodurch Abfragen deutlich schneller und stabiler laufen. Gleichzeitig bleibt die Filterlogik flexibel: Nutzer:innen können nach Kategorie, Alkoholgehalt und Zutaten suchen, ohne dass alle Kriterien zwingend gesetzt sein müssen.

Die “Signature”-Drinks

Dieses neue Feature bietet dem/der User:in die Möglichkeit, sich seinen/ihren Drink (Cocktail) selbst nach eigenen Wünschen zusammenzustellen. Diese Drinks in Form von Rezepten werden entsprechend gekennzeichnet und sind mit dem/der Ersteller:in verknüpft. Die Datenspeicherung erfolgt in der selben Tabelle, wo die Drink Rezepte der API abgespeichert sind. Nach dem Anlegen eines “Signature”-Drinks stehen dem/der Ersteller:in die Möglichkeit zur Verfügung den Drink . Hier ein Blick in die App (Bild folgt):

Weitere Features/Verbesserungen

Redesign

Mit dem Wechsel von einer WebApp auf eine native Mobile-App wurde das bestehende Design nicht vollständig neu entwickelt, sondern gezielt modernisiert und an mobile Nutzungsszenarien angepasst. Der Fokus lag dabei auf einer klareren visuellen Struktur, einer verbesserten Bedienbarkeit sowie einem konsistenten Erscheinungsbild über alle Ansichten hinweg.

Ein wesentlicher Schritt war die Umstellung des UI-Designs auf das Utility-First-Framework Tailwind CSS, das eine deutlich effizientere Gestaltung und höhere Flexibilität bei der Komponentenentwicklung ermöglicht. Dadurch konnten wiederkehrende Layouts vereinheitlicht, Abstände und Typografie präzise gesteuert und das gesamte Erscheinungsbild minimalistischer und moderner gestaltet werden.

Zutaten Suchfunktion

Bisher musst man sich durch eine lange Liste von Zutaten “quälen” – mit einem neuen Suchfeld bei den Zutaten wurde dies nun deutlich vereinfacht.

Herausforderungen im Entwicklungsprozess

Anbei zwei wesentliche Herausforderungen, die sich während der Entwicklungsarbeit zunehmend herauskristallisiert haben:

Die mobile Umsetzung von MixMatch mit NativeScript und Angular brachte einige technische und strukturelle Herausforderungen mit sich. Der Umstieg von der bisherigen Angular-Webumgebung auf NativeScript erforderte eine Einarbeitung in neue Syntaxkonzepte und native UI-Komponenten. Viele Layouts und Funktionen ließen sich nicht direkt übernehmen, sondern mussten gezielt an mobile Anforderungen angepasst werden. Zudem NativeScript auch noch ein sehr “junges” natives Framework ist und die Dokumentation derzeit noch nicht als allzu ausgereift erscheint.

Gleichzeitig wurde deutlich, dass Teile des bestehenden Codes, insbesondere im Hinblick auf Wartbarkeit und Performance auf mobilen Geräten, zu komplex aufgebaut waren. Um dem entgegenzuwirken, habe ich z. B. Übersetzungen in separate Lokalisations-Files ausgelagert, anstatt sie direkt im Code zu halten. Auch die Datenverarbeitung wurde angepasst: Statt verschachtelter Aufrufe zu der thecocktaildb API erfolgt die Filterung nun über eine lokale Datenbank, nachdem alle Daten der externen API einmalig gespeichert wurden.

Resümee mit Ausblick

Das Projekt stellte in mehrfacher Hinsicht eine wertvolle Lernerfahrung dar – insbesondere durch den mutigen Schritt, mit NativeScript in ein für mich völlig neues Framework einzusteigen. Dieser Ansatz bot die Gelegenheit, die Stärken und Schwächen der Plattform unmittelbar kennenzulernen: Auf der einen Seite die hohe Flexibilität, die tiefe Integration nativer Funktionen und die Möglichkeit, moderne Frontend-Technologien wie Angular und Tailwind zu kombinieren; auf der anderen Seite aber auch die typischen Herausforderungen eines jungen Frameworks – etwa eingeschränkte Dokumentation, komplexe Build-Prozesse und teils unerwartete Kompatibilitätsprobleme.

Gerade dieser direkte Umgang mit den Schattenseiten und positiven Aspekten des Frameworks hat jedoch den größten Lerneffekt gebracht. Es entstand ein tieferes Verständnis für mobile App-Architekturen, die Bedeutung einer sauberen Code-Struktur.

Auch nach Abschluss dieser Entwicklungsphase bleiben einige naheliegende Erweiterungen vorstellbar, die sich mittelfristig umsetzen lassen. Dazu zählt etwa eine Kommentarfunktion, mit der Nutzer:innen direkt Rückmeldung zu einzelnen Drinks geben oder sich austauschen können. Ebenso wäre es denkbar, die „Signature Drinks“ für andere sichtbar zu machen. Mit der individuellen Möglichkeit, eigene Rezepturen anderen Usern/Userinnen sichtbar zu machen, können persönliche Rezeptideen einem weiten Publikum präsentiert werden.
Ergänzend ließe sich eine einfache Einkaufsliste integrieren, in der fehlende Zutaten gesammelt und als Liste exportiert werden könnte. Diese funktionalen Erweiterungen würden, wie üblich, Hand in Hand mit weiterem Bugfixing, Code-Optimierungen und kleineren UI-Verbesserungen erfolgen, um die App sowohl technisch als auch inhaltlich weiter zu stabilisieren, der Benutzerfreundlichkeit hin zu optimieren und auszubauen.

Beitragsbild: dieses wurde mittels Einsatz von KI erzeugt

The post Projekt SS25 | MixMatch (Fortsetzung) appeared first on Mobile USTP MKL.