The following could easily be a quote from someone just learning about Titanium:
I’ve certainly had these conversations with clients as a freelance Titanium developer. Also in my role as a Developer Advocate I hear this a lot when I start to explain Titanium to developers looking for a cross-platform app development solution.
Titanium !== HTML
Every time the comparison with Phonegap (Cordova), Ionic or the like popped up, I used to start shaking my head, waving my arms and stating loudly that Titanium apps involve no HTML.
“Titanium apps are not websites gift-wrapped as apps.”
What do you mean with Native?
So, I started asking a question in response:
“What makes an app native?”
Does it mean that…
- The developer used the platform tools provided by Apple, Google and Microsoft?
- The developer programmed in the default languages for these platforms?
- The app uses the building blocks (APIs) that these platforms expose?
- The app offers users the experience they expect on these platforms?
What is a good User Experience?
So, what does platform conform UI & UX mean? Well, first of all it means we don’t care about the technology, but what it gets us; How does the app look and feel to the user? Second, the desired experience is platform specific.
It looks and works as expected
TabGroups are a great example. On Android they’re typically integrated in the top Action Bar and the tabs will scroll if you have more than it can fit. On iOS the Tab Bar can be found at the bottom and when you have more than five the fifth tab will lead to a screen to access the others. Windows Pivot Tabs work much like Android, but look slightly different and they are not integrated in the Command Bar, which is typically found at the bottom of the screen.
So, the technology to build a native app should not introduce its own UI controls, but use the ones provided by the platform.
Titanium provides cross-platform APIs where possible, but always maps these to the platform specific UI components. So Ti.UI.TabGroup for example will get you the above platform-specific results while using the same code (here as Alloy XML View):
<Alloy> <TabGroup> <Tab title="Tab A" icon="/images/icon.png"> <Window><Label>Tab A</Label></Window> </Tab> <Tab title="Tab B" icon="/images/icon.png"> <Window><Label>Tab B</Label></Window> </Tab> <Tab title="Tab C" icon="/images/icon.png"> <Window><Label>Tab C</Label></Window> </Tab> </TabGroup> </Alloy>
For controls that have no parity across platforms we provide APIs under platform specific namespaces, like Ti.UI.Android.CardView.
API parity where we can, platform-specific APIs where we can’t – always honouring the target platforms.
It “feels” as expected
But there’s another, more subtle factor that makes a good user experience. The interaction with the app needs to feel right. By this we mean the response (time) and visual feedback is as can be expected from the platform.
This in particular has historically been challenging for cross-platform solutions. All of them in one way or another provide a run-time abstraction layer over the platform APIs. This can easily become a bottleneck. With Titanium we’ve come a long way optimising our APIs. Take ListView, which can be up to 60% more responsive than its successor TableView.
For apps that use HTML for the UI, this continues to be a struggle. The flat UI trend made it easier to get the look right, but you don’t need to be too much of a nerd to notice the difference in how the UI “responds” to interactions. It often just doesn’t feel quite right, and that’s what UX is all about: getting it right.
What does it take to achieve a great UX?
Above all, it takes a great developer. You can build crappy apps in Xcode using Swift, so surely you can do the same with any other (cross-platform) technology. Use the right platform-specific UI controls on the right places, fix memory leaks, code clean and efficient.
Second, use the provided building blocks – don’t imitate. This is where we circle back to Titanium !== HTML and our 4 bullet points. We strongly believe that in order to deliver that platform-native UX you need to build on the platform-native UI and system APIs. To achieve bullet number four, you need number three.
This is why Facebook gave up on HTML apps and eventually wrote React Native.
And yes, this is what we have offered with Titanium since 2009: