This year, Apple introduced Core ML 2 at WWDC 2018, with a focus on making machine learning more flexible and powerful for developers to use.

With the release of this new and improved framework, Apple also announced a freshly updated version of coremltools. This handy Python library can be used to convert trained models into a Core ML format as well as making predictions directly from your machine.

For mobile applications using Core ML, one of the main burdens is the model size. A heavy app can discourage some users from downloading it. As such, developers often end up storing models in the cloud, costing both time and money.

Introducing Quantization

Quantization is one of the new features in the updated coremltools, and it can help solve this size problem by reducing — sometimes drastically — the size of Core ML models.

It works by trimming the number of bits used to describe weights in models. As some models can have millions of weights, shaving a few bits on each one can have a tremendous impact on overall size.

In iOS 11, models only used 32-bit floats to describe weights. This was later improved in 11.2 with the introduction of half-precision floats, using 16-bit for the same accuracy.

With iOS 12, weights can now be encoded using any number of bits, all the way down to just 1-bit.

So now, instead of having the continuous representation of values weights would have with floats, we actually end up with a discrete subset. Of course, this will lower your prediction accuracy, but it’s up to you to consider what tradeoff you might be able to accept.

There are multiple ways to choose the values representing those new, quantized weights. The most straightforward is to distribute them linearly, like in the example above.

We can also have them distributed in other arbitrary ways using a lookup table (or LUT), based on the particularities of your model.

In total, you have access to these 4 distribution modes : linear, kmeans, linear_lut, andcustom_lut.

Quantizing your Core ML model

Let’s dive into the code!

First there are a few pre-requisites:

• Must be working on MacOS 10.14 (Mojave)
• Have the last version of coremltools installed. A simple pip install coremltools==2.0should do it.

Once your environment is ready, you should be able to run the following script. Just edit the last few lines to feed it your own model filename, along with the combination of bits-per-weight and distribution functions you wish to use.

Right away, you should see that the less bits-per-weight used, the lighter the quantized file will be.

This script was used on one of Looq’s Neural Style Transfer models. It gives you an idea of the accuracy loss on a real-world use.

The first image is the un-styled picture for reference. After it are displayed the outputs for original, 16-bit, 8-bit, 6-bit, 3-bit, 4-bit, 2-bit and 1-bit quantized models.

Now let’s look at the actual size difference between each of those files.

In this case, we can see that the 8-bit model output is nearly identical to the original one. This means that we can get the model size from 6.7MB to 1.7MB—4 times lighter!

This example is, of course, very specific to NST models. A linear distribution won’t always work. Fortunately, you should be able to apply the same approach to your own models, as long as you have a good understanding of how those values should be distributed.

Save your models!

As of now, there is no way to “re-quantize” a model. Meaning that if you’ve quantized a model to 16-bit and later decide to make an 8-bit version, you won’t be able to do it unless you still have your original file.

I hope you found this article helpful. If you want to read more on machine learning (and more specifically, Core ML), have a look at my piece on how to build a Neural Style Transfer app!

Discuss this post on Hacker News.

Editor’s Note: Heartbeat is a contributor-driven online publication and community dedicated to providing premier educational resources for data science, machine learning, and deep learning practitioners. We’re committed to supporting and inspiring developers and engineers from all walks of life.

Editorially independent, Heartbeat is sponsored and published by Comet, an MLOps platform that enables data scientists & ML teams to track, compare, explain, & optimize their experiments. We pay our contributors, and we don’t sell ads.

If you’d like to contribute, head on over to our call for contributors. You can also sign up to receive our weekly newsletters (Deep Learning Weekly and the Comet Newsletter), join us on Slack, and follow Comet on Twitter and LinkedIn for resources, events, and much more that will help you build better ML models, faster.

Reducing Core ML 2 Model Size by 4X Using Quantization in iOS 12 was originally published in Heartbeat on Medium, where people are continuing the conversation by highlighting and responding to this story.

