There’s a lot of MD5 iOS solutions floating around out there. From the ones I’ve seen, they all have a common problem. They all assume you want to MD5 an NSData instance, meaning all of the data must be in memory in order to digest it.
Now this will work in most cases, but say you want to MD5 a 1 gigabyte file… on an iPhone. You’re probably going to have a few problems.
I’ve always been interested in app file size and the overall app’s performance. When dealing with images, these sometimes go hand in hand…
Whenever you have a couple of apps that are extremely similar, it will make sense to share the code between the two. For example, a Lite version and a Paid version of the same app, or the same app skinned differently for different clients. At first you might be tempted in duplicating the project. Don’t. If the code splits then it’s going to be a nightmare copying changes between two places, or even just having them in two separate projects.
When coding, personal notes are a good way to make sure you don’t forget anything, and keep track of certain things. I often see people making notes either physically or in a document, however there is a better solution…
Automatic Reference Counting (ARC) has been around since iOS 5, however it has been an optional tick box when beginning a new project, and if not selected, Manual Reference Counting (MRC) is used. As of Xcode 5, the ARC tick box is missing, and all new projects start with ARC. While you can still disable ARC manually in the project's config file, this is probably a good sign that ARC is the way to go for new projects.
When you send a build to your client or testers, it can be difficult telling development builds from AppStore builds. At b2cloud we split the builds with two different app ids, and a different app title to make it easy to tell them apart. Because the app id is different it means you can have both builds on your device at the same time, and the development one wont overwrite the AppStore one, and vice versa.
Unit Tests are a good way to ensure things don’t break while coding. In Xcode by default they are run manually. Because it’s manual you may forget to run them, or a new person to the project may not know about them. You can set Xcode up to run them automatically every time you build your app, which ensures nothing will go unnoticed.
Here’s how to do that.
If you started an Xcode project a long time ago or just didn’t tick the “Include Unit Tests” box when creating your project, it may be a bit confusing how to get them in. Not to fear, I will show you how.
A while back a couple of our devs were having some problems syncing to the git. It seemed everything but their Xcode projects would sync up. I looked into it, and while it took a bit to solve the problem I finally figured out what the issue was.
The solution was quite buried, so hopefully this post helps at least one other person out there.
There have been a few very rare scenarios where I have actually required a dynamic header in a project. I mention Xcode in the title however this technique really applies to nearly any IDE or command line project.