iOS Helper

Have you ever wanted to use the exact same codebase for both a free version and a paid version of your iOS app? Does your client have both a development and a production server that the same code needs to talk to? Do you need to create an internal ad-hoc build of your app for testers on your team? If you have ever answered “yes” to any of these questions, it sounds like you need a custom build scheme. I wish I had discovered the awesomeness that is the Xcode build scheme sooner. As a developer, they give you the ability to deliver different versions of the same code with small tweaks for different environments. Once you learn how to use them, you will love them too. With custom build schemes, you can Write code that only runs on the free version of your app, allowing you to show ads or offer in-app purchases without duplicating targets or project files. Flick a switch to deliver a build that talks to the production server after testing your app in a development environme...

Swift 3 brought a tsunami of changes to the language as well as our codebase, some of you reading this may even still be battling with the migration too. But even with all these changes, we’re still left with some APIs within Foundation that are  stringly typed , which is totally fine… Until it’s not. It’s kind of a love/hate relationship in that we love the flexability that strings within APIs afford us, but we hate that we have to use them because of the inherit consequences they bring if we’re not careful, they’re pretty much the programming equivalent of running with scissors. We’re given stringly typed APIs because the Foundation framework engineering gods could not predetermine exactly how we intend to use them. So in all their wisdom, power and knowledge, they decided to use strings in some of the APIs because of the unlimited possibilities it creates for us as developers. It’s either that or some type of dark arcane magic. UserDefaults Our topic for today is going...