feat: prepare v0.1.0 and redesign the cross-platform send experience

Prepare Sync360 for its first public Android and Windows release while
improving the send flow across Android, desktop, and iOS.

Send experience:
- replace secondary send tabs with a Material 3 Expressive button group
- add explicit nearby-device selection before starting a transfer
- show contextual send actions using the selected device name
- keep selected-device state and derived send availability in screen state
- validate selected content and target device in the ViewModel
- clear device selection when the selected device is no longer available
- improve empty, scanning, selected, and unavailable device presentation
- add accessible radio-selection semantics to nearby-device cards
- simplify nearby-device information by hiding unnecessary technical details
- add text character count, clear action, and improved input guidance

File selection:
- introduce shared file-selection content across supported platforms
- replace the expanding vertical file list with a horizontal lazy row
- add larger file cards with filenames, sizes, previews, and remove actions
- display image thumbnails when available through Coil
- show suitable file-type fallbacks for files without image previews
- report selected file count and total size without misrepresenting unknown sizes
- prevent duplicate files from being added using their stable URI
- change the picker action from selecting files to adding more files
- keep picker implementations platform-specific while sharing presentation
- fix desktop file selection by reading files from the AWT dialog explicitly
- preserve the iOS document-picker delegate for the required native lifetime
- keep Android picker and URI handling inside the Android implementation

Architecture and state:
- keep UI components declarative and driven by immutable screen state
- route user actions through callbacks and ViewModel event handlers
- avoid platform ViewModel injection inside file-picker implementations
- centralize shared file presentation without changing transfer behavior
- use supported Material 3 Expressive button-group APIs
- preserve existing network discovery and transfer flows

Release preparation:
- set Android, desktop, and iOS version metadata to 0.1.0
- add optional Android release-signing configuration through ignored properties
- provide a safe example keystore-properties file
- configure Windows MSI packaging and stable upgrade identity
- resize the desktop splash artwork for a more appropriate launch window
- keep local signing credentials and generated release material out of Git

Documentation:
- update README platform and installation information
- document current Android and Windows packaging workflows
- clarify local-network behavior, privacy, and present security limitations
- update architecture, development, contribution, and open-source notes
- refresh roadmap, changelog, store listing, and security guidance
- remove or correct stale platform and implementation claims

No Gradle builds or automated tests were run.

Author: CodePandaaAI

.gitignore

@@ -24,6 +24,7 @@ captures/
 
 # Signing secrets
 *.jks
+*.jkis
 *.keystore
 keystore.properties
 

CHANGELOG.md

@@ -25,6 +25,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 - Compose Desktop startup, platform DI implementations, native file dialog, clipboard, and Downloads actions.
 - Navigation 3 adaptive 50/50 Send/Receive scene for wider windows.
 - Application-lifetime network startup and state-driven connection repair.
+- Enabled iOS device and Apple-silicon Simulator targets with native Bonjour discovery, document selection, clipboard, Files-visible storage, and streamed TCP transfer implementations.
+- Added an iOS-only GitHub Actions workflow for an unsigned Simulator app and optional development-signed iPhone IPA.
+- Prepared version `0.1.0` across Android, Desktop, and iOS; added private Android release signing configuration and a permanent Windows MSI upgrade identity.
 - Public architecture, development, roadmap, security, privacy, and contribution documentation.
 
 ### Changed
@@ -52,4 +55,4 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 - No speed, ETA, retry, pause/resume, or interrupted-transfer recovery; transfer progress currently shows batch-wide whole-byte percentage.
 - Foreground/background and network-change lifecycle handling are incomplete.
 - Desktop support needs broader operating-system, adapter, firewall, and router validation.
-- Automated transfer coverage is minimal; iOS is inactive.
+- Automated transfer coverage is minimal; iOS physical-device discovery and transfer are unverified.

CODE_OF_CONDUCT.md

@@ -30,7 +30,7 @@ Project maintainers may remove comments, close issues, reject contributions, or
 
 If you see a problem, report it privately to the maintainer.
 
