Skip to content

Apps Dissected Posts

Making your circular views circular in Interface Builder

A really common thing to do in iOS interfaces is make interface elements either circular or into a squircle (squircular?). This is a common thing to do when displaying user avatars, for example.

If you’re building your interface in a storyboard, though, you’ll find one big problem when you add the code to make your view circular: Your storyboard doesn’t look like your app.

Ugly. This just won’t do.

Luckily, there is a really simple way to make your storyboard controls match your app controls.

You can go home again — Using unwind segues to navigate back to previous screens

If you are doing all of your app navigation in storyboards, one of the advantages you have surely discovered is that it’s a great way to specify all of the navigation for your app with minimal code. You may run into this catch, though: specifying a segue for forward navigation is straightforward, but what if you want to specify a segue to dismiss a screen, such as the simple case of tapping a Done button to dismiss a modal screen? Suddenly the answer isn’t quite so obvious.

If you search for this on the web, you get all sorts of proposals, from pretty close to just plain wrong:

  • Make a regular segue
    • This solution is clearly wrong, because you want to remove view controllers from the stack when you dismiss, not add to them
  • Dismiss the controller yourself in code
    • We’re using storyboards to get our navigation out of code, this defeats our purpose
  • Write a custom segue to dismiss your view controller
    • This is closer, but is inflexible and makes reuse of your view controllers more difficult as we’ll touch on later

The correct solution for flexible navigation backwards in your storyboards is what is called an unwind segue. The functionality is a little more hidden in Interface Builder than the regular segue — let’s talk about how they work, and how to find and use them in Interface Builder.

Slow, laggy Xcode? Maybe it’s not (just) Xcode…

When you’re developing for iOS, there is pretty much no other game in town other than Xcode. And if you’ve needed to use it for any period of time, you know: it’s a memory hog. Not just Xcode, but the iOS simulator, Interface Builder, debugger… You can easily use several GB of memory with just the iOS development tools alone. If you have 8GB of RAM (or 4GB… 😱), it’s enough to bring Xcode to its knees, and your blood pressure to a boil. When your code completion starts lagging to the point you can’t type… 🤬

It’s 2019. Shouldn’t your machine be thinking faster than you?

But your problem may be more than just Xcode. You may want to look at what else is running on your machine to see if you need to put it on a RAM diet.

Keep your debug toolkit handy but hidden using conditional compilation

When you’ve been working on an app for a while, especially as it gets large, you often start to include snippets of code in the app that have been useful for debugging your app in the past. Such debugging code may be as simple as log statements, to as complex as adding full screens to your interface, activated by controls that you add to your interface for debugging only.

Such tools become an integral part of your debugging environment; you don’t want to throw them out. But do you really want to ship those in your app? It makes your app bigger and slower. You could comment them out before you release, but after a marathon debug session, do you trust that you’ll comment out again all of the debugging tools you enabled?

How can I keep my debugging addons, but ensure they aren’t in the version I deploy to the App Store?

There is a way: you can use a feature of Swift called conditional compilation to enable debugging code on your debug build. If you still have Objective-C code, you’re still in luck: a similar feature called preprocessor macros can provide the same functionality.

I’ve done the courses, tutorials, videos. Where do I go from here to get hired?

You’ve been learning iOS development for months now. You been taking courses, like the Stanford iOS development course, or Angela Yu’s courses on Udemy. You’ve watched YouTube channels like Let’s Build That App. You’ve checked out random tutorials on the web from Medium, or you’ve bought some books from Ray Wenderlich (or even sprung for the full video subscription).

And still you’re frustrated… It doesn’t feel like I’m progressing anymore.

At some point, you realize that all of these resources only take you so far, and that you need something more.

What is the next step between learning, and getting hired?

There are several paths from there, but one easy way you can make yourself stand out is to make a “clone app:” an app that replicates the functionality of an existing, well-known app. Let’s talk about the many benefits of doing that.