Live Sports Score App

A Live Sports Score App is not the same as a regular list app. In a normal app, you may fetch data once, render it, and let the user refresh manually. Live sports data is different because scores, match status, cards, periods, innings, goals, substitutions, and final results can change at any moment. If you build the app as a simple “fetch once and display” screen, users will see outdated information very quickly.

The main challenge is not only calling an API. The real challenge is deciding how the app should refresh data without wasting network requests or making the UI jump every few seconds. For example, a live match may need frequent updates, while a finished match does not need polling at all. Upcoming matches may only need occasional refreshes. If every match is treated the same, the app becomes slower, more expensive to run, and less reliable.

A better solution is to model match freshness as part of the data flow. Live matches can refresh more often, finished matches can stop refreshing, and upcoming matches can refresh only when the user opens the screen or changes the selected date. This makes the app feel live without turning the API into a constant background loop.

Problematic approach:

          function ScoresScreen() {
            const [matches, setMatches] = useState([]);

            useEffect(() => {
              async function loadMatches() {
                const response = await fetch("/api/scores");
                const data = await response.json();

                setMatches(data.matches);
              }

              loadMatches();
            }, []);

            return <MatchList matches={matches} />;
          }

This loads scores once when the screen opens. If a goal is scored after the request finishes, the user will not see it unless they restart or manually reload the app.

Better refresh-aware approach:

          type MatchStatus = "scheduled" | "live" | "paused" | "finished";

          function shouldRefresh(status: MatchStatus): boolean {
            return status === "live" || status === "paused";
          }

          function ScoresScreen() {
            const [matches, setMatches] = useState<Match[]>([]);
            const hasLiveMatches = matches.some((match) => {
              return shouldRefresh(match.status);
            });

            useEffect(() => {
              let cancelled = false;

              async function loadMatches() {
                const nextMatches = await scoresApi.getTodayMatches();

                if (!cancelled) {
                  setMatches(nextMatches);
                }
              }

              loadMatches();

              if (!hasLiveMatches) {
                return () => {
                  cancelled = true;
                };
              }

              const intervalId = setInterval(loadMatches, 30000);

              return () => {
                cancelled = true;
                clearInterval(intervalId);
              };
            }, [hasLiveMatches]);

            return <MatchList matches={matches} />;
          }

Pay attention to: Live data needs a refresh strategy. Poll active matches, stop polling finished matches, and avoid treating every sports record like a static API response.

Sports apps often become confusing because match status is handled as plain text from the API. One provider may return "FT", another may return "finished", another may return "Full Time", and another may return numeric status codes. If your UI uses these raw values directly, every screen needs to understand provider-specific status names.

A Live Sports Score App should normalize status values early. The UI should work with a small set of internal statuses such as scheduled, live, paused, finished, postponed, or cancelled. This gives the app predictable rendering rules: live matches show a live badge, scheduled matches show time, finished matches show final score, and cancelled matches show a clear message.

This also protects the app when you later support multiple sports. Football, cricket, basketball, and tennis do not describe match progress the same way. A normalized status model keeps your UI stable even when raw API details differ.

Problematic approach:

          function MatchCard({ match }) {
            return (
              <View>
                <Text>{match.homeTeam} vs {match.awayTeam}</Text>
                <Text>{match.status}</Text>

                {match.status === "FT" && (
                  <Text>Final score</Text>
                )}

                {match.status === "LIVE" && (
                  <Text>Live now</Text>
                )}
              </View>
            );
          }

This component is tied to raw API status strings. If the API returns a different value, the card may render the wrong state.

Better normalized model:

          type MatchStatus =
            | "scheduled"
            | "live"
            | "paused"
            | "finished"
            | "postponed"
            | "cancelled";

          type Match = {
            id: string;
            sport: "football" | "cricket" | "basketball";
            leagueName: string;
            homeTeam: string;
            awayTeam: string;
            homeScore: number | null;
            awayScore: number | null;
            startTime: string;
            status: MatchStatus;
            minute?: number;
          };

          function normalizeFootballStatus(apiStatus: string): MatchStatus {
            switch (apiStatus) {
              case "1H":
              case "2H":
              case "LIVE":
                return "live";

              case "HT":
                return "paused";

              case "FT":
              case "AET":
              case "PEN":
                return "finished";

              case "PST":
                return "postponed";

              case "CANC":
                return "cancelled";

              default:
                return "scheduled";
            }
          }

Status-aware rendering:

          function MatchStatusLabel({ match }: { match: Match }) {
            if (match.status === "live") {
              return <Text>Live {match.minute ? `${match.minute}'` : ""}</Text>;
            }

            if (match.status === "finished") {
              return <Text>Final</Text>;
            }

            if (match.status === "postponed") {
              return <Text>Postponed</Text>;
            }

            return <Text>{formatKickoffTime(match.startTime)}</Text>;
          }

