One of the longstanding criticisms of Core Data is how much code it takes to setup the infamous Core Data stack in your iOS or macOS app just so that you can create some instances of entities and save them to a persistent store. The frustration has spawned a number of blog posts outlining the latest, greatest way to setup your stack. Not long after the blog posts came the open source projects aimed at reducing the amount of boilerplate you’ve got to write and helping you avoid common mistakes.
With the release of iOS 10 and macOS 10.12 in many cases you can now forget about the blog posts and third party dependencies thanks to NSPersistentContainer. This one is a no-brainer and it would have been nice if Apple had included it back in the days of iOS 3.0 when they introduced Core Data.
In iOS 9 and macOS 10.11 Apple introduced the libcompression APIs to provide a more standard way of compressing and decompressing data in your apps while offering a selection of algorithms with tradeoffs between compression efficiency, time, and energy requirements. In the past I’ve used third party APIs to compress or decompress ZIP archives given the popularity of the format, but hadn’t considered using other algorithms to either benefit from better compression or energy efficiency. Given that, I decided to take a look at the algorithms offered by libcompression and see how they compare.
When developing for macOS, iOS, tvOS, or watchOS to get the best performance or provide a secure solution you often need to develop apps that run asynchronously using tools such as XPC, GCD, and NSOperationQueue. Debugging this type of code can be difficult, especially when data is being passed between queues, threads, or processes.
Logging is an age old technique to help in these situations, but it’s easy to be overwhelmed by the amount of log data and to introduce or mask problems because of the observer effect — the overhead associated with many logging frameworks. I know logging isn’t exactly going to steal the headlines away from Siri integration or watchOS 3, but as a developer it’s a valuable debugging tool and the changes in these APIs look to save some significant time while debugging crashes and squashing bugs.
With the release of the iPhone SE and the iPad Pro, along with the expectation that iPad apps will include support for slide over and split screen mode it’s now clear that Auto Layout is here to stay. If you’re not already developing apps using Auto Layout and Size Classes now is a great time to learn more about them and prepare yourself for any updates to the APIs that Apple introduces at WWDC in June.
Fortunately there’s a lot of great resources to quickly get up to speed and learn the best way to support a variety of devices and size classes in your next app.