CERTIFICATE

I, Ms. Khushi Kumari Singh, Roll No. 03911104425, certify that the Project Report (MCA-
170) entitled “Glass Cast” is done by me and it is an authentic work carried out by me at
Banarsidas Chandiwala Institute of Information Technology. The matter embodied in this
project work has not been submitted earlier for the award of any degree or diploma to the best
of my knowledge and belief.

Signature of the Student

Date:

Certified that the Project Report (MCA-170) entitled ”Glass Cast” done by Khushi Kumari
Singh, Roll No. 03911104425, is completed under my guidance.

Countersigned Signature of the Guide

Director Date:

Dr. Shobha Chawla

(Professor)
 ACKNOWLEDGEMENT

Perseverance, inspiration & motivation have always played a key role in the success of any
venture. A successful & satisfactory completion of any dissertation is the outcome of invaluable
aggregate contribution of different personal fully in radial direction. Whereas vast, varied &
valuable reading efforts lead to substantial acquisition of knowledge via books & allied
information sources; true expertise is gained from practical work & experience. I have a feeling
of satisfaction and relief after completing this project with the help and support from many
people, and it is my duty to express sincere gratitude towards them.

I am extremely thankful to faculty name “Ms. Shobha Chawla” for her help, encouragement and
advice during all stages in the development of this project. He helped to understand the things
conceptually. Without his help I would not been able to get the things in such a small period. I
am also thankful to all faculty members for their continuous support & valuable suggestions in
our project. The matter embodied in this project work has not been submitted earlier for award
of any degree or diploma to the best of my knowledge and belief.

(Signature)

Student Name: Khushi Kumari Singh

Roll No.: 03911104425

 SYNOPSIS

The weather forecasting industry has experienced a major digital transformation, evolving from
traditional television reports and static forecasts to real-time, mobilebased weather applications.
Modern users demand speed, accuracy, personalization, and easy access to environmental
information. The Weather Forecasting iOS App is a comprehensive mobile application
developed using Swift, SwiftUI, and Supabase to bridge the gap between current user
expectations and the limitations of conventional weather information systems.

Problem Definition

Existing weather forecasting systems at the small-to-medium scale suffer from inaccurate or
delayed updates, complex user interfaces, limited personalization, security concerns in user
authentication, poor mobile optimisation, and the absence of intelligent assistance. Users often
need to switch between multiple platforms to check weather conditions, air quality, humidity,
and future forecasts, leading to inconvenience, confusion, and a fragmented user experience.

Objectives and Scope

The Weather Forecasting iOS App is built to: (i) implement secure and seamless authentication
via Supabase; (ii) provide city-based weather search with personalized saved locations; (iii)
deliver real-time weather updates including temperature, humidity, and AQI through live API
integration; (iv) display accurate 7-day weather forecasts for better planning; (v) provide AI-
powered assistance for weather-related guidance and recommendations; and (vi) deliver a
smooth, modern, and responsive mobile interface using SwiftUI. The scope covers mobile
application development, backend integration, database management, API integration, and AI-
powered feature implementation.

Methodology and Technology Stack

The Agile Software Development Methodology is followed for iterative development. The
technology stack is:
 Frontend: Swift, SwiftUI
Backend: Supabase
Database: PostgreSQL (via Supabase Database)
Authentication: Supabase Auth (JWT-based identity management)
APIs: Weather API and AQI API for real-time forecast data
AI Integration: AI Assistant API for smart weather guidance
Architecture: Native iOS Application with RESTful API integration and cloud-based
backend services

Volume of Work

The project encompasses six functional modules: Authentication and Security, City Search and
Management, Real-Time Weather Monitoring, Forecast Analysis, AI Assistant Support, and
User Dashboard. The backend integrates multiple REST API services for weather data, air
quality updates, authentication, and cloud database operations. The database schema includes
three main tables: Users, Saved Cities, and User Preferences. The frontend consists of multiple
SwiftUI screens and reusable components. The system implements real-time weather fetching,
7-day forecast display, AQI monitoring, secure authentication handling, personalized city
management, and AI-powered weather guidance.

Limitations

The currentversion lacks a hotel owner admin panel, AI-based recommendation engine,
dynamic pricing logic, multi-language support, and a native mobile application.

Future Directions

Planned enhancements include an advanced AI recommendation engine, severe weather alert

notifications, interactive radar and map integration, voice-enabled AI assistant support, user
feedback and weather reporting system, OTP verification, multi-language support, Android
version development, Apple Watch integration, and a real-time analytics dashboard for
monitoring user activity and weather trends.
 TABLE OF CONTENTS

[Link]. Topic Page No

1. Certificate

2. Acknowledgement

3. Synopsis / Executive Summary

4. Chapter-1: Introduction

1. Existing System Overview

1.1 Industry Background

1.2 Problems in Existing System

1.3 Need of New System

1.4 Objectives of Project

1.5 Scope of Project

1.6 Methodology Adopted

1.7 Data Required and Data Collection Method

5. Chapter-2: System Analysis of existing System

2. Existing System Limitations

2.1 Proposed System Advantages

2.2 Feasibility Study

2.21 Technical Feasibility

2.22 Economic Feasibility

2.23 Operational Feasibility

2.24 Legal Feasibility

Chapter-3: System requirement analysis

3.1 Functional Requirements

3.2 Non- Functional Requirements

6. Chapter-4: System Design

 4. System Architecture

4.1 Workflow Diagram

4.2 DFD Level 0

4.3 DFD Level 1

4.4 ER Diagram

4.5 Use Case Diagram

4.6 Database and File Design

4.7 Data Dictionary

4.8 Input Design

4.9 Output Design

4.10 Interface Design

7. Chapter-5: System Development

5. Frontend Development

5.1 Backend Development

5.2 API Design

5.3 Database Integration

5.4 Authentication Implementation

5.5 Stripe Payment Integration

5.6 Folder Structure

5.7 Sample Code Snippets

8. Chapter-6: Systems Testing

9. Chapter-7: Systems Implementation

7.1 Hardware Requirements

7.2 Software Requirements

7.3 Deployment Process

7.4 Installation Steps

7.5 Conversion Method

7.6 Training Needs

7.7 Operation Manual

7.8 User Manual

10. Summary/Conclusion

11. Limitations Of the Project

12. Future Directions

13. References
 LIST OF TABLES

S. No. Topic Page No.

1. Comparison of Existing vs Proposed System

2. Functional Requirements

3. Non-Functional Requirements

4. CityWeather Table – Database Field Design

5. WeatherSnapshot / SavedCity Table – Field Design

6. User Collection – Database Field Design (WeatherWise)

7. Data Dictionary

8. API Endpoints

9. Test Cases – Authentication Module

10. TestCases – weather data retrieval Module

11. Error Log and Rectification

12. Hardware Requirements

13. Software Requirements

 LIST OF FIGURES

