Library / SDK
tidev/titanium-sdk avatar
tidev/titanium-sdk

tidev/titanium-sdk: native mobile apps compiled from JavaScript

🚀 Native iOS and Android Apps with JavaScript & TypeScript

2,802 stars1,200 forksObjective-CNOASSERTION

At a glance

What is it?
The SDK behind Titanium and Alloy, where JavaScript compiles into a real native binary for iOS and Android with platform UI controls rather than a WebView.
Who is it for?
Titanium's pitch is unusually specific for a cross-platform framework: not a WebView, not a JavaScript engine bolted onto a native shell, but a compiler that turns your JavaScript into a native executable, with native UI controls such as TabGroup on iOS and ActionBar on Android. That is the claim the README makes and the claim the repository layout is built to support, with parallel `iphone/` and `android/` trees and a shared `common/`.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 5 days ago.
What is it written in?
Mainly Objective-C, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 9, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Native compilation rather than a WebView wrapper

The README makes a claim that is worth reading twice, because most cross-platform frameworks make a softer version of it: native apps built using JavaScript, no hybrid and no embedded WebView, compiled and run locally with full offline support.

If that holds, the difference from a hybrid approach is not cosmetic. There is no HTML document to render, so the app runs without a network round trip on launch, and the UI comes from platform controls. The README names them: TabGroup on iOS and ActionBar on Android. A framework that reaches the platform's own widgets can look and behave like an app the platform expects, and it inherits accessibility and system integration work that a WebView tends to reimplement badly.

The feature checklist behind that claim names watchOS targets, an in-application SQL database, geolocation with forward and reverse lookup, camera work covering photos plus video playback and recording, and calendar events. Those are the modules people depend on in a shipping app, and the fact that they sit in the SDK rather than in plugins says something about where the project's centre of gravity is.

iphone/ and android/ trees with a shared common/

The repository root explains how the SDK is put together better than any prose would. There is `iphone/` for the iOS implementation, `android/` for Android, and `common/` for the JavaScript layer both share. Alongside them sit `cli/` for the command line tooling, `build/` for the build system, `templates/` for project scaffolding, `apidoc/` for API documentation, `tests/` for the test suite, `support/` and `maintainer-docs/` for the people maintaining it.

There is also documentation that is not the README: `MIGRATION_GUIDE.md` and `CHANGELOG.md` at the root, and a `docs/` directory. For a framework that has existed long enough to have a 230-item open issue list, a migration guide is a better signal of health than any claim about activity, because it records how existing apps are expected to move between versions.

The tree also carries configuration that says a lot about the project's tooling: `.swiftlint.yml` for Swift, `.oxlintrc.json` for JavaScript linting, `.husky/` for commit hooks, `lint-staged.config.js` for staged formatting, and an `AGENTS.md` alongside a `CLAUDE.md`. Those last two are unusual to see in a mobile SDK and suggest the project has started writing repository guidance for automated coding assistants, which is its own kind of currency in 2026.

Every build command is an npm script wrapping scons

Building the SDK means running SCons through npm scripts. The scripts in `package.json` are a readable map of the build:

bash
npm run build -- ios
npm run build -- android

Underneath, those call `node ./build/scons build` with a platform argument. The same pattern repeats for the variants you would expect: `cleanbuild`, `clean`, `clean-modules` and `clean-sdks`, each with `android` and `ios` suffixed forms where the distinction matters. A full local packaging run is chained in `build:local`, which builds, packages with `--skip-zip`, and then installs.

Two details in that script list are practical rather than cosmetic. `format:android` echoes that formatting Android code is not supported, so only Objective-C and Swift go through the formatters. And `build:docs` runs `docgen apidoc`, meaning the API reference is generated from annotations in the source rather than written by hand, which is why `apidoc/` can be regenerated on demand.

The scripts also include `deprecations` and `docs:removed`, the latter pinned to `8.0.0`. A framework that tracks what it removed in a given major version, and can print that list, is telling you something real about upgrade planning.

Version 14.0.0 in the manifest, 13.4.1 as the newest tag

Here is a discrepancy worth naming rather than smoothing over. `package.json` reports version 14.0.0 and the package name `titanium-mobile`, with per-platform module API versions of 2 for iphone and 4 for android. The published tags tell a different story: 13_4_1_GA on 2026-08-25, 13_4_0_GA on 2026-07-28 and 13_3_1_GA on 2026-07-21, with underscore-separated names and a GA suffix.

Both statements can be true at once. A development branch on the way to 14.0.0 is exactly what you would expect to find in `package.json` on the main branch, while the GA tags lag until a release is cut. What you should not do is read 14.0.0 as a shipped version.

