Storyboards and Their (Better) Alternatives


It seems that in almost every iOS project, one of the first questions developers ask themselves is:

Should we use storyboards, XIBs or write the whole UI in code?

It’s always hard to answer it because preferences tend to vary even among members of the most closely-knit teams. However, enforcing a consistent approach to the way UI flow is handled within an app almost always results in higher quality of the project.

Every decision of this magnitude requires the team to take a closer look at the pros and cons (or tradeoffs 🙅) of all available solutions. This article discusses the majority of the known (and popular) ways of dealing with UI flow management to help you choose the one that fits your or your team’s goals the best.

Continue Reading

Our Farewell to an Eventful 2015

Our Farewell to an Eventful 2015 The beginning of the year is always a good moment to look back and get a new, fresh perspective on things past. 2015 was truly a great year for designers and developers, and with widespread adoption of collaborative software like InVision and Slack, more amazing products got shipped faster and in a more effective manner. Looking forward to all the things that 2016 has in store for us, we prepared a short list of events that had the most profound impact on the industry in 2015:

Continue Reading

Automate Testing & Build Delivery with fastlane and Travis CI

Cover Image

Continuous Integration (CI) and Continuous Delivery (CD) are both relatively fresh practices in our, iOS developers’ that is, toolkits. This is mostly because we didn’t really have good tools to facilitate their proper deployment until recently. Gone are the days of breaking the build or tests without even noticing. Forget about archiving and sending builds manually to your testers or clients. Build servers are here to save us from the mundane toil.

The process of setting up our build server will consist of two steps:

  1. Continuous Integration: First, we’ll set up Travis CI to run our test suite on each pull request. This will allow us to be sure that neither a build nor tests will break after merging with the main branch (develop in our case). One cool thing here: Travis CI doesn’t actually use the branch a pull request is based on. Instead, it merges it with develop first and then uses this temporary branch.
  2. Continuous Delivery: Then, we’ll set up Travis CI to build, archive, and push a build to HockeyApp after each commit is pushed to (or merged to) develop. This will allow all interested parties to always be able to get the latest build of the app. We’ll also show how to set up the same capability on our local machine.

The knowledge collected and presented in this article is derived from other sources available online. Given some of the most common reactions 👏 in our team after one of us manages to set up CI & CD, I came to the conclusion that there’s real value in getting every little detail about their deployment covered in a single piece.

We’re going to use GitHub, fastlane, Travis CI, and HockeyApp, as that’s what we use in most cases here at Macoscope. A sample project with the history (mostly) matching the one described in this article is available on GitHub: ContinuousIntegrationExample.

Continue Reading

Improving Notification Center

A couple of weeks ago, in his How Not to Crash series, Brent Simmons wrote in detail about common issues related to using NSNotificationCenter. The piece clearly demonstrated how much busy work rests on our shoulders and how hard it is to get everything right.

Continue Reading