Laravel Appleseed Laravel Package

Getting Started

Before installing, verify the package actually fits your Laravel version. mike-bronner/laravel-appleseed was last released in November 2015, so it targets the Laravel 5.x era and predates package auto-discovery. On Laravel 5.5+ or any modern Laravel application, treat it as a reference implementation rather than a dependency.

Minimal install for a legacy Laravel 5.x app:

composer require mike-bronner/laravel-appleseed

Register the service provider manually in config/app.php:

'providers' => [
    // ...
    MikeBronner\Appleseed\AppleseedServiceProvider::class,
],

Look first at:

• vendor/mike-bronner/laravel-appleseed/src/ — the service provider and route definitions are the whole package.
• config/app.php — confirm the provider is registered exactly once.
• php artisan route:list | grep -i apple — confirm the package routes are actually registered.
• storage/logs/laravel.log — confirm the exact URL variants that are spamming your logs.

The first use case is simple: iOS Safari requests /apple-touch-icon.png and /apple-touch-icon-precomposed.png when no icon is declared, and your app logs 404s for those paths. After installing, verify with:

curl -I https://your-app.test/apple-touch-icon.png
curl -I https://your-app.test/apple-touch-icon-precomposed.png

You want a non-404 response and no new log entry. Also check the browser network tab from an iOS device or Safari responsive mode.

If the package does not install cleanly on your Laravel version, reproduce its behavior directly. The day-to-day value is the route, not the dependency:

// routes/web.php
Route::get('/apple-touch-icon.png', fn () => response()->noContent());
Route::get('/apple-touch-icon-precomposed.png', fn () => response()->noContent());

Implementation Patterns

Use it as a 404 suppressor, not an icon server. The package exists to stop log noise. If you have a real Apple Touch Icon, put it in public/apple-touch-icon.png and let Nginx/Apache serve it directly. Add the corresponding HTML so iOS stops guessing:

<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">

The package then only matters as a fallback for clients that still probe the default paths.

Configure a real icon if the package supports it. Check the package source for a publishable config file. If present:

php artisan vendor:publish --provider="MikeBronner\Appleseed\AppleseedServiceProvider"

Then inspect config/appleseed.php or similarly named config for an icon path, response status, or enable/disable flag. Prefer serving the actual image bytes over redirecting; older iOS versions are unreliable about following redirects for touch icons.

Gate it to production if log noise is the concern. If the provider registers routes unconditionally and you do not want them in local/testing, either wrap registration in a custom service provider or add middleware/config checks. A common pattern is to keep the package route in production and let local environments show the 404 so missing assets are visible during development.

Register before fallback routes. If your application defines Route::fallback(...) or a catch-all, confirm route:list shows the apple-touch routes ahead of it. In Laravel 5.x, provider routes are normally registered during boot before routes/web.php, but route caching can freeze an unexpected order. After any change:

php artisan route:clear
php artisan route:cache

Handle the common size variants deliberately. iOS may request paths such as /apple-touch-icon-120x120.png, /apple-touch-icon-152x152.png, and /apple-touch-icon-180x180.png. Decide whether you want a catch-all pattern or explicit routes:

Route::get('/apple-touch-icon{size?}.png', function ($size = null) {
    return response()->noContent();
})->where('size', '-?[0-9]+x[0-9]+');

Only do this if you are comfortable masking all missing icon probes; otherwise list the exact paths you see in logs.

Test the behavior in your HTTP test suite. A simple assertion prevents a future route refactor from reintroducing the noise:

public function test_apple_touch_icon_does_not_404(): void
{
    $this->get('/apple-touch-icon.png')->assertStatus(204);
    $this->get('/apple-touch-icon-precomposed.png')->assertStatus(204);
}

Adjust the expected status to whatever the package actually returns in your version.

Use logging context to distinguish sources. If the log noise continues, check whether it comes from the application or the web server. Laravel logs a 404 only when the request reaches Laravel; Nginx/Apache access logs may still show missing static assets even when the package route works.

Gotchas and Tips

• The package is effectively abandoned. Last release in 2015, 30 stars, and no modern Laravel support. Do not add it to a new Laravel 9/10/11 application; copy the two-line route instead. Composer may fail on PHP 8 due to old illuminate/support constraints, and --ignore-platform-reqs is not a fix.

• No package auto-discovery. Laravel 5.5+ expects extra.laravel.providers in composer.json. A 2015 package will not have it, so manual registration is required in legacy apps.

• Clear caches after every change. Route caching, config caching, and OPcache can all hide a newly registered provider or changed config. Run php artisan route:clear, php artisan config:clear, and restart PHP-FPM if necessary.

• Check provider order. If another package or your own code registers a catch-all or fallback route first, the apple-touch route may never be reached. php artisan route:list is the fastest diagnostic.

• Web-server rewrites can bypass Laravel. For Nginx, ensure missing files fall through to index.php:

  location / {
      try_files $uri $uri/ /index.php?$query_string;
  }
  

  If the server returns its own 404 for /apple-touch-icon.png, the package never runs and the log noise persists.

• A 200 with an empty body stops Laravel logging but not all client requests. iOS may re-request the icon on subsequent visits. Add cache headers if the package or your custom route allows it, or serve a real icon.

• Do not redirect unless you have verified iOS behavior. Touch-icon fetching on older iOS versions can be inconsistent with redirects. Returning 204 No Content or the actual image bytes is safer.

• favicon.ico is not covered. Browsers and bots also request /favicon.ico; this package only addresses Apple Touch Icon paths. Handle favicon separately.

• Masking can hide real asset problems. If your layout references a missing touch icon path, a blanket 204 response hides the mistake. Prefer declaring the icon in HTML and using the package only as a fallback.

• Do not build a file-serving route from request input. If you extend the package to serve icons dynamically, never pass the request path directly into response()->file() or Storage::get(). Use a fixed allowlist of icon paths.

• Extension point is the service provider, not a stable API. Since the package is tiny, the most maintainable extension is to fork the provider or replace it with an application route. Publish config if available, but expect no documented upgrade path.

• Treat the package as a snippet with a Composer wrapper. The score and maintenance history suggest it is not a long-term dependency. The day-to-day recommendation is to replicate the route in your own application and remove the dependency once the log noise is gone.