-Maintainer contact: TODO: add private contact email
+Until a dedicated contact email is added, contact the maintainer privately through the GitHub or LinkedIn profile linked in `README.md`.
 
 ## Scope
 

CONTRIBUTING.md

@@ -13,13 +13,14 @@ Implemented today:
 - Current macOS/Linux discovery and registration through JmDNS.
 - Direct text and multi-file transfer between nearby devices.
 - Shared Compose UI for Android and Desktop.
+- Enabled iOS source implementation for Bonjour discovery, text/file transfer, selection, clipboard, and Files-visible storage.
 
 Important current limitations:
 
 - Local transfers are not authenticated or encrypted.
 - Background and automatic network-change lifecycle handling is incomplete.
 - Desktop networking has not been broadly validated across operating systems, adapters, VPNs, and routers.
-- iOS platform implementations are inactive.
+- iOS physical-device discovery and transfer behavior is not yet validated.
 
 Please keep that status in mind when opening issues or PRs.
 

PRIVACY.md

@@ -1,33 +1,35 @@
 # Sync360 Privacy
 
-Last updated: June 29, 2026
+Last updated: August 3, 2026
 
-Sync360 is currently an early rebuild prototype. The current Android-first milestone supports local discovery and a simple Ktor request/response proof between nearby devices. Real text transfer, file transfer, production security, and public releases are not implemented yet.
+Sync360 sends text and files directly between nearby devices on the same reachable local network. It does not use a Sync360 account, cloud-storage service, analytics service, advertising service, or Sync360 transfer backend.
 
 ## Data Handling
 
 - No account is required.
-- No cloud service is used by the current prototype flow.
+- No cloud service is used for discovery or transfer.
 - No analytics, advertising, tracking, or telemetry is included.
 - A random installation identifier is stored locally so devices can identify each other.
-- Nearby-device discovery data stays on the local device while the app is running.
-- The current prototype does not transfer or save user-selected files.
-- The current prototype does not send user content to the developer.
+- Nearby-device discovery information is exchanged only with devices on the reachable local network and is kept as runtime state.
+- Text and selected files are sent directly to the receiver chosen by the user after the receiver approves the offer.
+- Received files remain on the receiving device in its platform Downloads location.
+- Shared text and transfer state are temporary runtime state; Sync360 does not maintain chat or clipboard history.
+- Sync360 does not send shared content to the developer.
 
 ## Network Security
 
-The current prototype uses cleartext HTTP on the local network for learning and testing. Final authentication, session validation, request signing, replay protection, and encryption are not implemented yet.
+Sync360 currently uses cleartext local HTTP for offers and text and raw TCP for file bytes. Sender authentication, session validation, request signing, replay protection, encryption, and cryptographic integrity verification are not implemented yet. Receiver approval exists in the UI but is not a complete security boundary.
 
 Do not treat the current code as production-secure file-transfer software. Use it only on private networks you control while testing.
 
 ## Permissions
 
-Sync360 uses network access for local discovery and request/response testing. Future versions may require additional Android permissions for reliable transfer sessions, notifications, foreground services, wake locks, Wi-Fi multicast behavior, and file access.
+Sync360 uses network access for local discovery and direct transfer. Android uses system file pickers and `MediaStore` for selected and received files. iOS source declares local-network and Bonjour usage and exposes its app Documents directory through Files. Future lifecycle work may require notification, foreground-service, wake-lock, or other platform permissions.
 
 ## Retention
 
-The current prototype stores a local installation identifier. Discovery/request state is runtime state. Real transfer retention behavior will be documented when file transfer is implemented.
+Sync360 stores a local installation identifier. Discovery, offer, text, and transfer state are runtime state. Files successfully received remain in Downloads until the user removes them through the operating system. Incomplete current files are removed after receive failure or cancellation where the platform implementation supports it.
 
 ## Contact
 
-Add a support email or website before publishing this policy.
+For privacy questions, contact the maintainer through the GitHub profile linked in `README.md`. Report security-sensitive findings through the private-contact guidance in `SECURITY.md`.