In June 2017 Apple introduced CoreML, a framework designed to integrate Machine Learning models into iOS apps.
This opened a great deal of possibilities for developers, from image analysis to NLP (Natural Language Processing), decision tree learning and more.

During Spring 2018 I started to dive into CoreML after reading a few articles on another domain of Machine Learning : Neural Style Transfer. This ended up mutating into a full-fledged project, Looq.

Alexis Creuzot on Twitter

La Vilaine #rennes via ⁦@Looq_app⁩

In this article, I will explain the basic blocks required to create this kind of app, and hopefully pass a few of the things I learned along the way.

Training an NST model

In a nutshell, ML models are similar to functions : they take one or multiple inputs to returns one or multiple outputs. One big difference though is that as a developer you don’t write a model, you train it. The trained model can then be fed inputs which will be processed through its underlying tensors to reach a result, or prediction.
Our knowledge is therefore shifted to a higher level task : implementing the training algorithm.

Multiple frameworks are available to achieve this : Tensorflow, Keras, Caffe, PyTorch… We will focus on that last one in this article, PyTorch, as it provides a strong GPU acceleration, which will reveal as an important feature in the next steps.
To get started, I recommend using Anaconda which makes it very easy to manage your environment in case you have several conflicting dependencies on your workstation. If you have an NVidia Graphic Card, it’s very important that you also install the proper CUDA toolkit for it to enable GPU acceleration during training.

Once your environment is set, you can go to PyTorch Github repo which list multiple usage examples, one being a Fast Neural Style sample. Clone this repo onto your workstation and activate your environment.
You should now be able to try training your first model using the default parameters. This will start a training loop which will save a checkpoint every two thousands iterations.

Those checkpoint are nothing more than a model at a given number of iterations. Usually the more iteration, the better, but in our case we are aiming for beauty, which is subjective and difficult to measure without actually having a look at the result.
You can look at how neural_style.py implements the actual training and what makes it “improve” over the previous iteration, which uses multiple metrics like style-weight, content-weight, regression loss and more.

Trying with other style image, you‘ll find that tweaking those style-weight and content-weight is a good place to start in order to improve the model predictions.

Exporting your model to CoreML

Here comes one of the tricky parts. PyTorch doesn’t natively support exports to CoreML (yet). Fortunately, you might have heard about an endeavour aiming at make Machine Learning models interoperable, the Open Neural Network Exchange.
ONNX provides tools for importing and exporting models from almost any framework to the .onnx format (mandatory xkcd).

Hence, we can export our model to CoreML in 2 phases :

PyTorch → ONNX→ CoreML

neural_style.py already have an ONNX export, so we really just need to implement the second step. We can find everything we need on the onnx-coreml Github repo to bridge that gap.

Now that we have our ONNX to CoreML converter, we can convert a checkpoint with a simple bash command.

Using a CoreML NST model on iOS

You should feel more at home for this part if, like me, you are an iOS developer.

First, we start by creating a simple project with an UIImageView to hold our original and output image, as well as an UIButton to launch the process.
Next, we add an UIBarButtonItem to pick an image from the device’s photo library and set it onto the UIImageView.
Alternatively, we can just provide a default image and use that one.

Once the UI is implemented, we can import our model into the app (download this pre-trained model if you don’t have one). This is done by simply drag-and-dropping the file on Xcode’s files view.
By clicking on the model, you can see some important details about it.

• Specifications (Name, type, Size, Author, Description and License)
• Evaluation parameters (Inputs and Outputs with their respective names as well as expected types).

You can also see a Model Class which was auto-generated by Xcode. You can click on the little arrow next to the Class name to jump in the actual file and see the API that will enable us to use our NST model. The function that we will call here is prediction(inputImage: CVPixelBuffer).

Yep, it might be counter-intuitive but in CoreML the image type is CVPixelBuffer, not UIImage. Fortunately, Matthijs Hollemans has an awesome library to help us make that conversion easily (and many more things).

So here are the steps once we have picked the original image:

• Save the input image size
• Convert the input UIImage to a 720 x 720 CVPixelBuffer, as specified in the model view.
• Feed it to our Model
• Convert the CVPixelBuffer output to an UIImage
• Resize it to the original size saved at the first step

Here is a Swift 4 excerpt of the implementation of those steps.

We’re done! You will see that it doesn’t hurt to do all this on a background thread as it is pretty CPU intensive. It’s also a real memory hogger, so you might have to make some optimisations to get your code working on an actual device!

If you wish to get your hands dirty, you can find the sources for this project on Github.

I hope you have learned a few things about CoreML or even Machine Learning in this article. If you want to go further, have a look at how I managed to reduce my model size by 4x using quantization for iOS12.

First, the result we want to achieve.

Let’s hop into Xcode and create a new “Single View Application” project. We’re going to begin by designing our interface.
A simple UINavigationController with our ViewController as its root will do.

Let’s add our UITableView and add an UITableViewCell to it. We need two labels, one that will be our title, and a second one below that will be our subtitle that will be either shown or hidden.

As we want for AutoLayout to compute the cell height itself, we need to setup the constraints accordingly.
Add a leading and trailing constraint to both labels. Then we want to add a top constraint between the title and its superview, a bottom constraint between the subtitle and its superview, and a vertical spacing constraint between both labels.
This will allow AutoLayout to understand that we want the superview to grow based on our labels intrinsic height. We’ll also set both label numberOfLines property to zero, so they don’t get truncated.

At that point AutoLayout may display an error, asking you to set a different vertical hugging priority to one of the labels. Seems logic, as for now both have the same priorities and AutoLayout need to know which one should take precedence. We can decrease the vertical hugging priority or set a fixed height constraint to either labels in order to get rid of this error.

Our UI seems good for now, let’s dive into the code! First, we need to create a new class for our prototyped UITableViewCell. We can call it ExpandingTableViewCell for the sake of originality.
Add both labels outlet and link them to their actual view in InterfaceBuilder.

Now, it’s a good idea to have a backing class for our cell. You can use a simple dictionary, but having typed properties is always a plus. To accurately represent our cell state we need a title, subtitle and a boolean to check wether the cell is expanded or not.

Now that this is taken care of, onto our ViewController!

We want a property linked to our UITableView, and another for the array that will contain our cell representations. Let’s populate it with a few ExpandingTableViewCellContent instances to it so we can have something to display later.

We still have to implement the datasource for the UITableView, and more importantly the delegate, where the magic happen!
In our delegate method didSelectRowAtIndexPath, we want 2 things :
- Change the expanded state of our backing class at that particular index
- Reload the cell to reflect its new state

Alright, everything seems in place, let’s build & run (command + R)!

Whoops, that’s not what we want! Well, we miss one last detail in our ViewController viewDidLoad to make this a home run. We need to explicitly specify to our UITableView that AutoLayout should take care of our cell heights. This is done in 2 lines :

tableView.estimatedRowHeight = 60
tableView.rowHeight = UITableViewAutomaticDimension

This time the code should run smoothly and behave correctly. Enjoy!

Hope you liked this tutorial, you can find its source-code on github. Don’t hesitate to like/comment if you found it useful!

EDIT2 : After a call with someone from the Chartboost team, I got an apology, 300$ in advertising credit and — most importantly — some context on why my account got suspended in the first place.
Apparently my email was flagged in their system for some reason. As it uses machine learning for fraud detection, the user behaviour variation in combination with my flagged email triggered a false positive.
They understand that automating the account suspension isn’t the best developer-friendly approach and are apparently working on improving this. Let’s hope they do!

For transparency, I decided to keep the following article as is so you can form your own opinion.

Some background

A few months ago, I decided to entertain myself on a tiny side-project. With the Pokemon GO craze at the time, the idea was an obvious — and not very original — one : a buddy app for Pokemon GO.

A few days and cups of coffee later, MapVision was born : a simple map with pokemons popping in and out.

Despite a (still) spotty API, the app got immediately some traction.

This encouraging curve brought with it the possibility to test some monetization techniques and compare how Video Ads fared compared to IAP.