S. No. Topic Page No.

1. Workflow Diagram

2. DFD Level 0 (Context Diagram)

3. DFD Level 1

4. Entity-Relationship (ER) Diagram

5. Use Case Diagram

 Chapter-1

INTRODUCTION

1. Existing System Overview

The global weather services and forecasting industry plays a critical role in sectors such as
agriculture, transportation, tourism, disaster management, and daily life planning. Weather
information systems have evolved from traditional television and radio broadcasts in the early
twentieth century, to computer-based meteorological systems in the late twentieth century, and
now to mobile applications that provide real-time forecasts directly to users. With the growth of
smartphones and cloud computing, users increasingly expect fast, personalized, and intelligent
weather solutions. Despite the availability of many weather platforms, several small-to-medium
scale applications still suffer from cluttered interfaces, inaccurate personalization, limited
forecasting features, and weak backend integration. The proposed AI Powered Weather
Forecasting iOS Application aims to address these shortcomings by delivering a clean user
experience, secure authentication, real-time weather insights, and AI-assisted user interaction.

1.1 Industry Background

Billions of weather datarequests are processed digitally every year worldwide through mobile
applications, websites, and smart devices. Major forecasting platforms rely on cloud-based
distributed systems capable of serving millions of concurrent users with realtime updates.
However, the engineering principles behind these large-scale systems are rarely implemented in
smaller or academic-grade weather applications. Modern iOS development technologies such as
Swift and SwiftUI have emerged as industry-standard choices for building fast, scalable, and
user-friendly mobile applications. SwiftUI’s declarative and component-based architecture has
redefined expectations for mobile interface performance, responsiveness, and seamless user
experience. Combined with backend platforms like Supabase, these technologies enable secure
authentication, real- time database integration, and scalable cloud connectivity for intelligent
weather forecasting solutions.

1.2 Problems in Existing System

Despite technological advancements, the following critical problems persist in existing hotel
booking systems at the small-to-medium scale:

• Delayed or Inaccurate Weather Updates: Without real-time API synchronization, users may
receive outdated forecasts, temperature values, or AQI data, reducing trust in the application.
• Fragmented User Experience: Users often need multiple apps or websites to check weather,
air quality, forecasts, and travel suggestions, causing inconvenience and wasted time.

• High User Drop-off Rates: Lengthy registration forms, poor onboarding design, or lack of
simple email/social login options can increase bounce rates and reduce retention.

• Weak Data Security: Poor authentication implementation may expose user accounts, saved
preferences, or personal data to unauthorized access.

• Poor App Performance: Inefficient architecture or repeated screen reloads can slow
navigation, especially when fetching weather data on weak mobile networks.
• Limited Mobile Optimisation: Non-responsive layouts, cluttered dashboards, or poorly
designed interfaces reduce usability on iPhones and smaller devices.

• Lack of Personalisation: Absence of saved cities, recent searches, smart alerts, or AI-based
recommendations makes the weather discovery process repetitive and less engaging.

• No Intelligent Assistance: Many standard weather apps only display raw data without helping
users interpret conditions such as rain risk, pollution safety, or clothing recommendations

1.3 Need of New System

The identified problems establish a clear need for a purpose-built, modern weather forecasting
platform. Specifically:

A real-time weather synchronisation mechanism is required to fetch updated forecasts,

AQI, humidity, and temperature instantly, ensuring users receive accurate and current data.
A unified platform integrating weather insights, weekly forecasts, and AI assistance
eliminates the need to switch between multiple apps or websites.
A frictionless authentication system using secure email-based login and backend
authentication (Supabase Auth) reduces user drop-off rates and simplifies account
management.
Secure cloud-based data handling ensures safe storage of user accounts, saved cities, and
preferences without exposing sensitive information.
A SwiftUI-based application architecture provides smooth navigation, fast rendering, and
an app-like premium experience without unnecessary reloads or delays.
A responsive mobile-first interface ensures equal quality of experience across different
iPhone models and screen sizes.
A personalization engine allowing saved cities, recent searches, and custom dashboards
improves convenience and user retention.
An AI-powered assistant helps users understand weather conditions, pollution risks, travel
suitability, and daily planning rather than only displaying raw numbers.

1.4 Objectives of Project

The primary objectives ofthe AI Powered Weather Forecasting iOS Application are as follows:

To implement a secure and frictionless authentication system using Supabase, supporting

email-based sign up and login.
To create an intuitive city search feature allowing users to find and add multiple cities to
their personalized home dashboard.
To develop backend synchronisation logic that fetches real-time weather data including
temperature, humidity, AQI, and forecast updates.
To provide accurate next-week weather forecasting for selected cities, helping users plan
activities and travel efficiently.
 To integrate an AI Assistant capable of answering weather-related queries and providing
smart recommendations.
To deliver a modern, responsive, and mobile-first interface using SwiftUI across different
iPhone screen sizes.
To provide users with a personalized weather dashboard displaying saved cities, current
conditions, and future forecasts in one place.
To ensure secure cloud storage of user preferences, selected cities, and account data using
Supabase backend services.

1.5 Scope of Project

1.51 User-Centric Functionality

The system provides unified authentication and profile management. Users sign up, log in,
manage sessions, update profiles, save cities, search locations, and view realtime weather
including temperature, humidity, AQI, and weekly forecasts instantly.

1.52 Booking and Transactional Logic

The backend weather engine validates real-time forecast availability before display proceeds.
The API response lifecycle ensures database updates occur reliably even if the user closes the
application during weather synchronisation requests.

1.53 Technical and Performance Scope

The project encompasses full-stack development including SwiftUI-based interface design,

Supabase-backed REST API integration, structured PostgreSQL schema for Users and
SavedCities tables, and a mobile-first layout architecture for displaying AQI, humidity,
temperature, and weekly weather forecasts.

1.6 Methodology Adopted

Glass Cast is developed following the Agile Software Development Methodology, chosen for its
iterative, incremental approach that accommodates evolving requirements and enables
continuous testing. The development is structured into seven phases:
Phase 1 – Requirements Gathering: User needs identification, problem definition, and
selection of weather, AI, and backend services.
Phase 2 – System Design: Architecture diagrams, data flow diagrams, use case diagrams,
API contract design, and Supabase schema definition.
Phase 3 – Sprint 1 (Foundation): Xcode project scaffolding, SwiftUI setup, Supabase
configuration, database connection, and authentication integration.
 Phase 4 – Sprint 2 (Core Features): City management flows, weather API integration, home
dashboard with AQI and humidity, and weekly forecast presentation.
Phase 5 – Sprint 3 (AI and Polish): AI assistant integration, conversational UI refinement,
interface polish, and responsive layout testing across devices.
Phase 6 – Testing and Debugging: Unit, integration, system, and validation testing of
authentication, city storage, and weather retrieval.
Phase 7 – Documentation: Complete project report preparation in the prescribed
institutional format and compilation of technical references.

