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

Circle Draw for Android

How well can you draw circles? Circle Draw, after having had a few thousand downloads on the App Store, is now available for free on Android via Google Play.

Things I wanted from Android

A year ago today (March 24th 2012) I published a post on my old blog about things that I wanted from Android. I thought I would do a follow up post now, a year later, to see whether or not those things did ever happen:

  • SVG support everywhere: the key advantage of using SVG for UI graphics is that you don’t have problems with pixel density on the screen. Unfortunately Android still doesn’t support the use of SVG like this, so we are stuck with PNGs for UI graphics. The ADT does now make it easier to import one high-resolution graphic and produce lower resolution versions, and 9-patch PNGs are always an option
  • Better font support: Roboto was introduced with Android 4, but Android still lags behind big time on the number of fonts
  • Higher PPI displays: At the time nothing really competed with the iPhone 4/4S, however now there are a good number of Android phones that do.
  • One Android: I had envisioned that all devices would come with one standard Android. This hasn’t happened, but the growing popularity of Nexus devices has lead to more devices using stock/Google Android
  • Google Play gift cards: these have been introduced, and sales have increased as a result 🙂
  • Better integration between Eclipse and Google Play: when you finish producing an iOS app, it only takes a couple of clicks in Xcode to send it off to Apple. With Android, you still have to produce an APK and upload it via the web interface. Obviously this isn’t much of a pain, but I like Apple’s simple system.
  • OTA updates: obviously automatic updating of the Android system is something that vendors do rather than Google (aside from Nexus devices, and their increasing dominance is a very good thing for developers) however the difference between users on the latest version of iOS and Android is still huge. Interestingly, long before the original post was written Google had announced in 2011 the ‘Android Update Alliance’ which promised timely updates by manufactures every 18 months after a device release. This never happened, and I should imagine that the reasoning is that the devices of early 2011 would have been running Android 2.x, whereas the devices released last summer would have been running Android 4.x which required much higher performance
  • A better emulator: today the emulator is much faster, especially thanks to the introduction of GPU/hardware acceleration and a new Intel (rather than ARM) image that makes the execution of apps a hell of a lot faster

Obviously Android still hasn’t met all of these requirements and I didn’t think it will meet some of these for quite some time, if ever. I’m pleased, however, to see that changes have happened and that they have worked. Here is what I would still like from Android, from a developing perspective:

  • Faster development time: This is most likely due to my lack of experience with Android development compared to iOS development, however I’ve found that I can write an iOS app much faster than I can write an Android app. Setting up the UI takes longer, linking the UI to code takes longer, the IDE is slower, the emulator* is slower, deploying the app takes longer and the export process takes longer
  • A better IDE: Eclipse has been a great IDE and it is still very usable, however IntelliJ seems to have a lot more useful features
  • Java?: I’m not sure that we need to stick with Java for Android development at all. Xaramin have done an awesome job at bringing C# to Android, and they claim that performance is just as good (if not better) than Dalvik. That’s impressive, and with a better IDE, nicer language and full API support (but high cost) it certainly is a viable option

*The iOS ’emulator’ is actually a simulator. When you test iOS apps on desktop it compiles an x86 version instead of an ARM version.

Android on the desktop

Over the past year or so there has been a great deal of speculation online over whether or not Google will bring Android to the desktop. I personally don’t think that Google will do it1. I decided that I would have a play around with the Android-x86 project last weekend to see what it is like and whether or not one could use it as a full time desktop environment. My logic was that people use tablets as their primary computer, so Android 4 should be usable as desktop OS too.

Installation and booting

I decided to try out two Android versions; Android 4 (a stable release on Android-x86, originally released by Google in December ’11) and Android 4.2 (still in development, Google released it in November ’12). I was impressed by the small download size (300MB each). I installed both of them by booting from a memory stick, and the installation for both only took a few minutes (the Android x86 guys seem to have done a good job with installation and drivers). From there on you set it up like a regular Android tablet2, logging into WiFi, setting locale and most interestingly logging into your Google account.

Applications

Both versions had full access to the Gmail app and Google Play, which I was very surprised by. Unfortunately Android-x86 doesn’t include Chrome, but the stock browser was actually quite a bit better3. I had a go at installing Chrome, but I got a message in Google Play that told me ‘this app isn’t compatible with your device’. I managed to get Google Drive on Android 4 but not on Jelly Bean.

The main problem with apps at the moment is the fact that the vast majority of apps are designed to run on ARM devices rather than Intel devices. Intel devices get round this by using a bunch of libraries (which can be installed in Android-x86 but I failed completely at doing so) to emulate ARM. This makes it very difficult to install games on Android-x86 unless you install the ARM emulation stuff. If you do get it working, you can play games like Angry Birds.

Oddly I couldn’t install apps at all in the Android 4.2 installation. This is probably because it’s using development keys because it isn’t a stable release yet, but I should imagine it was probably me doing something wrong.

Performance

It’s actually really fast. Boot times were generally sub-30 seconds on a netbook and application switching (in Jelly Bean especially) was very quick. Web browsing was comparable to using a regular Linux distro with Firefox or Chrome installed. I disliked, however, the lack of screen space visible for the web page because you have the black bar across the bottom and the notifcation bar across the top, along with action bars and any other chrome an app may have.

The general speed is probably a credit to where Android has come from; it was designed originally to run on smartphones with less than 128MB of RAM, whereas modern OSes often require at least 2GB.

General experience

Aside from a limited range of apps (or at least limited on my machine) it actually proved to be a pretty good desktop OS. I wouldn’t use it as a full time OS because I spend most of my time using a keyboard rather than a mouse, which Android-x86 is designed to be used with. Android is still a touch OS, so no usual desktop shortcuts work, which is a shame.

Another slightly odd problem I had was the lack of a shutdown option in Android 4 (since added in Jelly Bean) although you can install an app (originally designed for rooted devices) that will shutdown for you.

If you are planning on playing around with Android on your computer it is probably worth noting that Android-x86’s Android 4.0 builds are a lot more stable than the 4.2 build, which will probably be worth getting after it has come out of development.

Conclusion

In general Android-x86 is a very functional, lightweight desktop OS. It’s good if you want to browse the web, do email and read books (the Kindle app isn’t great in landscape though), but not so good if you want to code, play games or do other intensive tasks. The main disadvantage it has is that Android is a touch OS, and Android-x86 hasn’t quite made it a desktop OS. Google’s alternative offering, Chrome OS, does all of these things better and it is designed as a desktop OS rather than a tablet OS. It’s the same reason that it doesn’t make sense to have the same OS on your 27″ desktop as your 10″ tablet (*cough* Windows 8 *cough*). A real benefit is for developers because you can debug apps via VirtualBox, although the latest emulator with the Intel image is actually pretty good.

Ultimately I don’t think that Google will bring Android to the desktop because it isn’t what they are aiming Android at. I can see Chrome OS coming to mobile (because it is such a lightweight OS as it is) on the other hand so it can compete with Firefox OS.

You can use Android on your computer now, but that doesn’t mean you should.

  1. Probably worth noting the difference between an Intel version of Android and Android on the desktop. Google and Intel have both worked on porting Android to Intel smartphones, however the Android-x86 has further adapted it so that you can install it on a desktop PC.
  2. I was a little annoyed that my *computer* was referred to as a tablet throguhout the installation process. I assume Android has a string somewhere for ‘tablet’ or ‘phone’ but it would have been nice to see ‘computer’
  3. Whilst Chrome is a very good browser on mobile and desktop, stats show that the stock Android browser is actually faster

Keep Calm Pro 2

pronew01I’ve just issued an update to Keep Calm Pro for Android. The new update brings the feature set inline with the iOS version of the app and users are now able to access, edit and share all the posters that they create within the app. A major new addition is the Montserrat font which is a major change from PT Sans, which I was using previously. I’ve also improved the way that posters with background images are handled.

Get Keep Calm Pro 2 on Google Play for 99c/69p now.

pronew04

Keep Calm Pro for Android updated

This morning I released an update to Keep Calm Pro for Android and it changes quite a bit. Before I overview the new features, here are some common complaints about the previous version:

  • UI was difficult to use
  • Poster was ‘forgotten’ on device rotation
  • Poster wouldn’t always save/didn’t appear in the Gallery app for a long time
  • UI looked nasty and didn’t feel like an Android app
  • Posters saved were poor quality
  • No option to save square posters

Keep Calm Pro 1.9 has resolved all of these issues. The first major change is the appearance of the app; the image on the left shows what it used to look like and what it now looks like:

ImageThe new UI is now ‘Holo’ and has an Action Bar on all versions of Android (I’m using Action Bar Sherlock) which means it now conforms to the newer Android design schemes. This also lead to a huge reduction in the amount of code as well – and there is definitely a major performance boost because I’m using more standard techniques now.

The poster is no longer ‘forgotten’ when you rotate the device. It was a weird ‘feature’ of Android but I’ve now fixed it and it means that the UI will now properly turn.

