Adrien Humilière
iOS developer

Objective-C coding styles

Where Java has its Code Conventions for the Java Programming Language, Python its PEP 8 or C# its Coding Conventions, Objective-C doesn’t have any official guidelines for formatting sourcecodes. The official Coding Guidelines for Cocoa exists, but doesn’t cover code formatting or recent features of Objective-C like object literals.

However, there are guidelines that reference best practices, including about formatting that is missing in Apple’s official documentation. In this post, I will highlight topics that sounds particularly pertinents to me. It can be considered as my guidelines for Objective-C code formatting and will be formalized soon in a Github repository.

NYTimes Objective-C Style Guide

The iOS development team of The New York Times formalized its coding conventions in a Github repo. It is a great document, that covers a lot of syntax topics. I globally agree with this coding style. Here is a list of my favorite tips.

Dot-notation syntax

NYTimes suggest to always use the dot-notation syntax for accessing or mutating properties, but to use bracket notation in every other cases.

view.backgroundColor = [UIColor orangeColor];
[UIApplication sharedApplication].delegate;


Always use braces when a conditional body could be written without, to prevent errors. It also help with reading.

The ternary operator might be used only when it increase code neatness or readability. It should never been used to evaluate multiple conditions, except refactored in multiple boolean variables.

Error handling

If a method returns a NSError instance by reference, the good practice is to switch on the returned value, not on the error variable (switching on the error variable value can cause false negatives in some cases).

