Why Ionic is Ideal for Enterprise


Let’s start with a couple of facts;

  1. I am – and the rest of the folk at MobileCaddy are, too – massive fans of Ionic. We’ve been using their tools and loving their work since early beta, and the incredible team there (and their community) just keep turning out more and more amazing stuff.
  2. I’ve never had training to use software, or websites. Whether for the desktop or mobile, these things are usually very straightforward to use.
  3. I’m a liar – Of course I’ve had training on apps and software – and so has everyone else I know who’s been forced to use any form of enterprise software. One company I worked for once had every employee undertake training on our new expenses software. It included a module on changing your password. For too long enterprises have forced poor software on their employees… but no more!

And what’s the point of this post? Well it’s to call-out enterprise software and to tell it that it needs to up its game. Traditionally, software given to employees to use has been given next to no time in terms of graphical design, let alone any dedicated UX focus. And don’t get me started on employee-facing mobile apps.

Perhaps the reason for this has been how tough it used to be to build good apps, maybe it’s because there wasn’t any evidence that showed the evidence of correlation between quality of the software and user adoption and productivity. It could be that there used to be a smaller mobile workforce expected to have mobile apps to assist in their everyday tasks, so maybe less investment was put in. There’s also no doubt that the pre-hybrid-app-world required larger, and more specialist, development teams… so as you can see, not everything was stacked in the favour of users getting good apps from the companies.

It’s clear though, that the number of mobile workers is growing at an incredible rate. This could be thanks to the real adoption of SaaS, perhaps due to its increased accessibility and proven stability. And with this growing workforce comes growing expectations. As I said earlier, I was trained to use internal systems at previous employers, but I’ve never had training on Amazon, Ebay, Trello, Jira, or banking apps… so why on Earth should we think it acceptable to release software to our own employees that isn’t intuitive enough, or works well enough, for them to be able to use without training? THIS STOPS HERE.


As designers, developers, CTOs, and architects, what do we need in our tool-chest to right these wrongs?

  • Outstanding Performance – If our apps don’t function well, in terms of speed and robustness, then our app isn’t performing. And if our app doesn’t perform, our users won’t use it.
  • BYOD – Users don’t want to carry around specific devices for their business tasks, would you?
  • Familiarity of UI – Sure, companies want to have full control over the branding of their apps, but that’s not the same thing as disabling the users’ muscle memory because you’ve decided to use a set of non-standard icons in your app.
  • A Standard-Based Open Stack – There’s many benefits to using standard open tools in your stack. A couple of key ones are the community support, and backing a horse that’s got a low risk of becoming neglected.

Ionic – It’s got Enterprises’ Back

Tis true, Ionic answers a whole lot of questions when it comes to turning around enterprise software.


Their recognition of performance issues in mobile apps, and the impact that it can have on users, has led to them make incredible progress in enabling apps to perform beautifully, even across older versions of both iOS and Android. You simply don’t get this in other solutions. As I said, I really like what Ionic have done, across the board, but this one thing is the real key for me. Janky apps need to die.

And their out-the-box platform continuity is entirely painless. There’s no need for users to be served up Android-looking apps on iOS devices, there’s no chance that they’ll be confronted by an unfamiliar UI that makes them stumble in their tasks.

Being based upon open web standards, the hugely popular AngularJS has many benefits too;

  • Existing web developers can pick up the code with ease, they don’t necessarily need to have any bespoke training or qualifications.
  • The development of the framework and its underlying technology is all in the open.
  • There are many developers around the world building with the tools, filing bugs and fixing issues.
    Support channels are numerous and active.

The above points not only mean that there are many already trained developers out there, but also that your application relies on a single code-base, thus removing issues not only with having two sets of skills, but also with minimising other tasks further down the chain, such as testing.

What it Means for your Business

Using Ionic as part of your stack when delivering apps can be boiled down to a couple of key points – though for me my favourite aligns absolutely with our goal at MobileCaddy – which is that it enables developers to get on with engineering functions and features that drive business value.


