Most frameworks and libraries have guidelines and best practices. And Apple’s SDKs are no different. While there is room for experimentation and exploration, a typical iOS application, for example, uses one or more view controllers and the user can navigate between those view controllers. That is a recipe you are probably familiar with.
But not every problem you face during development has one solution. This is a common issue developers face when they use Core Data, for example. They run into an issue and they try to resolve it by looking for the recipe that resolves their problem.
An Example
A few years ago, Florian Kugler wrote an excellent article in which he compares three Core Data stack configurations. In the article, Florian tests how each Core Data stack performs when the application imports a large data set in the background. The results were surprising, to say the least.
The Core Data stack Apple and several Core Data experts recommend performed terrible. I was surprised by the results and so was Florian. In the article, Florian investigates the test results and unravels why a Core Data stack with a parent-child configuration doesn’t handle large background imports very well. It is a very good read if you are interested in Core Data performance.
To resolve the issue, Florian didn’t go looking for the silver bullet in the Core Data programming guide. There is no silver bullet. There are best practices and there are guidelines, but not every problem can be solved with a clear-cut recipe.
Investigate and Test
Yesterday, I came across an article of Sam Soffes about improving application performance with the help of Instruments, one of the most underused developer tools. In the article, Sam describes how he spent an afternoon investigating three performance issues in an application he was working on.
As with many performance issues, the bottlenecks were unexpected. One issue, for example, was caused by a date parser that parsed ISO 8601 dates. He only discovered this issue by profiling the application’s performance. Sam tested, investigated, and improved the application’s code base. He didn’t follow a recipe and he certainly didn’t search for a silver bullet to solve his performance problems.
Stop Looking for the Silver Bullet
If you are new to a framework or library, it can be frustrating or even scary to know that you are on your own to fix performance issues or other issues that are specific to your application. But that is the reality of software development.
It is true that you may be using the framework or library incorrectly. That is actually a common cause of bugs and performance problems. But if your project gains in complexity, you are often on your own. You can learn from other developers that have faced similar issues, but it is important to stop looking for the silver bullet that you may think you can find somewhere.
Instead, profile your application, investigate the results, and try to improve performance problems or fix that hard to find memory leak. That is how you grow as a developer. Being afraid of exploring uncharted waters is understandable, but that doesn’t mean you shouldn’t give it a try.
