@maccesar/titools 4.4.0 → 4.5.0

package/skills/ti-expert/references/sharing.md

@@ -0,0 +1,227 @@
+# Sharing content out
+
+How to hand a link, a text or a file from your app to the rest of the system — the share sheet on iOS, the intent chooser on Android.
+
+The two platforms are not symmetric and have not been for years, which is the single fact that explains every confusing implementation you will find in an older codebase. Android does this with the core SDK and no module. iOS does not: the SDK exposes no wrapper for `UIActivityViewController`, so a native module is still required. Code written before that split settled tends to route both platforms through the module, or through a cross-platform helper that only ever needed to exist for iOS.
+
+This file is about sending content **out**. For receiving files — declaring a custom extension, UTIs, intent filters, `handleurl` — see [File type association](file-type-association.md).
+
+## Contents
+
+1. [The platform split](#1-the-platform-split)
+2. [Android: the core SDK is enough](#2-android-the-core-sdk-is-enough)
+3. [iOS: which module, and why one is still needed](#3-ios-which-module-and-why-one-is-still-needed)
+4. [Text is not a file](#4-text-is-not-a-file)
+5. [Do not pass text alongside a file](#5-do-not-pass-text-alongside-a-file)
+6. [iPad needs an anchor](#6-ipad-needs-an-anchor)
+7. [Knowing whether the user actually shared](#7-knowing-whether-the-user-actually-shared)
+8. [Failing without an exception](#8-failing-without-an-exception)
+9. [Verify instead of assuming](#9-verify-instead-of-assuming)
+10. [Symptom to cause](#10-symptom-to-cause)
+
+## 1. The platform split
+
+| | Text or link | File |
+| --- | --- | --- |
+| **Android** | `Ti.Android.createIntent` + `createIntentChooser` | Same, with `putExtraUri` |
+| **iOS** | Native module — no SDK API | Native module, or `DocumentViewer` if the type is previewable |
+
+The asymmetry is historical, not architectural. Sharing on Titanium used to go through `com.alcoapps.socialshare`, a CommonJS wrapper by Ricardo Alcocer that split by platform and drove the same iOS module underneath. Once Android could open the system sheet directly, the Android branch stopped needing anything and the module became iOS-only — but the wrapper stayed in projects, and with it a layer of indirection that no longer buys anything.
+
+**When you find one of those wrappers,** check what it still does. The usual finding is dead weight: version-comparison helpers, Facebook app-id variables, `image_blob` / `image_url` normalization for an argument shape nobody passes anymore. Adapting the old helper costs more than writing the two branches.
+
+## 2. Android: the core SDK is enough
+
+`Ti.Android.createIntent` and `Ti.Android.createIntentChooser` are core SDK APIs and are not deprecated. No module, no widget.
+
+```javascript
+function shareTextAndroid (text, chooserTitle) {
+  const activity = Ti.Android.rootActivity || Ti.Android.currentActivity
+
+  // No activity, no chooser to present. Calling startActivity on null throws in
+  // the face of whoever tapped Share.
+  if (!activity) {
+    return false
+  }
+
+  const intent = Ti.Android.createIntent({
+    action: Ti.Android.ACTION_SEND,
+    type: 'text/plain'
+  })
+
+  intent.putExtra(Ti.Android.EXTRA_TEXT, text)
+  activity.startActivity(Ti.Android.createIntentChooser(intent, chooserTitle))
+
+  return true
+}
+```
+
+For a file, two things change and both are mandatory:
+
+```javascript
+intent.putExtraUri(Ti.Android.EXTRA_STREAM, file.nativePath)
+intent.addFlags(Ti.Android.FLAG_GRANT_READ_URI_PERMISSION)
+```
+
+`putExtraUri` makes the SDK convert the path into a `content://` URI served by `TiFileProvider`, which ships declared in the merged manifest — nothing to configure. **Without `FLAG_GRANT_READ_URI_PERMISSION` the receiving app cannot read the file.** It is granted a URI it has no permission for, so the share appears to work and the other app shows an error or an empty attachment.
+
+Set `type` to the real MIME type rather than `*/*`. An unknown type falls back to `application/octet-stream`, which offers every app on the device instead of the ones that can do something useful.
+
+## 3. iOS: which module, and why one is still needed
+
+There is no share sheet API in the SDK. This is verifiable rather than folklore — see [Verify instead of assuming](#9-verify-instead-of-assuming). The SDK offers `Ti.UI.iOS.DocumentViewer`, which is a previewer, and `Ti.App.iOS.UserActivity`, which is Handoff. Neither presents `UIActivityViewController`.
+
+**The module is `dk.napp.social`**, and its provenance matters because the obvious repository is the wrong one:
+
+| Repository | Status |
+| --- | --- |
+| [viezel/TiSocial.Framework](https://github.com/viezel/TiSocial.Framework) | **Archived April 2021.** Last release 2.0.0. This is the one search engines surface. |
+| [hansemannn/TiSocial.Framework](https://github.com/hansemannn/TiSocial.Framework) | **The maintained fork.** Its 3.0.0 release states "Moved to this fork as the base repository". |
+
+Releases on the fork: 3.0.0 (macOS support), 3.0.1 (fixes a possible iPad crash), 3.0.2 (restores iOS 12 compatibility). **3.0.2 is the highest published version.** If a project declares something higher in `tiapp.xml`, that build came from somewhere other than a release — treat the local copy as irreplaceable and say so in the project's install instructions, because nobody can download it.
+
+```javascript
+function shareTextIos (text, subject) {
+  const social = require('dk.napp.social')
+
+  if (!social.isActivityViewSupported()) {
+    return false
+  }
+
+  social.activityView({ subject: subject || '', text }, [])
+  return true
+}
+```
+
+Require the module inside the iOS branch, not at the top of the file. A module-level `require` runs on Android too, where it resolves to nothing useful.
+
+## 4. Text is not a file
+
+`DocumentViewer` takes the URL of a file; there is no way to hand it a string. So a file has two possible routes on iOS and a text has one.
+
+**The file route via `DocumentViewer` works only when iOS can preview the type.** The viewer presents the document and its action button opens the real system sheet — no module involved. But "presents" is conditional: with a type the system cannot render, it presents nothing and reports no error. Silence, and the user sees a tap that did nothing.
+
+So the decision is about the type, not about the file:
+
+- **Type the system knows** (PDF, image, ZIP, plain text) → `DocumentViewer` is enough, and it saves you the module on this path.
+- **Opaque type** — anything conforming to `public.data`, which is what a custom document type usually declares so that Files hands it over instead of previewing it (see [File type association](file-type-association.md)) → the viewer has nothing to show. Use the module's `activityView({ file })`.
+
+This is the trap worth naming: **the same declaration that makes tapping the file open your app is what stops `DocumentViewer` from presenting it.** The two behaviors pull in opposite directions and both are correct.
+
+## 5. Do not pass text alongside a file
+
+When sharing a file, pass only the file. Adding `text` to the same payload makes iOS treat the string as a **second item** in the sheet, and "Save to Files" writes two files: the document, plus a `.txt` holding the caption.
+
+```javascript
+// wrong — "Save to Files" leaves the backup AND a stray text file
+social.activityView({ file: file.nativePath, text: title }, [])
+
+// right — the subject rides along without becoming an item
+social.activityView({ file: file.nativePath, subject: title }, [])
+```
+
+The symptom shows up only in destinations that write to disk. Sharing to a messaging app looks fine, which is why this survives testing.
+
+## 6. iPad needs an anchor
+
+On iPad the sheet is a popover and must be anchored to the view that was tapped, or it has nowhere to attach:
+
+```javascript
+if (Ti.Platform.osname === 'ipad') {
+  options.view = sourceView
+  social.activityPopover(options, [])
+  return true
+}
+
+social.activityView(options, [])
+```
+
+This means the controller has to pass the source view down to the sharing service — usually `event.source` from the tap handler. Services that take only a URL cannot support iPad without changing their signature, which is why the parameter is worth adding before the app ships on tablets.
+
+## 7. Knowing whether the user actually shared
+
+Both platforms open a sheet and return immediately. Neither the intent chooser nor a bare `activityView` call tells you what happened next.
+
+On iOS the module emits it:
+
+```javascript
+const social = require('dk.napp.social')
+
+social.addEventListener('complete', event => {
+  // event.activityName — where it went
+})
+
+social.addEventListener('cancelled', () => {})
+```
+
+Register these **once**, at module scope inside the iOS branch, not per share — re-adding on every tap leaks listeners.
+
+Android has no equivalent through the chooser. If the product needs to know, that asymmetry is the design constraint, and treating "sheet opened" as success is the honest fallback.
+
+Skip all of this when nothing depends on the answer. An analytics event or a "Shared!" confirmation is a reason; symmetry with iOS is not.
+
+## 8. Failing without an exception
+
+Sharing fails for reasons that are not bugs: no activity, a device without sheet support, a file that was deleted between the tap and the call. **Return a boolean and let the caller decide whether to warn.** Throwing from a share function means an exception reaches whoever tapped a button.
+
+```javascript
+function share (payload, sourceView) {
+  try {
+    return OS_ANDROID
+      ? shareAndroid(payload)
+      : shareIos(payload, sourceView)
+  } catch (error) {
+    Ti.API.error(`[sharing] Could not share: ${error.message}`)
+    return false
+  }
+}
+```
+
+The failure worth auditing in an existing codebase is a **mixed contract**: one branch returning `false` while its sibling throws or returns nothing. It usually means one path was hardened after a crash and the other was never revisited.
+
+## 9. Verify instead of assuming
+
+Whether the SDK exposes something is checkable in the installed SDK's API metadata, and takes less time than the argument about it:
+
+```bash
+JSCA=~/Library/Application\ Support/Titanium/mobilesdk/osx/<version>/api.jsca
+
+python3 - "$JSCA" <<'PY'
+import json, sys
+d = json.load(open(sys.argv[1]))
+for t in d.get('types', []):
+    if any(k in t['name'] for k in ('Activity', 'Share', 'Social', 'DocumentViewer')):
+        print(t['name'])
+PY
+```
+
+On 13.4.0.GA this returns `Titanium.UI.iOS.DocumentViewer`, `Titanium.App.iOS.UserActivity`, `Titanium.UI.ActivityIndicator` and the Android `Activity` types — and nothing wrapping `UIActivityViewController`. The same query tells you whether an API you are about to rely on is marked deprecated.
+
+For the module, check what is actually installed rather than what `tiapp.xml` claims:
+
+```bash
+ls ~/Library/Application\ Support/Titanium/modules/iphone/dk.napp.social/
+cat ~/Library/Application\ Support/Titanium/modules/iphone/dk.napp.social/*/manifest
+```
+
+**Do not verify a suspicion by comparing against a sibling project.** Two codebases that share a lineage share its mistakes, so agreement between them proves nothing. The control is the platform documentation or the SDK metadata.
+
+## 10. Symptom to cause
+
+| Symptom | Cause |
+| --- | --- |
+| Tapping Share does nothing on iOS, no error | File type is not previewable and the code used `DocumentViewer`. Use the module for opaque types. |
+| Receiving app shows an error or an empty attachment (Android) | Missing `FLAG_GRANT_READ_URI_PERMISSION`. |
+| "Save to Files" writes two files | `text` passed alongside `file`. Use `subject`. |
+| Sheet does not appear on iPad | `activityView` used instead of `activityPopover`, or no `view` anchor. |
+| Crash when tapping Share on Android | `startActivity` on a null activity. Guard `rootActivity || currentActivity`. |
+| Chooser offers every app on the device | `type` left as `*/*` or an unknown extension falling back to `application/octet-stream`. |
+| `Couldn't find module: dk.napp.social` | Module not installed, or `require` at file scope running on Android. |
+| Module version in `tiapp.xml` has no matching release | Locally built copy. It cannot be downloaded; document it as an install requirement. |
+
+## Sources
+
+- Titanium SDK 13.4.0.GA `api.jsca` — the absence of a share sheet API on iOS and the non-deprecated status of `Ti.Android.createIntentChooser`.
+- [hansemannn/TiSocial.Framework](https://github.com/hansemannn/TiSocial.Framework) — maintained fork, releases 3.0.0 through 3.0.2.
+- [viezel/TiSocial.Framework](https://github.com/viezel/TiSocial.Framework) — original, archived April 2021.
+- [ricardoalcocer/socialshare](https://github.com/ricardoalcocer/socialshare) — the historical cross-platform wrapper, for recognizing it in old code.

package/skills/ti-expert/references/theming.md

@@ -1,7 +1,6 @@
 # Theming and dark mode
 
-Choose the styling path from the project, not from personal memory. Semantic
-roles are the shared contract; PurgeTSS or standard Alloy materializes them.
+Choose the styling path from the project, not from personal memory. Semantic roles are the shared contract; PurgeTSS or standard Alloy materializes them.
 
 ## Contents
 
@@ -19,16 +18,13 @@ roles are the shared contract; PurgeTSS or standard Alloy materializes them.
 1. Detect `purgetss/` or `purgetss/config.cjs`.
 2. If detected, invoke the `purgetss` skill before writing any class or style.
 3. If not detected, use standard Alloy TSS and Titanium semantic colors.
-4. Use `Alloy.Globals` for a runtime palette only when the product requires
-   custom themes beyond the semantic light/dark/system model.
+4. Use `Alloy.Globals` for a runtime palette only when the product requires custom themes beyond the semantic light/dark/system model.
 
-Do not mix these paths accidentally. In particular, never teach a PurgeTSS
-project to maintain the generated `app/styles/app.tss` by hand.
+Do not mix these paths accidentally. In particular, never teach a PurgeTSS project to maintain the generated `app/styles/app.tss` by hand.
 
 ## Semantic color contract
 
-Name colors by purpose rather than appearance. A practical design-system
-contract includes:
+Name colors by purpose rather than appearance. A practical design-system contract includes:
 
 - app background and elevated surface;
 - primary and secondary text;
@@ -62,28 +58,20 @@ Example:
 }
 ```
 
-Titanium resolves a semantic color name when a color-accepting property uses
-that name. Keep component APIs tone-based (`neutral`, `success`, `warning`,
-`error`) and map tones to semantic roles inside the visual layer. Do not pass
-raw brand hex values through business controllers.
+Titanium resolves a semantic color name when a color-accepting property uses that name. Keep component APIs tone-based (`neutral`, `success`, `warning`, `error`) and map tones to semantic roles inside the visual layer. Do not pass raw brand hex values through business controllers.
 
 ## PurgeTSS projects
 
-The `purgetss` skill is the source of truth for supported classes, configuration,
-appearance behavior, and commands. Apply these integration rules:
+The `purgetss` skill is the source of truth for supported classes, configuration, appearance behavior, and commands. Apply these integration rules:
 
-- Map semantic color names under `theme.extend.colors` in
-  `purgetss/config.cjs`.
+- Map semantic color names under `theme.extend.colors` in `purgetss/config.cjs`.
 - Use verified utility classes in Alloy XML.
 - Configure `options.widgets: true` when Widgets contain utility classes.
 - Prefer `config.cjs` for reusable custom rules.
 - Treat `app/styles/app.tss` as generated output and never edit it.
-- Keep only truly specific properties in Widget/controller TSS when no verified
-  utility exists.
-- Use the PurgeTSS Appearance module for light/dark/system selection instead of
-  creating a competing mode service.
-- Read the current PurgeTSS references before naming any utility. Similarity to
-  Tailwind is not evidence that a class exists.
+- Keep only truly specific properties in Widget/controller TSS when no verified utility exists.
+- Use the PurgeTSS Appearance module for light/dark/system selection instead of creating a competing mode service.
+- Read the current PurgeTSS references before naming any utility. Similarity to Tailwind is not evidence that a class exists.
 
 Conceptual mapping only; verify the actual PurgeTSS syntax before use:
 
@@ -102,8 +90,7 @@ module.exports = {
 }
 ```
 
-After generation, inspect the final `app.tss` section for unused or unsupported
-classes. A clean build that still lists a new unsupported class is not complete.
+After generation, inspect the final `app.tss` section for unused or unsupported classes. A clean build that still lists a new unsupported class is not complete.
 
 ## Standard Alloy projects
 
@@ -133,23 +120,17 @@ Example:
 }
 ```
 
-Do not copy a large utility system into manual TSS. Create only the small set of
-selectors the app actually uses.
+Do not copy a large utility system into manual TSS. Create only the small set of selectors the app actually uses.
 
 ## Alloy build-time themes
 
-Alloy's `app/themes/<name>/` folders can override views, styles, and assets at
-build time. Select a theme through `app/config.json`. This is appropriate for
-separate branded builds or compile-time variants.
+Alloy's `app/themes/<name>/` folders can override views, styles, and assets at build time. Select a theme through `app/config.json`. This is appropriate for separate branded builds or compile-time variants.
 
-Do not describe an Alloy build-time theme as runtime light/dark switching.
-Semantic colors are the default for appearance changes while the app runs.
+Do not describe an Alloy build-time theme as runtime light/dark switching. Semantic colors are the default for appearance changes while the app runs.
 
 ## Runtime custom themes
 
-Use a centralized runtime palette or theme service only when semantic
-light/dark/system colors cannot model the requirement, such as multiple user
-selectable brand themes.
+Use a centralized runtime palette or theme service only when semantic light/dark/system colors cannot model the requirement, such as multiple user selectable brand themes.
 
 If that exception applies:
 
@@ -157,11 +138,9 @@ If that exception applies:
 - expose semantic roles, not control IDs;
 - document how already-created proxies receive updates;
 - remove all listeners in controller cleanup;
-- avoid rebuilding the entire window tree unless the app has measured and
-  accepted that tradeoff.
+- avoid rebuilding the entire window tree unless the app has measured and accepted that tradeoff.
 
-`Alloy.Globals` is a legacy/advanced interoperability option, not the first
-recommendation for ordinary dark mode.
+`Alloy.Globals` is a legacy/advanced interoperability option, not the first recommendation for ordinary dark mode.
 
 ## Component rules
 
@@ -169,10 +148,8 @@ recommendation for ordinary dark mode.
 - Widgets own anatomy and behavior, not the product palette.
 - Localized strings and business callbacks come from the host.
 - Destructive styling must remain distinguishable in both appearances.
-- Overlays, focus indicators, disabled states, and text must retain usable
-  contrast in light, dark, and system modes.
-- Do not create separate light/dark controller branches when a semantic color
-  can express the difference.
+- Overlays, focus indicators, disabled states, and text must retain usable contrast in light, dark, and system modes.
+- Do not create separate light/dark controller branches when a semantic color can express the difference.
 
 ## Verification
 
@@ -185,6 +162,4 @@ For every supported platform and form factor:
 5. run PurgeTSS generation when detected and resolve unsupported classes;
 6. compile and build both platform targets before claiming completion.
 
-For exact PurgeTSS behavior, load its current `semantic-colors.md` and
-`appearance-module.md` references. For Titanium property availability, verify
-against the current `ti-api` skill.
+For exact PurgeTSS behavior, load its current `semantic-colors.md` and `appearance-module.md` references. For Titanium property availability, verify against the current `ti-api` skill.

package/skills/ti-guides/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ti-guides
-description: 'Use when working on Titanium SDK fundamentals: project configuration (`tiapp.xml`, `timodule.xml`), CommonJS modules, Hyperloop native access, app distribution (App Store / Google Play, certificates, provisioning), Titanium CLI usage, memory management, bridge optimization, SQLite transactions, image memory, or coding standards. Triggers include `tiapp.xml` in the project root, for either Alloy (`app/`) or Classic (`Resources/`) Titanium projects.'
+description: 'Use when working on Titanium SDK fundamentals: project configuration (`tiapp.xml`, `timodule.xml`), CommonJS modules, Hyperloop native access, app distribution (App Store / Google Play, certificates, provisioning), Titanium CLI usage, memory management, bridge optimization, SQLite transactions, image memory, coding standards, the compatibility matrix (which JDK, Node.js, Xcode or Android SDK a given Titanium SDK needs), or what changed in a Titanium SDK release. Triggers include `tiapp.xml` in the project root, for either Alloy (`app/`) or Classic (`Resources/`) Titanium projects.'
 ---
 
 # ti-guides
@@ -19,6 +19,8 @@ Use this skill when:
 - Using Hyperloop to call native APIs (Objective-C / Swift / Java)
 - Optimizing memory: removing global listeners, caching native properties, image memory footprints
 - Working with the Titanium CLI (`ti build`, `ti sdk install`, `ti sdk select`)
+- Checking which JDK, Node.js, Xcode or Android SDK a Titanium SDK version requires
+- Finding out what changed in a Titanium SDK release and whether it affects existing code
 - Writing CommonJS modules (stateful caching, ES6+ patterns, antipatterns)
 - Authoring `AndroidManifest.xml` overrides
 - Following TiDev style and naming conventions
@@ -47,6 +49,8 @@ Do NOT use for:
 | Google Play (APK / AAB), App Store (IPA), certificates, provisioning, deployment | [app-distribution.md](references/app-distribution.md) |
 | Complete `tiapp.xml` and `timodule.xml` reference | [tiapp-config.md](references/tiapp-config.md) |
 | Titanium CLI commands, options, tasks, configuration, build processes | [cli-reference.md](references/cli-reference.md) |
+| JDK, Node.js, Xcode and Android SDK versions each Titanium SDK supports | [compatibility-matrix.md](references/compatibility-matrix.md) |
+| What changed per 13.x release, and which changes affect your code | [sdk-release-notes.md](references/sdk-release-notes.md) |
 | Community support, modules, sample code, Slack, learning materials | [resources.md](references/resources.md) |
 
 ## Core practices

package/skills/ti-guides/references/coding-best-practices.md

@@ -66,8 +66,7 @@ if (isAndroid) { /* Android path */ } else { /* iOS path */ }
 - Avoid extending the `Ti` namespace. Three reasons:
   1. Ti objects are proxies to native OS components — your extensions may conflict with native functionality.
   2. Arrays stored on the namespace may be immutable; objects may be null unexpectedly.
-  3. There is no guarantee properties persist across SDK versions.
-  Use your own namespace or CommonJS module instead of modifying `Ti`.
+  3. There is no guarantee properties persist across SDK versions. Use your own namespace or CommonJS module instead of modifying `Ti`.
 
 ## 5. App architecture recommendations
 

package/skills/ti-guides/references/compatibility-matrix.md

@@ -0,0 +1,89 @@
+# Compatibility matrix
+
+Which JDK, Node.js, Xcode and Android SDK versions a given Titanium SDK release can build with. Components outside the min/max ranges below are not compatible.
+
+Only the currently supported ranges are reproduced here. Upstream also keeps collapsed tables of long-unsupported ranges (back to Titanium 1.7); if a project is pinned to something older than the rows below, consult the upstream matrix directly.
+
+<!-- TOC-START -->
+## Contents
+
+- [1. Operating system](#1-operating-system)
+- [2. Java Development Kit](#2-java-development-kit)
+- [3. Node.js](#3-nodejs)
+- [4. Android](#4-android)
+- [5. iOS and Xcode](#5-ios-and-xcode)
+- [6. Which platform can build what](#6-which-platform-can-build-what)
+
+<!-- TOC-END -->
+
+## 1. Operating system
+
+| Operating system | Version |
+|---|---|
+| macOS | 10.11.5 and later |
+| Windows | Windows 7 and later (Android) |
+| Linux | Tested on Fedora and (K)Ubuntu; others should work |
+
+## 2. Java Development Kit
+
+The JDK is required to build Titanium apps and modules for Android. OpenJDK or Oracle both work.
+
+| Titanium SDK version | Min JDK | Max JDK |
+|---|---|---|
+| 13.3.0 - latest | 18 | 25 |
+| 12.8.0 - 13.2.0 | 18 | 21 |
+
+`12.0.0 - 12.7.0` (JDK 11-17) moved to the unsupported table when 13.3.0 shipped.
+
+## 3. Node.js
+
+Node.js is required to install and run the Titanium SDK. On Windows, enable `dev mode` in Windows settings for Node to work correctly.
+
+| Titanium SDK version | Min Node | Max Node |
+|---|---|---|
+| 13.1.1 - latest | 20.x | 24.x |
+| 13.0.0 - 13.1.0 | 20.x | 22.x |
+| 12.6.0 - 12.8.0 | 18.x | 22.x |
+
+## 4. Android
+
+As of Titanium 9.0.0 the build system downloads the needed Android SDK platforms and tools automatically. Upgrade those packages only between major projects — changes there have broken the Titanium toolchain several times.
+
+| Titanium SDK version | Min target (`android:targetSdkVersion`) | Max target | Min supported (`android:minSdkVersion`) |
+|---|---|---|---|
+| 13.1.0+ | 15.x (API 35) | 15.x (API 35) | 7.x (API 24) |
+| 12.8.0 - 13.0.1 | 15.x (API 35) | 15.x (API 35) | 5.x (API 21) |
+| 12.5.0 - 12.8.0 | 14.x (API 34) | 14.x (API 34) | 5.x (API 21) |
+| 12.0.0 - 12.5.0 | 13.x (API 33) | 13.x (API 33) | 5.x (API 21) |
+
+A `android:targetSDKVersion` set in `tiapp.xml` must fall inside the min/max target range of the SDK in use.
+
+> **Note:** Titanium SDK 13.4.0 is described in its release note as *preparing the SDK for Android target SDK 36*. The matrix above still lists API 35 as the maximum; treat API 36 as in-progress rather than as a supported target until the matrix says otherwise.
+
+Developing native Android add-on modules on macOS also requires the Xcode command line tools.
+
+## 5. iOS and Xcode
+
+Building for iOS requires macOS — Apple's license agreement allows iOS development only on Apple hardware.
+
+| Titanium SDK version | Min Xcode | Max Xcode | Notes |
+|---|---|---|---|
+| 12.6.3 - latest | 12.0.0 | 16.x | Full support for iOS 18.4 |
+| 12.2.0 - 12.6.2 | 12.0.0 | 16.2 | Full support for iOS 17 |
+| 10.1.0 - 12.1.2 | 11.0.0 | 13.x | Full support for iOS 15 |
+
+| Titanium SDK version | Min iOS SDK | Max iOS SDK | Min target iOS | Max target iOS |
+|---|---|---|---|---|
+| 12.2.0 - latest | 13.0.0 | 17.x | 12.0 | 17.x |
+| 10.1.0 - 12.1.2 | 13.0.0 | 15.x | 12.0 | 15.x |
+
+> **Note:** these two tables lag behind the release notes. Titanium SDK 13.3.0 shipped *support for Xcode 27 and iOS 27*, which no row above reflects. Where they disagree, the release note is the newer statement — see [sdk-release-notes.md](sdk-release-notes.md).
+
+## 6. Which platform can build what
+
+| Target | macOS | Windows | Linux |
+|---|---|---|---|
+| Android | Yes | Yes | Yes |
+| iOS | Yes | No | No |
+
+Anything marked *pre-release* upstream — Beta, Developer Preview, Release Candidate, and continuous builds — is not officially supported.

package/skills/ti-guides/references/resources.md

@@ -111,7 +111,13 @@ See `hyperloop-native-access.md` for native module development:
 
 ### IDE support
 
-- VS Code: https://code.visualstudio.com/ (with Titanium extensions)
+Titanium has no IDE of its own; the CLI is the common denominator and every editor below drives it.
+
+| Editor | Integration |
+|---|---|
+| Visual Studio Code | Titanium extension — https://code.visualstudio.com/ |
+| JetBrains IDEs | Community plugin — https://github.com/devloopsnet/titanium-jetbrains |
+| Atom | Titanium package (Atom itself is discontinued) |
 
 ### CLI tools
 

package/skills/ti-guides/references/sdk-release-notes.md

@@ -0,0 +1,75 @@
+# SDK release notes: what changes your code
+
+Condensed 13.x release history, filtered down to what actually affects how you write or configure an app. Full changelogs (every commit, every credit) live upstream under `Titanium_SDK_Release_Notes/`.
+
+Each GA release desupports the previous patch release. Running an unsupported version is allowed, but bug reports against it are not accepted.
+
+<!-- TOC-START -->
+## Contents
+
+- [1. Version timeline](#1-version-timeline)
+- [2. 13.4.0 — Android target SDK 36 groundwork](#2-1340--android-target-sdk-36-groundwork)
+- [3. 13.3.1 — patch](#3-1331--patch)
+- [4. 13.3.0 — Xcode 27, iOS 27, multi-scene](#4-1330--xcode-27-ios-27-multi-scene)
+- [5. 13.2.0 — ViewPager2, keepHardwareMode](#5-1320--viewpager2-keephardwaremode)
+- [6. Bundled module versions](#6-bundled-module-versions)
+
+<!-- TOC-END -->
+
+## 1. Version timeline
+
+| Version | Date | Headline |
+|---|---|---|
+| 13.4.0.GA | 28 July 2026 | Prepares the SDK for Android target SDK 36; v8 memory cleanup |
+| 13.3.1.GA | 20 July 2026 | Patch — iOS restart and LiveView fixes |
+| 13.3.0.GA | 01 July 2026 | Xcode 27 and iOS 27, Hyperloop 8.0.0, iOS multi-scene apps |
+| 13.2.0.GA | 08 April 2026 | iOS core changes, Node.js 24 support, Android fixes |
+| 13.1.0.GA | — | Minor release, high-priority fixes |
+| 13.0.0.GA | — | Major release: iOS 26 / Xcode 26, Android 16 KB page size |
+
+## 2. 13.4.0 — Android target SDK 36 groundwork
+
+- **Prepares the SDK for Android target SDK 36.** Groundwork only; the compatibility matrix still lists API 35 as the maximum target. See [compatibility-matrix.md](compatibility-matrix.md) § Android.
+- v8 memory cleanup (Android).
+- `Window.rect` now reflects pre-open `left`/`top` instead of reporting zeros before the window opens (Android).
+- Build paths adjusted for Windows hosts.
+- iOS: fixed the dimming area in a TableView SearchBar.
+- The debug-only selector for `Ti.App._restart()` was removed, making the method callable outside debug builds.
+
+## 3. 13.3.1 — patch
+
+iOS-only fixes: the `restart` method, and LiveView restart. Hyperloop bumped to 8.0.1.
+
+## 4. 13.3.0 — Xcode 27, iOS 27, multi-scene
+
+- **Xcode 27 and iOS 27 support.** This postdates the Xcode/iOS rows in the compatibility matrix, which still cap at Xcode 16.x.
+- **iOS multi-scene applications** are supported.
+- **Hyperloop 8.0.0.**
+- ScrollableView (Android): a deprecation note was added for its older events. As of SDK 13.4.0 no ScrollableView event is actually flagged deprecated in the API metadata — `scroll`, `scrollend` and `dragend` all remain current — so treat this as advance warning, not as a removal.
+- ImageView: pinch-and-zoom improved on Android; the remote-image fade-in animation was removed on iOS.
+- TabGroup (iOS): `focus` is now emitted separately from `selected`. Code that assumed one event covered both cases needs checking.
+- `borderWidth` no longer renders at double thickness when `borderRadius` is an array (iOS).
+- Android: Material 3 BottomNavigation theme and dark/light switching fixes, CameraX rotation fix under orientation lock, WebView fix for URLs carrying large GET data, `Ti.Preferences` optimized.
+
+## 5. 13.2.0 — ViewPager2, keepHardwareMode
+
+- **ScrollableView moved to ViewPager2 on Android.** A backing-widget swap; verify paging, nested scrolling and any custom paging control against it.
+- **`keepHardwareMode` added to `Ti.UI.View`** (Android) — controls the view's render mode.
+- **`hideKeyboardAccessoryView` added to WebView** (iOS) to hide the keyboard accessory bar.
+- **AttributedString support on Android**, previously iOS-only.
+- Images can be dragged horizontally inside a ScrollableView (Android).
+- ListView caches `searchText` (Android).
+- The app name in `AndroidManifest.xml` now uses the i18n value.
+- Node.js 24 support; core-js upgraded, removing the `baseline-browser-mapping` warning.
+- iOS: Mac Catalyst fixes for `Ti.UI.Button` styling and events, and module builds with `mac=true`.
+
+## 6. Bundled module versions
+
+Versions shipped with each SDK. Unchanged rows are omitted.
+
+| Module | 13.2.0 (Android / iOS) | 13.3.0+ (Android / iOS) |
+|---|---|---|
+| facebook | 14.0.0 / 15.0.0 | 15.0.0 / 16.0.0 |
+| hyperloop | 7.1.0 / 7.1.0 | 8.0.1 / 8.0.1 (8.0.0 in 13.3.0) |
+
+Stable across 13.2.0–13.4.0: `ti.map` 5.7.0 / 7.3.1, `ti.webdialog` 2.5.0 / 3.0.2, `ti.playservices` 18.6.0 (Android only), `ti.identity` 3.2.0 / 5.0.0, `urlSession` 4.0.1 (iOS only), `ti.coremotion` 4.0.1 (iOS only), `ti.applesignin` 3.1.2 (iOS only).

package/skills/ti-guides/references/style-and-conventions.md

@@ -46,8 +46,7 @@ else
 const fullName = firstName + ' ' + lastName
 ```
 
-Return statement placement:
-Do not put `return` on its own line followed by an object literal. JavaScript will insert a semicolon automatically and return `undefined`.
+Return statement placement: Do not put `return` on its own line followed by an object literal. JavaScript will insert a semicolon automatically and return `undefined`.
 ```javascript
 // Wrong
 return

package/skills/ti-howtos/references/debugging-profiling.md

@@ -382,8 +382,7 @@ Android Studio (GUI): Tools → Device Manager → Create Device.
 
 ### Modifying emulators
 
-Increase disk space:
-Edit `~/.android/avd/<NAME>.avd/config.ini`:
+Increase disk space: Edit `~/.android/avd/<NAME>.avd/config.ini`:
 ```
 disk.dataPartition.size=1024m
 ```

package/skills/ti-howtos/references/location-and-maps.md

@@ -3,8 +3,7 @@
 ## 1. GPS position tracking
 
 ### FusedLocationProvider (Android)
-Since TiSDK 7.1.0, Titanium supports `FusedLocationProvider` for significant battery savings.
-Requirement: include the `ti.playservices` module in your project.
+Since TiSDK 7.1.0, Titanium supports `FusedLocationProvider` for significant battery savings. Requirement: include the `ti.playservices` module in your project.
 
 ### Accuracy configuration
 

package/skills/ti-howtos/references/using-modules.md

@@ -25,8 +25,7 @@ Community modules:
 - From Zero To App list: https://fromzerotoapp.com/modules/
 - Curated list of modules maintained by Michael Gangolf
 
-Marketplace:
-The original Appcelerator Marketplace is no longer available. Find community modules on GitHub and npm. A curated list is at https://fromzerotoapp.com/modules/.
+Marketplace: The original Appcelerator Marketplace is no longer available. Find community modules on GitHub and npm. A curated list is at https://fromzerotoapp.com/modules/.
 
 ### Pre-installed modules
 Some modules ship with the SDK and do not need separate installation: `ti.map`, `ti.identity`, `ti.webdialog`, `ti.applesignin`.

package/skills/ti-howtos/references/web-content-integration.md

@@ -80,8 +80,7 @@ Events:
 
 ### Local web content communication
 
-Logging from WebView:
-Ti.API methods work inside local HTML.
+Logging from WebView: Ti.API methods work inside local HTML.
 
 ```html
 <html>

package/skills/ti-howtos/references/webpack-build-pipeline.md

@@ -53,8 +53,7 @@ Example:
 When you `import { func } from '@/utils'`, Webpack picks the correct version for the build target.
 
 ## 5. Diagnostic web UI
-Webpack includes a web interface to analyze builds and asset sizes.
-Default URL: `http://localhost:1732/webpack/latest/web`
+Webpack includes a web interface to analyze builds and asset sizes. Default URL: `http://localhost:1732/webpack/latest/web`
 
 ## 6. Project plugins
 Webpack support is powered by plugins chosen based on project type: