• v3/examples/android/frontend/package-lock.json: Language not supported
• v3/examples/ios/frontend/package-lock.json: Language not supported

v3/pkg/application/dialogs_android.go-66-70 (1)

66-70: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Handle JSON marshaling errors.

The json.Marshal error is ignored. If marshaling fails, invalid JSON will be passed to the native bridge, potentially causing a crash or unexpected dialog behavior.

🛡️ Proposed fix to handle marshaling errors

-	optionsJSON, _ := json.Marshal(androidDialogOptions{
+	optionsJSON, err := json.Marshal(androidDialogOptions{
 		Title:   title,
 		Message: d.dialog.Message,
 		Buttons: buttons,
 	})
+	if err != nil {
+		// Log or handle the error appropriately
+		return
+	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/pkg/application/dialogs_android.go` around lines 66 - 70, The json.Marshal
call for androidDialogOptions currently ignores errors; update the code that
builds optionsJSON (the json.Marshal(androidDialogOptions{ Title: title,
Message: d.dialog.Message, Buttons: buttons })) to capture the error, handle it
(e.g., log via the existing logger or return the error from the surrounding
function), and avoid calling the native bridge with invalid JSON—ensure you
check the err variable and either return or gracefully fail before using
optionsJSON.

v3/pkg/application/dialogs_ios.go-59-59 (1)

59-59: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Handle JSON marshaling errors.

The json.Marshal error is ignored. If marshaling fails, invalid JSON will be passed to the native iOS bridge, potentially causing a crash or unexpected dialog behavior.

🛡️ Proposed fix to handle marshaling errors

-	buttonsJSON, _ := json.Marshal(buttons)
+	buttonsJSON, err := json.Marshal(buttons)
+	if err != nil {
+		// Log or handle the error appropriately
+		return
+	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/pkg/application/dialogs_ios.go` at line 59, The code currently ignores the
error from json.Marshal when creating buttonsJSON, which can pass invalid JSON
to the iOS bridge; update the function containing the json.Marshal(buttons) call
to check the returned error, handle it by logging the error (or returning it to
the caller) and aborting or using a safe fallback instead of sending invalid
data; specifically, after json.Marshal(buttons) validate err != nil, use the
enclosing function (the dialog construction/sending routine) to call
processLogger or return the error so the native bridge is not invoked with a bad
buttonsJSON.

v3/pkg/application/dialogs_android.go-131-133 (1)

131-133: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Handle JSON marshaling errors.

The json.Marshal error is ignored. If marshaling fails, invalid JSON will be passed to the native bridge, potentially causing incorrect file picker behavior.

🛡️ Proposed fix to handle marshaling errors

-	optionsJSON, _ := json.Marshal(androidFilePickerOptions{
+	optionsJSON, err := json.Marshal(androidFilePickerOptions{
 		Multiple: d.dialog.allowsMultipleSelection,
 	})
+	if err != nil {
+		return nil, fmt.Errorf("failed to marshal file picker options: %w", err)
+	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/pkg/application/dialogs_android.go` around lines 131 - 133, The
json.Marshal call for androidFilePickerOptions ignores errors and can send
invalid JSON to the native bridge; update the code around optionsJSON :=
json.Marshal(androidFilePickerOptions{Multiple:
d.dialog.allowsMultipleSelection}) to check the returned error, and on error
either return it (propagate from the surrounding function) or log and abort the
native call so you don't pass invalid JSON to the bridge; reference the
androidFilePickerOptions type, the optionsJSON variable, and
d.dialog.allowsMultipleSelection when locating the statement to add error
handling.

v3/internal/commands/android/Taskfile.yml-196-201 (1)

196-201: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

AVD selection may fail if emulator -list-avds output ends with a blank line.

Line 196 uses tail -1 to pick the last line from the AVD list. If the emulator command's output ends with a newline (common in shell utilities), AVD_NAME will be empty and the error message on line 198 will be shown even when AVDs exist.

🛠️ Suggested fix to filter blank lines

         # Get first available AVD
-        AVD_NAME=$("{{.EMULATOR}}" -list-avds | tail -1)
+        AVD_NAME=$("{{.EMULATOR}}" -list-avds | grep -v '^$' | tail -1)
         if [ -z "$AVD_NAME" ]; then

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/android/Taskfile.yml` around lines 196 - 201, The AVD
selection can return an empty string when "{{.EMULATOR}} -list-avds" outputs a
trailing blank line; update the AVD_NAME assignment to filter out empty lines
before taking the last entry (i.e., run the emulator list through a filter such
as grep -v '^$' or sed '/^$/d' or awk 'NF' and then use tail -n1) so AVD_NAME
reliably contains the last non-empty AVD name and the subsequent check using
AVD_NAME works as intended.

v3/internal/commands/android/app/build.gradle-30-37 (1)

30-37: ⚠️ Potential issue | 🟡 Minor

Add fail-fast validation for Android release keystore env vars
v3/internal/commands/android/app/build.gradle enables signingConfigs.release when only ANDROID_KEYSTORE_FILE is set, but it always reads ANDROID_KEYSTORE_PASSWORD, ANDROID_KEY_ALIAS, and ANDROID_KEY_PASSWORD; if any are missing, the release build can fail later with a confusing error. Add validation for all four variables (or clearly document they must be set together—v3/ANDROID.md provides an example with all of them).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/android/app/build.gradle` around lines 30 - 37, The
signingConfigs.release block reads multiple keystore env vars but only checks
ANDROID_KEYSTORE_FILE; update signingConfigs.release to perform fail-fast
validation that all four env vars (ANDROID_KEYSTORE_FILE,
ANDROID_KEYSTORE_PASSWORD, ANDROID_KEY_ALIAS, ANDROID_KEY_PASSWORD) are present
before using them (or skip configuring release signing if any are missing), and
emit a clear error/log message when they are partially provided; locate the
signingConfigs.release block in build.gradle to add the validation and error
handling.

v3/internal/commands/build_assets/ios/Taskfile.yml-85-95 (1)

85-95: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fail fast when device-only tasks are invoked with simulator defaults.

With IOS_PLATFORM=simulator and CODESIGN_IDENTITY=- as the defaults, package:ipa can zip a simulator bundle, and deploy-device can try to install whatever stale .app happens to be in bin. Add explicit preconditions for IOS_PLATFORM=device plus a real signing identity, and make deploy-device build/package the device app first.

Also applies to: 157-166, 177-190

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/build_assets/ios/Taskfile.yml` around lines 85 - 95, The
package:ipa Taskfile task currently runs unguarded and can package simulator
builds; update the package:ipa task to fail fast unless IOS_PLATFORM equals
"device" and CODESIGN_IDENTITY is not "-" (or empty) by adding an explicit
precondition check at the top of the task (use the task's preconditions/vars
mechanism), and update the deploy-device task to ensure it first invokes the
device build/package steps (e.g., call the existing package or build task that
produces a device-signed .app/.ipa) before attempting installation; apply the
same precondition enforcement to the other device-only tasks referenced around
the same area (lines 157-166 and 177-190) to prevent running with simulator
defaults.

v3/internal/commands/ios/scripts/deps/install_deps.go-241-241 (1)

241-241: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Hardcoded "iPhone 15 Pro" simulator may not exist in older Xcode versions.

Line 241 creates an "iPhone 15 Pro" simulator via xcrun simctl create "iPhone 15 Pro" "iPhone 15 Pro" .... The device type identifier "iPhone 15 Pro" was introduced in Xcode 15. Users running Xcode 14 or earlier will encounter xcrun simctl create errors like "Invalid device type: iPhone 15 Pro."

Proposed fix

Query available device types dynamically and select a fallback:

// Get available device types
deviceOut, err := exec.Command("xcrun", "simctl", "list", "devicetypes").Output()
if err == nil {
	lines := strings.Split(string(deviceOut), "\n")
	var deviceType string
	// Prefer iPhone 15 Pro, fallback to any iPhone
	for _, line := range lines {
		if strings.Contains(line, "iPhone 15 Pro") {
			deviceType = "iPhone 15 Pro"
			break
		} else if strings.Contains(line, "iPhone") && deviceType == "" {
			// Extract first available iPhone type
			parts := strings.Fields(line)
			if len(parts) > 0 {
				deviceType = parts[0]
			}
		}
	}
	if deviceType != "" {
		createCmd := []string{"xcrun", "simctl", "create", deviceType, deviceType, latestRuntime}
		// ... proceed
	}
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/ios/scripts/deps/install_deps.go` at line 241, The
hardcoded simulator device type "iPhone 15 Pro" (the createCmd variable used to
run xcrun simctl create with latestRuntime) can fail on older Xcode; modify the
logic that builds createCmd so it first queries available device types via
`xcrun simctl list devicetypes`, prefer "iPhone 15 Pro" if present, otherwise
pick a suitable fallback iPhone device type (extracting the device
identifier/token from the list) and then construct createCmd using that chosen
deviceType and latestRuntime; ensure you handle errors from the devicetypes
query and only run the create command when a valid deviceType was found.

v3/examples/android/build/android/app/src/main/java/com/wails/app/WailsBridge.java-207-214 (1)

207-214: ⚠️ Potential issue | 🟡 Minor

Reframe XSS risk in WailsBridge.executeJavaScript: sink is raw JS, but key Go payloads are JSON-encoded

WailsBridge.executeJavaScript(String js) forwards js directly to WebView.evaluateJavascript(js, null) with no sanitization, so any caller that interpolates untrusted text into the JS string would be an XSS/JS-injection surface.

The main Android-reachable dynamic call sites in Go we found avoid raw string interpolation by embedding JSON:

• WebviewWindow.DispatchWailsEvent: dispatchWailsEvent(%s) where %s is CustomEvent.ToJSON() (uses json.Marshal)
• WebviewWindow.InitiateFrontendDropProcessing: handlePlatformFileDrop(%s, ...) where %s is json.Marshal(filenames) (inserted as a JSON expression)

Action: audit remaining ExecJS/execJS call paths to ensure any user-controlled string content is JSON-encoded/escaped before it’s interpolated into the JS string passed to executeJavaScript.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/examples/android/build/android/app/src/main/java/com/wails/app/WailsBridge.java`
around lines 207 - 214, WailsBridge.executeJavaScript currently forwards raw JS
to WebView.evaluateJavascript, creating a JS-injection/XSS sink when callers
interpolate untrusted data; audit all callers of executeJavaScript/ExecJS/execJS
(notably WebviewWindow.DispatchWailsEvent and
WebviewWindow.InitiateFrontendDropProcessing) and ensure any user-controlled
strings are JSON-encoded (e.g., via json.Marshal or equivalent) before being
embedded in the JS expression, or refactor call sites to pass structured JSON
values into a fixed JS wrapper rather than concatenating raw strings; update any
unsafe call sites to perform proper JSON encoding/escaping before calling
executeJavaScript.

v3/ANDROID.md-162-175 (1)

162-175: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add language specifier to fenced code block.

The fenced code block is missing a language identifier. Add a language specifier (e.g., text or tree) to silence the linter warning.

📝 Proposed fix

-```
+```text
 build/android/
   app/

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/ANDROID.md` around lines 162 - 175, The fenced code block showing the
build/android tree in v3/ANDROID.md is missing a language specifier; update the
opening triple-backticks that precede the "build/android/" block to include a
language like text or tree (e.g., change ``` to ```text) so the linter warning
is resolved while preserving the block contents.

Source: Linters/SAST tools

v3/internal/commands/android/Taskfile.yml (1)

69-73: ⚖️ Poor tradeoff

Host toolchain detection doesn't account for Apple Silicon.

Line 70 hardcodes HOST_TAG="darwin-x86_64" for all macOS hosts, but Apple Silicon Macs (M1/M2/M3) use arm64 architecture. The NDK provides both darwin-x86_64 and darwin-arm64 toolchains. On Apple Silicon, the wrong toolchain may cause performance issues (Rosetta translation) or build failures.

🔧 Suggested fix to detect the correct NDK toolchain

         # Determine toolchain based on host OS
         case "$(uname -s)" in
-          Darwin) HOST_TAG="darwin-x86_64" ;;
+          Darwin)
+            if [ "$(uname -m)" = "arm64" ]; then
+              HOST_TAG="darwin-arm64"
+            else
+              HOST_TAG="darwin-x86_64"
+            fi
+            ;;
           Linux)  HOST_TAG="linux-x86_64" ;;
           *)      echo "Unsupported host OS"; exit 1 ;;
         esac

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/android/Taskfile.yml` around lines 69 - 73, The host OS
detection hardcodes HOST_TAG="darwin-x86_64" and doesn't handle Apple Silicon;
update the case logic around the HOST_TAG assignment (the case "$(uname -s)"
block) to inspect architecture (e.g., uname -m) on Darwin and set HOST_TAG to
"darwin-arm64" when on arm64 (M1/M2/M3), keep "darwin-x86_64" for x86_64, and
preserve the existing Linux and default branches; ensure a clear fallback path
if an unknown architecture is found.

v3/internal/commands/android/app/src/main/java/com/wails/app/MainActivity.java (1)

327-332: Replace deprecated onBackPressed() with OnBackPressedCallback (OnBackPressedDispatcher).

v3/internal/commands/android/app/src/main/java/com/wails/app/MainActivity.java overrides onBackPressed() (lines 327-332), while the app targets targetSdk 34 (v3/internal/commands/android/app/build.gradle), so this will trigger deprecation/lint on API 33+. Use an OnBackPressedCallback (registered in onCreate) to run webView.goBack() when canGoBack(), and otherwise delegate to the dispatcher’s default back behavior.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/internal/commands/android/app/src/main/java/com/wails/app/MainActivity.java`
around lines 327 - 332, Replace the deprecated override of onBackPressed in
MainActivity with a registered OnBackPressedCallback on the activity’s
OnBackPressedDispatcher (register it in onCreate); inside the callback check
webView != null && webView.canGoBack() and call webView.goBack() when true,
otherwise call requireActivity().getOnBackPressedDispatcher().onBackPressed()
(or disable the callback to let the default dispatcher handle it) so the back
behavior is delegated correctly; remove the onBackPressed override after adding
the callback.

v3/internal/commands/build_assets/android/app/src/main/java/com/wails/app/WailsJSBridge.java (1)

52-61: ⚡ Quick win

Avoid creating a raw thread per runtime call.

invokeAsync() sits on the main JS→native transport path, and this spawns an unbounded Thread for every call. Prefer a shared executor, or call bridge.handleRuntimeCall() directly if this method is already off the UI thread, so bursty frontend traffic does not turn into thread explosion.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/internal/commands/build_assets/android/app/src/main/java/com/wails/app/WailsJSBridge.java`
around lines 52 - 61, The current invokeAsync path spawns a raw Thread per call
(the new Thread(...) block that calls bridge.handleRuntimeCall and
sendCallback), which can exhaust threads under bursty traffic; replace this with
a shared ExecutorService (e.g., a static cached or fixed thread pool) and submit
Runnables to it, or, if invokeAsync is already guaranteed to run off the main/UI
thread, call bridge.handleRuntimeCall(payload) directly and then
sendCallback(callbackId, response, null) without creating a new Thread; update
the code around invokeAsync/bridge.handleRuntimeCall/sendCallback to use the
shared executor (or direct call) and ensure exceptions are caught and logged via
Log.e(TAG, ...).

v3/internal/commands/ios/Taskfile.yml (1)

229-229: 💤 Low value

Consider a more precise UUID pattern for robustness.

The current pattern [A-F0-9-]\{36\} matches any 36-character sequence of hex digits and dashes, which could theoretically match malformed strings. A more precise UUID pattern would be:

grep -oE '[A-F0-9]{8}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{12}'

This ensures the UUID structure (8-4-4-4-12) is validated. However, since simctl output is well-formatted, the current pattern should work in practice.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/ios/Taskfile.yml` at line 229, The DEVICE_ID extraction
uses a loose regex `[A-F0-9-]\{36\}` which can match malformed sequences; update
the command that sets DEVICE_ID to use a precise UUID regex (8-4-4-4-12) via an
extended regex (e.g., use grep -oE with the pattern
'[A-F0-9]{8}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{12}') so the variable
assigned in the DEVICE_ID assignment (the line using xcrun simctl list devices
available | grep "iPhone" | ... ) only captures properly formatted UUIDs.

v3/internal/commands/ios_xcode_gen.go (1)

161-163: ⚡ Quick win

Consider validating MinIOSVersion format.

The code copies in.IOS.MinIOSVersion into cfg.MinIOSVersion without validating the format. Users may provide invalid values like "15" (missing minor version), "iOS 15.0" (prefixed), or "latest" (non-numeric). These will be embedded directly into the Info.plist templates (lines 22 of both plist.tmpl files) and the Xcode build settings, potentially causing App Store rejection or runtime crashes.

Suggested validation

Add a regex check after line 163:

if in.IOS.MinIOSVersion != "" {
	cfg.MinIOSVersion = in.IOS.MinIOSVersion
	// Validate format: major.minor (e.g., "15.0", "16.2")
	matched, _ := regexp.MatchString(`^\d+\.\d+$`, cfg.MinIOSVersion)
	if !matched {
		return fmt.Errorf("invalid ios.minIOSVersion: %q (expected format: major.minor, e.g., 15.0)", cfg.MinIOSVersion)
	}
}

Import regexp at the top of the file.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/ios_xcode_gen.go` around lines 161 - 163, The code
assigns in.IOS.MinIOSVersion to cfg.MinIOSVersion without validating format; add
a validation step after setting cfg.MinIOSVersion that enforces a major.minor
numeric pattern (e.g., "15.0") using regexp (e.g., `^\d+\.\d+$`), return an
error (fmt.Errorf) if it doesn't match, and import the regexp package at the top
of the file; reference the variables in.IOS.MinIOSVersion and cfg.MinIOSVersion
where you add the check.

v3/internal/commands/updatable_build_assets/ios/entitlements.plist.tmpl (1)

5-7: ⚡ Quick win

Removed entitlements may be required by some apps.

The AI summary notes that app sandbox (com.apple.security.app-sandbox), network client (com.apple.security.network.client), and user-selected file access (com.apple.security.files.user-selected.read-only) entitlements were removed. While this simplifies the template, apps making network requests or accessing user files will need to manually add these entitlements back, or they may fail at runtime with security/capability errors.

Since this PR is marked experimental, consider either:

1. Documenting the minimal entitlements set in IOS.md or ANDROID.md and instructing users to add additional entitlements as needed, or
2. Making entitlements configurable via build/config.yml (e.g., ios.entitlements: [network, files]) and conditionally rendering them in the template.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/updatable_build_assets/ios/entitlements.plist.tmpl`
around lines 5 - 7, The entitlements template removed important keys
(com.apple.security.app-sandbox, com.apple.security.network.client,
com.apple.security.files.user-selected.read-only) which some apps need; either
document the minimal entitlements in IOS.md (add a section listing these three
keys and instructions to re-enable them) or make entitlements configurable via
build/config.yml (add a key like ios.entitlements: [sandbox, network-client,
user-files]) and update entitlements.plist.tmpl to conditionally render the
corresponding plist keys (com.apple.security.app-sandbox,
com.apple.security.network.client,
com.apple.security.files.user-selected.read-only) when those config flags are
present.

v3/internal/commands/ios/scripts/deps/install_deps.go (1)

262-264: 💤 Low value

Fragile string matching for counting iPhone simulators.

Lines 262-264 count simulators by checking strings.Contains(line, "iPhone") && !strings.Contains(line, "unavailable"). This approach can miscount if:

• A line contains "iPhone" in a label/comment but isn't a device entry
• Device names or states change format in future simctl versions
• Non-iPhone devices (e.g., "iPhone Simulator Host") appear in output

More robust parsing

Parse the structured output or use a more specific pattern:

// Look for lines matching typical device format:
// "    iPhone 15 Pro (UUID) (Booted)"
count := 0
for _, line := range lines {
	trimmed := strings.TrimSpace(line)
	if strings.HasPrefix(trimmed, "iPhone") && strings.Contains(trimmed, "(") {
		count++
	}
}

Alternatively, parse xcrun simctl list devices --json for structured output.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/ios/scripts/deps/install_deps.go` around lines 262 -
264, The current simulator counting loop that checks strings.Contains(line,
"iPhone") && !strings.Contains(line, "unavailable") is fragile; update the logic
in the loop that populates count (the code iterating over lines and incrementing
count) to more reliably detect actual iPhone device entries — either (preferred)
call "xcrun simctl list devices --json" and parse the JSON to count devices with
name starting with "iPhone" and state != "unavailable"/"Shutdown", or (simpler)
trim each line and check that it HasPrefix("iPhone") and contains a device
UUID/token like "(" to avoid matching labels/comments before incrementing count;
replace the existing string.Contains checks in that loop with one of these
approaches.

v3/examples/android/build/android/Taskfile.yml (1)

196-196: ⚡ Quick win

Comment-code mismatch: "first" vs last AVD.

The comment says "Get first available AVD" but tail -1 retrieves the last AVD from the list. Consider updating the comment to match the implementation, or use head -1 if the first AVD is actually preferred.

📝 Suggested comment fix

-        # Get first available AVD
+        # Get last available AVD
         AVD_NAME=$("{{.EMULATOR}}" -list-avds | tail -1)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/examples/android/build/android/Taskfile.yml` at line 196, The AVD
selection line assigns AVD_NAME using "{{.EMULATOR}} -list-avds | tail -1" which
picks the last AVD but the comment says "Get first available AVD"; either update
the comment to reflect that AVD_NAME picks the last AVD, or change the pipeline
to use head -1 to actually select the first AVD; locate the AVD_NAME assignment
(the variable AVD_NAME and the command string "{{.EMULATOR}} -list-avds | tail
-1") and make the appropriate change so comment and implementation match.

v3/examples/android/build/android/app/src/main/java/com/wails/app/MainActivity.java (1)

212-220: ⚖️ Poor tradeoff

Background thread may leak if activity is destroyed during file copy.

The file-copying thread started at line 212 is not tracked or interrupted when the activity is destroyed. If the user navigates away or the system destroys the activity while files are being copied, the thread continues running, holding references to the activity context (via getContentResolver(), getCacheDir()), potentially causing a memory leak and preventing timely garbage collection.

Consider using an ExecutorService that can be shut down in onDestroy(), or tracking the thread and interrupting it during cleanup. For most use cases the leak is minor (short-lived copy operation), but could accumulate if users repeatedly trigger pickers then navigate away.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/examples/android/build/android/app/src/main/java/com/wails/app/MainActivity.java`
around lines 212 - 220, The background Thread that runs copyUriToCache(...) and
calls bridge.filePickerResult(...) / bridge.filePickerDone(...) can leak the
Activity because it uses getContentResolver() and getCacheDir(); instead replace
the raw Thread with a managed ExecutorService (e.g., a single-threaded
ExecutorService) stored as a field and submit the Runnable to it, and shut it
down (or call shutdownNow()) in onDestroy() to cancel ongoing work;
additionally, make copyUriToCache(...) context-independent where possible or
ensure it checks Thread.interrupted() and returns early so pending tasks can
stop promptly when the ExecutorService is shut down.

v3/examples/android/build/android/app/src/main/java/com/wails/app/WailsBridge.java (1)

309-321: ⚡ Quick win

Clipboard read may silently fail on Android 10+ without input focus.

The comment at line 298 mentions that clipboard reads on Android 10+ require input focus, but getClipboardText() doesn't verify this precondition or provide any indication to the caller that the read failed due to lack of focus. It returns an empty string both when the clipboard is genuinely empty and when access is denied, making it impossible for the Go side to distinguish between these cases or provide user feedback.

Consider logging a warning when clipboard access is attempted on Android 10+ without focus, or document this limitation clearly for developers.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/examples/android/build/android/app/src/main/java/com/wails/app/WailsBridge.java`
around lines 309 - 321, Detect Android 10+ focus loss before attempting
clipboard access in getClipboardText: check android.os.Build.VERSION.SDK_INT >=
Build.VERSION_CODES.Q and !activity.hasWindowFocus(), and in that case
Log.w(TAG, "clipboard read requires input focus on Android 10+; access denied")
and return null (instead of empty string) so the caller can distinguish denied
access from an empty clipboard; keep the existing try/catch fallback for other
errors and update any callers that expect empty-string to handle a null return
as "access denied".

v3/examples/ios/build/ios/Taskfile.yml (1)

220-258: 💤 Low value

Consider parameterizing the fallback iPhone device type.

Line 235 hardcodes "iPhone 15" as the fallback when no device type is detected. This will become outdated as newer Xcode versions ship with newer default simulators.

♻️ Parameterize the fallback device type

+  FALLBACK_IPHONE_DEVICE: '{{.FALLBACK_IPHONE_DEVICE | default "iPhone 15"}}'

Then reference it on line 235:

-            DEVICE_ID=$(xcrun simctl create "Wails iPhone" "${DEVICE_TYPE:-iPhone 15}" "$RUNTIME")
+            DEVICE_ID=$(xcrun simctl create "Wails iPhone" "${DEVICE_TYPE:-{{.FALLBACK_IPHONE_DEVICE}}}" "$RUNTIME")

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/examples/ios/build/ios/Taskfile.yml` around lines 220 - 258, The
ensure-simulator task currently hardcodes the fallback device type "iPhone 15"
when DEVICE_TYPE detection fails; introduce a configurable fallback variable
(e.g., FALLBACK_DEVICE_TYPE or a Taskfile variable referenced in the
ensure-simulator task) and use that variable in place of the literal "iPhone 15"
in the DEVICE_ID creation step so maintainers can update the default without
editing the script; update the task to read a passed-in env/Taskfile variable
(and document its name) and replace the "${DEVICE_TYPE:-iPhone 15}" usage with
the new variable reference (e.g., "${DEVICE_TYPE:-${FALLBACK_DEVICE_TYPE}}").

v3/examples/ios/README.md (1)

18-76: ⚡ Quick win

Remove or update the generic template content.

The old "Welcome to Your New Wails3 Project" template content (lines 18-76) remains below the iOS-specific introduction. For an iOS example project, this generic guidance is potentially confusing — especially commands like wails3 dev and wails3 build on lines 29 and 37, which don't represent the iOS workflow shown above.

Consider either removing this section entirely or replacing it with iOS-specific next steps.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/examples/ios/README.md` around lines 18 - 76, Remove or replace the
generic "Welcome to Your New Wails3 Project!" section (the block including the
headings and the commands `wails3 dev` and `wails3 build`) because it conflicts
with the iOS-specific introduction; either delete that entire section or rewrite
it with iOS-specific next steps (e.g., how to run the iOS example, any
Xcode/simulator instructions, and links to iOS-focused docs) so the README's
content aligns with the iOS example.

v3/examples/android/build/android/Taskfile.yml (1)

13-16: ⚖️ Poor tradeoff

SDK_ROOT fallback silently accepts non-existent paths.

When ANDROID_HOME and ANDROID_SDK_ROOT are both unset and neither default path exists, SDK_ROOT will be set to a non-existent directory without error. Downstream tasks (e.g., compile:go:shared at line 63) will fail with cryptic messages when they attempt to use the invalid path.

♻️ Optional: Add validation in dependent tasks

Consider adding a precondition to tasks that depend on SDK_ROOT:

compile:go:shared:
  preconditions:
    - sh: '[ -d "{{.SDK_ROOT}}" ]'
      msg: "Android SDK not found. Set ANDROID_HOME or install to default location"
  # ... rest of task

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/examples/android/build/android/Taskfile.yml` around lines 13 - 16, The
SDK_ROOT expression silently returns a non-existent path when ANDROID_HOME and
ANDROID_SDK_ROOT are unset, so add an explicit existence check and fail fast:
either change the SDK_ROOT derivation to validate the chosen path exists and
exit with a clear message if not, or add a precondition to dependent tasks
(e.g., compile:go:shared) that runs '[ -d "{{.SDK_ROOT}}" ]' and prints "Android
SDK not found. Set ANDROID_HOME or install to default location" on failure;
reference the SDK_ROOT variable and the compile:go:shared task when making the
change.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

v3/examples/mobile/build/android/app/src/main/java/com/wails/app/WailsJSBridge.java (1)

136-142: 💤 Low value

Consider more comprehensive JavaScript string escaping.

The current escapeJsString handles \, ', \n, and \r, but doesn't escape other potentially problematic characters like \t (tab), \f (form feed), \b (backspace), or control characters that may appear in JSON responses from Go.

♻️ More robust escaping

 private String escapeJsString(String str) {
     if (str == null) return "";
     return str.replace("\\", "\\\\")
             .replace("'", "\\'")
             .replace("\n", "\\n")
-            .replace("\r", "\\r");
+            .replace("\r", "\\r")
+            .replace("\t", "\\t")
+            .replace("\f", "\\f")
+            .replace("\b", "\\b");
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/examples/mobile/build/android/app/src/main/java/com/wails/app/WailsJSBridge.java`
around lines 136 - 142, The escapeJsString method currently only handles
backslash, single quote, newline and carriage return; update escapeJsString to
comprehensively escape control and special characters by iterating the input and
replacing tab (\t), backspace (\b), form feed (\f), vertical tab (\u000B) and
any control chars (char <= 0x1F) with their JS escape sequences or a \\uXXXX hex
escape, and also consider escaping backticks and double quotes if the string
could be injected into different JS contexts; implement this in the
escapeJsString(String str) method (use a StringBuilder and switch on characters)
so all problematic/control characters are safely encoded for JS.

v3/examples/mobile/build/android/Taskfile.yml (1)

192-224: ⚖️ Poor tradeoff

Emulator boot check could be more robust.

The emulator boot detection uses a fixed 120-second timeout with 1-second polling. While functional, consider adding feedback messages during the wait or checking for emulator failures that might cause an indefinite wait.

💡 Optional enhancement

         for i in $(seq 1 120); do
+          if [ $((i % 10)) -eq 0 ]; then
+            echo "Still waiting... ($i/120 seconds)"
+          fi
           BOOT_COMPLETED=$("{{.ADB}}" shell getprop sys.boot_completed 2>/dev/null | tr -d '\r')

This provides user feedback during longer boot times without changing the core logic.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/examples/mobile/build/android/Taskfile.yml` around lines 192 - 224, The
emulator boot detector in the start script (the AVD selection and boot loop
using AVD_NAME, "{{.EMULATOR}}", and "{{.ADB}}") should be made more robust by:
increasing or making the 120-second timeout configurable, emitting periodic
progress feedback inside the for-loop (e.g., print a message every N seconds or
every X iterations with remaining time), and adding a failure check (e.g.,
verify the emulator process is still running or check for "{{.ADB}} devices" /
emulator state such as "offline" to bail early). Update the wait loop around
"{{.ADB}} wait-for-device" and the for-seq loop to include these checks and
messages so users see progress and the script exits promptly on emulator
failure.

v3/examples/mobile/build/ios/scripts/deps/install_deps.go (1)

189-191: ⚡ Quick win

Consider logging command output on failure.

When the fix command fails (line 189-191), the script exits immediately without showing the command's stderr, which might contain helpful diagnostic information for the user.

📝 Optional improvement

 						fmt.Println("Running command...")
 						cmd := exec.Command(dep.InstallCmd[0], dep.InstallCmd[1:]...)
 						cmd.Stdout = os.Stdout
 						cmd.Stderr = os.Stderr
 						cmd.Stdin = os.Stdin
 						if err := cmd.Run(); err != nil {
-							fmt.Printf("Command failed: %v\n", err)
+							fmt.Printf("Command failed: %v\n", err)
+							fmt.Println("Please run the command manually and check the error output.")
 							os.Exit(1)
 						}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/examples/mobile/build/ios/scripts/deps/install_deps.go` around lines 189 -
191, The failure handler for the command invocation currently just prints the
error from cmd.Run() and exits; update the block around cmd.Run() to capture and
log the command's stderr/stdout (e.g., use cmd.CombinedOutput() or attach
bytes.Buffer to cmd.Stdout/Stderr) and print that output alongside the error
before calling os.Exit(1) so failing commands (in install_deps.go where
cmd.Run() is invoked) surface diagnostic output.

v3/examples/mobile/build/android/app/src/main/java/com/wails/app/MainActivity.java (1)

229-263: ⚡ Quick win

Resource cleanup on early returns.

The copyUriToCache method has multiple early returns (lines 244, 250) that leave the directory created on line 242 in place. While the cache directory will eventually be cleaned by the system, explicitly cleaning up on failure would be better.

♻️ Optional cleanup improvement

     `@Nullable`
     private String copyUriToCache(Uri uri) {
         String name = "document";
         try (Cursor cursor = getContentResolver().query(uri, null, null, null, null)) {
             if (cursor != null && cursor.moveToFirst()) {
                 int idx = cursor.getColumnIndex(OpenableColumns.DISPLAY_NAME);
                 if (idx >= 0 && cursor.getString(idx) != null) {
                     name = new File(cursor.getString(idx)).getName();
                 }
             }
         } catch (Exception ignored) {
         }
 
+        File dir = null;
         try {
-            File dir = new File(getCacheDir(), "wails-picker/" + System.nanoTime());
+            dir = new File(getCacheDir(), "wails-picker/" + System.nanoTime());
             if (!dir.mkdirs()) {
                 return null;
             }
             File out = new File(dir, name);
             try (InputStream in = getContentResolver().openInputStream(uri);
                  OutputStream os = new FileOutputStream(out)) {
                 if (in == null) {
                     return null;
                 }
                 byte[] buf = new byte[64 * 1024];
                 int n;
                 while ((n = in.read(buf)) > 0) {
                     os.write(buf, 0, n);
                 }
             }
             return out.getAbsolutePath();
         } catch (Exception e) {
             Log.e(TAG, "Failed to copy picked document", e);
+            if (dir != null && dir.exists()) {
+                deleteRecursive(dir);
+            }
             return null;
         }
     }
+
+    private void deleteRecursive(File file) {
+        if (file.isDirectory()) {
+            File[] children = file.listFiles();
+            if (children != null) {
+                for (File child : children) {
+                    deleteRecursive(child);
+                }
+            }
+        }
+        file.delete();
+    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/examples/mobile/build/android/app/src/main/java/com/wails/app/MainActivity.java`
around lines 229 - 263, The copyUriToCache method creates a temporary directory
(dir) but returns early on failures (when mkdirs() fails or when openInputStream
returns null) without deleting that directory; update copyUriToCache to ensure
dir and any partially written file (out) are deleted on all early-return paths
by restructuring the logic (use a try/finally or explicit cleanup before each
return) so that if mkdirs() fails you remove the created dir (if any), and if in
== null or an exception occurs you delete out and dir before returning;
reference the copyUriToCache method, the dir and out File variables, and the
InputStream in to locate where to add the cleanup.

v3/examples/mobile/build/android/app/src/main/java/com/wails/app/WailsBridge.java (1)

229-247: 💤 Low value

System bar insets query may fail on older Android versions.

On Android API < 30 (line 241-246), the code doesn't query system bar insets, leaving them at 0. While this is a reasonable fallback, documenting this limitation would help users understand safe-area behavior on older devices.

📝 Optional documentation

             } else {
+                // Note: System bar insets are not available before Android R (API 30).
+                // Apps targeting older versions will receive 0 for all inset values.
                 DisplayMetrics metrics = new DisplayMetrics();
                 activity.getWindowManager().getDefaultDisplay().getRealMetrics(metrics);
                 widthPx = metrics.widthPixels;
                 heightPx = metrics.heightPixels;
                 density = metrics.density;
             }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@v3/examples/mobile/build/android/app/src/main/java/com/wails/app/WailsBridge.java`
around lines 229 - 247, The system-bar inset values are left at 0 for API < 30
which can be surprising; update the WailsBridge code that computes window
metrics to explicitly document and communicate this fallback: add a concise
comment and/or Javadoc on the method in class WailsBridge explaining that for
Build.VERSION.SDK_INT < Build.VERSION_CODES.R the Insets are unavailable so
insetTop/insetBottom/insetLeft/insetRight remain 0 (and that callers should
treat them as unknown), and optionally emit a debug log when falling back to the
older DisplayMetrics path to make the limitation observable at runtime.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

v3/internal/commands/updatable_build_assets/ios/project.pbxproj.tmpl (1)

158-158: 💤 Low value

Overlay generation silently ignores failures.

The overlay generation command uses || true to suppress errors. While this may be intentional to handle cases where the overlay doesn't exist yet, it could hide legitimate failures (e.g., invalid config.yml, wails3 binary not in PATH, or I/O errors).

Consider logging a warning when overlay generation fails, or verifying that the overlay file exists afterward:

🔍 Optional improvement to detect overlay generation failures

 if [ ! -f build/ios/xcode/overlay.json ]; then
-  wails3 ios overlay:gen -out build/ios/xcode/overlay.json -config build/config.yml || true
+  wails3 ios overlay:gen -out build/ios/xcode/overlay.json -config build/config.yml || echo "Warning: overlay generation failed, proceeding without overlay"
 fi

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@v3/internal/commands/updatable_build_assets/ios/project.pbxproj.tmpl` at line
158, The shell script in the project.pbxproj.tmpl currently suppresses errors
from the overlay generator by appending "|| true" to the wails3 ios overlay:gen
command; update the shellScript so that instead of silencing failures you run
the overlay generation command without "|| true", capture its exit status (or
immediately check for the existence of build/ios/xcode/overlay.json), and if
generation fails emit a clear warning or fail the build (use the surrounding
context: the shellScript string that runs wails3 ios overlay:gen and references
build/ios/xcode/overlay.json and build/config.yml). Ensure the script logs a
warning message including the command context when wails3 fails or the overlay
file is missing so legitimate errors aren’t hidden.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes