To Localise An App Or To Improve It With More Content?

I’m at a crossroads with my app Quiz&Learn Python. The sales and downloads have been less than stellar, and it’s time to make some decisions. Options are to localize the app or to create more educational content. My choice at this point is to create more content. Read the full post to know why.

Read More

Should You Minify Resources in Cordova/PhoneGap Apps?

In an earlier post, I researched the load times of Cordova when using jQuery and jQuery Mobile. Now, I want to dig deeper on how you should load your files in a Cordova application. This time I’m focusing on whether you should minify your JavaScript and CSS resources. I mean the local files which are not loaded over a network. I think the general belief is that there is no need to minify the files as they are loaded fast from the local filesystem. However, a smaller file will still probably be loaded and parsed faster, but the question is: how much faster?

Read More

Effect of jQuery and jQuery Mobile on PhoneGap/Cordova Startup Speed

App load time can have a significant effect on how users perceive your app (see these articles). While load time of Cordova apps is a complex thing made up of multiple steps, one (possibly big) part of it is loading all the JavaScript and CSS resources on the initial HTML page.

An often used framework for mobile apps is jQuery Mobile. Just look at the "related tags" statistics on Cordova questions on StackOverflow. Such libraries are useful for beginners. Lately, though, I have been trying to write plain JavaScript without libraries. To validate the performance gains from this approach, I wanted to see how much using jQuery and jQuery Mobile affect the load time of an app.


I originally measured with four devices: iPhone 3GS, iPhone 4S, iPad 2, and 3rd generation iPad. While I procrastinated writing this post, new devices were released (and bought). So I made additional measurements on iPhone 5S and retina iPad Mini as well.

In all measurements, I used Cordova 3.0 (although 3.1 3.2 3.3 is already released). I had the console plugin installed, but no other plugins. The template I used was a stripped down version of the default project template (see this gist for the complete HTML I used). I had three versions:

  • without any JavaScript libraries, only loading cordova.js
  • with cordova.js and jQuery 2.0.3
  • with cordova.js, jQuery 1.9.1, and jQuery Mobile 1.3.2 (including CSS and JavaScript)

The versions of jQuery and jQuery Mobile are the latest versions at the time of making the first measurements.

I measured the time between a script element in the beginning of head and the deviceready event to fire (as you can see from the template). With each device, I measured every version 10 times to get more reliable data.


The results are summarised in the figure below. The raw data is also available.


The results show no real difference between iOS 5 and 7 on iPad 2 and between iOS 6 and 7 on 3rd generation iPad. Neither is there much difference between those two devices. iPhone performance has clearly improved in newer devices. The same is true for iPad Mini. Nothing surprising in that, though.

What is notable is that jQuery Mobile does affect the start-up time of the application quite significantly. In most devices, it takes around 0.5s for the deviceready event to trigger. And over 0.4s even on the latest iPhone, not to mention the over a second on 3GS.

Take Aways

So what can we learn from the results? I’d say that if you target older versions of iOS which run on 3GS (or, perhaps iPad 1), you should think long and hard before you adopt a large library like jQuery Mobile. If you still device to go with jQuery Mobile (or similar libraries), the load speed of the app could (and should) be improved by loading the libraries after deviceready. Also, I used the complete library, and you should definitely build your custom version with only the needed components.

Another alternative is to use more lightweight frameworks such as Zepto + Topcoat. The fastest approach, performance wise, is writing JavaScript and CSS without libraries. If you are not comfortable with that, now might be a good time to learn.

All in all, just keep in mind that half a second can feel like a long time and can have an effect on your app ratings and business performance. On the other hand, if you do a lot of other processing on startup, the JavaScript loading times might not be a significant factor in app startup.


As with most questions in software development, my suggestion whether or not to use libraries in Cordova apps is “it depends”. It is a balance between app load performance and developer productivity. Just keep in mind that the libraries you use can have a big impact on load times. Personally, while I do have an app in the app store (published by my previous company) that uses jQuery Mobile, I would not use it in a new project.

What do you think? Do you use libraries in your Cordova apps?

Update: If you read this far, you might also want to check out the post about whether you should minify your resources in a Cordova/PhoneGap app.

PhoneGap Files, Filepaths, Backups, and a Nasty Bug

I recently updated my main phone to iOS7. To my surprise, images within my The Fisher app no longer appeared. All the stored data was there but instead of the images I only got a white screen.

My first hope was that this was due to my app not being the version downloaded from the App Store and the restoring from backup not working for non-App Store. But I had to test it with my backup phone which I can easily erase and restore from backups. After testing, I was in a bit of a panic mode since the images really were not restored from the backups. To put it mildly, in an app with user-generated content, losing that content is not good.

Inspecting the contents of the app bundle with iExplorer (which I highly recommend), I found out that the files were there but they were not shown in the UI. Comparing the catches from the backup with newly added catches, I noticed that the file paths were different.

PhoneGap Files and Filepaths

On iOS (and when working with PhoneGap), files have a path like this:


In my app, I was saving these absolute paths to the database. And apparently you should never do that! As the Apple File System Programming Guide says, file paths consist of application home directory and the location of the file within the apps sandbox. The thing is, the application home directory can change at least when restoring from backups.

Fixing is Easy

Fixing the problem is easy. Instead of storing the absolute path of the file, you should only store the part of the file that you specify. In my app, the file names are based on the time they were created, so they are all of the form 1377869303030.jpg (or, [0-9]+\.jpg). Thus, whenever wanting to access the file, I can simply replace the beginning of the stored file path with the correct path to the application persistent file directory. To get this directory path, I have the following code executed on deviceready event.

function setFsRoot(callback) {
  function fail() {
    // handle the error

  function gotFS(fileSystem) {
    // save the file system for later access
    window.FS_ROOT = fileSystem.root.fullPath;

A file path is then window.FS_ROOT + fileName. Changing all file access to work like this I was able to fix the issue with relatively little changes. If you are storing absolute paths, you should make this fix now, before everyone upgrades to iOS7.


Accessing files is critical in my app, so I really should have done a better job in testing backup restores. However, I do think that the Apple documentation as well as PhoneGap API docs should mention this potential pitfall.

Now my problem is fixed and an updated version 1.1.1 is already available in the App Store. Hopefully, no major harm was done to my users. I was also lucky that file removals used the same file path, so the user was not able to remove the catches before I updated the app.

App Transfers in Apple App Store

Last night I (like all iOS developers) got the email below from Apple. The gist of the mail is that developers can now transfer approved apps to other accounts. Previously this has been impossible to do. This has many benefits and use cases for developers:

  • If you sell an app, you can transfer it to the buyer instead of having to handle updates for them. Likewise, if you buy an app, you get full control to it in iTunesConnect under your own account.
  • If you outsource app development, the final deliverable can be an App Store accepted app transfered to your account without having to give your credentials to the developer or managing the App Store submission yourself.  Similarly if you develop apps for others.
  • If you develop apps on your personal account (like I currently do), you can start a company once things grow, without having to distribute the apps forever under your personal account. 

App transfers are also likely to boost the business of app marketplaces such as Apptopia .