Thanks trigger.io, but we’re sticking with Appcellerator

    Posted in News & Stuff    |    No Comments

We recently got a mailshot from trigger.io about their mobile build solution which apparently had

none of the bloat and bugginess of a compile-down solution like Appcelerator.

which made me think two things.

  1. What is the bloat and bugginess assumed in Appcellerator?
  2. Is this new solution any good

Where’s the Bloat and Bugginess?
First of all, the whole Eclipse thing (which Appcellerator is based on) is something that some folks either love or hate. Once you’ve got over the whole ‘who needs an IDE, I just use vi’ nonsense, Eclipse is at the same time one of the best IDEs and also one of the most ‘fragmented’ due to it’s plugin natures and all things to all men approach. But is it bloated or buggy? Not so much, because of it’s modular nature, it only has what it needs, and you can add the other stuff as and when you need it (so we added the Trac plugin). (Disclosure: I’m from a Java background and Eclipse always wins for me with it’s great debugging, integration with svn/git, trace, tomcat and plugin support)

None of this really applies to Appcellerator as it is packaged as one download for you and off you go – Eclipse is stable. Appcellerator on the other hand may be where the trigger.io guys were aiming at – bloat from the bundled libraries, and bugs in the toolchain.

Fixing Bloat and Bugginess
Appcellerator includes all libraries (+200) which act as the bridge between your javascript and native. This can be reduced by removed the libraries you don’t need for a project – not pretty, but this may help http://developer.appcelerator.com/question/45861/reducing-apkapplication-filesize

Switch to Trigger.io?
Should we switch to Trigger.io? Here are my top 5 reasons why not:

  1. It’s not mature right now.
    You’ve got to start somewhere, but trigger.io are still working on some native components, so if we did switch to this kind of tech, we’d probably go for PhoneGap
  2. Internet Connection
    Cloud based builds are a dependancy on my internet connection, which means I can’t build and compile in the deepest countryside (or 5 miles outside the M25)
  3. Opaque toolchain and dependancy on Trigger.io
    What if trigger.io goes down? I can’t even see how their toolchain works, much less still try and fix any problems with it.
  4. Native Modules . Sorry guys, but if I need to add a new module and expose it in javascript I can do this in Appcellerator. I can’t do this in trigger.io, and neither can anyone else so I can’t benefit from their efforts either.
  5. Pricing
    Maybe I’ve got this bit wrong, but nobody else does Per-App Pricing (what? I’ve just discovered that Appcellerator now do the same) – $299/month for a Pro account is madness https://trigger.io/pricing/

Comments?

London Film Museum – iPad iTour App

    Posted in News & Stuff    |    No Comments

We are pleased to announce the launch of the new iPad App for The London Film Museum. The App is the first of its kind, enabling visitors of the museum to scan QR codes throughout their visit to the museum, unlocking additional content associated to exhibits.

The App is built using our extensive Appcelerator expertise combined with our server-side development skills to create a fully content managed back end with some rich educational features embedded.

The App is now running at London Film Museum which you can get your hands on when you visit. This App is not available through the public Apple store so sadly no downloads for those of you that want to take a peek, you will simply have to visit London Film Museum to get the full experience.

Some screenshots posted below, content for this App is copyright restricted, hence the lack of real content here.

Native Apps vs HTML 5 Apps

    Posted in News & Stuff    |    3 Comments

The debate at the moment regarding native mobile vs. HTML 5.0 apps is an interesting debate to say the least. Whilst our position on this topic should be relatively obvious having developed native apps, we still wanted to provide an objective viewpoint.

Lets first take a look at native apps. Native apps are strong in a number of ways that HTML apps just simply can’t compete with. When we want a high gloss, easy to navigate, feature rich and fast responding mobile application it has to be native all the way. Native applications are designed in short to run natively, taking full advantage of devices hardware graphics acceleration hard disk, memory and other hardware resources. If you also add integration with other applications such as the phones photo library, the user’s address book and the geo location services, we can see that what are basic features for a native app that are just impossible for an HTML app.

Now I am not saying that you can’t have an easy to navigate and feature rich HTML app, however from a usability perspective the native app will win hands down as the user experience of the native app will always far exceed the HTML app. We are assuming here that we are talking about the same well designed app being developed in both technologies competing against each other, badly designed apps will always be bad, regardless of the technology behind them.

Functionality aside, let’s talk about the relationship that people have with mobile apps. The world is fast moving in the technology arena and mobile is definitely one of the fastest areas of technology progression with regards to social impact. Smartphones in many cases are starting to replace other electronic devices such as laptops and now many non-electronic lifestyle items such as wallets. I strongly believe that we have started to see what is soon to become the norm, people running and managing their lives through a series of mobile apps that they choose to install on their phones. Now faced with the choice to install an app to service a function that is of use, if there are two apps both capable of performing the same task, however one is native and one is HTML, which would you install? The one that is the most enjoyable and simple to use.

Native apps can do far more than HTML apps. If you want to develop an application tomorrow to create a guitar tuner, this application would have to be done natively. The guitar tuner application would need to take advantage of many of the native resources available to the device such as its microphone and speaker. This app simply couldn’t be built using HTML technologies as there is no API into the smartphones microphone or speaker from HTML or JavaScript, even if there were it would be slow in comparison to a native app. If you simply want to allow the user to add your clients company phone number to their Contacts, better go native. If you want to save some user settings, in an HTML app you can save a cookie and hope when the user clears their other cookies, they leave yours alone.

So what is an HTML app if it can’t make use of the devices resources and services?

An HTML app is nothing other than a mobile optimised website making use of some very clever mobile web technologies such as jQT and iWebKit for instance. Lets not mistake that actually it is no more of an app to a mobile device than a website is an app to a desktop or laptop. It just has some clever mobile optimised JavaScript and CSS libraries that can be used to create nice animation and interaction for the user on the mobile device. Many of these mobile frameworks are simply copying the style of view components that exist on the devices natively anyhow.

This sounds like I am being negative towards HTML apps, well in fact I’m not, they just are what they are. As I said there is some very clever technology that goes into optimising web sites for mobile.

So if HTML apps are not able to outperform native apps why develop them?

Well the answer is quite simple. There are two factors here that sway people towards HTML apps. The first is platform interoperability. An HTML app can be developed once and used by multiple mobile platforms such as iPhone, Android and Blackberry. A native phone app built using Apple IOS will only run on iPhone meaning that native apps requiring deployment onto multiple platforms require re-developing for each supported platform.

This brings us around to the second factor, which is in fact a by-product of the first, cost. Working with web technologies it is quick to get results compared to development in IOS and Java, especially IOS, lengthy development cycles for multiple platforms is not a cheap exercise. So the reality is that it is quick to develop, only has to be developed once and with a couple of tweaks you can get an HTML app ready for a multiplatform launch quickly and much cheaper.

Is an HTML app the right platform choice for me? Well if speed to market and price of development are the key drivers then in short, yes. You will however be massively limited to exactly what you can deliver functionally to your user base, as you won’t be able to take advantage of any of the devices native resources.

However if you are more focused on the benefit that your customers get from your applications, then native is the only way to go.

Ed Stark
CEO
The Technical People Ltd