NSError *error;
if (![self trySomethingWithError:&error]) {
    // Handle Error


Method signatures should be formated with a space after the scope (-/+ char) and a space between each method segment.

- (void)setExampleText:(NSString *)text image:(UIImage *)image;


Variables have to be named as descriptively as possible and single letter names should be reserved to for() or while() loops.

The asterisk indicating pointers is sticker with the variable name, with a space before : NSString *aString.

Property instances should be used instead of simple instances variables. Direct instance variables access may be reserved to initializer, dealloc and setter/getter methods.

Apple naming guidelines should be followed at all time.


When needed, comments have to be used to explain why a piece of code does something. Most of the comments could be avoided by great code formatting and variable/methods naming.

init and dealloc

The dealloc method should be placed at the top of the implementation, with init just behind. init methods should be formatted as follows :

- (instancetype)init {
	self = [super init]; // or call the designated initalizer
    if (self) {
	      // Custom initialization
    return self;

instancetype is, here, prefered to id, essentially because your compiler and IDE can check your code and autocomplete better.


NSNumber, NSString, NSArray and NSDictionnary haves literal notations that has to be used when creating immutable instances of those objects.

NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingZIPCode = @10018;


Constants should be declared as static constantes instead of #define macros. #define can be used only as an explicit macro.

static NSString * const NYTAboutViewControllerCompanyName = @"The New York Times Company";

Enumerated types

Use the macro NS_ENUM()included with the SDK instead of C’s enum. It has stronger type checking and code completion.

typedef NS_ENUM(NSInteger, NYTAdRequestState) {

Private properties

Private properties should be declared in the implementation file using a class extension. Man should avoid named categories, unless when extending external classes.

@interface NYTAdvertisement ()

@property (nonatomic, strong) GADBannerView *googleAdView;
@property (nonatomic, strong) ADBannerView *iAdView;
@property (nonatomic, strong) UIWebView *adXWebView;



Images should be named as a Camel Cased string in very descriptive way. It’s name must help preserve project organization and developers sanity. It is prefixed with the name of the class where it is used (wich has to be correctly named as well). For example : RefreshBarButtonItem or RefreshBarButtonItemSelected.

Images can be grouped in folders when they are used for similar purposes.


Singleton objects should use a thread safe implementation for creating or getting their shared instances.

+ (instancetype)sharedInstance {
	static id sharedInstance = nil;

	static dispatch_once_t onceToken;
	dispatch_once(&onceToken, ^{
  	sharedInstance = [[self alloc] init];

	return sharedInstance;

Xcode projects

Each physical file should be kept in the project folder. Groups in Xcode may be reflected by folders in the file system. Source files should be grouped by types and modules for greater lisibility.

Github’s Coding conventions for Objective-C projects

Github’s documentation is less complete than the NYTimes’ one. It is considered as a subclass of Apple’s official Coding Guidelines for Cocoa. It contains some interesting points of view.


Tabs may be used instead of spaces (configure your Xcode that way). You can use as many empty lines as you want to divide code into logical chunks.

Documentation and organization

Make use of #pragma mark - to categorize methods into functional groupings and protocol implementations. A good practice could be to group methods that override methods from the same super class.


Github suggest that you should declare an ivar only if you need to change its type from its declared property. Actually, I didn’t know that it was possible, but it sounds nice. Prefer exposing an immutable type for a property, it’s a valid reason to declare an ivar for a property.

Don’t use a space between an object type and the protocol it conforms to. C functions should have no space before the opening parenthesis. It is suggested to name C functions just like Objective-C classes (with a capital letter at the beginning) but I don’t think it is a good practice.


Each long form ternary operator should be wrapped in parenthesis for readability. Il might be used only for assignments and arguments. The shirt form can avoid parenthesis.

Blah *a = (stuff == thing ? foo : bar);
Blah *b = thingThatCouldBeNil ?: defaultValue;

Separate binary operands with a single space, but unary operands with none.

void *ptr = &value + 10 * 3;
NewType a = (NewType)b;

for (int i = 0; i < 10; i++) {

Control structures

All the curvy braces should begin on the same line as their associated statement. They should end on a new line. Put a single space between the keyword and the parenthesis. No spaces between parenthesis and their content. (I particularly love this list !)

if (something == nil) {
    // do stuff
} else {
    // do other stuff

Error handling and exceptions

You should use exceptions only to preserve from programmer error, for example to force the override of a method (abstract).

NSError should be passed as reference in methods that need to indicate errors.

Google Objective-C style guide

Google’s style guide is the most complete and accomplished proposal. It is based on Apple’s Cocoa Coding Guidelinesand Google’s Open Source C++ Style Guide. In this guide too, I picked some interesting things.

Line length

The maximum line length for Objective-C should be 100 colums. You may set Xcode to display a visual limit in text editor. *Please note that it is corresponding to the size of a text window with inspectors displayed on both side and the splitter view in the center. *


You should always keep your class simple. Don’t make it a “fourre-tout” by extending the class and it’s area. Methods that don’t need to be public may not. Better use private categories to prevent cluttering the public header.

Root headers should be imported before individual files. Also keep in mind to #import Objective-C headers and #include C headers.

Memory management

When creating new temporary objects, use autorelease on the same line as the declaration rather than a separate release a few lines later in the same method.

dealloc methods should process instances in the same order as declared in the interface, for readability issues.

Project "Coding Styles"

At edjing, we are used to have great arguments about coding styles. Some of us argue for a brace at the end of the line, where others want to put it on the following line. When you want to put a full stop to this kind of discussion, you need to find a good reference documentation.

Coding styles. A reference of conventions and guidelines for writing code

Coding Styles is here for this. This website references conventions and guidelines for writing code in a variety of languages. Any kind of contribution is welcomed and anybody can submit an issue or a pull-request to add a language, a coding style reference, etc.

A propos des applications Freepod

Edit du 22/05/2014 : L’application coté serveur n’étant plus en ligne et suite à l’arrêt de Freepod, j’ai pris la décision de supprimer l’application de l’AppStore.

Quelques mots à propos des apps Freepod, sorties depuis déjà un mois. Sur le bilan de cette sortie, sur “comment on a fait le bébé” et sur les évolutions futures de l’application.

2500 applications Freepod dans la nature

En additionnant les scores de l’App Store et du Marketplace, on arrive à un score d’environ 2500 applications téléchargées depuis la sortie officielle le 4 juillet. Si la plupart ont été téléchargées les premier jours sur iOS, l’appli Windows Phone a sans doute bénéficié de sa présence dans le haut des classement puisque les plus gros scores de téléchargements ont eu lieu plus tard.

Pas mal de flyers ont été distribués pendant Comic Con pour faire la promo des applications. Il en reste encore quelques centaines/milliers à distribuer (si vous en voulez pour aider à la com, n’hésitez pas à demander !).

Merci également à tous pour vos retours et votre soutien. Les commentaires sur l’App Store et le Marketplace font souvent chaud au coeur, même si on sent bien qu’on vous a forcé la main. Pas non plus le temps de répondre à tous les mails qui nous parviennent via le formulaire sur

Bref, on tire un plutôt bon bilan de ce lancement, même si il faudrait relancer un peu la communication pour que tout le monde soit au courant !

Comment on a fait le bébé ?

Pas mal de choses ont déjà été dite pendant le lancement officiel des applications dans l’ADC #124, mais revenons-y un peu. Pour Michel comme pour moi, le dev pour mobile était quelque chose de nouveau. On a donc pas mal tâtonné avant d’arriver au résultat final.

Depuis sa création en octobre 2011, Freepod souhaitait se doter d’applications mobiles pour faciliter la consommation des podcasts en mobilité. Le pas a été franchi ce printemps dans le cadre d’un projet universitaire : Michel a développé l’application Windows Phone 7, j’ai développé le web-service et l’application iPhone.

Le web-service est la clé de voute de tout ça. Il est associé à une petite interface d’administration qui permet d’ajouter simplement de nouveaux podcasts, de modifier quelques paramètres et d’afficher des statistiques d’utilisation (à terme, il devrait permettre aussi d’autres choses, en lien avec les nouvelles fonctionnalités proposées dans les applis). Il traite donc les flux RSS des podcasts (avec toutes leurs incohérences), insère ça dans une jolie base de données MySQL et propose à qui veut de récupérer une liste de podcasts ou d’épisodes au format JSON.

L’application (que ce soit la version iOS ou la version WP7, puisqu’elles n’ont pas les mêmes fonctionnalités) ne fait que s’interfacer sur ce service. Elle récupère la liste des podcasts, puis des épisodes pour un podcast et affiche ces informations à l’écran (oui, comme ça, ça a l’air facile).

Notre système de live audio est hébergé par Infomaniak et nous permet pour une somme modique d’obtenir un flux suivable par 200 personnes simultanément, soit plus que ce qui est aujourd’hui nécéssaire !

Et maintenant ?

On a déjà annoncé pas mal de choses au niveau des évolutions futures des applis. La première chose à dire aujourd’hui, c’est que Jérémie rejoint l’équipe de dev et va se charger de la version Android. Donc oui, ça devrait arriver un jour ou l’autre !

La priorité numéro 1 pour les apps existantes, c’est d’uniformiser les fonctionnalités : permettre à l’appli iOS de lire des émissions offline, permettre à l’application Windows Phone de suivre les enregistrements en direct. On essaye de faire ça et de balayer quelques bugs pour la rentrée en septembre.

Ensuite viendra le temps d’ajouter autre chose à l’application. Là aussi, plein d’idées : des notifications push à la sortie d’un nouvel épisode ou au démarrage d’un live, l’intégration d’un chat cross-plateforme pour discuter depuis son mobile avec ceux du navigateur pendant les lives et vice-versa, des versions compatibles avec les tablettes…

En bref, les choses partent bien et on a plein de beaux projets pour l’avenir !

De l’importance de contrôler le flux RSS de son podcast

Il serait temps de faire revivre ce lieu…

Il y a quelques temps, j’ai publié ici un billet expliquant comment mettre en place un flux rss “à la main” pour son podcast (voir ici). Suites aux mésaventures traversées par quelques camarades podcasteurs autour de leur flux RSS, j’ai ressenti le besoin d’écrire une bafouille pour expliquer l’importance de contrôler soi-même son flux.

J’en ai moi même fait les frais pour les extras de Poli*Geek. Ce podcast audio et vidéo est hébergés sur le service, qui propose un bon service d’hébergement gratuit pour des podcasts d’audience modeste (le débit de téléchargement n’est pas particulièrement rapide). propose de générer automatiquement un flux qui puisse être récupéré par iTunes pour en faire un podcast. La plupart des CMS génèrent eux aussi (plus ou moins nativement) un flux RSS exploitable par iTunes pour en faire un podcast.

Naïf jeune podcasteur et informaticien que j’étais au moment du lancement de ce podcast, j’avais laissé gérer 100% de ce podcast, de l’hébergement des fichiers à la génération du flux RSS. Quelle erreur ! Suite à une erreur de manipulation, l’adresse du flux a été changée par, sans en notifier iTunes. Le podcast, ses commentaires et ses abonnés sont donc perdus, iTunes ne permettant de changer l’URL du flux RSS que dans le code de celui-ci (et ne permettant pas non plus de supprimer un podcast pour le recréer).

Pour un podcasteur qui veut garder un minimum de continuité dans son travail et ne pas perdre ses abonnés et commentaires sur sa page iTunes, il est donc extrêmement important de garder un contrôle sur son flux rss. C’est à dire héberger soi-même le fichier .xml sur son site internet et le coder ou le générer “à la main”. Les fichiers peuvent par contre continuer à être hébergé ailleurs, c’est ce que j’ai fait pour les extras de Poli*Geek : les fichiers sont chez et le xml sur

Si jamais vous avez besoin de modifier l’URL de votre flux, c’est simple : Ajouter la ligne de code suivante dans le fichier .xml change automatiquement le flux sur la page iTunes, et la répercute progressivement pour les abonnés.


Bien sûr, il faut que “l’ancien” flux reste en place un moment pour que le transfert puisse se faire tranquillement.

Bref, si vous vous lancez dans un projet de podcast, gardez ça en mémoire. Pour un podcasteur, le flux RSS, c’est la vie !

Créer un flux RSS de podcast “à la main”

Quand on souhaite créer un podcast, il y a d’abord la phase de conception du podcast (la partie la plus important, on en parlera ici prochainement), puis vient le moment fatidique où il faut mettre tout ça en ligne pour le partager et le faire découvrir à ses futurs poditeurs.

Pour rendre votre podcast disponible, les fichiers audio doivent d’abord être hébergés en ligne puis répertoriés dans un flux RSS qui permet leurs récupération facile par les auditeurs.

La plupart des CMS de blogs forment des flux RSS compatibles avec les contraintes des podcasts, mais il manque toujours certaines informations. Le mieux est donc de créer “à la main” ce flux.

Pour ça, Apple fournit une bonne documentation sur son site.

En pratique, ça se passe de la façon suivante :

On place l’ensemble de ce qui va suivre entre les balises suivantes.

<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:itunes="" version="2.0">
        <!-- INSERER LA SUITE ICI -->

On entre ensuite les données propres au podcast de la façon suivante.

<description>Poli*Geek, c'est le podcast qui revient toutes les deux semaines sur l'essentiel de l'actualité politique autour des nouvelles technologies. Retrouvez dans chaque épisode les news et le grand débat, avec des invités passionnants ! Blog et plus d'infos sur</description>
<copyright>cc by-nc-sa 2.0 fr</copyright>
<lastBuildDate>Tue, 26 Feb 2011 11:00:00 +0200</lastBuildDate>
<pubDate>Tue, 26 Feb 2011 11:00:00 +0200</pubDate>
<webMaster> (Nom)</webMaster>
<itunes:subtitle>Le podcast qui vous parle politique et technologies !</itunes:subtitle>
<itunes:summary>Poli*Geek, c'est le podcast qui revient toutes les deux semaines sur l'essentiel de l'actualité politique autour des nouvelles technologies. Retrouvez dans chaque épisode les news et le grand débat, avec des invités passionnants ! Blog et plus d'infos sur</itunes:summary>
<itunes:image href=""/>
<itunes:category text="News &amp; Politics"/>
<itunes:category text="Technology">
    <itunes:category text="Tech News" />

On doit ensuite ajouter pour chaque épisode le code suivant, en adaptant les données à son podcast bien sûr !

<!-- EPISODE 0 -->
    <title>&#35;0 - Le ventilo du Captain Liban</title>
        On y cause :
        # Les scarabés et le Vatican
        # L’ACTA dévoilé
        # Couvre-feu sur les Meuporgs
        # SeedFuck Hadopi !?
        Et dans le "grand débat" :
        # Les droits d’auteurs et la rémunération des artistes
        Plus d'infos sur
    <enclosure url="" type="audio/mpeg"/>
    <pubDate>Thu, 22 Apr 2010 15:00:00 +0200</pubDate>
    <itunes:subtitle>&#35;0 - Le ventilo du Captain Liban</itunes:subtitle>
        On y cause :
        # Les scarabés et le Vatican
        # L’ACTA dévoilé
        # Couvre-feu sur les Meuporgs
        # SeedFuck Hadopi !?
        Et dans le "grand débat" :
        # Les droits d’auteurs et la rémunération des artistes
        Plus d'infos sur
    <itunes:image href="" />
    <itunes:keywords>politique, technologie, droits, auteurs, majors, acta, hadopi</itunes:keywords>

Et le tour est joué !

Pour optimiser les statistiques sur le téléchargement et les abonnements, le flux peut être passé par Feedburner.