Portfoldio

Sechs Plattformen aus einer Codebasis

Portfoldio ist mein eigenes Produkt — und damit auch das Projekt, in dem ich die größten Freiheitsgrade bei Architekturentscheidungen hatte. Die kompromisslose Wahl: eine Codebasis für sechs Plattformen. iOS, Android, Web, macOS, Windows, Linux laufen aus dem gleichen Flutter-Repository, mit minimaler plattformspezifischer Logik (vor allem In-App-Purchase und biometrische Authentifizierung, beide hinter Abstraktionen).

Das ist kein „dann läuft die App halt auf dem Mac”-Versprechen — es bedeutet, dass eine neue Funktion in einer Session implementiert und auf allen sechs Plattformen ausgeliefert wird. Das ist die einzige Art, wie ein Solo-Entwickler überhaupt sechs Plattformen seriös bedienen kann.

Die Architektur teilt sich in drei klar getrennte Ebenen:

1. State-Layer (BLoC): alle State-Übergänge sind Events, alle Reads sind reine Funktionen über den State. Bei der schieren Zahl asynchroner Flows (Auth ↔ Sync ↔ IAP ↔ Subscription ↔ Watchlist ↔ Live-Kurse) zahlt sich BLoC mit seiner Strenge aus — Provider/Riverpod wäre flexibler, aber bei diesem Maß an Cross-Cutting-Effekten unübersichtlich geworden.
2. Data-Layer (Repository + Hive + GraphQL): jede Datenart hat ein Repository, das Hive (lokaler Cache) und Supabase (Cloud-Quelle) zusammenführt. Schreibvorgänge gehen optimistisch lokal raus und werden später im Hintergrund synchronisiert.
3. Presentation-Layer: Widgets, die direkt auf BLoC-States hören. Keine ViewModels, keine Controller — der State ist das Modell, das Widget rendert ihn.

Vorgehen

Die App ist um drei klare Achsen organisiert. Das BLoC-Pattern für State-Management (vor allem für die Vielzahl asynchroner Flows — Auth, Sync, Subscriptions, In-App-Purchases). GraphQL-Codegen gegen Supabase pg_graphql für typsichere Abfragen und Mutations, dazu Live-Kurse als GraphQL-Subscription. Hive als lokale Cache-Schicht, sodass die App auch im Flugmodus benutzbar bleibt. Sensible Aktionen (Login, Werte einsehen) sind hinter local_auth (FaceID / TouchID) abgesichert.

Dazu kommt ein weniger sichtbarer, aber genauso wichtiger Block: die Build- und Release-Pipeline. Eine Flutter-App auf sechs Plattformen ist sechsmal die Möglichkeit, sich in Signing-Themen zu verlieren. Wir haben das früh in Skripte gegossen — pro Plattform ein klar dokumentierter Pfad von flutter build zu „artefakt in der jeweiligen Store-/Distribution-Pipeline”.

// Sync-Bloc: koordiniert Auth-Status, Online-Status und letzten Sync-Stempel.
on<SyncRequested>((event, emit) async {
  if (!await _auth.isSignedIn()) return emit(SyncIdle.signedOut());
  emit(SyncRunning(startedAt: DateTime.now()));
  try {
    final remote = await _gql.fetchPortfolio(userId: _auth.userId);
    await _cache.replaceAll(remote);                // last-write-wins
    emit(SyncIdle.success(at: DateTime.now()));
  } on NetworkException catch (e) {
    emit(SyncIdle.offline(lastSyncAt: await _cache.lastSyncAt()));
  } catch (e, s) {
    emit(SyncIdle.failed(error: e.toString()));
  }
});

Tiefe Einblicke

@freezed
class PortfolioState with _$PortfolioState {
  const factory PortfolioState.loading() = _Loading;

  const factory PortfolioState.loaded({
    required List<Position> positions,
    required Money totalValue,
    required Map<String, Decimal> dailyChange,
    required SyncStatus syncStatus,
  }) = _Loaded;

  const factory PortfolioState.error(String message) = _Error;
}

