Overview
❗️ Important Information
- This project was developed during Lukas’ and my free-time and was not related to our work nor university studies
- Any methods mentioned or any knowledge we applied was self-taught by several online courses (Udemy, Coursera, Youtube and other documentation)
- After the explanation of the Creation process there are information on our project management and major problems which occurred during the development
- This report/documentation was only created for my portfolio and does not necessarily follow university standards
🛠 Frameworks used
- SwiftUI (Swift)
- Firebase (Swift/Python/Javascript)
📌 Further links
👨🏼💻 Personal Contribution
Being only a team of two participants, both of us had different jobs to do. My tasks were to administrate our AppStore page and everything related to that (e.g., uploading the app and communication with Apple and the AppStore team). However, my main tasks were to design and develop the whole frontend. Basically every button, picture or textfield one can see was programmed by myself. At first, I sketched wireframes on paper, then designed them on Figma tested them with the Figma mobile app and finally implemented them into our app using the SwiftUI framework. My friend Lukas created our backend working with Firebase to update our user and event data. In addition, I created all documentation, the legal documents, the support website and this project report.
📼 App presentation
Darkmode version incl. onboarding process
Creation Process
🖌 Design Process
With DAISY the creation and development of on iOS app was the central task/learning we wanted to achieve. We agreed on a simple-to-follow design process, which I created using Figma (see below). The bluish part is a linear process and after that we switched into a circular one to iterate as long as needed to achieve the best result.
🔍 Identify problems
We started with identifying problems e.g., our friends had been using other networking apps like „spontacts“ or „bumble“. Then we combined all information gained into a user journey map which we created using Google’s Jamboard.
Our first name idea for the app was „Meet Me“ but later we figured out that there was already an app which has offered a similar aim with this name. So we came up with the new name DAISY and different in-app names such as „Marketplace“ instead of „Meet Me Market“
🧠 Brainstorm
After the creation of our user journey, I started to ideate different sketches on paper. The important part was to figure out how screens are connected and which menu buttons were needed on each part of the app. This was very important to organize for the general structure of our app.
🖌 Design
After I had finished the sketches, I started designing the app screen in the design and prototyping tool Figma. There I could start with the exact screen size of different devices. As the main size I used the iPhone X/XS/11 Pro resolution because it had the most users at that time and scaling up the screens for the iPhone XR/11 was possible in later iterations.
🔨 Build
After a first version of the general design was created with Figma I could start with the transition into real code. Consequently, I used a Figma plugin called SwiftUIinspector which can help to transfer complex color schematics such as angular or radial gradients. In general, the use of SwiftUI as a very new framework from Apple introduced in 2019 was a good choice even though sometimes I had to go back to classic UIKit code for more design options. SwiftUI is especially useful because it has a similar workflow to the design process itself by describing how everything looks exactly with the use of modifiers. Another handy feature of working with SwiftUI is the live preview on the right side of the code, so design changes can immediately be seen.
The app should follow the MVVM architecture hence we prepared the screens and our interface variables before implementing them in a Jamboard.
🧪 Test
We started with a self-test - we locally installed the app on our phones to test out new features. We could then test the new implementations of each other and regarding the usability I could easily gather direct feedback from Lukas when he could not figure out how I created the user journey.
After the direct personal tests, we did external testing with our friends and family. We used the Apple platform TestFlight for this task because we could easily send invitation to our friends, they could install the app on their device and give us feedback via a screenshot service provided by TestFlight. This was very helpful because we also recognized any app crashes.
After several iterations of TestFlight testing we finally submitted our app to the AppStore. We needed to fix a few things as well to get the approval from Apple’s AppStore to make our app public available.
Then the last test was accomplished by class representatives at our university because we only wanted to release our app at our university to test the concept in general.
🤔 Evaluate
After receiving feedback via TestFlight or directly, we listed everything in a Google Sheet to prioritize aspects and address them in an organized order.
Project management is crucial when dealing with such a project. Many files, lines of code and methods are created - so it is very important to keep everything organized and assign the right tasks to the right person. We dealt with this mainly via a so called Kanban-Board on which you can put little kanbans (Japanese for sticky note) with the tasks. On our digital board we had several „buckets“ to collect every task we gathered. When somebody had finished his task the kanban was moved into the „Done“ section. When problems occurred we could place them in a separate bucket to discuss them in our next call/meeting and help each other out. Milestones (very big task) were placed into another bucket to break them later into pieces.
Chat
DAISY offers the user a chat functionality when matched on an event with another person. Compared to the rest of the app where the user normally taps on a button and a new/updated view is shown the chat is different due to live updates on both sides and different options on each device (message as sender or receiver, deleting and blocking other user). We brainstormed on how to best implement the desired functionality and the structure in our noSQL database „Firestore“ from Firebase.
Security Issue / PushNotifications
We had a difficult time implementing proper push notifications. What sounds very basic, was a trick thing to do, because we tried to use a client-based sending technique to avoid creating expensive server functions. When a user liked one of the events he/she triggered the push-notification service to send a message directly with the notification-token from the other person which was downloaded onto the device. The security problem was that with a man-in-the-middle attack one could get the notification-token of the other person and send via a http-POST another self-written message at any time. We fixed this issue by creating a server-based system which sends notifications with a database-trigger - e.g., one user likes an event of another user then the „like“ for the event is saved in the database collection of the event. This triggers a server-side function to send a push notification to the notification-token that is saved in the database.
