Reducing Platform Branching with Titanium SDK Aliases

The 'If-Else' Bloat Problem

When building cross-platform applications, it is common to encounter native APIs that behave differently on iOS and Android. The instinctive reaction is to wrap every platform-specific call in a conditional block:

if (Ti.Utils.isIOS) {
    // iOS specific logic
} else if (Ti.Utils.isAndroid) {
    // Android specific logic
}

While this works for a few calls, it quickly degrades the readability of your business logic. Your core application flow becomes buried under a mountain of platform checks, making the code harder to test and more prone to regressions when adding a new OS version. The solution is to move from inline branching to an Alias system.

Abstracting Native Logic via Aliases

The Alias system in Titanium SDK allows you to define a common interface in your main application logic while delegating the actual implementation to platform-specific files. Instead of asking "Which platform am I on?" inside your main function, you call a generic method that the SDK resolves based on the target build.

This architectural pattern separates the intent (e.g., "Request Camera Permission") from the implementation (the specific Android Manifest request vs. the iOS Info.plist prompt). By isolating these in separate directories, the main application logic remains platform-agnostic.

Implementation Example: Hardware Permission Handler

Consider a scenario where you need to handle file system paths, which differ fundamentally between iOS and Android. Rather than checking the OS every time you save a file, you can create a permission and path alias.

1. Define the Common Interface

In your main logic file (e.g., app.js), call the function as if it were a standard library method:

// Main Logic
const pathHandler = require('platform/pathHandler');
const savePath = pathHandler.getStoragePath('user_data');
Ti.FileUtils.write(savePath, 'Hello World');

2. Create Platform-Specific Implementations

You must create separate files in your project structure to handle the actual logic. These files should export the same function name to maintain the interface.

For iOS (/platform/ios/pathHandler.js):

exports.getStoragePath = function(folder) {
    return Ti.FileUtils.getApplicationDocumentsDirectory() + '/' + folder;
};

For Android (/platform/android/pathHandler.js):

exports.getStoragePath = function(folder) {
    return Ti.FileUtils.getExternalStorageDirectory() + '/' + folder;
};

Verification

To verify this is working, run the app on both an iOS simulator and an Android emulator. Check the device logs (Logcat for Android, Xcode Console for iOS) to confirm that the file is being written to the Documents directory on iOS and the External Storage directory on Android.

Trade-offs and Debugging Hurdles

While aliases clean up the main codebase, they introduce a layer of indirection that can complicate development:

• Traceability: When you "Go to Definition" in some IDEs, the editor may not know which platform file to open, forcing you to manually navigate to the correct directory.
• Parity Risk: If you update the iOS implementation to accept a second argument but forget to update the Android version, the app will crash or behave unexpectedly only on Android.
• Fragmentation: Overusing aliases for trivial tasks (like changing a button color) can lead to a fragmented codebase where the logic is scattered across too many files.

Decision Matrix: Alias vs. Inline Check

Scenario	Recommended Approach	Reasoning
Simple UI tweak (e.g., padding)	Inline Ti.Utils check	Low complexity; doesn't justify a new file.
Native API / Hardware access	Alias System	High complexity; keeps business logic clean.
Complex File System logic	Alias System	Different OS architectures require distinct logic.

Final Takeaway

Use the Alias system to encapsulate behavioral differences, not visual differences. When a native feature requires more than three lines of platform-specific code, move it into a platform directory. This ensures your core application logic remains a readable blueprint of what the app does, while the platform files handle how it is done on specific hardware.