I threw a few more days in the project for the killer feature. A “radar” that would notify the user of nearby pokemons from a list of “wanted” ones.
Monetization-wise : one video view unlocks 1 more pokemon to get notified about. The IAP unlocks them all. Simple enough.

Chartboost comes in

I decided to go with Chartboost for Video Ads mostly by laziness. I knew that is was used on some iOS games, and their SDK seemed simple enough to implement. Plus they had a “rewarded video” ad type which was exactly what I was looking for : watch one, get one. Perfect.

Despite a slow start, the video ads started to pick up a little after a few day. Something around 1$ per 250–300 views. Still, it seemed very low for the hassle it put the user through, but I had something working so I decided to let it as-is and let it go its course.

Then 2 weeks later, out of the blue :

I was fucking pissed. No warning, no real contact to call and on top of that, no access to the Chartboost dashboard to review what went wrong.

Fortunately, I had put a custom event on Fabric to monitor successful Rewarded Video views.

After reviewing the small dent in the graph, it appeared that one or 2 users had gone rogue and decided to view loads of videos instead of actually getting the IAP. Well, those people exists, and isn’t that precisely why we use ads in apps?
Moreover, I had put a limit on videos watchable from the Chartboost dashboard itself, the very one I had no longer access to.

Prompting my disbelief in response did not phase them, and I received a few hours later a very formal, very polite mail closing the issue — unilaterally — for good.

Epilogue?

My last attempt at contacting Chartboost Support afterwards stayed unanswered, and I’m left with a bitter taste in my mouth.

Not because I won’t see a dime of those 14 days of ads, or the hours I put into implementing this feature.

No, I’m sick to my gut to see how a company that profess being “on a mission to empower developers” can care so little that it won’t engage in a real chat or even provide any data to help remediate the issue…

One thing for sure, being empowered never left me feeling that powerless.

I am actually curious if anyone have had similar experiences with advertisers, Web or Mobile. I you did, don’t hesitate to share your experience too!

Le forfait

Le système est ainsi fait : les clients expriment un besoin — généralement sous la forme d’un appel d’offres — auquel les entreprises compétentes répondent avec un devis.

Pour ce faire, elles font suivre le cahier des charge au personnel technique pour obtenir une estimation du temps. Cette estimation est “challengée” par l’équipe commerciale afin de la diminuer au maximum, car évidemment il ne faut pas oublier que plusieurs entreprises sont susceptibles d’être en concurrence pour décrocher le contrat. Un savant calcul est alors effectué en prenant des critères comme le coût journalier, le nombre de personnes affectées au projet et différentes marges de sécurité pour obtenir le tarif final. Ce processus est souvent vecteur de stress pour les personnes impliqués. Pourtant, le travail n’a pas encore commencé…

Estimer le temps de réalisation d’un projet informatique est loin d’être une science exacte. Sa précision est inversement proportionnelle au nombre de fonctionnalités. En clair, plus la tâche est grande, plus l’incertitude augmente.

Un vrai casse-tête pour les entreprises qui n’ont alors d’autre choix que d’ajouter une marge de sécurité afin de limiter les risques.

Au final, quelque soit le prestataire sélectionné par le client, le résultat est par forcément l’un des suivants :

• Le prestataire a sous-estimé la charge et finit le projet à perte, auquel cas il devra souvent bâcler la fin du travail pour limiter la casse.
• L’estimation est tombée juste — ce qui est rare— et le projet peut donc être considéré comme un succès.
• Le projet est fini en avance, le prestataire augmente donc sa marge. Cependant le client aurait probablement bien aimé utiliser celle-ci pour d’autres éléments de son business plan.

Indépendamment de ces résultats, il ne faut pas oublier que “challenger” l’équipe technique en début de projet ne se fait pas sans prendre des raccourcis. Ces mêmes raccourcis se transforment immanquablement en dette technique, au détriment du client et de l’éventuel prestataire qui reprendra le projet par la suite.

Le client est donc bien souvent perdant en récupérant un projet fait à la va-vite, potentiellement bâclé et/ou surpayé.

La régie

