Appcelerator Blog

The Leading Resource for All Things Mobile

What Defines a Native App?

88 Flares 88 Flares ×

The following could easily be a quote from someone just learning about Titanium:

“JavaScript?! Like Phonegap? Sorry, I rather have a native app.”

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.”

But, with clients or other less technical people to whom JavaScript simply triggered an association with these other technologies, introducing HTML as yet another technical term wasn’t always successful. Plus, defining Titanium by what it is not, just didn’t feel like the way to go.

What do you mean with Native?

So, I started asking a question in response:

“What makes an app native?”

Does it mean that…

  1. The developer used the platform tools provided by Apple, Google and Microsoft?
  2. The developer programmed in the default languages for these platforms?
  3. The app uses the building blocks (APIs) that these platforms expose?
  4. The app offers users the experience they expect on these platforms?

After talking a bit about what they believe JavaScript can’t offer, it always boils down to number four. This was also the result of a Twitter Poll I ran recently:

Twitter Poll

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

iOS, Android and Windows each have different design guidelines (see iOS, Android, Windows) and by sticking to them, your app will be more predictable and therefor easier to use.

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):

		<Tab title="Tab A" icon="/images/icon.png">
			<Window><Label>Tab A</Label></Window>
		<Tab title="Tab B" icon="/images/icon.png">
			<Window><Label>Tab B</Label></Window>
		<Tab title="Tab C" icon="/images/icon.png">
			<Window><Label>Tab C</Label></Window>

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:

“A single, JavaScript codebase bridging to thousands of platform-specific, original APIs for UI controls and system services, to deliver a great UX.”

Code Strong, Code Native.. in JavaScript! 🚀

88 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 88 Email -- 88 Flares ×


  1. Ophir Oren

    I agree with every written word in this article. But I also think that while presenting it like this is aimed more for the beginner developers and non-technical clients, the more experienced developers are looking for more…

    I think experienced self-respecting developers, when choosing a technology check and learn the platform they choose more in-depth (or at least I hope they do). So they come to the conclusion that Titanium !== HTML.

    Part of what a platform should aim for is the developer who uses it. Developers want to maximize their experience with the platform not only by how it works, but by the tools it gives for developers, and by how much code reuse is possible to do – not only in the platform itself – but also use the same code of our app in web, node, or any other way (which is something I see a lot done with React these days).

    But overall – great article (one of many to come I hope – I always enjoy reading your stuff).

  2. Cool Fokke! “Mast read” issue.

  3. Since when native looking apps equal to native apps?
    Native apps always were apps, compiled to binary which is executed on the platform’s CPU

    • That’s exactly what I tried to show with this post; there are many definitions of what a native app is. Writing in languages that compile down to binary is one, but whether or not the UI is using native components is another.

Comments are closed.

Sign up for updates!

Become a mobile leader. Take the first step to scale mobile innovation throughout your enterprise.
Get in touch
computer and tablet showing Appcelerator software
Start free, grow from there.
88 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 88 Email -- 88 Flares ×