Mobile web performance has become increasingly
important as users expect fast and reliable experiences across
a wide range of devices and network conditions. Traditional
rendering methods often struggle to meet these demands due to
heavy JavaScript execution and long network round trips. This
paper examines two modern rendering techniques, React Server
Components and edge rendering, and discusses how they address
key mobile performance challenges. By reducing JavaScript
workload on the client and generating responses closer to the
user, these approaches can improve Core Web Vitals such as LCP,
FID/INP, and TTFB. While both methods offer promising results,
they also introduce new architectural and runtime limitations.
This state-of-the-art overview evaluates their potential impact
on mobile web performance and highlights open challenges for
future research.

The post SOTA | Mobile Web Performance: React Server Components and Edge Rendering appeared first on Mobile USTP MKL.

When we build web applications, we often assume that the internet is stable and always available. In development environments, everything is set to work smoothly, APIs respond quickly, and connection issues rarely appear in local network.. But once an application reaches real users, the situation changes. Networks fluctuate. People switch between WiFi, mobile data, or no connection. In those moments, an application that depends entirely on live server communication can suddenly feel slow or broken.

Offline first design tries to solve this by changing the starting assumption. Instead of building around constant connectivity, it treats unreliable networks as a normal condition. Google’s Progressive Web App documentation describes reliable applications as ones that load consistently regardless of network quality. That idea sounds simple, but it shifts how we think about architecture. The goal is not to eliminate the server, but to reduce how much the user experience depends on it at every single moment.

What Offline First Actually Means

Offline first does not mean that a web application runs forever without internet access. It also does not mean simply storing a few static files in the browser cache. It is more about prioritizing local availability. Essential resources and parts of the interface should be available immediately, while synchronization with the server happens when possible.

According to Google’s PWA guidelines, reliable applications should load quickly and behave predictably even under poor network conditions. Instead of blocking the interface until the server responds, the application can render what is already stored locally and update the data in the background. From a user perspective, this feels faster and more stable. From a developer perspective, it requires thinking about caching and synchronization early in the design process, not as an afterthought.

Service Workers as the Core Mechanism

At the center of offline first web applications is the Service Worker API, which is explained in detail in the MDN documentation. A service worker is basically a script that runs separately from the actual web page. It does not live inside your React or Vue component tree. Instead, it sits in between the application and the network and can intercept requests before they go to the server.

What makes this interesting is that the service worker can decide what happens with each request. It can fetch fresh data from the network, return something that was previously cached, or even combine both approaches. This extra layer changes the normal request flow of the browser. Instead of always asking the server directly, the browser first asks the service worker what to do.

Because service workers run independently from the page lifecycle, they can continue working even when the page is not actively rendering something. They can handle caching logic, background updates, and certain events without blocking the interface. That separation between UI logic and network logic is what makes offline first behavior possible in modern browsers. It sounds simple when described like this, but it changes the architecture quite significantly.

App Shell and Caching Strategies

One concept often mentioned in Google’s PWA documentation is the App Shell model. The idea is to cache the structural part of the application, such as navigation and layout, so it loads instantly. The dynamic content is then loaded separately. Even if the network request for data fails, the user still sees a working interface instead of a blank screen.

Caching itself can be handled in different ways. In The Offline Cookbook, Jake Archibald explains several strategies. Some applications use a cache first approach, where content is served from the cache and only fetched from the network if needed. Others use network first, which tries to retrieve fresh data and falls back to cached content if the request fails. There is also stale while revalidate, which shows cached content immediately while updating it in the background. Each strategy affects how up to date the content is and how responsive the application feels. Because implementing these patterns manually can become complex, many developers rely on Workbox, which is Google’s official library for managing service workers and caching rules.

Offline First in Vue

In the Vue ecosystem, offline capabilities are commonly added using tools like the Vite Plugin PWA, which integrates Workbox into the build process. The plugin automatically generates a service worker and allows developers to configure caching behavior without writing everything from scratch.

I had some experience working with a Vue PWA in a professional setting. At first, the main goal was not offline support but installability. We wanted users to be able to download the application similarly to how platforms like GitHub can be installed as a web app. Once that was working, we started thinking about offline access, mainly so that users could still view certain reports if they temporarily lost connectivity.