Pay attention to: Convert provider-specific status codes into your own internal status model. The rest of the app should not depend on raw API strings.

Live score apps are easy to over-poll. Beginners often set an interval that refreshes every few seconds because they want the app to feel real-time. But sports APIs often have rate limits, paid tiers, or request quotas. Too many requests can slow the app, drain battery, exceed the API plan, or temporarily block the client.

A better live-score strategy should consider screen focus, match status, selected leagues, and app state. If the user leaves the scores screen, polling should stop. If the app moves to the background, polling should pause. If there are no live matches, the refresh interval should slow down or stop completely. If the user follows one favorite match, that match can refresh more frequently than a full list of all games.

You should also avoid overlapping requests. If a previous request is still running, do not start another one immediately. This is especially important on mobile networks, where latency can be unstable.

Problematic approach:

          useEffect(() => {
            const intervalId = setInterval(async () => {
              const response = await fetch("/api/live-scores");
              const data = await response.json();

              setMatches(data.matches);
            }, 5000);

            return () => clearInterval(intervalId);
          }, []);

This refreshes forever while the component is mounted, even if no matches are live. It also does not prevent overlapping requests.

Better controlled polling:

          function useLiveScoresPolling(params: {
            enabled: boolean;
            intervalMs: number;
            loadScores: () => Promise<void>;
          }) {
            const requestInProgress = useRef(false);

            useEffect(() => {
              if (!params.enabled) {
                return;
              }

              let cancelled = false;

              async function runRequest() {
                if (requestInProgress.current) {
                  return;
                }

                requestInProgress.current = true;

                try {
                  await params.loadScores();
                } finally {
                  requestInProgress.current = false;
                }
              }

              runRequest();

              const intervalId = setInterval(() => {
                if (!cancelled) {
                  runRequest();
                }
              }, params.intervalMs);

              return () => {
                cancelled = true;
                clearInterval(intervalId);
              };
            }, [params.enabled, params.intervalMs, params.loadScores]);
          }

Using screen focus:

          const isFocused = useIsFocused();

          const hasLiveMatches = matches.some((match) => {
            return match.status === "live" || match.status === "paused";
          });

          useLiveScoresPolling({
            enabled: isFocused && hasLiveMatches,
            intervalMs: 30000,
            loadScores: refreshScores
          });

Pay attention to: Poll only when it makes sense. Respect API limits, stop polling when the screen is not active, avoid overlapping requests, and use slower refresh behavior for non-live data.

Live sports data changes frequently. If you replace the entire match list on every refresh without stable IDs and careful ordering, the UI may jump, scroll position may reset, and match cards may flicker. This feels especially bad on mobile because users often follow one game while glancing at the list.

The app should preserve stable match identities. Each match needs a reliable ID from the provider or a generated key based on league, teams, and kickoff time. When fresh data arrives, update existing match records instead of treating every response as a brand-new list. This keeps animations, list rendering, and scroll behavior more stable.

Ordering also matters. If live matches move to the top on every refresh, users may lose the match they were reading. Decide a clear sorting strategy: group by league, date, favorite teams, or live status. Then keep that strategy consistent instead of constantly reshuffling the entire screen.

Problematic rendering:

          <FlatList
            data={matches}
            keyExtractor={(item, index) => String(index)}
            renderItem={({ item }) => (
              <MatchCard match={item} />
            )}
          />

Using array indexes as keys is risky because live data can be inserted, removed, reordered, or updated. React Native may reuse the wrong row and display confusing content.

Better list model:

          function mergeMatches(
            currentMatches: Match[],
            incomingMatches: Match[]
          ): Match[] {
            const currentById = new Map(
              currentMatches.map((match) => [match.id, match])
            );

            return incomingMatches.map((incomingMatch) => {
              const currentMatch = currentById.get(incomingMatch.id);

              return currentMatch
                ? {
                    ...currentMatch,
                    ...incomingMatch
                  }
                : incomingMatch;
            });
          }

Stable FlatList:

          <FlatList
            data={visibleMatches}
            keyExtractor={(match) => match.id}
            renderItem={({ item }) => (
              <MatchCard match={item} />
            )}
            initialNumToRender={12}
            windowSize={7}
            removeClippedSubviews
          />

Consistent grouping:

          function groupMatchesByLeague(matches: Match[]) {
            return matches.reduce<Record<string, Match[]>>((groups, match) => {
              if (!groups[match.leagueName]) {
                groups[match.leagueName] = [];
              }

              groups[match.leagueName].push(match);

              return groups;
            }, {});
          }

Pay attention to: Live updates should feel stable. Use real match IDs, avoid index keys, merge updates carefully, and keep list ordering predictable.