README.md

@@ -42,7 +42,7 @@ Chat apps and cloud drives are great when the other person is far away. Sync360
 
 ## Current status
 
-Sync360 has a working Android-to-Android MVP for text and multiple-file transfer. The Desktop/JVM app now uses the same shared flow, and Desktop-to-Android file transfer is working in manual testing. It is still an active rebuild, not a production-ready release.
+Sync360 has a working Android-to-Android MVP for text and multiple-file transfer. The Desktop/JVM app now uses the same shared flow, and Desktop-to-Android file transfer is working in manual testing. An initial iOS implementation is enabled in source and has opened successfully in a cloud simulator, but nearby discovery and transfer still need physical-device validation. It is still an active rebuild, not a production-ready release.
 
 In an initial Windows 11 Ethernet test, the native Windows DNS-SD backend discovered the Android device quickly, removed it promptly after the Android app closed, appeared promptly on Android after Sync360 started, and disappeared from Android after the Desktop app closed. The Desktop discovery UI also left its initial loading state when the native browse operation started instead of continuing to show loading while resolved devices were already visible. These are manual observations from one setup, not broad Windows or laptop compatibility guarantees.
 
@@ -67,6 +67,7 @@ In an initial Windows 11 Ethernet test, the native Windows DNS-SD backend discov
 - Save received Desktop files safely into Downloads through a temporary `.part` file, then move completed files into place without overwriting an existing name.
 - Copy received text and open the Downloads folder on Desktop.
 - Open connection troubleshooting from Send, Receive, or the top app bar, then manually restart local discovery and service advertising without resetting the app or removing received files.
+- Provide enabled iOS device and simulator targets with native Bonjour discovery, file selection, clipboard, Files-visible storage, and streamed TCP transfer implementations.
 
 ### Still needs work
 
@@ -79,7 +80,8 @@ In an initial Windows 11 Ethernet test, the native Windows DNS-SD backend discov
 - Automated transfer coverage and broader device/router testing.
 - Broader Desktop validation across Windows, macOS, Linux, routers, firewalls, VPNs, and machines with multiple network adapters.
 - Desktop packaging and release testing.
-- iOS discovery, transfer, and storage implementations.
+- Physical iOS device testing for local-network permission, discovery, text/file transfer, cancellation, and Files behavior.
+- Public iOS packaging, signing, and distribution.
 
 The current progress UI tracks the exact bytes transferred across the accepted batch and displays the resulting percentage.
 
@@ -154,9 +156,10 @@ Compose screen -> ViewModel -> controller/service -> common contract -> platform
 - `shared/src/androidMain/` — Android NSD, file selection metadata, clipboard, local identity, raw TCP transfer, Downloads storage, and Android DI bindings.
 - `shared/src/jvmMain/` — Windows system DNS-SD and macOS/Linux JmDNS discovery/registration, native file selection metadata, clipboard, local identity, raw TCP transfer, Downloads storage, and Desktop DI bindings.
 - `desktopApp/` — Compose Desktop entry point and DMG/MSI/DEB packaging configuration.
-- `iosApp/` — iOS shell; iOS targets are currently disabled in the shared Gradle configuration.
+- `shared/src/iosMain/` — iOS Bonjour discovery/registration, file selection, clipboard, identity, streamed TCP transfer, Files-visible storage, and iOS DI bindings.
+- `iosApp/` — SwiftUI iOS host for the enabled device and Apple-silicon Simulator targets.
 
-The project remains Android-first, but the current Desktop app reuses the shared UI, ViewModels, controllers, HTTP protocol, and transfer contracts. Platform source sets implement only the parts that require Android or JVM APIs.
+The project remains Android-first, but Desktop and iOS reuse the shared UI, ViewModels, controllers, HTTP protocol, and transfer contracts. Platform source sets implement only the parts that require Android, JVM, or iOS APIs.
 
 ## Tech stack
 