The tag naming also tells you how releases are labelled, and the underscore convention matters if you script against the releases page. The release notes themselves are empty in what is published here, so for what actually changed in a given version, `CHANGELOG.md` in the repository and `build:changelog` in the scripts are the places to look.

GitHub reports the last push on 2026-09-24 and the repository is not archived. The repository language is Objective-C, which is the tell that iOS work has historically been the deeper of the two platform implementations.

Apache 2 by the README, no assertion in the metadata

Two licensing statements again, and this one is worth resolving before you build anything on top. The README says Titanium SDK is licensed under the OSI approved Apache Public License, version 2, and points at the `LICENSE` file for specifics. The repository's own license metadata records no assertion rather than naming a licence.

In practice, a metadata field that says no assertion usually means GitHub's licence detector did not recognise the file rather than that the licence is uncertain, and an Apache 2 header is straightforward to detect. The README statement is the more specific and more likely accurate of the two.

Still, the resolution takes thirty seconds and the stakes are high for an SDK embedded in a commercial app: open `LICENSE` at the repository root and read it. The same applies to any module or plugin you add, since Titanium's module ecosystem carries its own licences that this repository does not govern. The README's sponsors section points at TiDev as the organisation behind the SDK, which is the entity to ask when a question spans the framework and its commercial modules.

Alloy, Hyperloop and SPM are named in the table of contents

The README's table of contents lists considerably more than the feature checklist, and those section names are the most honest summary of the project's scope. Alloy appears with its own example, which points to the Alloy MVC framework as the structured way to write Titanium apps rather than ad hoc view construction. Hyperloop gets the longest treatment in the outline, with sub-entries for cross-platform reuse, direct API access, JavaScript everywhere, third-party libraries, custom animations and running native code.

Hyperloop is the interesting one historically. It is a mechanism for sharing native source between platforms from one definition, and if it is still in the table of contents in 2026, that is a statement about how the project handles drift between its two implementations. Swift Package Manager support for iOS has its own heading, which is a small but real signal: adopting a toolchain Apple itself pushes matters for a framework that has been around since Appcelerator.

The README is mostly a feature checklist and an outline, so the substance of those sections lives in the documentation site. The repository root points at titaniumsdk.com, and `docs/`, `apidoc/` and `maintainer-docs/` cover different audiences.

Editorial conclusion

Titanium's pitch is unusually specific for a cross-platform framework: not a WebView, not a JavaScript engine bolted onto a native shell, but a compiler that turns your JavaScript into a native executable, with native UI controls such as TabGroup on iOS and ActionBar on Android. That is the claim the README makes and the claim the repository layout is built to support, with parallel `iphone/` and `android/` trees and a shared `common/`. Two things a reader should settle before committing. First, version naming: `package.json` says 14.0.0 while the newest published tag is 13_4_1_GA from 2026-08-25, so ask which line you are targeting. Second, licensing: the README states Apache Public License version 2 while the repository's own metadata records no assertion. Open `LICENSE` and treat that as the answer. For everything past the feature list, the README's own table of contents points at Hyperloop, Alloy and Swift Package Manager support, and the repository carries `MIGRATION_GUIDE.md` and `CHANGELOG.md` for the parts a new contributor actually needs.

Frequently asked questions

Is Titanium SDK still actively developed?

GitHub reports the last push on 2026-09-24 and the repository is not archived, and tagged GA releases appeared in July and August 2026 at 13_4_0 and 13_4_1. The main branch manifest already reads 14.0.0, so development is on a 14 line while the newest published tag is 13.4.1.

Does Titanium use a WebView like other cross-platform frameworks?

The README states the opposite, listing native apps built with JavaScript with no hybrid and no embedded WebView as a supported feature, along with native platform controls such as TabGroup on iOS and ActionBar on Android. It also claims the apps are compiled locally with full offline support, which follows from not rendering an HTML document.

Which platforms does Titanium SDK target?

iOS and Android are named as the currently supported native platforms, and watchOS targets appear in the feature list. The repository is split into `iphone/` and `android/` trees with a shared `common/` directory, and `package.json` carries separate module API versions for each platform.

How do I build the Titanium SDK from source?

Through the npm scripts in `package.json`, which wrap SCons. `npm run build -- ios` and `npm run build -- android` call `node ./build/scons build` with a platform argument, and there are matching `cleanbuild`, `clean` and `clean:ios` or `clean:android` variants. The build needs a native toolchain for the platform you are targeting, not just Node.

Official sources

  1. Issues
  2. Project website
  3. README
  4. Releases
  5. tidev/titanium-sdk on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/tidev-titanium-sdk.svg)](https://hysenlabs.com/projects/tidev-titanium-sdk)