1.7 Data Required and Data Collection Method

The following data categories are required for WeatherWise’s operation:

City Weather Data: City name, country, coordinates, current conditions, temperature,
humidity, AQI, and 7‑day forecast values. This data is fetched from a weather API and
cached in the app or Supabase tables as needed.
User Data: Identity information (name, email, optional avatar) managed by Supabase Auth.
Only the Supabase-generated unique user ID is used to associate saved cities and
preferences.
Preference Data: Saved city identifiers, display order, temperature unit selection,
notification settings, and AI assistant context, linked to each authenticated user profile.
Analytics Data: Non-sensitive interaction details such as last refreshed time, most viewed
cities, and recent assistant queries used for improving experience and performance.
Data collection methods: (i) secure API responses from third‑party weather services; (ii)
real-time form input from users while searching and saving cities; (iii) authenticated
requests and responses between the iOS app and Supabase for persisting user preferences.
 Chapter-2

SYSTEM ANALYSIS OF EXISTING SYSTEM

2. Existing System Limitations

A thorough analysis of existingweather forecasting applications at the small-tomedium scale

reveals the following critical limitations:

Absence of Personalised City Management: Many apps provide generic weather search
only, without persistent, user-specific lists of favourite locations on a central home screen.
Limited Contextual Interpretation: Applications often display raw temperature, humidity,
and AQI values without intelligible explanations, making it hard for users to understand
practical implications for daily activities.
Insecure or Basic Authentication: Weak or ad‑hoc login systems may store credentials
insecurely, increasing the risk of data exposure and unauthorised account access.
No Integrated Intelligent Assistance: Weather apps typically work in isolation from AI-
based guidance, forcing users to interpret conditions themselves or consult multiple
external sources.
Poor Mobile Experience: Cluttered, advertisement-heavy layouts and nonadaptive designs
render poorly on smaller screens and degrade usability on different iPhone models.
Manual or Inconsistent Updates: Lack of structured refresh logic or background updates can
cause stale data, forcing users to repeatedly refresh and increasing the chance of outdated
information

2.1 Proposed System Advantages

GlassCast addresses each identified limitation. The comparison table below summarises the key
differences:
 Criterion Existing System Proposed

Singleapp, SwiftUIbased
Architecture Multiscreen, adheavy layouts
architecture

Supabase Auth with secure

Basic or custom email login with weak
Authentication token‑based sessions, no plaintext
security
password storage

Structured refresh logic to avoid

Over‑refresh No control over redundant API calls or
stale data and minimise
Prevention outdated cached data
unnecessary requests
 Supabase‑backed integration
Direct weather API calls from the client
API Usage centralising user preferences and
without structured backend
weather access

Not optimised for smaller devices or Mobile‑first SwiftUI layouts that

Mobile Support
different iPhone sizes adapt to various iOS screen sizes

Basic city search with limited filtering or Multi‑parameter search based on

Search
personalisation city and user‑managed favourites

Integrated AI assistant offering

No AI‑based help; users must interpret
Intelligent Assistance contextual explanations and
values alone
suggestions

Planned support for configurable

No clear, consistent reminders for
Notification / Alerting alerts about major weather and AQI
important weather changes
changes

Fast rendering with efficient state

Slow, with frequent full view rebuilds and
Page Load Speed management and asynchronous
blocking network calls
networking

Table No-1: Comparison of Existing vs Proposed System

2.2 Feasibility Study

A feasibility study was conducted across four dimensions:

2.21 Technical Feasibility

The weather forecasting application is built using modern, industry-standard technologies. Swift
and SwiftUI are widely adopted for iOS development, offering strong performance and
community support. Supabase simplifies backend management including authentication and
database handling. Weather APIs provide reliable real-time data integration. Xcode ensures
efficient development and testing. The overall technology stack is compatible with Apple
ecosystem devices and cloud services. Technical feasibility is highly favorable for scalable and
efficient mobile application development.

2.22 Economic Feasibility

All core technologies (Swift, SwiftUI, Supabase, Xcode, Weather APIs) are free or provide
generous free tiers, resulting in minimal development cost. Supabase offers a free tier
supporting authentication and database usage. Weather APIs provide limited free access for real-
time data. Apple tools require no extra licensing. Deployment and testing can be done on
simulators or devices. Economic feasibility is excellent for scalable iOS application
development.

2.23 Operational Feasibility

The weather forecasting application is designed with maximum usability as a core principle.
Users can securely log in using email authentication via Supabase, avoiding complex processes.
The application is fully optimized for iOS devices. All weather data retrieval, updates, and
dashboard management are automated, requiring minimal user effort. Operational feasibility is
very high.

2.24 Legal Feasibility

User data management is handled by Supabase, ensuring secure authentication and database
storage without exposing sensitive information. The application follows standard data
protection practices and secure API communication protocols. All technologies used are based
on widely accepted platforms and open-source tools where applicable. No intellectual property
rights are violated. Legal feasibility is confirmed for this weather forecasting application.
 Chapter-3

SYSTEM REQUIREMENT ANALYSIS

3.1 Functional Requirements

The following table enumerates the functional requirements of GlassCast:

Table No-2: Functional Requirements

3.2 Non-Functional Requirements

Non-functional requirements define quality attributes the system must exhibit:

Table No-3: Non-Functional Requirements

 Chapter-4

SYSTEM DESIGN

4. System Architecture

The weather forecasting application adopts a structured architecture separating the presentation
layer (SwiftUI), the application logic layer (Swift), and the data layer (Supabase). All
components communicate through API-based data exchange over secure protocols, enabling
independent scalability, efficient performance, and easy maintenance of the overall system.

Figure No-1: System Architecture Diagram (MERN Stack)

4.1 Workflow Diagram

The workflow diagram below illustrates the end-to-end user journey from landing on the
homepage to receiving a booking confirmation email:

Figure No-2: Workflow Diagram

4.2 DFD Level 0 (Context Diagram)

The Context Diagram represents the system as a single process showing all external entities and
data flows:

Figure No-3: DFD Level 0 – Context Diagram

4.3 DFD Level 1

Figure No-4: DFD Level 1

4.4 ER Diagram

The ER Diagram shows three primary entities and their relationships. User has a oneto-many
relationship with Booking; Hotel has a one-to-many relationship with Booking:

Figure No-5: Entity-Relationship (ER) Diagram

4.5 Use Case Diagram

The Use Case Diagram identifies actors and operations they can perform in the QuickStay system:

Figure No-6: Use Case Diagram

4.7 Database and File Design

WeatherApp uses Supabase backend cloud-hosted. The database stores Users authentication and
saved cities with weather data AI.

4.71 CityWeather Table – Database Field Design

Table No-4: CityWeather Table – Database Field Design

4.72 SavedCity Table – Field Design

