Objective C tips for Performance based iOS applications!

Most of the apps we’ve been working on in iOS test the limits of iPAD/iPAD Air devices in terms of memory and performance. The strain some of these apps can put on the processor is enormous and over the years we’ve come up with our own set of best practices based on mistakes made and issues resolved!

This series of blogs read together with our blog on Quick pointers for architecting Real Time Apps for Mobiles! should make a good read for anyone working on creating high performance demanding iOS apps

Be gentle with SQLite if you are dealing with a LOT of data!

1. Don’t use Concurrent queues with SQLLite:- If you are using SQLlite then you are probably using FMDB ( and FMDBQueue) to access the database. The general recommendation when using SQLLite is to funnel all DB accesses into a Serial Queue . SQLite is essentially best( read safe) used in a single threaded fashion. One common mistake that is made is using a concurrent queue to dispatch write commands to the DB. This should be avoided at all costs as this will freeze the database completely.

2. If your database is going to grow big, read up on indexes. Don’t create duplicate Indexes in SQLLite! It will impede performance. If you’ve put up a unique constraint then you already have an index on that column and don’t need to create another index on it!

3. When creating DB Blocks to execute queries do absolutely minimal work inside the block. Remember that a serial queue is used to execute the blocks and the blocks themselves are blocking! Whenever possible get the query result out of the block and then unarchive it.

NSCache will release contents on backgrounding!

4. One very useful and thread-safe collection container is NSCache. However keep in mind that NSCache releases all its contents when app goes into background state forcing you to recreate all the contents when you foreground again. This can get expensive!


5. Avoid using NSLog. There are no Logging levels with NSLog and since you don’t want your detailed debug statements in prod code you will end up having to remove them all before going live. Also NSLog is pretty slow and extensive logging impacts performance. We used CocoalumberJack for our app and it worked pretty well for us https://github.com/CocoaLumberjack/CocoaLumberjack

We have some more tips on Notifications, GCD and Auto-release in  part 2 of this series! So Read on and don’t forget to add a comment if you agree/disagree or have something to share for this topic!

Team Cennest!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>