La régie consiste tout simplement à facturer au temps passé. Avec ce format, le prestataire peut toujours fournir une estimation au client, mais celle-ci reste informelle.

Fonctionner ainsi présente plusieurs avantages.

• Côté technique, le prestataire n’a aucun intérêt à prendre des raccourcis ou à bâcler le travail.
• Si le projet se termine plus rapidement que prévu, le client comme le prestataire rentrent dans leurs frais.
• Dans le cas contraire, le prestataire est plus facilement capable d’expliquer les raisons du retard, chose qui ne serait pas possible en avance de phase.

Avec ce système, le client est toujours gagnant. Il a par-ailleurs la possibilité d’arrêter le projet à tout moment si le prestataire ne répond plus à ses attentes.
Au niveau du prestataire, plus de possibilité de “marge bonus”, mais cependant la garantie de toujours rentrer dans ses frais.

C’est du gagnant-gagnant avec — cerise sur le gâteau — moins de stress à la clé.

La stratégie de l’échec

Alors pourquoi la grande majorité des projet informatiques sont-ils toujours effectués au forfait?

Il y a plusieurs raisons :

• Les appels d’offres restent pour les entreprises un moyen — bien que virtuel — de se projeter sur les coûts.
• Le manque de confiance et la peur que le prestataire fasse “traîner” le projet aux frais du client.
• Le besoin aussi d’une communication plus régulière dans le cadre de la régie, qui n’est pas toujours réalisable.

En ce qui me concerne, je ne regrette pas le choix de m’être tourné presque exclusivement vers du temps passé depuis que j’ai lancé mon activité.
Cela m’a permis d’aborder l’entrepreneuriat avec moins d’insécurités, mais aussi et surtout de créer des relations de confiance (et donc de travail) durable avec mes clients.

Si vous souhaitez vous aussi faire la transition, n’hésitez pas à relayer cet article. Le meilleur choix est toujours celui fait en toute connaissance de cause !

Alexis Creuzot est développeur et co-fondateur de Monoqle, une entreprise spécialisée en développement mobile.

Dans cet article je souhaite parler de la création de l’association de coworking Happy Hours auquel j’ai pris part et qui a pris une bonne partie de mon temps de fin 2014 à début 2015.

Le projet Happy Hours est le fruit d’une problématique commune à Gwénolé, Jérémy, Matthieu et moi même.

Comment travailler agréablement et éviter l’isolement lorsque l’on est indépendant?

L’existant

A l’origine, deux solutions se présentaient pour ne pas être seul chez soi.

La location de bureau auprès d’une société spécialisée

Celle-ci sous entend un prix prohibitif, notamment pour les entreprises qui démarrent et ne garanti absolument pas une ambiance décontractée telle que nous recherchions.
Leurs offres de coworking se sont d’ailleurs souvent faites “sur la vague” en créant un open space mais sans aller beaucoup plus loin.

Utiliser un coworking “sponsorisé” par la municipalité

Après avoir testé la solution proposée par Rennes Métropole (la cantine numérique et l’Annexe), le retour était mi-figue mi-raisin.

Bien que l’atmosphère y soit détendue, les locaux, le manque d’indépendance vis-à-vis de la municipalité et l’objectif assez marqué par celle-ci de “booster” les entreprises y entrant ne correspondaient pas à nos attentes.

Le concept

Après en avoir discuté ensemble, nous avons trouvé un concept sur lequel nous étions d’accord. Celui-ci comportait plusieurs priorités.

• Des locaux agréables, faciles d’accès et si possible proches du centre.
• Des bureaux de qualité — on y passe après tout 8 heures par jour — et spacieux.
• Un effectif limité privilégiant les résidents au nomades afin de faciliter la cohésion entre les membres.
• Une indépendance nous permettant de gérer l’espace, son aménagement ainsi que l’animation.
• Et bien sur être dépourvu de toute étiquette “accélérateur”, “booster” ou encore “pépinière d’entreprise”. Juste un endroit sympa ou il fait bon vivre et — presque accessoirement — travailler.

