Why is my mobile app slow???


I have been part of many hybrid verses native mobile app performance discussions over the last 6 months. In my experience as being a developer of native mobile apps (iOS/Android & WP) in the past and lately in the hybrid space (Cordova with Kendo or Ionic) I’m slowly learning that the client side implementation doesn’t have a lot to do with performance of a mobile app in the ‘grand scheme of things’. What can affect performance of either platform, and in my option matters more than your client side technology, are your services.

high-speed-internetIn my experience the easiest and usually the most important performance gain you can make is optimizing your services and your client to talk to those services. If your used to developing web sites, internal/corporate apps and the like chances are you’ve never thought of API calls as expensive, “Dude I’m using WebAPI and JSON, I’m set”.

Below we are going to talk about your mobile app to your mobile services. Lets assume that your mobile services and everything behind them are well tuned and performant.

Below are some key points I’ve noticed when mobile apps talk to remote services.

Data Size

1 ANSI character = 8 bits, a 3G connection transfers of at least 200 kbit/s which means to transfer 1 ANSI character takes just under 1/2 a millisecond, not including TCP/Network overhead, latency, etc. It doesn’t sound like much, 1/2 a millisecond really, but it adds up. How much data are you sending over the wire, when you don’t need to? When looking at some of our JSON payloads we found that that in the worst case scenarios we could be adding 1/2 a second in data that didn’t need to be on the wire.

Take a look at this data model, pretty standard in the .Net space. ActionTypes and UserStateTypes are simple Integer enumerations.

public class PersonnelStatusResult
    public string UserId { get; set; }
    public string Name { get; set; }
    public ActionTypes ActionType { get; set; }
    public DateTime ActionTimestamp { get; set; }
    public string DestinationId { get; set; }
    public string DestinationName { get; set; }
    public UserStateTypes StateType { get; set; }
    public DateTime StateTimestamp { get; set; }

So how does this look on the wire:

"UserId": "f3a48991-3e5e-4f4c-ab3d-5e7a43a428e3",
"Name": "Shawn Jackson",
"ActionType": "StandingBy",
"ActionTimestamp": "2014-11-26T14:46:16.517",
"DestinationId": null,
"DestinationName": null,
"StateType": "Unavailable",
"StateTimestamp": "2014-12-01T12:24:52.047"

As you can see the JSON serializer used the String values of our enumeration, this instead of transmitting integer values we have long strings. Also for this request I’m sending back the users name, this is something that will rarely change, and probably shouldn’t be send with every request. Also although the names for the parameters are nice it cost of 4 milliseconds of 3G wire time to transmit them.

I’ve recoded the service to send less data on every request. Destination Names (which rarely change) along with users name’s are now loaded up and cached locally on the device.

public class PersonnelStatusResult
     public string Uid { get; set; }
     public int Atp { get; set; }
     public DateTime Atm { get; set; }
     public string Did { get; set; }
     public int Ste { get; set; }
     public DateTime Stm { get; set; }

Now lets see what the new data looks like over the wire.


Much more concise and very little wasted data. The delta between the first request and the 2nd one over a 3G connection is 5 milliseconds. The above data is in a list, with 100 items in the list I’ve saved 1/2 a second in unneeded transmission time.

The serialization mechanism used is also very important. You should not be using something verbose like XML/SOAP to communicate with your apps, instead utilize JSON or Protobuf. For any serialization mechanism you need to think about the serialization/deserialization speed but you still need to think about the syntax of it on the wire.

Data Types

As seen in the example above I’m using Guid’s for user’s id value. Each Guid will cost me almost 2 milliseconds of 3G network time. Although I cannot change that data type now, I need to ensure that all data that goes across the wire is as compact as possible, i.e. utilizing Integers for Id’s instead of Guids.


Never assume your users are on a great WiFi connection, LTE or 4G. There are A LOT of 3G connections out there and congestion in populated areas could easily kill your data transfer speeds of better networks. Just because your lucky enough to be on a 4G network doesn’t mean it’s fast, you need to think about latency, see the table below.

