What’s your favorite chocolate chip cookie recipe? I bet you could ask that question to 5 different people and get 5 totally different recipes… brown sugar vs white sugar, cake flour vs all purpose, dark chocolate vs milk chocolate. All of these recipes result in a chocolate chip cookie but the process by which we get there is a matter of personal preference. If you were to ask multiple developers to solve a problem, it’s doubtful that any two developers write identical code. It’s not that any one solution is necessarily better than the others… the resulting code is likely just a matter of personal preference.
Overstuffed View Controllers: a problem that is universally despised by iOS developers the world over. Who hasn’t had their eyes glaze over while staring down debugging a 3000 line VC? View Controllers can control so much information, and Apple seems to have very few opinions on where specific logic should go. They give us the decision making power. How can we prevent against this annoying problem and modularize our apps better? Model–View–View Model (MVVM) can certainly help with this, but ultimately leaves routing to View Controllers, which doesn’t make the most sense. This is where a Coordinator comes in.
There are a lot of APIs out there, a lot of networking layers, a lot of abstractions, I’m going to offer just one way to start building Swift models backed by a RESTful API. Out of personal preference, PromiseKit will be used instead of callbacks and ObjectMapper will be used to convert between JSON and Swift objects.
Working as developers, we are focused on the low level technical details of a product, being that a website or an app. This heads down approach often makes us not to pay attention to many high level details that are crucial to bring our product to success. The typical path for a developer, at least at the beginning, is to build an app, put it on the store and then see it fail miserably. If that has happened to your app, then this post is for you!
On September 9th, 2014, Tim Cook announced the Apple Watch. This wearable smartwatch quickly gained the loyalty of millions. The wearable was developed in part to incorporate fitness tracking and allow for health tracking, but more-so to free users from their phones. It includes a digital crown used to scroll and zoom, and a touchscreen with Force Touch technology. An extra button under the digital crown serves favorite contacts and access to Apple Pay.
Developing custom views for your iOS project and want to visualize your updates immediately? Just want to configure some properties directly in Interface Builder? Check out IBInspectable and IBDesignable.
With the acquisition of Next in 1997, a new tool was initiated into the Apple family. Originally known as an enhancement of OpenStep, called NextStep, it caught the attention of the developer community under the name of Interface Builder, as part of the XCode suite. Now about to celebrate its 20th birthday, Interface Builder represents the most powerful IDE to design user interfaces in a development suite. It doesn’t matter if you are writing an app for iOS, Cocoa, tvOS or watchOS; when carefully used, it will save you hundreds of lines of code. For this and other innumerable reasons, many developers, like myself, love this tool.
On a recent project I was tasked with creating a private CocoaPod to be used by several internal iOS applications. As I did my research to do this, I found that the information was spread across several sites and not 100% clear (the CocoaPods site’s documentation could use some love in places). I am taking this opportunity to assist those that follow to create, organize, test and distribute a private Pod. I’ll also throw in a few tips for general pod development.
One of the main reasons for having coding standards is to keep your code readable by everyone. By enforcing standards and formatting, the code base becomes consistent, and anyone can easily understand the structure of the code because he will be more familiar with what to expect. It is also very useful when a new developer joins the team because once he is familiar with the patterns, he will be able to easily read the existing code, which results in a more pleasant experience.
At the lastest Apple WWDC conference, Apple decided to suprise it’s developers with introducing a brand new language called Swift which will be used going forward in development all Mac and iOS applications. The good news for all Apple developers is that it is totally integratable with all existing Objective-C code. Another great positive for developers is that it also runs on the current version of iOS, iOS-7. Developers will still need to wait for Xcode-6 to come out of Beta before they can submit full Swift apps, but they will not require everyone to be running the latest iOS.