Le nom évocateur d’Happy Hours y prend tout son sens!

La démarche

La création d’une association n’est pas simple, et la charge administrative peut faire peur. Heureusement, à 4, on peut diviser le travail et s’entre-motiver pour avancer.

L’administratif

La première étape, consistant à déclarer l’association, etait une étape peu attrayante, se divisant elle même en une kyrielle de tâches décrites ici.

Nous avons cependant eu l’occasion d’être conseillés par plusieurs personnes, en particulier Nicolas Birckel ayant lui même créé le coworking de Nancy, la Poudrière. Encore merci!

Le financier

La seconde étape était la création du capital de départ servant à financer les premières charges auxquelles l’association ferait face avant de devenir auto-suffisante.

Passage à la banque obligé donc, et qui dit banque dit prévisionnel et autres informations personnelles de solvabilité. Cela dit aussi trou dans les finances personnelles, mais on a rien sans rien!

Les locaux

La dernière étape — la plus difficile, mais aussi la plus importante — consistait à trouver les fameux locaux qui formerait le coeur du projet.

Il nous a fallut de nombreuses visites, contre-visites, déceptions et frustrations avant de trouver la perle rare. Les fameux locaux 22 quai Duguay-Trouin où se situe l’espace de coworking Happy Hours.

Le style “pas trop bureaux”, l’emplacement et l’espace nous ont rapidement convaincu.

La mise en place

La planification

Avant même d’avoir les clés, Jérémy s’est mis au travail pour modéliser les locaux en 3D, ce qui nous a permis de tester plusieurs dispositions, comme il a pu le décrire plus en détail sur cet article.

L’aménagement

Une fois les clés en poche, on est passé à la partie “travaux manuels”. Nous avons décidé de construire les bureaux nous même afin d’avoir une qualité maximale pour un prix restant dans nos moyens.

Les autres meubles ont été achetés avec le budget restant ou grâcieusement offert par les membres de l’associations!

Le lancement

Le site

Jérémy, Gwénolé et Matthieu ont mis leur savoir-faire en commun pour mettre au point le site web d’Happy Hours. Y figurent des informations sur l’association, les locaux et les coworkers.

L’installation

Nous nous sommes officiellement installés dans les locaux le 5 janvier 2015. Le coworking s’est progressivement rempli à partir de cette date et nous avons dorénavant clos les inscriptions pour les places de résidents.

Retour d’expérience

Je ne suis pas trop entré dans les détails car certains points mériteraient un article à eux seuls. J’espère avoir cependant bien résumé cette aventure — il faut le dire — qu’aura été la création de d’Happy Hours.

Pour ma part, palper le bois des bureaux m’apporte aujourd’hui une réelle satisfaction, la fierté d’être aller au bout des choses. Un sentiment d’accomplissement que j’espère partagé par mes associés, sans qui rien n’aurait été possible.

A network abstraction layer is a must have in any app that interact with a server. In Objective-C, this abstraction layer is usually done in two steps :

• First, subclass the main networking component from our library, usually AFHTTPSessionManager when using AFNetworking.
• Second, create categories on our models — or services of some kind — to put in our networking stuff. All this wrapped in convenient, explicit methods of course.

It’s not too bad, but here comes Swift and we now get a chance to look at this layer from a new angle.

Our goals are:

• Flexibility, to be able to edit or add new endpoints efficiently
• Readability, to have a good idea of how our API work at a glance
• Code safety, with typed parameters. This allow all the pre-compilation goodness we expect from Xcode (completion, validation).
• Easy debugging, meaning being able to insert logs before and after web requests

Endpoints

Let’s imagine we want our app to connect to a web-service allowing us to both fetch and add objects for a given model Color. Our first task is of course to create this model in our app. Once this taken care of, we can start thinking about how we want to interact with this API.

With Swift, enumerations became more powerful than ever. They are a great way to define our endpoints in a readable and type-safe way. Moreover, each enum case can declare associated values of any type to be stored with it.

For each of those Endpoints, we can provide a clear switch-based implementation for the method, path and parameters we’ll want to use.