Generation | Data rate      | Latency
2G         | 100–400 Kbit/s | 300–1000 ms
3G         | 0.5–5 Mbit/s   | 100–500 ms
4G         | 1–50 Mbit/s    | < 100 ms

Even on a 4G network your latency could be 1/10’th of a second. This is without any other issues like, retries timeouts, dropped packets, etc.


TCP overhead matters. Every time you make a data call from your mobile app to an external service that goes out over the wire. Your TCP header is normally 20 Bytes but can be up to 60 depending on what options are being set. Then your IPv4 header is another 20 Bytes. That means for every connection you have 40Bytes of overhead occurring in the best case scenario. That means that 2 milliseconds are spent with every call over a 3G connection with TCP/IP overhead.


So below I have the following tips for service performance for mobile apps.

  1. Plan for the worst case but realistic network connection scenario. In the areas that my app works you can see Edge connections which are typically limited to 135 kbit/s. If you plan for the worst your app will perform just fine at better connections and speeds more typically seen.
  2. Don’t assume you’re going to be fast just because your on a 4G/LTE connection. If your doing connection based logic just determining the connection type isn’t enough. Latency, cell strength, congestion, etc can make a 4G or LTE connection just as slow as a 3G one.
  3. DRY (Don’t Repeat Yourself) and Cache your data on the device. Keep list calls and redundant data to a minimum.
  4. If you haven’t changed it in the last 3 months, chances are you wont! Don’t store configuration data on the server only to serve it up to the device every time. Keep it on the device or cache it.
  5. Don’t transmit or contact the server unless you have to. Every time you ‘leave process’ it’s a slow operation. Don’t do it unless you have it.
  6. For lists, utilize 1 call to bring back all the list data, then use that data to populate detail views. Unless the detail data is grossly larger then the data for the list it’s worth it to not make a detail view call.

So if you currently have a slow mobile app take a look at your services first and ensure they are as performant as possible before you go re-writing your app.

Moving from Kendo to the Ionic Framework


Over the last few months I’ve been taking a very hard and long look at AngularJS and trying to utilize it for my JavaScript code. I was first introduced to Angular by my partner Jason Jarrett who is always on the cutting edge. At first it was extremely daunting, almost impenetrable, and I blew it off, but the seed was planted. As I worked more and more in JavaScript it realized what power a framework like Angular brings, in organization, tooling and composition.

ionic-html5-native-framework1At Resgrid our apps are built utilizing AppBuilder and Kendo Core from Telerik. Kendo does support Angular, but from reading about it and looking at the code I feel that Angular support was just bolted on to check a box and Kendo was not rewritten to be a first class citizen in the Angular universe. So after some research we decided that Ionic was our way to go.

Why use Ionic?

  1. First class Angular support. Ionic was designed from the ground up to utilize Angular and that makes the experience consistent.
  2. Speed. While Kendo is no slouch, from initial tests Ionic performs better on older Android versions. Transitions are less janky and scrolling if feels more fluid.
  3. Consistent look and feel. Ionic does some platform specific things (how transitions are utilized, alignment, etc) but they leave the rest open to you by utilizing SASS. So you can customize your look and feel per platform utilizing platform specific SCSS if you want.

Why use Kendo?

  1. Native platform look and feel. Kendo does a great job at changing the UI to look like a native app for iOS6, iOS7+, Android, WP8 and Blackberry. If you need that native look and feel Kendo can’t be beat.
  2. Advanced/complex controls and interactions models.
  3. Great support from Telerik.

So why not Xamarin?

Xamarin seems to be the buzzword de’jure in the mobile space lately, especially if you’re a .Net developer. At this point we’ve scratched Xamarin for a number of reasons:

  1. Standard Xamarin is not cross platform all the way down the stack, you still have to write native UI’s but your backend logic is all C#. Xamarin Forms is the solution to this but it’s still very nascent, doesn’t support all the platforms yet and constantly has breaking changes.
  2. No re-use. Our current app is hybrid utilizing JS/CSS/HTML. Not all the code we have is ‘bad’ and can be migrated.
  3. No good theming/styling story. Xamarin Forms still doesn’t have a good global Theming or styling story yet, unlike Ionic where we can utilize SASS.