In theory, this sounded straightforward. In practice, it turned out to be more complicated than expected. Because of how the application was structured, caching specific dynamic resources was not trivial. We ran into several edge cases, especially around request handling and invalidation. Some caching strategies simply did not fit our data flow. We experimented, adjusted configurations, and even opened issues on GitHub when certain behaviors were unclear. Workbox itself worked reliably, but it was definitely more complex than it initially appeared. That experience made it clear that offline first design is not just about adding a plugin. It requires a deeper understanding of how requests and data flow through the application.

Challenges and Trade Offs

Offline first sounds great in theory. More reliability, better user experience, fewer network issues. But once you start implementing it, things get messy quite quickly. You have to think about what happens when content changes, how long something should stay in the cache, and what the user sees if the data is outdated. It is very easy to accidentally serve old information longer than you intended.

Synchronizing local data with the server can also become tricky. If a user interacts with content while offline and the application later reconnects, conflicts can appear. Service workers also have their own lifecycle, which is not always intuitive. Updates do not instantly replace older versions unless you handle the activation process carefully. The MDN documentation explains this, but it only truly makes sense once you run into it yourself.

There are also practical constraints. Service workers require HTTPS, which means proper deployment setup is mandatory. Browser storage limits and small behavioral differences between browsers can influence how reliable your implementation really is. In short, offline first architecture definitely improves robustness, but it forces you to think more carefully about how your application behaves behind the scenes.

Final Thoughts

For me, offline first design is less about adding a technical feature and more about adjusting expectations. It anticipates connection blackouts for which the user should be punished for. When implemented well, it makes web applications feel more stable.

At the same time, I would not describe it as effortless. Documentation examples often look clean and straightforward, but real projects usually have edge cases that do not fit perfectly into predefined caching strategies. My own experience showed me that adding offline capabilities can reveal architectural weaknesses that were not obvious before. It forces you to understand how requests, caching and updates actually work inside the browser.

When done thoughtfully, offline first can noticeably improve reliability and user trust. When handled carelessly, it can introduce subtle bugs that are hard to trace. That tension between simplicity in theory and complexity in practice is what makes offline first design both interesting and challenging.

Soruces:

https://web.dev/explore/progressive-web-apps

https://web.dev/articles/offline-cookbook

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

https://developer.chrome.com/docs/workbox

https://vite-pwa-org.netlify.app

The post Offline-First Web Applications: Designing for the Real World appeared first on Mobile USTP MKL.

For this semester project, I developed MealMate, a cross-platform mobile application built with React Native and Expo. The idea behind the project was to create a practical tool that helps users discover recipes (nutrition, instruction, ingredients) , build weekly meal plans, and automatically generate shopping lists based on selected meals.

The project combines API integration, local data persistence, and structured state management in a mobile environment. My goal was not only to build a functional app, but also to deepen my understanding of mobile architecture and data handling.

Goals and Motivation

The main motivation behind MealMate was personal relevance. Planning meals manually is often unstructured and time-consuming, especially when trying to balance convenience, variety, and nutritional awareness. With MealMate, I wanted to create a system that allows me to plan meals for the week in a structured way, understand the nutritional values of my selections, and easily access detailed instructions and ingredient lists. Instead of just collecting recipes, the app combines planning, learning how to cook the meals properly, and managing the required ingredients in one coherent workflow.

At the beginning of the project, I defined the following learning goals:

• Learn Expo as a framework
• Connect a mobile application to an external API (Spoonacular)
• Manage and persist structured data locally
• Design a scalable state architecture in React Native
• Build a clear and reusable component structure
• Understand how to organize a medium-sized Expo Router project

The project clearly connects to the master class topics by combining planning, programming, system structure, and usability considerations.

Tech Stack

The application was built using:

• Expo + React Native + TypeScript
• Expo Router for file-based navigation
• Axios for API communication
• AsyncStorage for local persistence
• NativeWind / Tailwind for styling

I intentionally chose Expo because of its fast development workflow and strong ecosystem. Using TypeScript helped me manage structured data models such as recipes, meal plans, and shopping lists more safely. Most importantly, I chose it to learn web-app development framework.

Core Features

MealMate currently includes:

• Recipe search via the Spoonacular API
• Detailed recipe views (ingredients, instructions, nutrition)
• Weekly meal planning
• Automatic grocery list generation
• Grouping shopping items by aisle
• Persistent local storage of favorites and plans