Table No-5: WeatherSnapshot / SavedCity Table – Field Design

4.73 User Collection – Field Design

Table No-6: User Collection – Database Field Design (WeatherWise)

4.8 Data Dictionary

The Data Dictionary lists all data elements across all collections in alphabetical order:
Table No-7: Data Dictionary
4.9 Input Design

Input design ensures data entering the system is accurate, complete, and validated at both client
and server levels:

• Weather Search Form: City (text required), search triggers API call, login session verified, city
must be valid, client side validation ensures correct input before Supabase request execution
completed successfully now.

• Home Page: Selected cities displayed, temperature humidity AQI shown, user can add or
remove cities, data synced via Supabase database updates in real time system.

• Authentication handled by Supabase, user login signup secure, AI assistant provides weather
insights and forecasts using backend data processing layer.

4.10 Output Design

Output design defines information presented to users as a result of system operations:

• Weather Home Results: Card-based grid showing city name, temperature, AQI, humidity,
weather icon, and an Add City button. Rendered by WeatherCard SwiftUI component.

• City Selection Confirmation Screen: City Name, Selected Status, Current Temperature, AQI
Level, Humidity Value, and View Dashboard button.

• My Cities Dashboard: All saved cities with City Name, Temperature, Humidity, AQI, and
Forecast Status badge (good moderate poor).

• Email Notification Summary: HTML formatted weather report with City Name, Temperature,
AQI, Humidity, Weekly Forecast, delivered via email and in-app notification.

4.11 Interface Design

WeatherApp follows a minimal modern interface with consistent colour palette (blue primary,
white background, green highlights) theme system.

The fixed tab bar provides access Home Saved Cities AI Assistant Profile/Auth.

A hamburger menu hides navigation on smaller screens. All interactive elements support touch
feedback and accessibility states properly
 Chapter - 5

SYSTEM DEVELOPMENT

5 Frontend Development

SwiftUI Navigation Stack manages client-side screen routing. Authenticated routes such as
SavedCities and AI Assistant are protected using Supabase authentication, redirecting
unauthenticated users to sign in screen.

SwiftUI styling enables clean UI development with reusable components instead of external
CSS frameworks. Its adaptive layout approach ensures views adjust across different iOS screen
sizes with responsive modifiers. Global state such as selected cities, user session, and
preferences is managed via ObservableObject and EnvironmentObject in SwiftUI. The
WeatherApp frontend is built using Swift and SwiftUI, powered by Supabase backend for
authentication, data storage, and real-time updates. SwiftUI's component based architecture
decomposes interface into small reusable views and modifiers. The application is organised
around screens and reusable components. Screens include Home SavedCities Search AI
Assistant and Profile views connected through navigation [Link] components include
WeatherCard CityCard SearchBar ForecastCard and AIChat components composed within
screens.

All modules are integrated seamlessly across the app production ready.

5.1 Backend Development

The backend is built using Supabase, providing a managed backend-as-a-service instead of a

custom [Link] server. Supabase is built on PostgreSQL and exposes RESTful APIs
automatically through PostgREST, handling data access, authentication, and real-time updates.
Supabase Auth manages user signup and login using email-based authentication, while Row
Level Security (RLS) policies ensure users can only access their own saved cities and profile
data.

The SwiftUI application communicates with Supabase using its official SDK for authentication,
database queries, and real-time subscriptions. Instead of a traditional [Link] server and
MVC structure, business logic is split between Supabase database rules and optional Edge
Functions used for AI assistant responses and external weather API calls. All API interactions
are secured over HTTPS, and data validation is enforced at both the client level (SwiftUI) and
server level (Supabase policies and schema constraints).
5.2 API Design

The WeatherApp backend uses Supabase API system architecture. GET fetch weather data
POST save cities PUT update DELETE remove records. All data uses JSON. Private endpoints
require valid Supabase JWT in authorization header verified by auth middleware before
accessing protected routes layer.
Table No-8: API Endpoints

5.3 Database Integration

Supabase is used as the backend database service system platform. The Supabase connection is
established using environment variables and configuration keys securely. Supabase tables Users,
Cities, and Preferences are defined with schema constraints ensuring required fields types and
defaults values. The Weather schema includes client side and server logic that computes weekly
forecast summaries using temperature and AQI data.

5.4 Authentication Implementation

Authentication is handled by Supabase Auth. On the frontend, the SupabaseProvider wraps the
entire SwiftUI application in App entry point. The useAuth() and session state provide access to
the current user object and authentication status throughout the view hierarchy.
On the backend, Supabase Auth verifies JWT tokens extracted from request headers
automatically. If valid, the decoded user ID is attached to the request context. If invalid or
missing on protected routes, a 401 Unauthorized response is returned. On first login, the
frontend calls Supabase signUp or signIn to create a user profile using Supabase user metadata.

5.5 Stripe Payment Integration

WeatherApp integration followsa Supabase-driven authentication and data synchronization

pattern for secure user experience compliance:

Step 1 – Session Creation: Frontend initiates sign-in request to Supabase auth with emailId.
Supabase validates credentials and returns JWT session token with user metadata.

Step 2 – Redirect to Home: Frontend receives authenticated session and redirects user to Home
dashboard displaying saved cities and weather data.

Step 3 – Data Sync: Supabase realtime API sends updates when user adds or removes cities.
Backend AI processing verifies requests and returns weather insights using AI assistant module.

Step 4 – Notification Delivery: sendNotification utility generates weather summary and delivers
email via SMTP integration.

All communication between frontend and Supabase is secured via HTTPS, with validation
performed at client side using SwiftUI and server policies enforced strictly layer.

5.6 Sample Code Snippets

GlassCastApp

//

// [Link]

// GlassCast

//

//

import SwiftUI

