I launched Cake Day a couple of weeks ago, but chose not to mention it too much because I’m waiting on Apple approving the iOS 7 update (it will be out within a few days). The premise of the app is pretty simple: you get a reminder once a year on your reddit cake day and you can manage multiple accounts within the app – so you can add your friends’ usernames too and get reminders for their cake days. It also shows you a nice picture of some cake :).
You can get Cake Day on the App Store for free now.
Disappointed with the default Apple clock app I decided that it was high time to create a simple, easy to use app that allows you to run and save multiple timers at once.
Multi Timer makes it really easy to save timers for tasks you do regularly and allows you to run multiple instances of the same timer at once. Even if you haven’t got the app open, Multi Timer will notify you when a timer has finished. Multi Timer is especially useful in scenarios such as cooking where you might want to time individual components separately.
Once again I have used FMDB and FlatUIKit to create this app (I’m also using Crashlytics for the first time). I had considered using UI7Kit for the UI, and given that the app is so simple I probably could have done however I really like the look of FlatUIKit (especially the buttons and color schemes) and I think it provides a bit more back compatibility with previous versions of iOS. If, however, you run the app on iOS 7 it will default to normal UINavigationBars and UITabBars in order to avoid some rendering issues on iOS 7 with FlatUIKit.
When you create a timer you can optionally assign it one of 12 icons (I’m planning extra/custom icons for a future release). My normal workflow for this would have been to create the icons in Inkscape and render them to PNGs. PNGs for icons tend to be pretty small – especially when compressed with ImageOptim – however instead I created all of the icons in Opacity (which proved to be a lot nicer to use on OSX than Inkscape) and then export Quartz rendering code for the icons instead. The code isn’t super well optimised, however it kept the size of the app incredibly small (~1MB) and allows for completely resolution independent icons.
You can get Multi Timer now on iOS for $0.99/£0.69.
If you’ve tried to buy the 1000 icons upgrade in the latest version of Keep Calm on your iPhone you will find that you won’t be able to. If you’ve got an iPad you can buy it on there and then restore the purchase on your phone in order to active it.
TL;DR: I’m incapable of remembering to link up IBActions from both storyboards.
I first released When You’ve Got Swag on Android a few months ago and to my surprise it actually ended up getting around 30,000 downloads. Over the weekend I decided that I wanted to play around with FMDB so I decided to put together a simple iOS app, and it struck me as a good time to bring the wildly ridiculous ‘swag’ images commonly found on Instagram and Tumblr over to iOS.
After having written the model code (which really is pretty simple) FMDB proved to be really awesome and I see it as reasonably likely that I will use it as an alternative to Core Data in all my apps – it was really easy to get started with, I didn’t have to write 100 lines of boilerplate code and I don’t have to worry about issues between threads as much as I did with Core Data – when I wrote Keep Calm I actually ended up with a whole extra model layer on top of Core Data to handle rendering on a separate thread (I now know that this could be easily rewritten).
The UI was all created with FlatUIKit (well not quite all, I had to use a tiny bit of UIAppearance) which proved to be just as awesome and I plan on using FlatUIKit+FMDB a lot in the future :).
To customise which words are highlighted you enter the text in block capitals (case doesn’t matter, all of the pictures are rendered with capital text anyway). I had originally planned to try and detect #hashtags, @usernames and URLs however I realised that just detecting punctuation next to capital letters would be a lot easier and more customisable. The text rendering is done using a regular expression to find characters and then an attributed string rendered with Core Text for the highlighting. I intend to add text sizing in a future release along with iPad support (the app is so simple and because it was originally written as a test app I don’t really see the need for this).
When You’ve Got Swag on the App Store (free)
Previously if you wanted to parse HTML on iOS/OSX using Objective-C you had to use an XML parser however I have now written an Objective-C wrapper around Gumbo, Google’s new C HTML5 parsing library, so that it is really easy to get parse HTML with minimum hassle.
To get started you will firstly need to download the Gumbo source code from their GitHub repo and follow their getting started instructions.
Once you have a working local copy of Gumbo (you can validate this by running one of the samples) you should download the source code forObjectiveGumbo from GitHub. To add ObjectiveGumbo to your Xcode projects do the following:
- Add the ObjectiveGumbo folder from the repository – this contains the source code for the framework, which is basically just a few classes
- Add the src folder from the Gumbo repo (only the .c and .h files)
- Ensure that Xcode is set to compile all .c and .m files (Xcode 5 doesn’t do this by default when adding files to a project
- Validate that the project builds correctly
- Import “ObjectiveGumbo.h” when you want to use it in your app
Usage for ObjectiveGumbo is pretty simple. You can either parse a whole document – which will gain you access to the DOCTYPE information – or just the root element (i.e. the body). These can be loaded from an instance of NSData, NSURL or NSString.
Simple example fetching the current top stories on Hacker News:
OGNode * data = [ObjectiveGumbo parseDocumentWithUrl:[NSURL URLWithString:@"http://news.ycombinator.com"]];
NSArray * tableRows = [data elementsWithClass:@"title"];
for (OGElement * tableRow in tableRows)
if (tableRow.children.count > 1)
OGElement * link = tableRow.children;
More detail is explained in the README and there is also a more developed Hacker News example (iOS) and simple Markdown to HTML parser (OSX – not complete) in the GitHub repo.
Last week I published Keep 2.2 however there were a couple of odd bugs with in-app purchases that have now been resolved. I had the bug fixed on Sunday, however I was unfortunately unable to get an expedited review because of the extended Apple Developer site outage so the update wasn’t approved until today.
The latest version of Keep Calm has introduced a bug when attempting to restore previously purchased items in the store. Currently the code that restores the purchase my side is not being run (due to a really stupid faulty if statement) however if you have already purchased an item you can press the ‘Buy’ button again and it will automatically acknowledge that you have already purchased an item with no need to buy it again.
I’ve just finished a fix for this bug which I intend to send to Apple shortly, so hopefully the bug will be resolved within the next few days.
Today I updated Keep Calm to version 2.2. This new version adds the following new features:
- Completely new flat UI – this is an iOS 7 style UI as I haven’t decided yet whether I will require iOS 7 when it comes out
- The new UI makes it a lot faster to make posters – on average fewer taps are require to make a poster and it is now a lot clearer how one carries out basic tasks
- The app is faster – for those interested, I took out redundant Core Data and Core Graphics calls
- When you first launch the app you are welcomed with a new welcome screen. I’m particularly pleased with these because it provides quite a nice way of demoing some of the Pro features. Again, for those interested I use a UIScrollView and a single UIImageView that gets translated by the scroll offset
- Runs much better on the iPhone 5 – I had spent a lot of time focussing on designing the regular iPhone version (because posters seem less stretched) rather than the full iPhone 5 screen which meant that there were a few buttons that weren’t showing up in the right places. This version is a lot more solid
- Less code – this isn’t really a feature that my users need to care about, but I swear to god it makes my life a lot easier. By reducing the total number of delegates in the app (almost every single view controller – and some views/models too – declared a protocol) and making each view controller focused on the purpose of the app rather than being generic meant that I could write a lot less code. I also removed a lot of UIActionSheets because a) I don’t think they look very pretty and b) I really don’t like declaring them and writing UIActionSheetDelegate methods 😦
On the whole, users should find this update far more enjoyable and easy to use than previously as they upgrade over the course of the weekend.
- C# is a great language and it is rapidly becoming more popular across many platforms. All C# outside of Microsoft is based off of the Mono project and there are two commercial bindings for iOS. Xamarin allows you to write C# code that integrates with every single Cocoa Touch API (and they have day one updates for each new iOS version, although you can also join their beta programme to get new features at the same time as Apple’s betas, I believe). Unfortunately the free license limits the compiled size of your app but in my experience this isn’t too much of an issue. Being able to write C# proves to be a huge advantage however I’ve found that deploying to device can be quite slow, and the start up time for apps is often a few seconds slower (it is managed rather than native code) and that some patterns from Objective-C such as protocols/delegates don’t transfer over to C# as well – you have to create a subclass of UITableViewDataSource, for example, rather than a class that accepts UITableViewDataSource as a protocol. Alternatively, if you want to write games and don’t care about UIKit, Unity is a great tool that allows you to write your game in C# and deploy across several platforms. I’ve found, again, that the disadvantage of managed code does mean that Unity games tend to be a tiny bit slower than their Objective-C equivalents.
- Despite Apple’s allegiance to the language in the early OSX days, Java is not a viable option for iOS development however a few bindings do exist. Codename One converts Java Bytecode to native code across several platforms (iOS, Android and Windows Phone) with a native UI. Their site is unclear whether or not they are actually binding to UIKit or if they are creating a native style UI. Alternatively, Google’s J2ObjC converts Java code to Objective-C. This project is very appropriate if you need to use Java for model code rather than UI code and it seems like a sensible choice if you have business logic you need to run on iOS.
- I had initially expected that there would be very few options for running Python on iOS due to earlier limitations on interpreted languages however evidently the popularity of the language has lead to several options emerging. The first option, PyObjC provides bridging between Objective-C and Python and allows you to write apps that link with UIKit in Python but, like with C#, the differences between the two languages mean that the Python code feels a little clunky. Another option is PyMob, however I can’t find a public version of it to play around with. Finally, Kivy presents itself as a far more viable option for writing iOS games in Python; it makes no attempt to bind with UIKit which brings the benefit that it cross-platform with support for iOS, Android, OSX, Windows and even the Raspberry Pi! I’ve recently enjoyed Pythonista, which is an iOS app that allows you to write Python on your iPad or iPhone. I’ve been using it for about a month and I’ve really enjoyed it – the price tag is definitely worth it.
- I’ve never really played around with Ruby for a particularly large amount of time but it has always struck me as the interpreted equivalent of Objective-C, which brings the benefit that the syntax doesn’t feel broken when attempting to bind to Objective-C – the MVC style, as well as protocols/delegates is adopted by both languages. RubyMotion links directly with Cocoa/Cocoa Touch and compiles to native code. Unfortunately the license is $200, however compared to the other languages I’ve mentioned here that definitely seems worth it.
- If you have experience with Flash you would have been initially disappointed by the decision that Flash wouldn’t be available on the iPhone, however thanks to Adobe’s Flash platform with Flex it is now possible to deploy Flash apps to the App Store. This doesn’t strike me as a very good option, however, because there is absolutely no effort to work with the standard iOS frameworks – the aim seems to be to make it possible to deploy your Flash game onto iOS. Furthermore, you lose a lot in performance because the Flash runtime seems to be addicted to battery power, using nearly 100% CPU and every spare bit of RAM – these are some of the reasons, aside from lack of demand – that Flash was removed from Play Store on Android.
When writing this blog post I came across a very common pattern. Often a language will have several bindings available for it, however none of them will be able to maintain the feel of the language (Ruby was the only one that isn’t entirely true of this) because they have to adopt Objective-C idioms which they may not employ themselves. The two best examples of this are protocols/delegates and the way Objective-C functions are named compared to how they are in all other languages. Ultimately, I’ve come to the conclusion that it is probably easiest to build your next iOS app in Objective-C, regardless of how tempting another language may be:
- There is significantly more documentation available for Objective-C
- There are disadvantages to working in Objective-C and some things can be achieved in a lot less code in other languages, but otherwise it works perfectly well as a language. With a bit of experience, it really isn’t too challenging to write good re-usable code that runs quickly
- All the Cocoa Touch frameworks are built in Objective-C and are designed to be interacted with from Objective-C rather than another language with different idioms
Today I have released version 2.1 of Keep Calm on the App Store. This new version has the following new features:
- Pro users can now export images of any size they like (up to 4000px by 4000px) making it easier to create posters for print or the web; you could create a desktop wallpaper if you wished
- Pro users can now now also import backgrounds by pasting them from the clipboard rather than having to save them to their device first
- Pro and free users now get faster scrolling across the app (I’ve optimised all the UICollectionViews to use NSCache to reduce loading time)
- Pro users no longer see multiple menus appearing at once
- All users can delete all their posters at the press of a button to reduce space
- Cancel buttons now work in a more standardised way between the iPad and iPhone version
- The images used by the app (icons, backgrounds, etc) are now significantly smaller which has reduced the App Store size of the app by 40%
Head over to the App Store now to update to Keep Calm 2.1. I intend to appropriately update the Android versions however I’m in the process of migrating code over to Android Studio from Eclipse.