@@ -262,7 +265,7 @@ Use the current app only for development and testing on private networks you con
 ### Later: bring the same simple flow to more devices
 
 - Desktop packaging, release workflow, and broader compatibility testing.
-- iOS investigation and implementation.
+- iOS physical-device validation, signing, and distribution.
 - More actionable connection errors and broader troubleshooting guidance.
 - Retry or resume support where the added protocol complexity is justified.
 

SECURITY.md

@@ -1,8 +1,8 @@
 # Security Policy
 
-Sync360 is an early local-network sharing app. It is not production-secure yet.
+Sync360 is an early local-network sharing app. It is not secure for untrusted networks yet.
 
-The current rebuild intentionally focuses on understanding local discovery and request/response before adding the final security model. Security work is planned, especially before real file transfer is treated as user-ready.
+The current rebuild implements local discovery, receiver-approved text sharing, and streamed file transfer before adding the final security model. Security work remains required before untrusted-network use.
 
 ## Supported versions
 
@@ -16,13 +16,7 @@ There are no stable supported releases yet.
 
 Please do not open a public issue for security-sensitive reports.
 
-Send private reports to:
-
-```text
-TODO: add security contact email
-```
-
-Until a contact email is added, please contact the maintainer privately through their GitHub/LinkedIn profile once available.
+Until a dedicated security email is added, contact the maintainer privately through the GitHub or LinkedIn profile linked in `README.md`. Do not include exploit details in a public issue.
 
 ## What to report privately
 
@@ -43,16 +37,15 @@ General bugs, crashes, UI issues, documentation problems, and non-sensitive arch
 
 ## Current security status
 
-Current implementation is a learning-stage prototype:
+Current implementation:
 
-- Android NSD discovery works.
-- Ktor request/response proof exists.
-- Receiver Accept/Decline proof exists.
-- Real file transfer is not implemented yet.
-- Final authentication/session validation is not implemented yet.
-- Encryption is not implemented yet.
+- Android NSD, Windows system DNS-SD, macOS/Linux JmDNS, and an initial iOS Bonjour implementation exist.
+- Ktor carries text/file offers, receiver decisions, metadata, and accepted text.
+- Raw TCP streams accepted file batches to platform Downloads storage.
+- File names and promised sizes are validated, but a file socket is not bound to its approved offer with a session token.
+- Sender authentication, encryption, replay protection, and cryptographic integrity verification are not implemented.
 
-Do not use the current code as a security model for production file transfer.
+Use current builds only on private local networks you control. Do not use the current code as a security model for production file transfer.
 
 ## Planned security work
 

STORE_LISTING.md

@@ -6,20 +6,20 @@ Share text and files directly between your Android and desktop devices over your
 
 ## Security Notice
 
-Sync360 currently uses trusted-network mode. Connections require device approval and authenticated session requests, but transferred content is not encrypted by Sync360.
+Sync360 currently uses trusted-network mode. The receiver approves offers in the UI, but requests and file sockets are not authenticated and transferred content is not encrypted by Sync360.
 
 Use Sync360 only on a private home network or personal hotspot controlled by you. Do not use it on public or shared networks such as cafes, hotels, airports, schools, or offices.
 
 ## Privacy Summary
 
 - Direct local-network transfer; no transfer cloud.
 - No account, ads, analytics, tracking, or telemetry.
-- Session approvals, tokens, and shared text are temporary.
+- Offer decisions, transfer state, and shared text are temporary runtime state.
 - Received files remain on the receiving device.
 
 ## Publishing Checklist
 
-- Add support contact to `PRIVACY.md`.
+- Keep the maintainer contact in `PRIVACY.md` current.
 - Publish `PRIVACY.md` at a public URL for store submission.
 - Keep store data-safety answers consistent with shipped code and permissions.
 - Revisit this disclosure before adding crash reporting, analytics, cloud services, or encrypted pairing.

androidApp/build.gradle.kts

@@ -1,11 +1,27 @@
 import org.jetbrains.kotlin.gradle.dsl.JvmTarget
