We are always looking for ways to be more efficient in the way we create new applications.
Faster development speeds can allow us to have more iterations, to spend our time bringing even more polish to our apps. Let’s look at ways to improve the biggest bottleneck for iteration speed, the Development Life Cycle.
Development life cycle
Simplified development life-cycle could be expressed as follows:
Code → Compile → Deploy → Test → Repeat
This can work fine while we are developing most features or business logic, but what happens if you are working on UI/Graphics/Physics?
Working on these topics requires immediate feedback. We often need to change a few variables and see how that influences our designs or physics. This means changing a few lines or even a few chars and recompiling the project. Tweaking usually requires quite a lot of iterations which means we spend most of our time in the Compile -> Develop -> Test phase.
How could we speed up those iterations ?
We can divide possible solutions into 3 categories:
- Faster compile process by tweaking compilation
- DWARF without dSYM file for debug builds
- dSYM generation is unnecesary for debug builds since the compiler already has access to all symbols while debugging, dSYMs are only useful for release builds
- Forwarding class declarations in headers instead of importing classes will significantly remove the amount of code needed to compile every time
- Using frameworks is designed to be more optimal than including their headers, plus you won’t need to manual add them to your project
- Your development machine should preferably have 16GB RAM and an SSD, but you can go even faster by leveraging RamDisk’s for your iPhone simulator and Xcode derived data folder. I recommend using iRamDisk which already has a template for Xcode.
- This is probably the biggest improvement you can do. You can recompile just one class and replace its implementation without touching the rest of your project. This will be a massive improvement.
Waiting for compilation/ re-deployment is even more visible in bigger projects, not only is it a big waste of your time but it can also lead to procrastination.
Fortunately for us, the Objective-C runtime mechanism allows us to reap benefits from code injection. There are two main tools that allow us to use code injection on iOS projects. They both work in Xcode and AppCode.
Let’s look at available tools:
Injection for Xcode was the first tool I’ve used when I started using code injection on iOS projects. On top of normal code injection, it allows you to expose some remote variables that can be accessed from your code.
- Remote variables
- Works on device
- Requires project code pathing
- Slower than dyci
2. Dynamic Code Injection tool (DyCI)
Someone told me about DyCI after my talk at MCE, I’ve been using it ever since and I’ve been loving it.
- No need to modify your code
- You can react to code recompilation by implementing a single method–very useful since we often need to reload views
- Very fast
- Works by modifying your clang compiler, requires reinstall on xcode updates
- Doesn’t work on device
Code injection is a great thing to have in your daily toolbox. If you’ve never had a chance to play with it, you really should. I’m sure it will save you dozens of hours and improve your productivity.