Mobile Apps and Web Solutions

Using JIMP to build an iOS icon resizer

Everytime I manually had to create some thumbnails for, or a whole set of icons for an iOS app, I thought “next time I’ll write a script to automate this”.

Finally I got around to writing the script, which only took a few minutes which should save me, er, a few minutes each year.

Once I found the excellent JIMP package - a pure JavaScript image manipulation library - it was easy to write a couple of scripts to do exactly what I wanted.

The script to generate all the image sizes required for an iOS app is available on GitHub if you want to try it out yourself.

N.B. This blog post has now moved to

Daily Optimiser now available for the iPhone

After a pretty long development “sprint”, Daily Optimiser 3.0 has finally hit the App Store.

Apart from lots of under the cover changes and UI improvements, the big news is that the app - previously iPad only - is now available for the iPhone.

The reason it took us so long to release an iPhone version is we always assumed one of the key features of the app is the ability to see both your task list and meetings in one view.

However after a few UX experiments it turns out - not for the first time - I was completely wrong! Having a quick way of switching between the 2 lists is very useful, and the visible timeline pulls together the two views in “task mode” nicely.


One thing I didn’t solve in this version is a reliable way to sync which reminders are “most important tasks” in the cloud. I tried using Apple’s CloudKit, but this proved wholly unreliable in the way I was using it. Unfortunately I had to pull the sync feature from this release, but will almost certainly revisit this topic in later releases.

We’re also trying the “patron model” of funding, where users get all features for free, but if they feel so inclined they can make a one off in-app purchase to support us. In other words, shareware :)

Be interesting how this pans out, whether the (hopefully bigger installed base we’ll get for a free app make up for lost revenue).

I’ve got another idea for an interesting app, and I’m very much looking forward to tackling some new problems for a while.

N.B. This blog post has now moved to

Problem with underscores in domain names in IE

We found an “interesting” issue at work yesterday regarding IE, cookies and domain names that I thought might be useful to share.

At FindMyPast - where I’m currently contracting - we heavily use GitHub Flow which involves multiple development branches being worked on at once.

By convention we use underscores in our branch names e.g. “dev_feature_branch”, and have recently automated hosting of feature branches for test purposes. For example for the above branch we’ll setup a host for

For a feature I was working on, everything worked great on Chrome and Firefox, but for some reason we couldn’t login properly using IE.

After much head-scratching, we fired up Fiddler which gave us the answer.

!! WARNING !!: Server hostname contains an underscore and this response sets a cookie. Internet Explorer does not permit cookies to be set on hostnames containing underscores. See

The obvious solution is not to use underscores in the domain name used for the virtual host, either by convention of stripping them out when setting everything up.

Hopefully if you see a similar issue, this may help you debug it quicker than we did!

N.B. This blog post has now moved to

watchOS 2 Complication Update Issue

Unfortunately there was a bug in v2.0.0 of Count The Days Left where the watch complication wasn’t reliably updating itself.

Fortunately the issue was interesting enough to blog about :)

What I believe was the issue - not 100% sure but it appears fixed now - is that a watchOS 2 app only has a limited budget of time where it’s allowed to update itself.

In the getNextRequestedUpdateDateWithHandler function in my complication data source class, I was telling the watch to update once an hour. This seemed a reasonable compromise (without thinking much!) where the watch would update itself once an hour automatically, even if the options for the countdown didn’t change - which forces a complication refresh.

However I believe that once an hour is too frequent. If you read the Apple Documentation closely, it says:

At the end of a scheduled update, ClockKit calls the getNextRequestedUpdateDateWithHandler: method to get the time for the next scheduled update. Specify a date as far into the future as you can manage. Do not ask the system to update your complication within minutes. Instead, provide data to last for many hours or for an entire day. If your budget is exhausted, the next scheduled update does not occur until after your budget is replenished.

Now obviously my count only updates once a day, so I can return in getNextRequestedUpdateDateWithHandler to next update itself at the start of tomorrow, which means it will only automatically update once a day (but should be correct all that day!)

It appears to have worked on my watch overnight, so I’m sending a v2.0.1 to the app store today (Wed 21 Oct 2015). The last version made it past review and into the store in about 2 hours(!), but it’s unlikely to be that quick again.

Update (2015-10-29)

Turns out it was more complicated than I thought :)

Even after the fixes above the complications still intermoittently failed to update overnight. I just think the “automatic updating” is just a bit flaky.

Anyway, I’ve much improved things by putting in an additional call to update watch complication every time the iPhone app, today widget or watch app is access. I also added a background app refresh handler in the iPhone app to call the same update method when ever it is intermittently called.

All of these calls shouldn’t be too frequent - so should have a neglible effect on battery life I hope - and guarantee as much as I can the complication is up to date.

Another version has been submitted to the app store, and hopefully this one will fix the issue.

N.B. All code can be seen on GitHub

N.B. This blog post has now moved to

Count The Days Left v2.0 Summary

All done! A final few tweaks and v2.0.0 of Count The Days Left has been submitted to the app store for review.

Things I learnt

Developing for the watch is fiddly

watchOS 2 is a pretty big change from the first version, with the extension code now running on the watch. In theory this should help the performance of watch apps - and I believe it does - but some thought needs to be put into to how you manage your data flow between the phone and the watch to optimise this.

I also struggled for a while understanding the best workflow for testing watch apps, using a combination of the Xcode simulators and the watch itself, but definitely learnt a lot along the way what works best.

Is Swift ready for prime time?

I really like Swift as a language compare to Objective-C (although now I’m used to the crazy square bracket syntax I don’t mind the latter any more), but I don’t feel as though Xcode is quite as reliable when building a Swift project compared to an Objective-C one.

Sometimes the dependency detection on what changed seemed a bit flaky, or the compiler would say a setting is missing from an Info.plist file when it was actually there (and a recompilation “fixed” the issue).

None of the problems are major, and won’t put me off starting a new project using Swift. However I’m hoping things get fixed in later versions of both Xcode and Swift.

What next?

Right now I think I’ve reached the end of features I can add to the app, at least until iOS10/watchOS3 come out and offer some new things to play with.

However I’m always open to suggestions, so drop me a line at or reach out on Twitter to @yeltzland if you have any thoughts.

v2.0 Articles

N.B. All code can be seen on GitHub

N.B. This blog post has now moved to