// Exhaustive switch in der UI — der Compiler erzwingt jeden Fall.
Widget build(BuildContext context) =>
  state.when(
    loading: () => const Shimmer(),
    loaded: (positions, total, change, sync) =>
        PortfolioView(positions, total, change, sync),
    error: (msg) => ErrorView(msg),
  );

// GraphQL-Subscription pro Watchlist — pg_graphql Streams.
Stream<Price> watchPrices(List<String> symbols) {
  final result = _client.subscribe(
    SubscriptionOptions(
      document: gql(r"""
        subscription WatchPrices($symbols: [String!]!) {
          prices(where: { symbol: { in: $symbols } }) {
            symbol price change_24h currency updated_at
          }
        }
      """),
      variables: {'symbols': symbols},
    ),
  );

  return result
      .where((r) => r.data != null)
      .map((r) => Price.fromJson(r.data!['prices']));
}

class PriceCache {
  final Box<Price> _box;

  PriceCache(this._box);

  Future<Price?> get(String symbol) async => _box.get(symbol);

  Future<void> put(Price p) async => _box.put(p.symbol, p);

  // UI abonniert direkt: Schreibt der Sync, rendert das Widget neu.
  Stream<Price?> watch(String symbol) =>
      _box
          .watch(key: symbol)
          .map((e) => e.value as Price?)
          .startWith(_box.get(symbol));
}

serve(async (req) => {
  const { receipt, platform, user_id } = await req.json();
  const verified = platform === 'ios'
    ? await verifyApple(receipt)
    : await verifyGoogle(receipt);

  if (!verified.valid) {
    return new Response(JSON.stringify({ tier: 'free' }), { status: 200 });
  }

  await supabase.from('subscriptions').upsert({
    user_id,
    tier: verified.tier,        // 'plus' | 'pro' | 'family'
    expires_at: verified.expiresAt,
    platform,
    original_transaction_id: verified.txId,
  });

  return new Response(JSON.stringify({ tier: verified.tier }), { status: 200 });
});

#: lib/portfolio/widgets/position_count.dart:24
#, dart-format
msgid "{count, plural, one {1 Position} other {{count} Positionen}}"
msgstr ""

#: lib/portfolio/widgets/last_synced.dart:18
#, dart-format
msgid "Letzte Synchronisation vor {minutes} Min."
msgstr ""

#: lib/iap/paywall.dart:42
msgid "Portfoldio Plus freischalten"
msgstr ""

Was zwei Jahre Produktion gezeigt haben

Drei Punkte, an denen ich mir am Anfang nicht sicher war, die sich aber im Betrieb klar entschieden haben:

Web ist die wichtigste Plattform, nicht iOS. Klingt absurd für eine „mobile-first”-App, aber: viele Nutzer kommen über die Web-App rein, probieren sie aus, und installieren erst danach die mobile Version. Die Web-Variante muss daher dieselbe Qualität haben wie die App. Flutter Web kommt 2024+ damit hin, solange man Frame-Budget-bewusst baut — keine Listen mit hunderten gerenderten Items ohne ListView.builder, kein setState auf einer Root-Komponente.

Offline-First ändert das Feedback-Verhalten der App komplett. Wenn der Nutzer nicht einmal auf einen Spinner schaut, sondern sofort die letzten Daten sieht und der Refresh im Hintergrund passiert, fühlt sich das wie native iOS-Apps an. Das war von Beginn an Architekturprämisse — und ist im Nachhinein der wichtigste Punkt, weshalb Nutzer länger bleiben.

Subscription-Logik ist 5 % der Codebase und 30 % der Bug-Reports. Server-side-Verifikation, Family-Plan-Sharing, Restore-Purchase, Subscription-Wechsel innerhalb des Tiers, plattformübergreifende Abos (jemand kauft auf iOS, will aber im Web nutzen) — jeder dieser Fälle hat seine eigenen Edge-Cases. Lessons-Learned: testbare reine Funktionen für „aus diesem Receipt folgt dieser Tier”, dazu eine kleine Matrix an integration tests, die die häufigsten Pfade abdeckt.