@main
struct GlassCastApp: App {

var body: some Scene {

WindowGroup {

RootView()

}
RootView

import SwiftUI

struct RootView: View {

@StateObject private var sessionStore = SessionStore()

var body: some View {

Group {

if [Link] {

ProgressView()

.controlSize(.large)

} else if [Link] == nil {

AuthView(sessionStore: sessionStore)

} else {
MainTabView(sessionStore: sessionStore)

.task {

await [Link]()

}
import SwiftUI

struct AuthView: View {

@ObservedObject var sessionStore: SessionStore

@State private var isLogin = true

@State private var email = ""

@State private var password = ""
@State private var isWorking = false

@State private var errorMessage: String?

var body: some View {

ZStack {

LinearGradient(

colors: [

Color(red: 0.06, green: 0.06, blue: 0.12),

Color(red: 0.12, green: 0.14, blue: 0.28),

Color(red: 0.06, green: 0.06, blue: 0.12)

],

startPoint: .topLeading,

endPoint: .bottomTrailing

.ignoresSafeArea()

VStack(spacing: 0) {

Spacer()

VStack(spacing: [Link]) {

VStack(spacing: [Link]) {

Image(systemName: "[Link]")

.font(.system(size: 56, weight: .medium))

.foregroundStyle([Link])

.symbolRenderingMode(.hierarchical)
Text("GlassCast")

.font(.system(size: 38, weight: .bold, design: .rounded))

.foregroundStyle(.white)

Text(isLogin ? "Welcome back" : "Create your account")

.font(.system(size: 16, weight: .medium))

.foregroundStyle(.[Link](0.6))

.padding(.bottom, [Link])

VStack(spacing: [Link]) {

VStack(spacing: [Link]) {

Text("Email")

.font(.system(size: 13, weight: .semibold))

.foregroundStyle(.[Link](0.7))

.frame(maxWidth: .infinity, alignment: .leading)

TextField("", text: $email, prompt:

Text("you@[Link]").foregroundStyle(.[Link](0.35)))

.textInputAutocapitalization(.never)

.keyboardType(.emailAddress)

.textContentType(.emailAddress)

.foregroundStyle(.white)

.padding(.vertical, 14)

.padding(.horizontal, 16)

.background([Link](0.08))
 .clipShape(RoundedRectangle(cornerRadius: [Link], style:
.continuous))

.overlay {

RoundedRectangle(cornerRadius: [Link], style:

.continuous)
 .strokeBorder([Link](0.12), lineWidth: 1)

VStack(spacing: [Link]) {

Text("Password")

.font(.system(size: 13, weight: .semibold))

.foregroundStyle(.[Link](0.7))

.frame(maxWidth: .infinity, alignment: .leading)

SecureField("", text: $password, prompt:

Text("••••••••").foregroundStyle(.[Link](0.35)))

.textContentType(.password)

.foregroundStyle(.white)

.padding(.vertical, 14)

.padding(.horizontal, 16)

.background([Link](0.08))

.clipShape(RoundedRectangle(cornerRadius: [Link], style:

.continuous))

.overlay {

RoundedRectangle(cornerRadius: [Link], style:

.continuous)

.strokeBorder([Link](0.12), lineWidth: 1)

if let errorMessage {
HStack(spacing: 8) {

Image(systemName: "[Link]")

.font(.system(size: 14))

Text(errorMessage)

.font(.system(size: 13, weight: .medium))

.foregroundStyle(Color(red: 1.0, green: 0.45, blue: 0.45))

.frame(maxWidth: .infinity, alignment: .leading)

.transition(.[Link](with: .move(edge: .top)))

 }

VStack(spacing: [Link]) {

Button {

Task { await submit() }

[Link]()

} label: {

HStack(spacing: 10) {

if isWorking {

ProgressView()

.tint(.black)

} else {

Text(isLogin ? "Sign In" : "Create Account")

.font(.system(size: 17, weight: .semibold))

.foregroundStyle(.black)

.frame(maxWidth: .infinity)

.padding(.vertical, 16)

.background([Link])

.clipShape(RoundedRectangle(cornerRadius: [Link], style:

.continuous))

.buttonStyle(PressScaleButtonStyle())
.disabled(isWorking)

Button {

withAnimation(.spring(response: 0.4, dampingFraction: 0.85)) {

[Link]()

errorMessage = nil

[Link]()

} label: {

HStack(spacing: 4) {
 Text(isLogin ? "Don't have an account?" : "Already have an account?")

.foregroundStyle(.[Link](0.6))

Text(isLogin ? "Sign up" : "Sign in")

.foregroundStyle([Link])

.fontWeight(.semibold)

.font(.system(size: 14))

.padding([Link])

.background(.[Link](0.5))

.background([Link](0.04))

.clipShape(RoundedRectangle(cornerRadius: [Link], style:

.continuous))

.overlay {

RoundedRectangle(cornerRadius: [Link], style: .continuous)

.strokeBorder([Link](0.1), lineWidth: 1)

.padding(.horizontal, [Link])

Spacer()

Text("Your weather, beautifully.")

.font(.system(size: 13, weight: .medium))

 .foregroundStyle(.[Link](0.4))

.padding(.bottom, [Link])

private func submit() async {

guard .isEmpty else {

errorMessage = "Email is required."

return

guard [Link] >= 6 else {

errorMessage = "Password must be at least 6 characters."

return

isWorking = true

errorMessage = nil

defer { isWorking = false }

do {

if isLogin {

try await [Link](email: email, password: password)

} else {

try await [Link](email: email, password: password)

} catch {
 errorMessage = String(describing: error)

}
MainTabView

import SwiftUI

struct MainTabView: View {

@ObservedObject var sessionStore: SessionStore

@StateObject private var favoritesViewModel = FavoritesViewModel()

@AppStorage("selected_city_id") private var selectedCityIdRawValue: String = ""

private enum Screen: CaseIterable {

case home

case cities

case settings

var title: String {

switch self {

case .home: return "Home"

case .cities: return "Cities"

case .settings: return "Settings"

var icon: String {

switch self {

case .home: return "[Link]"

case .cities: return "[Link]"

case .settings: return "[Link]"

}
 }

}
@State private var isMenuOpen = false

@State private var screen: Screen = .home

private let menuWidth: CGFloat = 280

var body: some View {

ZStack(alignment: .leading) {

content

.frame(maxWidth: .infinity, maxHeight: .infinity)

.offset(x: isMenuOpen ? menuWidth : 0)

.scaleEffect(isMenuOpen ? 0.92 : 1, anchor: .trailing)

.overlay {

if isMenuOpen {

[Link](0.4)

.ignoresSafeArea()

.onTapGesture { closeMenu() }

.disabled(isMenuOpen)

sideMenu

.frame(width: menuWidth)

.offset(x: isMenuOpen ? 0 : -menuWidth - 20)

.opacity(isMenuOpen ? 1 : 0)

.animation(.spring(response: 0.4, dampingFraction: 0.85), value: isMenuOpen)

}
@ViewBuilder

private var content: some View {

switch screen {

case .home:

HomeView(

favoritesViewModel: favoritesViewModel,

sessionStore: sessionStore,

selectedCityIdRawValue: $selectedCityIdRawValue,

onMenuTap: toggleMenu

case .cities:

CitySearchView(

favoritesViewModel: favoritesViewModel,

sessionStore: sessionStore,

selectedCityIdRawValue: $selectedCityIdRawValue,

onMenuTap: toggleMenu

case .settings:

SettingsView(sessionStore: sessionStore, onMenuTap: toggleMenu)

private var sideMenu: some View {

ZStack {

LinearGradient(

colors: [
 Color(red: 0.08, green: 0.08, blue: 0.12),

Color(red: 0.06, green: 0.06, blue: 0.10)

],
 startPoint: .top,

endPoint: .bottom

.ignoresSafeArea()

VStack(alignment: .leading, spacing: 0) {

// Header

VStack(alignment: .leading, spacing: [Link]) {

HStack(spacing: [Link]) {

Image(systemName: "[Link]")

.font(.system(size: 28))

.foregroundStyle([Link])

.symbolRenderingMode(.hierarchical)

Text("GlassCast")

.font(.system(size: 24, weight: .bold, design: .rounded))

.foregroundStyle(.white)

if let email = [Link]?.[Link] {

Text(email)

.font(.system(size: 13, weight: .medium))

.foregroundStyle(.[Link](0.5))

.lineLimit(1)

}
.padding(.top, [Link])

.padding(.horizontal, [Link])

.padding(.bottom, [Link])

// Navigation

VStack(alignment: .leading, spacing: [Link]) {

ForEach([Link], id: \.self) { item in

menuButton(item: item)

.padding(.horizontal, [Link])
 Spacer(minLength: 0)

// Footer

VStack(spacing: [Link]) {

Divider()

.overlay([Link](0.1))

Button {

Task { await [Link]() }

[Link]()

} label: {

HStack(spacing: [Link]) {

Image(systemName: "[Link]")

.font(.system(size: 16, weight: .medium))

Text("Sign Out")

.font(.system(size: 15, weight: .semibold))

Spacer()

.foregroundStyle(Color(red: 1.0, green: 0.45, blue: 0.45))

.padding(.vertical, 14)

.padding(.horizontal, 16)

.background(Color(red: 1.0, green: 0.45, blue: 0.45).opacity(0.12))

.clipShape(RoundedRectangle(cornerRadius: [Link], style:

.continuous))

}
 .buttonStyle(PressScaleButtonStyle())

.padding(.horizontal, [Link])

.padding(.bottom, [Link])

private func menuButton(item: Screen) -> some View {

let isActive = screen == item

return Button {

withAnimation(.spring(response: 0.35, dampingFraction: 0.88)) {

screen = item

isMenuOpen = false

[Link]()

} label: {

HStack(spacing: [Link]) {

Image(systemName: [Link])

.font(.system(size: 18, weight: .semibold))

.foregroundStyle(isActive ? [Link] : .[Link](0.7))

.frame(width: 28)

Text([Link])

.font(.system(size: 16, weight: .semibold))

.foregroundStyle(isActive ? .white : .[Link](0.7))

Spacer()

if isActive {

Circle()

.fill([Link])

.frame(width: 8, height: 8)

}
 .padding(.vertical, 14)

.padding(.horizontal, 16)

.background(isActive ? [Link](0.1) : [Link])

.clipShape(RoundedRectangle(cornerRadius: [Link], style: .continuous))

.buttonStyle(PressScaleButtonStyle())

private func toggleMenu() {

withAnimation(.spring(response: 0.4, dampingFraction: 0.85)) {

 [Link]()

[Link]()

private func closeMenu() {

withAnimation(.spring(response: 0.35, dampingFraction: 0.88)) {

isMenuOpen = false

SCREENSHOT:
 Chapter - 6

SYSTEM TESTING

6 Testing Strategy

System testing ensures the developed WeatherApp functions correctly, reliably, and securely
across all intended use cases. WeatherApp adopts a comprehensive testing strategy: UnitTesting,
Integration Testing, System Testing, and Validation Testing, following abottom-up approach that
begins with individual SwiftUI components and progressivelyintegrates Supabase services until
the complete application is validated. Test cases cover both positive scenarios (expected inputs
leading to expected outputs) and negative scenarios(invalid or edge-case inputs triggering error
handling responses). Supabase test environment provides simulated authentication and data
scenarios that mimic real weather updates without production impact.

6.1 Unit Testing

Unit testing was performed on individual SwiftUI views and Supabase logic in isolation layer
testing. Each Supabase table was tested with valid and invalid data to verify schema constraints
required fields and default values assignment logic. Backend functions were tested using
mocked Supabase responses and in-memory data sets. On the frontend individual SwiftUI
components WeatherCard CityCard and SearchBar were rendered in isolation and tested for
correct rendering state management behavior and event responses. The SearchBar date
validation logic was specifically tested with multiple edge cases including same day selection
past dates and empty fields inputs.

6.2 Integration Testing

Integration testing verified the SwiftUI frontend and Supabase backend work correctly together
via REST API. API endpoints were tested using Postman with valid Supabase JWT tokens,
invalid authentication headers, and various request body configurations. The city availability
endpoint was tested with multiple overlapping and non overlapping search scenarios. AI
integration was tested in test mode environment. Weather forecast sessions were created via the
API, completed using weather test responses, and resulting update events were forwarded to the
local SwiftUI application using Supabase realtime listeners verifying that user city weather
status updates correctly upon event receipt system confirmation complete.
6.3 System Testing

System testing evaluated the complete integrated WeatherApp as a whole simulating real world
user interactions from start to finish. Complete end to end user journeys were executed a new
user signs in via email authentication selects cities searches weather views AQI temperature
humidity forecasts uses AI assistant and checks updated dashboard in saved cities section
successfully verified. Concurrent city selection scenarios were simulated by opening two app
sessions simultaneously and attempting to add the same city for weather tracking. The duplicate
city prevention mechanism successfully blocked the second request confirming race condition
handling is functional system.

6.4 Validation Testing

Validation testing verified that input validation mechanisms correctly accept valid data and
reject invalid data at both client side (SwiftUI form validation) and server side (Supabase
request validation) logic.

6.5 Test Case Table

Authentication Module Test Cases:

Table No-9: Test Cases – Authentication Module
Weather data retrieval Test Cases:

Table No-10:TestCases – weather data retrieval Module

5.6 Errors Found and Rectification

The following tabledocumentssignificant errors encountered during testing and the corrective
actions taken:
Table No-11: Error Log and Rectification
Validation testing verified input validation in WeatherApp accepts valid data and rejects invalid
inputs at client SwiftUI and server Supabase levels, returning proper error messages without
crashing system behaviour was consistent. The system was also validated against original
functional requirements FR-01 through FR-10 in Chapter 2 confirming all requirements are
fully implemented and operational successfully verified.
 Chapter - 7

SYSTEM IMPLEMENTATION

7. Hardware Requirements

Table No-12: Hardware Requirements

7.1 Software Requirements

Table No-13: Software Requirements

7.2 Deployment Process

WeatherApp is deployed using a split architecture: the SwiftUI frontend is distributed via Apple
App Store andTestFlight builds platforms supported. Supabase is used as backend service.
Supabase provides database authentication realtime APIs and Apple infrastructure handles
global distribution and secure HTTPS connectivity for app. Environment configuration uses
Supabase API keys Apple developer credentials and secure environment variables managed
through platform dashboards never committed to source repository for security reasons.

7.3 Installation Steps

The following procedure describes the complete local development setup for GlassCast:

Step 1: Clone the repository:

git clone git clone [Link]

cd glasscast

Step 2: Install backend dependencies:

cd weatherapp

open [Link]

Step 3: Create backend .env file:

Add Supabase URL and anon key in configuration file securely.

Step 4: Create environment configuration file:

SUPABASE_URL=[Link]
SUPABASE_ANON_KEY=eyJXXXXXXXXXXXXXXXXXXXX
Step 5:

Install frontend dependencies:

Swift Package Manager automatically resolves

Supa base Swift SDK and required libraries.

Step 6:

Run the application:

Build and run project using Xcode simulator or physical iOS device.

Step 7:

Enable realtime updates:

Configure Supabase subscriptions for live weather and city updates.

Step 8:

Forward Stripe webhooks locally:

Verify email sign up login and session persistence using Supabase Auth system.

The Direct Changeover conversion method has been adopted for WeatherApp deployment.
Under this approach, the new system becomes available at a scheduled release while the
previous manual weather tracking approach is discontinued simultaneously.

Justification: Since WeatherApp is a newly developed mobile platform rather than a

replacement for an existing institutional system, there is no legacy database migration or
parallel operation required. The application starts with an initial empty user base and grows
organically as users sign up and save cities. The Direct Changeover method is suitable because
the system has been thoroughly tested using Supabase staging configurations and Xcode debug
environments before production release. A rollback option is available through previous build
versions and Supabase configuration restoration, reducing deployment risk significantly

7.5 Training Needs

7.5 Training Needs

End Users (iOS Users): No formal training required. The interface follows familiar mobile
weather app patterns, with clear labels, validation messages, and intuitive navigation. A
brief onboarding screen on first launch guides new users through key features such as
adding cities, viewing AQI, and using AI assistant.
System Administrator: Familiarity with Supabase Dashboard (database and authentication
management), Apple Developer Console (app distribution and certificates), and API
monitoring tools. A one-time orientation of approximately 2 to 3 hours is sufficient for
operational handling. The Direct Changeover conversion method has been adopted for
WeatherApp deployment. Under this approach, the new system becomes available at a
scheduled release while the previous manual weather tracking approach is discontinued
simultaneously.
Justification: Since WeatherApp is a newly developed mobile platform rather than a
replacement for an existing institutional system, there is no legacy database migration or
parallel operation required. The application starts with an initial empty user base and grows
organically as users sign up and save cities. The Direct Changeover method is suitable
because the system has been thoroughly tested using Supabase staging configurations and
Xcode debug environments before production release. A rollback option is available
through previous build versions and Supabase configuration restoration, reducing
deployment risk significantly.
Development Team (Maintenance): Proficiency in Swift, SwiftUI, and Supabase integration
is required. Familiarity with the codebase architecture documented in Chapter 4 is
necessary for updates, debugging, and feature enhancements across frontend and backend
layers.

7.6 Operation Manual

Starting the Application: Open the iOS project in Xcode and run it on simulator or device.
Ensure build succeeds and Supabase connection is active by checking authentication and initial
data load in console logs.

Monitoring Database: Access Supabase at [Link] Navigate to the project

database to view and query Users, Cities, and Preferences tables. Enable Supabase logs and
usage alerts for request limits and storage monitoring.
Monitoring Authentication: Access Supabase Auth section to view registered users, active
sessions, sign-in history, and manage account access or deletions for privacy compliance.

Managing Users: User accounts are managed through Supabase Auth dashboard where
administrators can view profiles, revoke sessions, and enforce security rules when required.

Handling Errors: Application errors are logged in Xcode console and Supabase logs. Common
errors such as authentication failure, invalid request, and network issues are handled using
structured error messages and fallback UI states.

Backup Procedure: Supabase provides automatic database backups depending on project plan.
Additional manual exports can be performed using SQL editor or data export tools for recovery
and archival purposes.

7.7 User Manual

Registering or Logging In: Open the WeatherApp and tap Sign In on the first screen. Register
using your email address or choose Continue with Apple or Google for instant authentication.
Upon first login, your profile is automatically created in Supabase.

Adding Cities: On the home screen, tap the search bar. Enter a city name and select it to add to
your saved cities list. The city is stored in Supabase and linked to your account.

Viewing Weather Details: Tap any saved city card to view full weather information including
temperature, AQI, humidity, weather icon, and weekly forecast summary with AI insights.

Using AI Assistant: Open AI Assistant tab and type questions like weather comparison or
forecast details. The system responds using integrated AI logic and Supabase weather data.

Receiving Updates: Weather data updates automatically in real time using Supabase
subscriptions. Any change reflects instantly on the home dashboard.

Viewing Saved Cities: Navigate to Saved Cities section to see all added locations with live
weather stats and quick access to detailed forecast screens.

Logging Out: Tap Profile tab and select Sign Out option to securely end your session and clear
authentication state from the device.
 SUMMARY / CONCLUSION

Achievements

WeatherApp has been successfully developed as a fully functional production ready mobile
application demonstrating effective application of SwiftUI and Supabase in solving real world
problems in weather tracking domain. The following achievements have been realised:

A complete end to end weather monitoring system has been built from scratch using
modern iOS technologies Swift SwiftUI and Supabase demonstrating proficiency in mobile
application development.
City management and duplicate entry issues are handled through real time Supabase checks
ensuring each user maintains an accurate personalized city list without conflicts.
Secure authentication system using Supabase Auth has been implemented supporting email
based login and third party providers without exposing sensitive credentials.
Real time weather updates using Supabase subscriptions ensure instant synchronization of
temperature AQI humidity and forecast data across the application.
A single screen navigation architecture using SwiftUI NavigationStack delivers smooth
transitions and faster user experience compared to traditional navigation systems.
A unified platform integrating weather tracking AQI monitoring and AI assistant provides
users with a complete environmental information system in one application.

Learning Outcomes

The development of WeatherApp has provided extensive practical learning across multiple
dimensions of modern mobile and backend development:

Mobile App Architecture: Comprehensive understanding of SwiftUI based architecture,

view composition, state management, API integration, and real time data synchronization
using Supabase.
Swift and SwiftUI Development: Expertise in SwiftUI lifecycle, state handling using
@State and @ObservableObject, NavigationStack routing, reusable components, and
declarative UI design patterns.
Supabase Backend Integration: Practical knowledge of Supabase Auth, PostgreSQL based
data modeling, real time subscriptions, API communication, and secure data access policies
using row level security.
Cloud Database Design: Deep understanding of relational schema design, table
relationships between users cities and preferences, query optimization, and secure data
handling in cloud environment.
Third Party Service Integration: Skills required to integrate and troubleshoot external APIs
such as weather data services and Supabase SDK including authentication flows and
realtime event handling.
 Security Best Practices: Token based authentication using JWT, secure storage of
credentials, HTTPS communication, and Supabase security policies ensuring protected user
data access.
Agile Development: Iterative development approach with continuous testing debugging and
feature enhancement improving ability to plan and deliver functional mobile application
incrementally.

Benefits of System

For Mobile Users: A faster, more intuitive weather experience with real time city tracking,
secure authentication, instant weather updates, AI powered insights, and a centralized
dashboard for managing all saved locations.
For System Backend: Automated weather data synchronization using Supabase, real time
updates for all connected clients, reduced data inconsistency, and a structured record of user
preferences and city selections.
For the Application: A scalable and maintainable codebase built on SwiftUI and Supabase
with minimal infrastructure overhead, capable of handling increasing users through cloud
based backend scaling and real time data services.
For the Academic Community: A practical and well documented demonstration of mobile
application architecture, backend integration using Supabase, real time data handling, and
modern iOS development best practices.
 LIMITATIONS OF PROJECT

Current Limitations

While WeatherApp successfully addresses the primary problems identified in the problem
statement and fulfils all stated functional requirements, several limitations exist in the current
version that represent areas for future improvement:

Absence of Admin Dashboard: Weather data and city configurations are managed through
Supabase directly. There is no dedicated interface for administrators to manage cities,
update weather sources, or control user permissions dynamically.
No AI Personalization Engine: The system provides general weather insights only. There is
no personalisation layer suggesting weather-based recommendations based on user
behaviour or historical usage patterns.
Static Data Handling: Weather values are fetched from APIs and stored temporarily. The
system does not implement predictive modeling or advanced forecasting adjustments based
on local environmental trends.
No Multi-Region Customization: The application supports a single global configuration. It
does not allow region-specific customization such as localized alerts, language-based
weather formatting, or regional units switching automatically.
No User Feedback System: Users cannot rate weather accuracy or provide feedback on AI
responses, limiting continuous improvement based on real user evaluation.
No Native Widget Integration: The platform does not include iOS home screen widgets for
quick weather access, relying entirely on in-app usage for updates and forecasts.
No OTP Phone Authentication: Authentication relies entirely on email and social login via
Supabase. SMS-based phone verification is not implemented for additional security layer.
Dependency on External Weather API: The system relies on third-party weather APIs. Any
downtime or rate limiting from external services directly affects application reliability.
No Offline Mode Support: The application requires active internet connectivity for all
features and does not support cached offline weather viewing.
Limited AI Capabilities: The AI assistant provides basic responses only and does not
include advanced forecasting models or deep learning based environmental prediction
systems
 FUTURE DIRECTIONS

Planned Enhancements

The following enhancements are planned for future versions of WeatherApp to transform it
from a functional academic project into a more advanced, production-grade mobile weather
intelligence platform:

AI-Powered Recommendation Engine

A machine learning based personalization system will be integrated to provide customized

weather insights using behavioural analysis of user-selected cities, search frequency, and
interaction patterns. Future implementation may use Python based ML models exposed through
an API layer or integration with cloud ML services such as Google Vertex AI or AWS
SageMaker. The recommendation module will appear on the home dashboard and city detail
screens, surfacing weather alerts, AQI trends, and forecast summaries most relevant to each user
based on historical usage and location preferences.

Dynamic Pricing Module

A demand-aware adaptive pricingsystem will be introduced in future versions to provide

intelligent, context-based adjustments to pricing and availability indicators for weatherrelated
premium services or advanced data features. The system will initially use rulebased logic
considering factors such as seasonal patterns, peak usage times, and regional demand for
weather insights, before evolving into a machine learning model trained on historical usage
behaviour and engagement trends.

Self-Management Portal

A dedicated admin and data management interface will be introduced in future versions to allow
system administrators to manage cities, weather sources, and user data without direct database
access. This portal will enable adding and updating city records, configuring weather API
sources, monitoring system usage, and managing user accounts and preferences.
User Ratings and Review System

A verified feedback system will allowusers who have consistently used city tracking features
and saved weather history tosubmit a 1 to 5 rating and written feedback on forecast accuracy
and AI responses. Reviews will be filtered using automated content moderation checks to
ensure appropriate content quality.

Multi-Language Support

Internationalisation (i18n) willbe implemented using a localisation framework for SwiftUI,

enabling the WeatherApp interface to be displayed in multiple languages. The initial expansion
will target Hindi, French, Spanish, and Arabic, allowing the application to serve a much broader
global user base with localized weather formats, units, and AI responses.

Native Android and iOS Applications

A cross-platform mobile application enhancement will be developed using SwiftUI for iOS and
potentially extended to Android using Kotlin or a shared backend-driven architecture. It will
leverage existing Supabase integration and business logic to maintain consistency across
platforms. Native features will include push notifications for weather alerts and AQI warnings,
biometric authentication (Face ID and Touch ID), location-based weather detection, and offline
access to previously loaded city weather data and forecasts.

OTP-Based Phone Verification

SMS-based OTP verification will be added as an optional authentication layer for enhanced
account security, using a third-party SMS service provider such as Twilio or similar APIs. OTP
will serve as a two-factor authentication (2FA) mechanism for users who want additional
protection beyond email or social login methods

Real-Time Analytics Dashboard

A comprehensive analytics dashboard will provide real-time visibility into user engagement
patterns, including geographic distribution of active users and most frequently accessed weather
features. The dashboard will use modern data visualization libraries such as Recharts or [Link]
to present insights through line charts, bar graphs, and heat maps, powered by Supabase queries
and aggregated user interaction data.
Real-Time Chat Support

An integrated real time assistance feature using WebSocket based communication will be
introduced in future versions to enable instant interaction between users and a support system
for weather related queries and app usage help. This system will support live chat between users
and a support agent, with an AI powered chatbot handling common queries such as forecast
explanations, AQI meaning, and app navigation guidance, escalating to a human agent when
required.
 REFERENCES / BIBLIOGRAPHY

1. Apple Inc. (2024). SwiftUI Documentation – Views, State Management, and

NavigationStack. Retrieved from [Link]
2. Apple Inc. (2024). Swift Programming Language Guide – Syntax, Data Structures, and
Concurrency. Retrieved from [Link]
programming-language/
3. Supabase Inc. (2024). Supabase Documentation – Authentication, Database, and Realtime
APIs. Retrieved from [Link]
4. Apple Inc. (2024). iOS Development Documentation – App Architecture and Lifecycle
Management. Retrieved from [Link]
5. OpenWeather (2024). Weather API Documentation – Current Weather and Forecast Data.
Retrieved from [Link]
6. Apple Inc. (2024). Combine Framework Documentation – Reactive Programming in Swift.
Retrieved from [Link]
7. Supabase Inc. (2024). Row Level Security (RLS) and Database Policies. Retrieved from
[Link]
8. Apple Inc. (2024). User Notifications Framework – Push Notifications and Alerts.
Retrieved from [Link]
9. Google (2024). Firebase Alternative Comparison and Backend Services Overview.
Retrieved from [Link]