The grocery list generation was one of the more interesting technical parts. Ingredients from multiple recipes need to be aggregated and normalized into a single structured list. This required careful mapping and data transformation.

Architecture and Data Flow

To keep the project structured, I separated it into logical layers:

• api/ → low-level API calls
• services/ → business logic (meal planning, grocery aggregation)
• state/ → global state management
• types/ → request/response models
• utils/ → normalization helpers

This modular approach helped me maintain clarity and avoid tightly coupled components. I learned how important early structural decisions are when building an app that handles multiple interconnected data types.

Challenges

One of the main challenges was handling API limitations. Since MealMate relies on the Spoonacular API, I had to deal with rate limits and request constraints. To prevent runtime crashes caused by too many simultaneous requests, I implemented a centralized API instance that manages headers and request configuration in one place. Additionally, I introduced controlled Promise delays to ensure that requests are spaced out properly. This forced me to think more carefully about request flow, caching, and responsible API usage.

Another major challenge was design. I am not a designer, so creating an interface that feels intuitive and structured required multiple iterations. It was difficult to balance functionality with simplicity, especially when dealing with multiple features such as recipe search, meal planning, and grocery list generation. I had to rethink layouts several times to make navigation clear and reduce cognitive load. This process helped me understand how important usability and visual hierarchy are in mobile applications.

Managing state complexity was also demanding. Recipes, favorites, meal plans, and aggregated grocery lists are all interconnected. Keeping this logic clean without creating tight coupling between components required careful separation of concerns.

What I Learned

This project significantly deepened my understanding of working with external APIs in a mobile context. I learned how to structure API calls properly, manage headers centrally, and implement basic caching strategies to reduce unnecessary requests. More importantly, I gained practical experience in handling asynchronous data flows and integrating API responses into React state in a stable and predictable way.

My understanding of Expo also improved considerably. Before this project, I had only limited experience with Expo. Through building MealMate, I learned how to leverage its development workflow, routing system, and build tools effectively. I became more comfortable with React Native’s JSX-like syntax, which resembles HTML but behaves differently in terms of layout and styling. Understanding how components render, how styling differs from traditional CSS, and how navigation works in a mobile environment was an important learning step.

Beyond technical skills, I learned how crucial project architecture is. Organizing the application into API, services, state, and utility layers made the project manageable and scalable. This reinforced the importance of planning system structure early.

Outlook

While the current version fulfills the MVP goals, there are several potential extensions I would like to explore in the future.

One improvement would be more advanced filtering and grouping features. Instead of only saving meals as favorites, users could create custom groups or collections for different goals, such as “High Protein,” “Quick Meals,” or “Vegetarian Week.”

Another interesting direction would be implementing an image-based scanner. For example, users could scan a meal or ingredient and receive similar recipes along with nutritional information. This would extend the application beyond manual search and introduce a more interactive discovery process.

Overall, MealMate provides a strong foundation that can be expanded further, both technically and conceptually.

The post Semester 1 Project: Meal Mate appeared first on Mobile USTP MKL.

For this Print2Mobile project, I created BrewCraft, a concept that connects a printed café flyer with a mobile web application. Instead of displaying a full menu on the flyer, the print acts as an entry point. It invites users to “Build Your Perfect Coffee” and includes a QR code that leads to a mobile website.

The Printed Element

The flyer uses warm coffee tones and a clean, minimal design. It contains only essential information and a QR code. The idea was to keep the print simple and use it as a trigger for interaction rather than a complete information source.

The Mobile Experience

After scanning the QR code, users land on a mobile-first website where they can personalize their coffee and interact with the product instead of simply viewing a static menu. The customization feature allows them to adjust their drink according to their preferences and save favorite combinations. In addition to the interactive builder, the website also includes sections such as “About” and “Favorites,” giving users the opportunity to learn more about the concept behind BrewCraft and explore the brand beyond the initial interaction.

Added Value

Without the mobile extension, the flyer would only provide static information. By connecting it to a mobile application, the user gets a personalized and interactive experience. The QR code bridges the physical and digital world, turning a simple café flyer into a small service interface.

Reflection

This project helped me understand how print can be used as a starting point rather than the main information carrier. The most important learning was that mobile web can add personalization and interaction to otherwise static print products.

View Website: p2-m-brew-craft.vercel.app

The post Print2Mobile: BrewCraft – Build Your Perfect Coffee appeared first on Mobile USTP MKL.