As you can see, associated values are ideal to wrap every informations needed for our request into one Endpoints enum case.

Request

With a proper representation of our endpoints, we can now create our own request function on top of Alamofire. It will only need an Endpoints enum case and a completion handler to rock and roll!
This function is also the perfect place to put any operations we might want to be executed before and after the request took place. Logging for instance (here I’m using Cocoalumberjack, don’t mind the syntax).

Result

After wrapping all that previous code into a publicly accessible class API, we can call our server like so:

Pretty sweet eh? Readable, type-safe and with only one file to reflect any changes in our API. Mission accomplished!

A project named Moya took the same direction using enums to abstract the network layer. A great library, though I feel Swift makes it actually pretty easy and brief to build it yourself.

You can find a working example of this approach on my Github repo ColourLoveSwift.
Ideas, remarks? Don’t hesitate to comment or send me a message on twitter!

iOS : Let’s Build a Network Abstraction Layer was originally published in Learning Swift on Medium, where people are continuing the conversation by highlighting and responding to this story.

I developed Nice Weather back in 2013. The concept was simple and I had no expectations. A weather app focused on simplicity with an interactive graph, packaged with a clean UI.
Its launch passed pretty much unnoticed, but nevertheless I kept on improving it little by little. Side projects are fun after all.

Several months later, I decided to redesign the app and — not wanting to force it onto existing users — branched the project as a new app : Nice Weather 2.

I got more traction. Then, out of the blue, an angel smiled upon me. Apple had noticed the app and decided to feature it on the App Store.
The downloads skyrocketed and it became quickly my number 1 selling app.

The next few weeks were pure craziness.

After a while, things gently settled down; Nice Weather 2 had made its place into the Weather section of the App Store, ensuring stable download rates. I kept on improving it and getting feedback from overall delighted users.

After one year of mostly small updates, I decided last April to make a huge upgrade of the app. It involved trashing and recoding some parts from the ground up.

One of the biggest part I wanted to improve was to store data more efficiently and reliably. If you already worked on databases, you know how painful and risky it is to make their structure evolve. To make sure you stay compatible with previous data models, you need to create what we call “migrations”, which essentially take the data from the old structure and process it so it “fits” in the new one.

The main issue with migrations is that you need to think of every form the data may have taken to process it accordingly.

The big update rolled out and I saw almost immediately the crash-free sessions drop from the usual 99.5% to 94%. Something was wrong and I jumped to my computer to solve it.

I took the opportunity to improve some of the data management and submitted a new update with an expedited review request, which was accepted swiftly.

The new-new update was then released, and it did not take long for me to realize that something was askew. Dozens of e-mails either from users reporting crash or from Fabrics, the tool I use to track crashes. The drop was harsh.

From 95% crash-free sessions I dropped to 40%. In my hurry I had forgotten a migration while submitting the fix, and essentially every existing user of the app was crashing on startup after this new update.

I jumped again to my screen and made sure that the migration was this time taken care of, testing heavily on previous versions to ensure that there would be no more mishap. Submission. Expedited review. Release.

Fuck.

Crash-free sessions stopped dropping, but passed a point they stabilized around 60%. What in the hell did I do wrong.

It took me a week to figure it out. I had forgotten the unlucky users who had crashed in the previous version, for which the data was stuck “in-between”, in some kind of limbo state.

So, here we go again. Submission, but no expedited review this time, as after two times in such a short timeframe, there was no point in even trying.
The waiting was excruciating, as while I was lingering for the update to pass, I was witnessing first-hand users tearing the app apart in their reviews and, consequently, all the indicators slowly go red.

It took 10 excruciatingly long days for the app to be reviewed and, at last, released.

As of now, Nice Weather 2 has returned to a more manageable crash-rate, hovering nicely around 1%. If anything, this adventure taught me two things :

• Never submit an update in a hurry, whatever the issue, give it at least a good night’s sleep
• Use a good crash reporting tool. Needless to say, this story would have ended way worse without Fabric allowing me to peek behind the curtain

