Building a mobile app can be hard, especially without much prior experience. First you have to come up with an idea that fulfills certain criteria:

• Is neither too easy nor too hard to make it worthwhile given your current skills.
• Is "fun" to work on: the idea should ideally solve a problem or improve your life in a personal area of interest.
• Is (somewhat) original: it doesn't have to be completely unique but should at least provide some new twist or perspective to an existing concept.

In addition to these things, there are also technical considerations to take into account. As of 2025, some of these are:

• Do I build a fully native app (Swift for iOS, Kotlin for Android)?
• Do I use a cross-platform framework like React Native, Flutter or Xamarin?
• Do I simply vibe code the whole thing using one of the many AI tools out there?

My motivation and how I picked a tech stack

I know, I know, a weather app is just as cliche and unoriginal as a to-do list or calculator when getting familiar with a new programming language or tech stack. But there was one thing that had always bothered me with most weather apps - the clutter. For the most part when I'm checking the weather on my phone I only care about how it will change in the course of the day at my current location.

I don't need an overload of data points and graphs for the next several weeks in order to make an informed decision about how to get dressed in the morning. So, I decided that the focus of my weather app was going to be simplicity, specifically to present the user with the current day's weather forecast for their current location.

Sketching out the user interface

To realize my "vision", I started by broadly sketching out the user interface. The original plan was to display each of the 24 hours in a day using a card, in the following way:

As you can see, each card displays the hour along with the weather conditions and temperature. When the user starts or refreshes the app, the current hour is highlighted in a contrasting color to the rest of the cards, and the view scrolls to keep the current hour in focus.

Starting with mock data

To see my UI in action, I decided to build out a basic version using mock data. The long-term plan was of course to fetch live data from a weather API, but I wanted to have something tangible up and running before then. The mock data consisted of any array of objects following the same format as outlined above.

{ hour: '05:00', temperature: 10, weather: 'Cloudy' }

With the mock data firmly in place, it was easy to set up the UI using a ScrollView:

<ScrollView ref={scrollViewRef} contentContainerStyle={styles.innerScrollView}>
<View style={styles.weatherContainer}>
{loading ? (
<View style={styles.loadingContainer}>
<ActivityIndicator size="large" color="#F5D547" />
</View>
) : (
forecast.map((weatherGroup: {startHour: string, endHour: string, weather: string, minTemp: string, maxTemp: string, icon: string}, index: number) => (
createWeatherCard(weatherGroup, index)
))
)}
</View>
</ScrollView>

Merging the weather data and modifying the UI

The end result looked OK, but it still felt a little cluttered: there were simply too many weather cards presented to the user at any one time. To remedy this, I decided to merge weather cards if they met all of the following conditions:

• Adjacent hours (00:00 and 01:00, 17:00 and 18:00 etc)
• Temperature difference (no more or less than 5 degrees difference from the lowest and highest temperature of the current group. For example, a temperature of 15*C and 21*C would result in two separate groups, but not 15*C and 20*C.
• The same weather type (clear, cloudy, sunny etc)

This process significantly cut down the number of weather cards displayed on the screen, unless each hour has its own unique weather type (which is very rare).

The updated UI now looks like this:

We now have a basic yet functional weather app, with one major issue: the weather data is hardcoded into the index.tsx file, meaning it always stays the same and making the app essentially useless apart from admiring the pretty UI. That is why the next part in this mini-series will cover how to fetch weather data from an API, handling an API key and dealing with the fetched data asynchronously.