At the same time we are versioning our back end services (v3) to match with new integration models. More on this in another post. So how are we proceeding:

  1. We are utilizing Telerik’s AppBuilder CLI, Sublime Text 3, Angular 1.2 and Ionic beta 13
  2. We will port our app over to Ionic and make it feature complete with the current version
  3. Then we will migrate to TypeScript, beta 14 of Ionic (or nightly/edge builds) and Angular 1.3
  4. We will layer in automation with grunt (auto generating TypeScript defs for API objects, unit testing, etc)

So why not go straight to TS, Angular 1.3, Ionic nightly, automation, etc? Well in creating a whole new app it’s silly to try and shoot for perfection straight out of the gate, especially when it’s with a new technology or implementations. We want to quickly get a good app into the hands of our customers and not worry about or waste time with technical minutiae that they don’t care about. At the same time we want to learn, grow and experiment.

Resgrid is a SaaS product deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).

From Visual Studio & AppBuilder to Sublime Text 3


I’m a die hard Visual Studio guy, it’s been my primary IDE since I started as a full time software developer. I’ve played with other IDE’s of course, Eclipse for Java and Android development, XCode for iOS/Objective-C Dev. My favorite non-VS IDE’s are usually from JetBrains so IntelliJIDEA, RubyMine and WebStorm. But I’ve always used an IDE of some sort. When I was at DevIntersection’s in Las Vegas I only had my Macbook Pro laptop, I could have used Fusion or Parallels to continue development but recently Telerik Announced a node command line interface and a Sublime package of their AppBuilder platform.


We all know ‘those’ developers, the ones that use command line for everything, can program something in Notepad and look down at us IDE users like were addicts. Look at the mouse as some kind of torture device and have command line shortcuts for every conceivable function, yea ‘them’. I’ve always looked at that as elitism but now I was going to try living in their world, if only for just a week.

So my mission, regardless if I wanted to or not, was to use Sublime Text 3 for an entire week for my mobile AppBuilder development. My setup was Sublime Text 3 with Package Control, AppBuilder and GitGutter packages installed. On the machine itself I have NPM and AppBuilder-CLI. I wanted to take a peek at OmniSharp but seeming I was only doing hybrid mobile development I didn’t get it setup.

So after a week how do I feel about it? Will I turn into an elitist jerk? Short answer no, long answer, maybe. After a week using pretty much stock Sublime Text 3 and AppBuilder CLI I can say I totally get it. My experience is that Sublime Text 3 is half text editor and half IDE, a lot of IDE style things (like the project view (file list on the left), IntelliSense, syntax highlighting I feel fall more into IDE components then a text editor

What I don’t like about Visual Studio, and I think is symptomatic of all larger IDE’s, is bloat and speed. They are rather clunky at times and contain every option under the sun. What I found was that just using Sublime Text I was quicker, the editor was quicker to respond, there were no issues with it jamming or getting stuck and I wasn’t overloaded by ‘ohh shiny’.

I was extremely productive in Sublime Text 3 working on the new Ionic Framework port of the Resgrid Responder app. Resgrid which is a SaaS product deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade). Our Responder app is geared toward first responders and intended to be used on the go as they respond to incidents.

The overall experience was quite freeing and it makes me question how many extensions and addons I need in Visual Studio. Although I won’t be replacing Visual Studio with Sublime anytime soon I may replace AppBuilder’s Windows IDE with Sublime. I can’t afford their Visual Studio extension for AppBuilder so I use the win client and although it works pretty good the editor is quite a drag and sometimes completely messes up. When I work in Sublime I have no such issues and the AppBuilder-CLI works great and their Sublime package is getting there functionality wise.

Go to Top