Laravel Mobile Pass Laravel Package

Technical Evaluation

Architecture Fit

• Pros:

  • Aligns with Laravel’s ecosystem, leveraging its Eloquent ORM, queues, and event system for pass generation and updates.
  • Supports Apple Wallet (iOS) and Google Pay (Android), addressing cross-platform mobile pass needs.
  • Modular design allows integration into existing Laravel applications without major architectural overhauls.
  • Push notifications for updates (via Apple/Google APIs) ensure real-time synchronization, critical for time-sensitive passes (e.g., event tickets, boarding passes).
  • Customizable templates (via JSON-LD) enable branding and functional flexibility (e.g., dynamic fields like expiration dates, barcodes, or loyalty points).

• Cons:

  • Not production-ready (explicitly marked as "IN DEVELOPMENT"), introducing technical debt risk (bugs, breaking changes, undocumented edge cases).
  • Apple Wallet/Google Pay API dependencies may introduce latency or rate-limiting issues if not pre-validated.
  • No native support for offline pass generation (relies on server-side rendering), which could complicate air-gapped or low-connectivity use cases.

Integration Feasibility

• Laravel Compatibility:

  • Requires Laravel 10.x+ (check compatibility with your stack; e.g., PHP 8.1+).
  • Assumes Eloquent models for pass data storage (e.g., Pass, PassUpdate).
  • Uses queues for async pass generation/updates (supports sync, database, or redis drivers).
  • Service Provider pattern for configuration (e.g., Apple/Google API keys, pass types).

• Third-Party Dependencies:

  • Apple Wallet: Requires Apple’s Wallet Web Service and a developer account ($99/year).
  • Google Pay: Requires Google Pay API and Play Console setup.
  • Barcode generation: Likely uses spatie/laravel-barcode (dependency not listed but implied by examples).

• Data Flow:

  [User Request] → [Laravel Controller] → [Queue Job] → [Pass Service] → [Apple/Google API] → [Mobile Device]
  

  Updates follow a similar path with webhook validation (e.g., verifying Apple’s push notification signatures).

Technical Risk

Key Questions

1. Use Case Criticality:
   • Are passes time-sensitive (e.g., boarding passes) or long-lived (e.g., loyalty cards)? This affects update frequency and API cost.
2. User Base:
   • What % of users have iOS/Android? Will you support both or prioritize one?
3. Existing Infrastructure:
   • Do you already use Apple/Google developer accounts? If not, budget for $99/year (Apple) + Play Console setup.
4. Data Sensitivity:
   • Will passes contain PII? If so, how will you handle deletion requests (Apple/Google require manual revocation).
5. Testing Strategy:
   • How will you validate passes before user-facing release? (e.g., manual testing with TestFlight/Google Pay Sandbox).
6. Scaling Assumptions:
   • What’s the expected peak load for pass generation? (e.g., 1000 passes/hour may require queue optimization.)
7. Fallback Plan:
   • How will you handle users without Wallet/Pay support? (e.g., PDF/email as secondary option).

Integration Approach

Stack Fit

• Laravel Core:

  • Eloquent Models: Store pass data (e.g., Pass, PassUpdate) with relationships to users/events.
  • Queues: Offload pass generation/updates to workers (e.g., PassGenerateJob, PassUpdateJob).
  • Events: Trigger PassGenerated, PassUpdated events for analytics or notifications.
  • Middleware: Validate Apple/Google API responses (e.g., ValidateApplePassSignature).

• Dependencies:

  Dependency	Purpose	Version Check
  spatie/laravel-barcode	Generate barcodes/QRs for passes.	v10.x
  guzzlehttp/guzzle	HTTP client for Apple/Google APIs.	^7.0
  spatie/array-to-object	Convert JSON-LD to PHP objects for pass templates.	^4.0
  laravel/framework	Core Laravel (test compatibility with your version).	10.x

• Database Schema:

  // Example Pass Model
  Schema::create('passes', function (Blueprint $table) {
      $table->id();
      $table->foreignId('user_id')->constrained();
      $table->string('type'); // 'boarding_pass', 'event_ticket', etc.
      $table->json('metadata'); // Dynamic fields (e.g., flight details)
      $table->string('serial_number')->unique(); // Required by Apple/Google
      $table->timestamps();
  });
  

Migration Path

1. Pre-Integration:

   • Set up Apple Developer Account and Google Pay API credentials.
   • Configure HTTPS and CORS for your Laravel app.
   • Test barcode generation (if using spatie/laravel-barcode).

2. Package Installation:

   composer require spatie/laravel-mobile-pass
   php artisan vendor:publish --provider="Spatie\MobilePass\MobilePassServiceProvider"
   

   • Publish config (config/mobile-pass.php) for API keys and pass types.

3. Model Setup:

   • Extend Spatie\MobilePass\Pass or create a custom model:

     use Spatie\MobilePass\Pass as BasePass;
     
     class BoardingPass extends BasePass {
         protected $type = 'boarding-pass';
         protected $logoUrl = 'https://example.com/logo.png';
     }
     

4. Pass Generation:

   • Use the PassGenerator facade:

     use Spatie\MobilePass\Facades\PassGenerator;
     
     $pass = PassGenerator::create(BoardingPass::class, [
         'flightNumber' => 'AA123',
         'departure' => 'JFK',
     ]);
     

   • Dispatch to queue:

     dispatch(new GeneratePassJob($pass));
     

5. Update Handling:

   • For updates, use PassUpdater:

     PassUpdater::update($pass, ['status' => 'boarded']);
     

6. Webhook Validation:

   • Implement a route to handle Apple/Google push notifications:

     Route::post('/apple-pass-updates', [ApplePassUpdateHandler::class, 'handle']);
     

Compatibility

• Laravel Versions:
  • Tested on 10.x; verify with your version (e.g., 9.x may require adjustments).
• PHP Extensions:
  • dom, fileinfo, mbstring (required for JSON-LD and barcode generation).
• Mobile OS:
  • iOS 12+ (Apple Wallet), Android 5.0+ (Google Pay).
  • Test with real devices (emulators may not fully support Wallet/Pay).

Sequencing