TrySound / TrySound/libras

Add iOS native support with a minimal Tauri 2 wrapper

Open
#4 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
9
Forks
0
Avg merge
12h 12m
Merged PRs (30d)
24

Description

Goal

Ship an iOS app using Tauri 2 with minimal changes to the current web app. Reuse the shared wrapper/build work from #3. Keep Svelte, HTML audio, browser Media Session, OPFS, and the Subsonic client initially; validate WKWebView independently rather than assuming Android or Safari/PWA behavior applies.

Scope

  • Add the iOS Tauri target, app identity/icons, signing/provisioning, and build configuration.
  • Document macOS/Xcode/Rust requirements, device builds, and TestFlight/App Store distribution requirements; keep signing secrets out of the repository.
  • Reuse a native Vite build with bundled assets and PWA generation, registration, and update UI disabled.
  • Preserve the existing web build/deployment workflow.
  • Select a minimum iOS version and verify HTML audio, Media Session, OPFS reads/streamed writes, Navigation API, URLPattern, and other required APIs in WKWebView. Add only necessary compatibility fixes.
  • Test authentication, browsing, artwork, streaming, and downloads against HTTPS servers, including CORS for the actual wrapper origin and App Transport Security behavior.
  • Verify safe-area insets, keyboard resizing, and back/swipe navigation.
  • Keep the packaged origin stable across updates and document that Safari/PWA data does not transfer automatically.

Background playback investigation

  • Test the existing HTML audio/Media Session implementation on a real iPhone.
  • Determine whether native audio-session configuration and the background-audio capability are needed for HTML audio playback.
  • Verify automatic queue advancement with the screen locked and the UI backgrounded; background-audio configuration alone does not guarantee JavaScript execution.
  • Introduce native playback or storage only if testing demonstrates a concrete limitation; document the findings before expanding scope.

Real-device acceptance tests

  • Foreground streaming and seeking work.
  • Lock-screen/Control Center metadata and controls, Bluetooth controls, interruptions, and audio-route changes behave correctly.
  • Extended screen-off/background playback continues and advances automatically between tracks.
  • Downloads survive restart and play after an airplane-mode cold launch.
  • Verify large downloads, quotas/storage pressure, and behavior when backgrounding a download.
  • App updates preserve credentials, queue, position, and downloaded music.
  • Record lifecycle/process-recreation limitations and any differences from Android.

First milestone

An installable development build on an iPhone using the existing web player and storage. Background playback remains an acceptance-test question, not an assumed benefit of the wrapper. Native releases use the iOS distribution workflow, not the PWA updater.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the shared wrapper/build work from #3 and the existing web player and storage behavior, then create the first installable iPhone development build with the native Vite and bundled-asset path. Validate the listed WKWebView APIs and foreground streaming, seeking, authentication, browsing, artwork, and downloads on a real device; the first milestone is an installable build, with background playback findings documented rather than assumed.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
audio-video-rtc, build-system, mobile
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.