Let it be a valuable lesson for all iOS developers out there !

pod ‘ObjectiveSugar’

ObjectiveSugar brings a set of functional additions for Foundation you wish you’d had in the first place.

Most of those additions are brought in the forms of Categories that extend existing classes of the Foundation framework. In particular, you’ll find some of the familiar functions that make your life so easier and come out of the box in Ruby.

This Pod will definitely help you write more readable and concise code, especially when your algorithms tend to get a little “spaghetti”.

pod ‘CocoaLumberjack’

If you rely a lot on logging to follow your app behavior, CocoaLumberjack will quickly become your best friend. You can define log levels, send them through the network or even save them locally. And it’s faster than NSLog.

You can also display logs in different colors by using the XcodeColors plugin for Xcode. A must have!

pod ‘AFNetworking’

It’s quite likely you have already heard or even used this library, but I couldn’t make this list without including it.

AFNetworking is simply the reference to manage network requests to an API. It is simple, fast and supported by a huge community of developers.

pod ‘Realm’

In my 3 years of development I’ve searched extensively for a satisfying database framework. I tried FMDB, CoreData, MagicalRecord and used iActiveRecord for a while.
Each time I got frustrated. Some are too low-level and need a lot of boilerplate code, some don’t play well with threads and some lack in performances as soon as your queries get a little complicated .

For now Realm seems to have achieved the perfect mix. It allows ultra-clean and readable code (think Active Record pattern) and manage to be very, very fast.

I cannot recommend enough this library if you need to have a client-side database.

pod ‘GPUImage’

If you need to process images or video in your app and don’t want to spend weeks cramming research papers and other complex documentation, this library is made for you !

With an impressive collection of filters and image processing algorithms, you can achieve blurs, blend images, detect edges and much more in just a few lines of codes.

It is also very well thought and allow easy chaining between different filters and transformations while staying performant.

pod ‘SVProgressHUD’

You are probably familiar with the image above, as you can now find this library in many iOS app.

In general, you don’t want your user to wait, and you should preload as much stuff as you can for a smooth experience.
But when you can’t, SVProgressHUD does a fine job at indicating a loading, in one line of code. You can also use it to display “toasts” to the user and even customize the image and text.

Too bad it doesn’t provide a determinate progress indicator, for which case you may want to use the equally good MBProgressHUD library.

pod ‘FontAwesomeKit’

Already well known in the web world, FontAwesome system is also available on iOS and it rocks !

If you are getting fed up of having to create @2x and @3x versions for each and every icon in your app, FontAwesomeKit will be a life savior. It basically allows you to use icons like you would use letters from a font. That means that every icons are vectorized and can take any color you want!

You can already use a variety of available icons from multiple iconic fonts like IonIcons or Zocial, but you can also create your own font and use it by extending the FAKIcon class.

That’s it! I hope you liked this article and that some of those libraries will find their way in your Podfile ☺

And you, what are your favorite Pods ?

UPDATE : This article is now deprecated, you can import any pods very easily in Swift by just adding use_frameworks! in your Podfile !

First, create your Podfile and add the pods you need as usual.

Install them using the pod install command and open the .xcworkspace file created in your project folder. Pods should now be included in your workspace.

Now for the interesting part. In order to use those pods, you are going to create a bridging header file. Click on File -> New -> File… and select “Header File” in the “Source” tab.

Name this file Bridging.h.

Open your project Build Settings and search for “Bridging”. Edit the key “Objective-C Bridging Header” to project_name/project_name-Bridging-Header.h.

You are now ready to add your imports into your Bridging-Header.h file for the pods you want to use, just as you would do in your .pch file.

That’s it, you can now use your pods*. You don’t even have to import them again in your .swift files. You can also import any other Objective-C file added to your workspace this way. Sweet !

I hope you liked this article, I’ll post more tips for Swift as I dive deeper into Swift. You can also find my some of my favorite Pods on this article :

7 Awesome Pods For Your iOS Projects

*Warning, some specific pods may not work or need additional configuration.