Codable is a great protocol for automating simple model persistence, but it lacks support for any kind of versioning or migrating the data from older versions.

You can, of course, implement custom Codable adherence and throw in a bunch of if statements and manual decoding to achieve this goal, but isn’t that kind of killing the main selling point of Codable?

Let’s look at an idea that adds Versoning yet still leverages derived Codable.

If your app has a lot of content, chances are that by the time you get a chance to work on a bug report, the data that the bug appeared on will be long gone.

Here are some tidbits on how I created a simple solution for that problem at The New York Times, it’s based on a simple idea.

Have you ever written tests? Usually, they use equality asserts, e.g. XCTAssertEqual, what happens if the object isn’t equal? Xcode throws a wall of text at you:

This forces you to manually scan the text and try to figure out exactly whats wrong, what if instead you could just learn which property is different?

Source Code on GitHub.

LifetimeTracker can surface retain cycle / memory issues right as you develop your application, and it will surface them to you immediately, so you can find them with more ease.

Instruments and Memory Graph Debugger are great, but too many times developers forget to check for issues as they close the feature implementation.

If you use those tools sporadicaly many of the issues they surface will require you to investigate the cause, and cost you a lot of time in the process.

Source Code on GitHub.

I’ve recently spoke at CraftConf about metaprogramming in Swift using my Sourcery

You can watch the talk online:

I like using composition and dependency injection, but when you need to inject each entity with multiple dependencies, it can get cumbersome fast.

As the project grows and you need to inject more dependencies into your objects, you will end up having to refactor your methods a lot of times, as we all know Xcode doesn’t help with that.

There is a more manageable way.

Closures in Swift are extremely useful, they are interchangeable with functions and that creates a lot of opportunities for useful use-cases. One thing we have to be careful when using them is to avoid retain cycles.

We have to do it so often that it begs the question:

Can we improve the call-site API?

I’ve been interviewed at Swift Coders podcast:

I’m definitely investing into a better Microphone next time I’m doing any audio recording.

Ben Scheirman from NSPodcast has good recommendations for affordable microphone

People use different words to classify Engineer skill, some companies give you more senior role just based on a number of years you have been working there, but what does it mean to be Senior?

In this article, I composed a complete and final list of API’s that you need to know to classify yourself as Senior Engineer.

Here’s a list of all the APIs you must know:

•

Writing tests in iOS apps is a touchy subject. Not everyone is so privileged to be able to write tests full-time, for different reasons.

Some people have full control over their development process and choose not to write tests, maybe because they have had a bad experience with it or they just don’t see the value in them.

I would argue that if you are part of a smaller team, tests can even be more helpful than in big corporations.

A big corporation might have dedicated QA team, but if you are one of 2 developers, then you are often responsible for ensuring quality and reliability of your work, its considerable pressure because each feature you write might break something else in your app.

Let us look at practices and tips for writing maintainable tests in your iOS Apps.