+import java.util.Properties
 
 plugins {
     alias(libs.plugins.androidApplication)
     alias(libs.plugins.composeMultiplatform)
     alias(libs.plugins.composeCompiler)
 }
 
+val releaseSigningPropertiesFile = rootProject.file("keystore.properties")
+val releaseSigningProperties = Properties().apply {
+    if (releaseSigningPropertiesFile.isFile) {
+        releaseSigningPropertiesFile.inputStream().use(::load)
+    }
+}
+val releaseSigningIsConfigured = listOf(
+    "storeFile",
+    "storePassword",
+    "keyAlias",
+    "keyPassword"
+).all { propertyName ->
+    !releaseSigningProperties.getProperty(propertyName).isNullOrBlank()
+}
+
 kotlin {
     compilerOptions {
         jvmTarget.set(JvmTarget.JVM_17)
@@ -21,7 +37,7 @@ android {
         minSdk = libs.versions.android.minSdk.get().toInt()
         targetSdk = libs.versions.android.targetSdk.get().toInt()
         versionCode = 1
-        versionName = "1.0"
+        versionName = "0.1.0"
     }
 
     buildFeatures {
@@ -34,11 +50,24 @@ android {
         }
     }
 
+    signingConfigs {
+        if (releaseSigningIsConfigured) {
+            create("release") {
+                storeFile = rootProject.file(
+                    releaseSigningProperties.getProperty("storeFile")
+                )
+                storePassword = releaseSigningProperties.getProperty("storePassword")
+                keyAlias = releaseSigningProperties.getProperty("keyAlias")
+                keyPassword = releaseSigningProperties.getProperty("keyPassword")
+            }
+        }
+    }
+
     buildTypes {
         getByName("release") {
             isMinifyEnabled = true
             isShrinkResources = true
-            signingConfig = signingConfigs.getByName("debug")
+            signingConfig = signingConfigs.findByName("release")
             proguardFiles(
                 getDefaultProguardFile("proguard-android-optimize.txt"),
                 "proguard-rules.pro"

context.md

@@ -21,9 +21,10 @@ The old AI-generated sync implementation was removed. The current app is being r
 - Multiple files sent sequentially over one accepted-batch connection.
 - Android file access through `ContentResolver` and Downloads writing through `MediaStore`.
 - Desktop native file selection, Java file streams, and safe Downloads writing through temporary `.part` files.
+- iOS Bonjour discovery, native document selection, streamed Ktor TCP transfer, and Files-visible Downloads storage.
 - Best-effort cancellation and batch-wide byte percentage.
 
-Android-to-Android text and multiple-file flows have manual validation. Desktop-to-Android transfer has initial manual validation. In one Windows 11 Ethernet test, native Windows discovery added and removed Android promptly as its app opened and closed, while Android added and removed Windows promptly as the Desktop app opened and closed. Laptop, macOS, Linux, and broader adapter/network behavior still need validation. The app is still development software, not a production-ready release.
+Android-to-Android text and multiple-file flows have manual validation. Desktop-to-Android transfer has initial manual validation. In one Windows 11 Ethernet test, native Windows discovery added and removed Android promptly as its app opened and closed, while Android added and removed Windows promptly as the Desktop app opened and closed. The enabled iOS implementation has opened successfully in a cloud simulator, but same-LAN discovery and transfer could not be tested there. Laptop, macOS, Linux, physical iOS, and broader adapter/network behavior still need validation. The app is still development software, not a production-ready release.
 
 ## Architecture rule
 
@@ -37,7 +38,7 @@ Compose screen -> ViewModel -> controller/service -> common contract -> platform
 - Ktor DTOs remain at the HTTP boundary.
 - Blocking file/socket work runs on `Dispatchers.IO`.
 - Files are streamed; they are never loaded whole into memory.
-- Platform APIs stay in Android/JVM source sets.
+- Platform APIs stay in Android, JVM, and iOS source sets.
 
 ## Protocol summary