Posters should now always save and appear in the Gallery app straight away. I’ve also optimized the saving routine as well because before it was running a Media Scanner across your entire SD card however now it will only scan across the specific file. The saved images are now high quality PNGs and appear exactly as they do in the app. A lot of Android users (the iOS version has had the feature for a couple of months) were complaining that their posters weren’t fitting on Instagram however there is now an option on the Share menu to create a square poster instead:

ImageAnother change that I’ve implemented is that the color of the icon will now change with the color of the text, which makes far more sense than staying white.

Overall Keep Calm Pro has significantly improved, and you can head over to Google Play to get the new version.

Keep Calm is a year old today

Exactly a year ago today I released the first version of Keep Calm on Android. Over the following year I’ve released an iOS version with Pro versions for both platforms. Combined, the apps have had almost 1.5m downloads.

The original version of Keep Calm was very different to the current version (and almost entirely different from the iOS version). Rather than being able to see the poster and edit it in real time the user instead had to fill in a form with the option to pick from around 25 icons before they got to see the poster. The poster generation was also incredibly slow.

I’ve got it noted down that Keep Calm had 200 downloads (I vaguely remember it being nearer 250) on its first day and I was particularly excited at the thought that somebody downloaded my app every 7 minutes, however at a peak I’ve had downloads every 7 seconds…

20130114-073725.jpg

New Android app: Logo Quiz Builder

Yesterday evening I launched Logo Quiz Builder for Android. Over the last few months hundreds (if not thousands) of Logo Quiz apps have been released on pretty much all the major app stores and they’ve proved to be reasonably successful, and addictive. However, after a little searching I soon discovered that people are limited to playing quizzes that have been made by programmers like me, and therefore can’t easily create their own without programming knowledge.

I’ve therefore put together a simple app that allows you to give your quiz a name, add icons by typing in their name (that users will have to guess) and pasting in the URL to the image before sharing a file representing the quiz with friends. I’ve aimed to give the app a minimalist design that is easy to use. Depending on success on Android, an iOS version may be released in the coming weeks/months and new features will be added to this app to make it even easier and faster to use.

Logo Quiz Builder on Google Play for 50p/99c

 

Making Keep Calm more memory efficient

Over the past couple of days I’ve been making some improvements to both Keep Calm and Keep Calm Pro to ensure that they are now significantly more memory efficient and require a lot less CPU power meaning that they can more comfortably run on older and slower devices.

The first thing that I’ve gone through and done is get rid of useless functions and variables that were just clogging up memory – this has reduced the amount of code by about half and should make the app a little faster.

A major problem that I’ve always resented with the app is that previously a bitmap was generated off screen before being displayed in an ImageView meaning that it was effectively stored and drawn twice (stored once by the main activity and drawn once by the drawing class before being stored and drawn again by the image view). I therefore decided to build a custom view which handles the drawing (along with saving, sharing and setting as wallpaper which all happen in different threads now meaning the app should run a bit faster). The custom view is a lot more lightweight and I’ve noticed fantastic performance effects in the emulator and I should imagine that it will run even better on real devices.

I’ve also updated some of the Keep Calm Pro code so that background images don’t have to be reloaded quite so often (helping to reduce memory/CPU usage). I’ve also ensured that aside from UI specific stuff both apps share as much code as possible which should make it easier for me to adjust them in the future. On a side note I’ve also halved the number of lines of code on both apps.

Both apps have had their default background changed as well – before it was a red gradient however I have now changed this to a simple grey for three reasons:

  • It’s going to look a lot better on Keep Calm 3.x*
  • Drawing the UI is a little faster
  • It means that hopefully people will pick better background colors for their posters – I’ve noticed that with the red gradient I tended to pick quite nasty colors whereas now with the grey the UI becomes less distracting so hopefully people will be able to better judge the color they want

Another minor adjustment I’ve made is exporting to PNG rather than JPEG which means that the images are of better quality when shared via the web.

Here’s a quick summary of all the improvements that I’ve made and how they affect the user experience:

  • Less memory in use means that the app can more comfortably run (and other apps can run faster when Keep Calm isn’t in use)
  • Less CPU power required for drawing
  • Reduction in amount of UI drawing done by half
  • Smaller executable
  • Simpler UI that will look better in current and future versions of the apps
  • Export to PNG rather JPEG to ensure higher quality posters are produced

*I’m currently planning what will be Keep Calm 3.x and Keep Calm Pro 2.x. I’m not sure if I’ll ever release them but they will be pretty cool if I do.