In the same way that MobileCaddy frees up the solution designers and developers from having to re-solve the implementation of a robust, offline process, Ionic frees them up from worrying about reinventing highly performant scrolling lists of thousands of items, or having to put effort into providing familiar UIs across different OSs.

Experience of such a solution can be read about in this interview with one of our clients. They ended up with an award-winning mobile app that blew all expectations out of the water.

And now it’s time to do your bit; start giving your employees the apps and experience they deserve and expect, and trust me, you’ll be seeing the benefits too.

London AngularJS Meetup – March Review

A very hectic few months has meant that I hadn’t been to an AngularJS meetup in quite some time, so I was looking forward to getting along again. And with the topic being AngularJS Performance – Tuning the Engine I was doubly set on making time for it.

The meetup was again held at the Bloomberg office at Moorgate, and as with the previous meetup there their food did not fail to impress – “Chicken Caesar on flatbread with a quail’s egg” canapés. As for the rest of the venue it’s perfectly suited to a large meetup. Huge thanks to them for hosting.

Tuning the Engine – Todd Motto

I’d heard of Todd before, though I wasn’t even following him on Twitter (I have rectified that now) so I wasn’t sure what to expect. Todd is a developer advocate at Telerik, who provide developer tools for desktop and mobile apps.

His talk was originally going to be called AngularJS: The Performance Parts but he’d updated it to suit the story of his presentation. At MobileCaddy performance is key, and potentially any tweak that can be made to improve a desktop JavaScript application has an even greater impact on performance when run on a mobile device.



Todd’s talk was split into two main parts, the first being some educational coverage of the Angular event loop and its $digest cycle, and the second covering some things you could do to help your app’s performance, as informed by the first part.

The slides for the talk are available here.

Angular Event Loop & $digest Cycle

First up, Todd talked us briefly through the Angular event loop (or should that be AngularJS event loop?). He showed us that it looks like the below (thanks to Todd for the image), with events from the DOM (change, click, blur etc) prompting a chain of events that results in a run (or two) of the Angular $digest cycle that generally ends up in the DOM being re-rendered with updates.



He went further into the $digest cycle next, covering $rootsScope, $scopes and $$watchers. This slowly built up a picture of how these, especially the $$watchers can impact AngularJS performance of an app. This idea, on a general scale, was one I was already familiar with, but he then mentioned something that I wasn’t aware of. When you assign a value to $scope it does not create a watcher for it, a watcher is created when interpolating a value in the view;



During the running through of the above, Todd showed us a very basic demo, and Angular uses the same techniques internally.


The second part of the talk covered a few techniques that can be used to make the most of the way Angular works, and one or two that, for me at least, seemed to appear from left field.

I don’t want to re-produce his talk here as I’d rather you use his material for that (useful links below). But I was previously unaware of a particularly interesting one, so I thought I’d cover it briefly as well as bullet-pointing some of the areas covered;

  • Reducing the $digest frequency
  • Optimising the use of ng-repeat
  • Speeding up filtering (using controller filters)
  • $digest batching
  • Production Settings

Disable Debug Info – You can remove unwanted (for production) bindings and class names by disabling the Angular Debug Info config. It’s a one liner in your config block;

I have yet to try this out myself, but I’ll update here once I have to see what impact this has. I have high hopes as the official AngularJS docs state a “significant performance boost.” Note though that doing this at build time might not be ideal as protractor and batarang (among others?) need it enabled to work.

Useful Links

Wrap Up

It was another really useful and interesting meetup, and as well as the talk itself being great I also got the chance to chat to a couple of folk I’d met at previous events: one of whom had actually seen me talk about how MobileCaddy and Ionic can be used to create offline mobile Salesforce apps – what a small world.


Big thanks should go to the event sponsors and also to Ed and Josh for organising another really good meetup, I really hope that time allows me to make the next one.