Before I left Germany in November 2014 for 5 weeks going to Indonesia and Thailand, I released HeapInspector, which is an iOS debug tool that monitors the memory heap in your app. You can discover memory leaks, no longer needed living objects and more issues directly on your device without ever starting Instruments. Any suggestions or proposals are very welcome. Or just start a Pull Request.

The idea for the HeapInspector was in my mind for a long time. Since ARC is alive we have less crashes or memory pressure. But you can still do a lot of things wrong (retain cycles, static pointer). I’ve seen memory design mistakes that caused crashes and strange behavior in apps. Those errors are mainly caused by a growing codebase and accompanying architecture problems. Identifying those issues  is not easy and time consuming. Apple Instruments can help to analyze the iOS app for memory issues. That is fine if you have enough time and a cable for tethered debugging with your Mac. But for real life debugging (on trains or subways) Instruments wouldn’t be the ideal solution. For some projects we added a label that displayed the current memory usage in Megabytes. This helped us to identify increasing memory and pressures while using the app in real world conditions (bad 3G and so on).
But to find the main reason (i.e. retain cycles) why the memory increased I needed to run Instruments again.
I asked myself: Is there a way to measure and snapshot the memory footprint on the device without Instruments. YES. I need to override ARC and swizzle retain, release, alloc, dealloc,…
I started digging into Clang’s ARC documentation. Also mike ash’s articles inspired me and helped me a lot to understand what goes on behind the scenes. (See links below)

Some Inspirations, Credits & Thanks

UICollectionViewCell Height Bug

UICollectionView is not the newest Apple stuff. But this bug is really annoying. First I expected it’s something wrong with my code. But after isolating the issue, it became clear, that it is a nasty UIKit bug.


This demo project on github demonstrates the UICollectionViewCell’s height bug when the dataSource (controller) returns a zero height for the 1st sections 1st row cell. The bug occurs with the following setup:

  • the UICollectionsView has 2 sections
  • The 1st section has one row
  • This row has a zero height for the cell
  • Result => the following UICollectionView cells (in bounds) are NOT visible, but the collectionView can be scrolled, looks like that the cells are hidden
  • I filed a bug report: rdar://18120029

Yes, I filed a bug report. As often: No response.

Access Control in Swift

Now since Xcode 6 Beta 4 Swift got some nice access control features we know a bit from Java. Now you can declare Classes, methods, properties, structs or enums with public, private or internal.

  • private entities are available only from within the source file where they are defined.
  • internal entities are available to the entire module that includes the definition (e.g. an app or framework target). Default behavior when no keyword is used.
  • public entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.

You can even declare the write access to private but expose the read access.
This gives us more control we knew from Objective-C with read only public properties or exposed methods in the header file.

See more and examples here at Apple’s Swift Blog

Let’s build an iOS app in Swift and own frameworks: WikiLocation

[Update July 23.] Apple added access control in Beta 4 which means that I have to adapt the new behavior (explicit exposing methods for public access) for my example frameworks. Right now I’m traveling around. This will be done later in August. [/update]
Enough theory, enough reading in Swift. Now it is time to build a real app. With this blog post I will demonstrate Swift. This is not a tutorial how to build iOS apps from scratch. I assume that you are familiar with building iOS apps in Objective C. The purpose of this article is to explain some Swift features, pitfalls and patterns with code snippets.
What is this app about? The app’s name is WikiLocation. As the name implies, it uses your current location and provides you nearby Wikipedia articles. (Buildings, lakes and so on). Straight forward. Not too much magic.
This mini app covers ViewControllers, Views & Models in Swift and custom iOS Frameworks (modules) :

Continue reading

final and lazy keywords in Swift

Mark methods,classes and variables as final to improve the performance if you know that the method won’t be overridden.

final func printMessage(message:String) {
  println("Log: "+message)


Mark your variables / properties with lazy to initialize them when you access the variable / property the first time.

class ViewController: UITableViewController {

    lazy var geoManager = GeoManager.sharedInstance
    var dataSource = WikiArticle[]()

    override func viewDidLoad() {


The geoManager will be initialized lazy. That means that the instance for the property will be created when we access the property the first time (in viewDidLoad).
“You must always declare a lazy property as a variable (with the var keyword), because its initial value may not be retrieved until after instance initialization completes. Constant properties must always have a value before initialization completes, and therefore cannot be declared as lazy.”Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/de/jEUH0.l

But: Swift lazily initializes global constants (and variables) per default.

let theSharedInstance = Singleton()
class Singleton  {

    class var sharedInstance : Singleton {
        return theSharedInstance