You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+44-1Lines changed: 44 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -130,6 +130,49 @@ The project now separates:
130
130
131
131
This keeps the background logic stable and easy to reason about, while allowing the forecast rows and current-condition UI to become much more specific without changing the rest of the app's visual architecture.
132
132
133
+
## Temperature Unit Behavior
134
+
135
+
The app currently fetches temperatures from OpenWeather in **metric** units and keeps those values in Celsius inside the app's domain models.
136
+
137
+
Temperature conversion happens only at presentation time:
138
+
139
+
- if the phone's system temperature preference resolves to Celsius, the app displays `°C`
140
+
- if the phone's system temperature preference resolves to Fahrenheit, the app converts the stored Celsius value and displays `°F`
141
+
142
+
This applies consistently to:
143
+
144
+
- the current temperature in the forecast header
145
+
- each daily temperature shown in the forecast list
146
+
147
+
### Current Limitation
148
+
149
+
This is intentionally limited.
150
+
151
+
Right now the app does **not** offer an in-app temperature preference. It only follows the phone's current system preference for temperature units. That is acceptable for a lightweight prototype, but it is not ideal for a production weather app because users may want control that differs from their device-wide regional setting.
152
+
153
+
Examples:
154
+
155
+
- a user may want Fahrenheit in the weather app even if their phone is configured for a metric region
156
+
- a user may want Celsius in the app while traveling in a locale that defaults to Fahrenheit
157
+
158
+
### Production Direction
159
+
160
+
For a production-ready version, the app should add a dedicated settings surface where the user can explicitly choose their preferred temperature unit.
161
+
162
+
That future settings flow should support:
163
+
164
+
-`Use System Setting`
165
+
-`Celsius`
166
+
-`Fahrenheit`
167
+
168
+
In that model:
169
+
170
+
- the app would still be able to respect the phone setting by default
171
+
- the user would be able to override that default when needed
172
+
- the chosen preference would be persisted and used consistently across the entire app
173
+
174
+
The current implementation does not include that settings page or persistence layer yet. It is a presentation-only improvement that makes the displayed unit match the phone setting without introducing additional app configuration UI.
175
+
133
176
## Configuration
134
177
135
178
The current testing configuration is defined in [AppConfiguration.swift](/Users/blessingmabunda/Documents/WeatherApp/WeatherApp/App/AppConfiguration.swift).
0 commit comments