How to Render Web and Mobile Views in Laravel: A Developer's Guide

As a senior developer working with Laravel, you often encounter the challenge of serving different experiences—a fully optimized web interface versus a mobile-first view. When you have separate Blade files for these contexts, deciding which file to render based on the incoming request is a common architectural decision.

The approach you proposed—using an if/else statement directly inside your controller to select the view—is functional, but as we scale applications, it often becomes brittle and violates core principles like the Single Responsibility Principle (SRP). Let’s dive into why this is often not the best practice and explore more robust, Laravel-idiomatic solutions.

The Pitfall of Controller Logic for Presentation

Your suggested method looks like this:

// Inside a controller method
if ($request->header('Accept') === 'application/vnd.jenssegers+json') {
    return view('mobile_view'); // Or use View::make()
} else {
    return view('web_view');
}

While this works for simple scenarios, embedding complex presentation logic directly into your controller introduces several problems:

1. Violation of SRP: The controller’s job should primarily be handling request flow, business logic, and data retrieval. Mixing in specific presentation decisions makes the controller bloated and harder to maintain.
2. Tight Coupling: Your controller becomes tightly coupled to the specifics of view naming conventions. If you introduce a third format (e.g., an API response), you have to modify this conditional logic everywhere.
3. Scalability Issues: As your application grows, these if/else blocks become unwieldy. We need solutions that separate what data to show from how that data is presented.

Recommended Architectural Approaches

Instead of making controller the view selector, we should leverage Laravel's built-in features—Views, Layouts, and Service Layers—to handle this separation cleanly.

Approach 1: Leveraging Blade Layouts for Responsive Design (The Default)

For most modern web applications, the best practice is to use a single base layout file (app.blade.php) and use CSS/Blade directives within that file to conditionally display elements based on screen size or device type, rather than serving entirely separate views. This keeps your data logic centralized in the controller and presentation logic localized in the view.

Example using Blade:

{{-- resources/views/products/index.blade.php --}}
@extends('layouts.app')

@section('content')
    {{-- Standard web content for desktop --}}
    <div class="desktop-layout">
        <h1>Product List</h1>
        <!-- Full table structure here -->
    </div>
@endsection

{{-- resources/views/products/index.blade.php (Mobile adjustment) --}}
@extends('layouts.app')

@section('content')
    {{-- Mobile-specific content, often simpler list view --}}
    <div class="mobile-layout">
        <h1>Product List</h1>
        <!-- Simplified card structure here -->
    </div>
@endsection

This approach is highly flexible. You handle the data once in the controller, and the views determine the presentation based on CSS media queries applied to the HTML output. This aligns perfectly with the philosophy of building robust applications using frameworks like Laravel.

Approach 2: Using a Service Layer for Complex View Selection

If you truly need entirely different data sets or structure based on the client (e.g., a mobile view requires completely different relationships), delegate this selection to a dedicated service class. This keeps the controller clean and moves the decision-making into a domain layer, which is excellent practice when architecting larger systems, much like how robust applications are designed within the Laravel ecosystem.

// In your Controller
use App\Services\ViewSelectorService;

class ProductController extends Controller
{
    protected $viewSelector;

    public function __construct(ViewSelectorService $viewSelector)
    {
        $this->viewSelector = $viewSelector;
    }

    public function showProducts(Request $request)
    {
        // The service decides which view to load based on request context
        $viewName = $this->viewSelector->getLayoutFor($request);

        return view($viewName);
    }
}

The ViewSelectorService would contain the complex logic to determine if it should return 'web_view' or 'mobile_view', making your controller purely responsible for orchestrating the request.

Conclusion

While your initial instinct to use an if/else statement is a starting point, senior development demands architectural elegance. For rendering web and mobile views in Laravel, I strongly recommend Approach 1 (Conditional Blade Rendering) for responsive adjustments and Approach 2 (Service Layer) for handling fundamentally different data structures. By separating presentation logic from business logic, you ensure your application remains maintainable, scalable, and adheres to the principles of clean code that underpin great frameworks like Laravel. Always strive for solutions that organize complexity logically, just as we aim to do when building powerful systems on the foundation provided by the Laravel framework.