Choosing Alloy Controllers or Raw Titanium SDK in Appcelerator Apps

When the Abstraction Helps and When It Hurts

Imagine you need a simple settings screen with a toggle for notifications. Writing the same UI twice—once for iOS, once for Android—quickly becomes tedious. That’s where Appcelerator’s Alloy MVC framework promises to reduce duplication by compiling XML views, TSS styles, and JavaScript controllers into plain Titanium SDK calls.

Alloy’s Strengths for Standard UI

Alloy shines when you follow common patterns:

• Forms with labels, switches, text fields
• Lists bound to a model or collection
• Navigation windows that share a controller across platforms

The framework removes boilerplate: you declare the layout in app/views/settings.xml, style it with app/styles/settings.tss, and handle events in app/controllers/settings.js. During alloy compile the XML becomes Titanium view creation, the TSS becomes style objects, and the controller supplies the logic.

Worked Example: A Settings Form with Platform‑Specific Switches

Suppose the notification switch should be green on iOS and blue on Android. In Alloy you can express that without branching logic.

<!-- app/views/settings.xml -->
<Alloy>
  <Window class="container">
    <Switch id="notifySwitch" value="false" platform="ios" />
    <Switch id="notifySwitch" value="false" platform="android" />
    <Label text="Notifications" />
  </Window>
</Alloy>

/* app/styles/settings.tss */
Switch {
  value: false;
}
Switch[platform=ios] {
  backgroundColor: '#2ecc71'; /* iOS green */
}
Switch[platform=android] {
  backgroundColor: '#3498db'; /* Android blue */
}

The controller can stay empty or just listen for the change event:

// app/controllers/settings.js
$.notifySwitch.addEventListener('change', function(e) {
  Ti.API.info('Notification switch is ' + (e.value ? 'on' : 'off'));
});

The raw Titanium equivalent would require creating two separate Switch instances, checking Ti.Platform.os for each property, and manually applying colors—more lines and more places to forget a platform check.

When to Drop to Raw Titanium

Alloy’s abstraction adds a build step and can obscure the generated Titanium code. If you need:

• Complex gestures that bypass Alloy’s event wiring
• High‑performance list rendering with custom recycling logic
• Direct access to low‑level APIs (e.g., Bluetooth, camera) that Alloy does not expose

you may find it easier to write the controller in pure Titanium. For example, a canvas‑based signature pad that captures touch points and draws lines is simpler when you manage the Ti.UI.View touch handlers yourself rather than fighting Alloy’s generated view hierarchy.

Actionable Decision Checklist

1. Check SDK compatibility: run ti sdk list and alloy --version; ensure the Alloy version matches the Titanium SDK release.
2. Create a prototype screen with both approaches and compare build time (time alloy compile) and runtime memory (use Ti Studio profiler).
3. If the UI is a standard form or list, start with Alloy; move to raw Titanium only when profiling shows a bottleneck or when a feature cannot be expressed in Alloy’s markup.
4. Keep a thin layer: if you start with raw Titanium, you can later extract reusable components into Alloy widgets without rewriting the whole screen.

Limitation: Legacy Compatibility

Older Alloy projects may fail to compile with newer Titanium SDKs because deprecated APIs (e.g., Ti.UI.iPhone) are removed. Before upgrading, run alloy compile --debug and inspect the output for warnings. When in doubt, pin the SDK version in tiapp.xml and update Alloy plugins incrementally.