Im 3. Semester des Master-Studiengangs Interactive Technologies (Masterklasse Mobile) stand das große Semestergruppenprojekt an. Als ganze Masterklasse (insgesamt 8 Personen) entwickelten wir über das ganze Semester hinweg bHere, eine soziale App, die Gruppen durch spielerische Mechaniken und Konsequenzen motiviert, beim gemeinsamen Ausgehen das Handy wegzulegen.

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ählt, 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 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 haben 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

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

1. User setzt sich an den Schreibtisch.
2. User legt das Handy auf eine Ablagefläche.
3. bHere App öffnet sich und Solomodus ist 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.

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 (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 (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 (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 (links), welcher wie ein Group Jar Modus funktioniert – man muss also den Preis pro Nutzung festlegen. Während der Session (Focus Session Screen, rechts) sieht man die gesamte Nutzungsanzahl und wie viel Geld man sich in das eigene Sparschwein zahlen müssen wird.

Feedback und Verbesserungsmöglichkeiten

Durch die Teilnahme and 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 während der Extreme Programming Week 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 Umsetzungen meistern können. Nichtsdestotrotz war der Weg dorthin nicht immer einfach.

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.