Push notifications are powerful in a sports app, but they can easily become annoying. Users may want alerts only for favorite teams, only for goals, only for match start, or only for final results. A common mistake is sending notifications for every score update or every live event. That creates notification fatigue and makes users disable notifications completely.

Notifications also need deduplication. If the backend sends the same goal event twice, or if Firebase delivery retries occur, the app should not show duplicate goal alerts. A sports notification should have a stable event ID, such as matchId + eventType + minute + teamId. The client or backend can store processed notification IDs and ignore duplicates.

Mobile permission flow matters too. Do not ask for notification permission immediately on first launch. Ask when the user follows a team, enables match alerts, or turns on a notification setting. At that moment, the value is clear: the user understands what alerts they are enabling.

Problematic approach:

          useEffect(() => {
            requestNotificationPermission();
          }, []);

          function onLiveEvent(event) {
            showPushNotification({
              title: "Sports update",
              body: JSON.stringify(event)
            });
          }

This asks too early and creates generic notifications that are not tied to user preferences.

Better notification preference model:

          type NotificationPreferences = {
            enabled: boolean;
            favoriteTeamIds: string[];
            alertTypes: Array<"match-start" | "goal" | "red-card" | "final-score">;
          };

          type SportsEvent = {
            id: string;
            matchId: string;
            teamId?: string;
            type: "match-start" | "goal" | "red-card" | "final-score";
            minute?: number;
            message: string;
          };

          function shouldNotifyUser(
            event: SportsEvent,
            preferences: NotificationPreferences
          ): boolean {
            if (!preferences.enabled) {
              return false;
            }

            if (!preferences.alertTypes.includes(event.type)) {
              return false;
            }

            if (event.teamId && preferences.favoriteTeamIds.length) {
              return preferences.favoriteTeamIds.includes(event.teamId);
            }

            return true;
          }

Deduplication example:

          async function handleSportsEventNotification(event: SportsEvent) {
            const processedIds = await loadProcessedNotificationIds();

            if (processedIds.includes(event.id)) {
              return;
            }

            await displayNotification({
              title: "Match update",
              body: event.message
            });

            await saveProcessedNotificationId(event.id);
          }

Pay attention to: Notifications should be user-controlled, event-specific, and deduplicated. A good sports app alerts users about what they care about, not every small data change.

Sports schedules are date-sensitive. A match that starts at 23:30 in one country may appear on the next day in another user's timezone. If you group matches using raw API dates without converting them for the user's local timezone, the app can show games under the wrong day. This is confusing for users who rely on the app to know what is live today, tomorrow, or later in the week.

The safest approach is to store kickoff time in an absolute format such as ISO UTC, then format it for the user's local timezone at render time. Match-day grouping should be based on the user's local date unless the app explicitly lets users choose a league timezone. This is especially important for international football, cricket tournaments, NBA/NHL schedules, and events that cross midnight.

The UI should also make dates easy to understand. Instead of showing only raw timestamps, use labels such as “Today,” “Tomorrow,” “Live now,” “Final,” or local kickoff time. Users open sports apps quickly; they should not need to interpret technical date strings.

Problematic approach:

          function getMatchDay(match) {
            return match.date.slice(0, 10);
          }

          function MatchTime({ match }) {
            return <Text>{match.date}</Text>;
          }

This uses the raw API date and may group the match according to the provider timezone rather than the user's local day.

Better local date formatting:

          function getLocalDateKey(isoDate: string): string {
            const date = new Date(isoDate);

            const year = date.getFullYear();
            const month = String(date.getMonth() + 1).padStart(2, "0");
            const day = String(date.getDate()).padStart(2, "0");

            return `${year}-${month}-${day}`;
          }

          function formatMatchTime(isoDate: string): string {
            return new Intl.DateTimeFormat(undefined, {
              hour: "2-digit",
              minute: "2-digit"
            }).format(new Date(isoDate));
          }

Day label helper:

          function getDayLabel(isoDate: string): string {
            const matchDateKey = getLocalDateKey(isoDate);
            const todayKey = getLocalDateKey(new Date().toISOString());

            const tomorrow = new Date();
            tomorrow.setDate(tomorrow.getDate() + 1);

            const tomorrowKey = getLocalDateKey(tomorrow.toISOString());

            if (matchDateKey === todayKey) {
              return "Today";
            }

            if (matchDateKey === tomorrowKey) {
              return "Tomorrow";
            }

            return new Intl.DateTimeFormat(undefined, {
              month: "short",
              day: "numeric"
            }).format(new Date(isoDate));
          }

Pay attention to: Store match times as absolute timestamps and format them locally. Date grouping should match the user's real day, not only the API provider's timezone.