Working in different languages on iOS

The standard language for developing iOS apps is Objective-C and it is what the vast majority of tutorials and sample code for the platform are written in, however over the last year I’ve seen several languages become increasingly dominant on the iOS platform. In this post I’ve tried to review and list as many of the languages as possible. I’ve ignored C/C++ from his post because they are within the Cocoa Touch tool chain already. I’ve also ignored JavaScript and other web technologies because so many platforms and frameworks already exist for them – I’m more interested in compiled platforms.

  • 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
  • You are potentially going to be making huge performance sacrifices. In cases when you have an interpreted language like Python or JavaScript this will be an obvious issue but even the performance of C# is radically different on mobile devices to native code. The most simple reason for this is Garbage Collection. Objective-C isn’t GC (the feature was deprecated several years and has never been available on the iPhone) however it uses Automatic Reference Counting instead to manage memory. In some ways this is far more sensible because the “Garbage Collection” effectively happens once at compile time, saving CPU cycles later but on the other hand it may confuse programmers coming from other languages – but this has always been a “feature” of Objective-C :).
Advertisements

Keep Calm 2.1 available on the App Store

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.

Lessons from iOS development #4: Let’s forget this part 2

A few weeks ago I blogged about tactics you can use to reduce memory usage in your iOS app however I came across a neat class that can make your life a lot easier.

NSCache is a very simple class that is little more than an NSMutableDictionary except that it will automatically clear objects when memory usage becomes high or they haven’t been used recently. For an app heavy on file/network IO this is perfect.

Keep Calm’s main view is a grid of images. Usually these are loaded from a thumbnail that is automatically generated in the background every time the user updates their poster. This works fine, however it can take up to 10ms to load a picture, so when scrolling (especially on iPad where up to four pictures are presented in one row) to a new row there is a slight jitter even though the images are loaded asynchronously.

So then I added an NSCache to store all the thumbnails and suddenly scrolling became completely smooth because the thumbnails were only loaded when they needed to be (if it all, one would expect that a tablet with 1GB of RAM could handle ~30 images happily). Another benefit of NSCache is that you can limit the total ‘cost’ of all the items (the cost of an item is a relative number you can dictate).

Obviously it can be used for things other than just images, but if you are working on any kind of app that presents images in a grid you can save yourself a lot of time by using NSCache.