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.
Pixel density is the number of pixels per linear physical unit. Measured in pixels per inch (ppi or dpi). Pixel density and resolution are technically the same thing, but often people say “resolution” to mean “pixel count,” a related metric:
count = densityH * width * densityV * height
When other things are held constant:
What are beacons?
a) A tiny piece of plastic.
b) A low energy bluetooth device.
c) An emerging technology with numerous applications.
d) All of the above.
If you guessed all of the above, you would be correct! Beacons are an IoT technology that is deceptively simple and small but packs a potentially large punch for app developers looking for new and interesting ways to engage their customers.
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.
For the past year, I’ve been working mainly with AngularJS and before that Ruby on Rails. I’ve never heard of Meteor until a few weeks ago. I am intrigued by the idea of tightly connecting the client and server together in a synergistic manner that allows for fast responsiveness, which is what Meteor is all about. I decided to go through Meteor’s tutorial online and get a feel for why the framework differentiates itself from other current technologies. From a very high level perspective, Meteor is a very good solution for quickly building an application from the ground up and provides some cool features out of the box.