Complete Back-end for iOS Party Game
Budget: $250 – $750 USD
Project: [APPNAME] (iOS Multiplayer Party Game)
Current Status
Development Stage: 8/10.
Frontend: SwiftUI app is ready; navigation, game rules, and UI components are functional.
Local Persistence: SwiftData is the primary source of truth on the device for session history, teams, and performance.
Backend: Supabase (PostgreSQL) is partially implemented for authentication, deck catalogs, and cloud lobbies.
Primary Blocker: Finalizing the "handshake" between local P2P gameplay and the Supabase cloud layer, specifically regarding state persistence and security validation.
Technical Architecture: Local-First / Cloud-Synced
The game utilizes a hybrid architecture to ensure low-latency gameplay while maintaining global persistence:
Real-time Gameplay: Driven by MultipeerConnectivity (P2P). The host drives the state, and clients apply messages locally. There is currently no Supabase traffic during active turns.
Cloud Persistence: Supabase is used for lobby creation (4-digit numeric codes), best-effort session history uploads, and AI-generated deck management via Edge Functions.
Synchronization: The app performs a launch-time sync (catalog refresh) and a post-game async upload of session data.
Monetization: StoreKit 2 is integrated but requires reconciliation between verified transactions and the local SwiftData PurchasedDeck model.
Work Required (Final 20%)
Security & RLS Optimization: Tighten Row Level Security policies, specifically for the multiplayer_games and past_players tables to prevent data scraping or unauthorized access.
Real-time Decision & Implementation: The database is configured for Realtime, but the iOS client currently lacks subscription logic. You will either implement Supabase Realtime for cloud lobbies/spectators or harden the existing P2P-only architecture.
Conflict Resolution: Refine the "Sync Handshake" to ensure data integrity when bridging local SwiftData models to Supabase PostgreSQL rows.
Edge Case Validation: Conduct end-to-end testing for host-drop scenarios, client reconnection, and cloud-snapshot restoration (resuming a game from a cloud state).
Schema Cleanup: Resolve identified "Schema Drift" (e.g., unwired ReviewRequestModel) and unify unique constraints for device-level upserts.
Timeline & Engagement
Deadline: Less than 30 days to App Store submission.
Availability: Looking for a partner to start within 2 weeks.
Collaboration: This is a lead project for WatersWorks Technology Solutions. We are looking for a reliable partner for ongoing work across our mobile software portfolio.
Questions for Your Quote
How do you handle conflict resolution between SwiftData and Supabase when performing asynchronous, best-effort uploads?
What is your experience with StoreKit 2 server-side validation and reconciling local purchase models with cloud records?
Given that our in-round gameplay is P2P-only for performance, do you recommend maintaining the current Supabase Realtime publication or moving lobby discovery to a different trigger?
Are you available for a 1-hour paid technical audit of our existing PostgreSQL schema and RLS policies this week?
Technical Note for Bidders: A full technical architecture document, PostgreSQL DDL export, and a prioritized 20-item tasklist are available for review upon request.
Current Status
Development Stage: 8/10.
Frontend: SwiftUI app is ready; navigation, game rules, and UI components are functional.
Local Persistence: SwiftData is the primary source of truth on the device for session history, teams, and performance.
Backend: Supabase (PostgreSQL) is partially implemented for authentication, deck catalogs, and cloud lobbies.
Primary Blocker: Finalizing the "handshake" between local P2P gameplay and the Supabase cloud layer, specifically regarding state persistence and security validation.
Technical Architecture: Local-First / Cloud-Synced
The game utilizes a hybrid architecture to ensure low-latency gameplay while maintaining global persistence:
Real-time Gameplay: Driven by MultipeerConnectivity (P2P). The host drives the state, and clients apply messages locally. There is currently no Supabase traffic during active turns.
Cloud Persistence: Supabase is used for lobby creation (4-digit numeric codes), best-effort session history uploads, and AI-generated deck management via Edge Functions.
Synchronization: The app performs a launch-time sync (catalog refresh) and a post-game async upload of session data.
Monetization: StoreKit 2 is integrated but requires reconciliation between verified transactions and the local SwiftData PurchasedDeck model.
Work Required (Final 20%)
Security & RLS Optimization: Tighten Row Level Security policies, specifically for the multiplayer_games and past_players tables to prevent data scraping or unauthorized access.
Real-time Decision & Implementation: The database is configured for Realtime, but the iOS client currently lacks subscription logic. You will either implement Supabase Realtime for cloud lobbies/spectators or harden the existing P2P-only architecture.
Conflict Resolution: Refine the "Sync Handshake" to ensure data integrity when bridging local SwiftData models to Supabase PostgreSQL rows.
Edge Case Validation: Conduct end-to-end testing for host-drop scenarios, client reconnection, and cloud-snapshot restoration (resuming a game from a cloud state).
Schema Cleanup: Resolve identified "Schema Drift" (e.g., unwired ReviewRequestModel) and unify unique constraints for device-level upserts.
Timeline & Engagement
Deadline: Less than 30 days to App Store submission.
Availability: Looking for a partner to start within 2 weeks.
Collaboration: This is a lead project for WatersWorks Technology Solutions. We are looking for a reliable partner for ongoing work across our mobile software portfolio.
Questions for Your Quote
How do you handle conflict resolution between SwiftData and Supabase when performing asynchronous, best-effort uploads?
What is your experience with StoreKit 2 server-side validation and reconciling local purchase models with cloud records?
Given that our in-round gameplay is P2P-only for performance, do you recommend maintaining the current Supabase Realtime publication or moving lobby discovery to a different trigger?
Are you available for a 1-hour paid technical audit of our existing PostgreSQL schema and RLS policies this week?
Technical Note for Bidders: A full technical architecture document, PostgreSQL DDL export, and a prioritized 20-item tasklist are available for review upon request.