Build a weather app with forecasts and alerts (no code)

Weather apps are a classic first project because they combine a real API, a nice UI and a reason to open the app every day. Farmers, fishermen, event planners and commuters all want a specific view of the weather — rain probability by hour, wind for the coast, a frost warning — that generic apps bury.

This guide builds a weather app with a free forecast API, city search, hourly and daily views, and alerts, and shows how to phrase the API details so the agent wires it correctly.

What a weather app should show

Pick the views your users care about; a fisherman’s app and a farmer’s app are not the same app:

• Current conditions — Temperature, feels-like, humidity, wind, an icon and a one-line summary.
• Hourly for the next 24 hours — Temperature and rain probability as a scrollable strip.
• 7-day forecast — Highs, lows, rain, and an icon per day.
• Locations — GPS for “here”, a search box for cities, saved favourites.
• Alerts — Rain in the next hour, frost tonight, wind above a threshold — as notifications.
• Units and language — °C/°F, km/h vs m/s, local names for weather words.
• Offline last-known — Show the last fetched forecast when there is no network, with a timestamp.

Build it with App Builder Agent, step by step

Name a free API so no key is needed — Open-Meteo is the usual choice — and the agent handles the rest.

1. Create a mobile app project. GPS and notifications want a native app; a website version works for a dashboard.
2. Describe the views and name the API. Say which data you want and where from.
   Build a weather app called Sky for Bangladesh. Use the free Open-Meteo API (no key). Home: current temperature, feels-like, humidity, wind, rain probability, with a background that changes by weather. Hourly strip for 24 hours. 7-day list. Location by GPS and a city search using Open-Meteo geocoding; favourites list. Units °C/km/h. Bengali and English. Cache the last forecast for offline.
3. Check a real city in the simulator. Compare with any weather site. If something looks wrong, tell the agent which field. Then use the Simulate panel to set a GPS position in Chittagong, confirm the app switches location, and turn the network off to be sure the cached forecast appears with its timestamp instead of a blank screen.
4. Add alerts. Rain in the next hour and heat/frost warnings as local notifications.
   Add alerts: notify me when rain probability in the next 2 hours exceeds 60%, and a morning summary at 7 am for my favourite location.
5. Install. Export the APK. Weather apps are also excellent websites — publish the project for a link people can bookmark.

Prompts that work well

Specialised weather apps people actually want:

Common mistakes (and the fix)

• Pasting an API key into the chat. Keys in prompts end up in the source code of the app you share. Use a keyless provider such as Open-Meteo, or ask for a settings screen where the key is typed on the device, or a small hosted backend that holds the key server-side.
• Showing forecast hours in the wrong time zone. Most APIs return UTC unless told otherwise. Ask the agent to request times in the location’s time zone (not the phone’s), so a Dhaka user looking at London sees London hours labelled correctly.
• Requiring GPS. Half your users will deny location on first launch. Make city search the fallback, remember the last city, and only ask for permission when someone taps “Use my location”.
• Fetching on every screen change. Hitting the API each time a tab opens is slow and gets you rate-limited. Cache the response for 15–30 minutes with a “last updated” label and a pull-to-refresh.
• Icons that do not match the words. A sun icon over “light rain” destroys trust. Ask for a single mapping from the API’s weather codes to icons and descriptions in your language, and check the night variants too.
• Alerts that fire repeatedly. A “rain in 2 hours” notification every 30 minutes gets the app muted. Ask for one alert per event with a cooldown, and a morning summary as the default instead of many small alerts.

Make it feel finished

• Cache the last response and show its time — networks drop, apps should not go blank.
• Use rain probability, not just an icon; people plan around it.
• Ask for a background that changes with conditions; it makes the app feel alive.
• Keep GPS optional: a city search must work without location permission.

Installing, publishing and next steps

Open-Meteo needs no key, so the app talks to it directly and there is nothing to host. If you use a keyed provider, ask the agent for a settings screen where the key is entered on the device, or for a small hosted backend that keeps the key server-side — the platform hosts it with the project. Download APK from the Preview tab gives you a release-signed test build to install today; a signed store build with your own package id comes from the same project when you want a Play Store listing. The AI app builder page lists what is free and what the $1.49 Member plan and plans unlock. Publish the website version too: a weather page for your town is easy search traffic and needs no install.

The ready-made weather apps gallery shows a few home-screen layouts worth borrowing. If you want a map with rain radar overlays or route weather, continue with the maps and location tracking guide; if your audience wants local news and warnings alongside the forecast, the news app guide uses the same fetch-and-cache pattern. Open the builder and name your city, units and API in the first sentence.

Frequently asked