Overall, Swift is an awesome bicycle for your mind, except for one thing. It is a compiled language, which means that you need to produce a product or binary to get your code to run.

On the other hand, unix shells like bash, zsh, fish & sh; can run scripts. This can be incredibly powerful because you don’t need to compile, you simply run and it runs for you. Scripts built with any of the mentioned Unix-shells can help you manipulate, customize and automate parts of your workflow which can be a huge timesaver for mundane tasks.

But there are some caveats, you typically need to context switch because it seldom involves the same language that you usually write code in.

I’ve lost count of how many times I’ve had to google: “How to write an if statement in bash”.

Wouldn’t it be great if we could combine the two and leverage Swift’s awesome type system and roaring syntax to write our automations without the need to produce a product?

Just write and run.

It just so happens that this comes baked in using Swift REPL.

So what would scripting with Swift look like?

The first thing we should do is to set up a super simple Swift package.

Sounds like a lot of work, but I assure you, it’s not. We do this to get help from the compiler when we write our script, if we simply open the file using Xcode, it won’t pick up warnings and errors like we are used to.

> mkdir ScriptingWithSwift
> cd ScriptingWithSwift
> touch Package.swift
> touch main.swift

In Package.swift, we can create a barebones package called HelloWorld.

We set the platform to be .macOS and decide which version we wish to be backwards compatible with. To be able to run script inside Xcode, we add an executable target with the same name as the package. We set the path to be an empty string so that it searches for swift files in the root folder.

Let’s do the same for main.swift and keep that super simple for now.

So open the file and add:

Now open the Package.swift with Xcode and run the terminal application.

Before we try to run the script in the terminal, there is one little modification we need to do. We need to give the file an executable attribute.

> chmod +x main.swift

Easy peasy lemon squeezy, now let’s run the script.

> ./main.swift
Hello, world!

Alternativly, you can run it via the swift binary by typing:

swift main.swift
Hello, world!

And voila, now it is off to the races.

If we wanted to, we can execute this script using the built-in app Shortcuts.

• Open Shortcuts and create a new shortcut.
• Choose Terminal as the command.
• Copy-paste the exact path to your script and click run.

This is where I leave you, but before we do, let’s summarize what we have done and end with some inspiration.

To summarise what we have done:

• We leverage Swift Package Manager to get a sane environment to write our scripts in, which is backed by the all-mighty Swift compiler, right there at your fingertips.
• We made the script executable from the Terminal or any other application or service that can run scripts
• Added our freshly brewed script to Shortcuts so that we can have instant access to it and run it at our leisure

So, what can we do with Swift scripting?

Well, it just so happens that with the release of Swift 5.7, you now gain the full force of structured concurrency at the top level which makes it ridiculously easy to fetch information from an API and manipulate the data before processing or presenting it somewhere else.

We can run apple scripts to control UI on macOS or even run other shell scripts or unix commands.

I’ve used it to tweak features in Ventura by changing settings in Stage Manager with the push of a key. You can find more info about that here:

• GitHub - zenangst/HideDockAndStageManager
• GitHub - zenangst/StageManagerAppWindowGroupingBehavior

The possibilities are endless.

If you made it to the end and still feel like you came up empty-handed.
Here is a picture of an adorable kitten.

Scripting with Swift was originally published in Fink Oslo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ahoy fellow buccaneers! You might have been in this game a long while or you might just be starting out, whichever rings true, I think we can agree that the following statement is universally true for mobile applications:

I reckon we can all agree that navigation be a cornerstone o’ any application. We often loot it fer granted ‘n don’t really try t’ scale it ’til th’ needs occurs which often comes as a curveball ‘n gives us wee time t’ iterate or optimize.

I think that is quite enough pirate speak for one blog post 🏴‍☠️
What I intended to say was:

I think we can all agree that navigation is a cornerstone of any application. We often take it for granted and don’t try to scale it until the need occurs, which often comes as a curveball and gives us little time to iterate or optimize.

What if we took a different approach to navigation and thought about it as a feature rather than a system-provided action. This article is not meant to force you into a direction, the following will show abstract implementations written in Swift and is meant as inspiration rather than forcing your hand. Keep in mind that new technologies like SwiftUI will flip the table, with that said there are still lessons to be learned here even if you are bleeding edge.

Don’t let the Swift language throw you off, the things we are going to go through here can be applied to other platforms with the help of your imagination.

What this means is that if the examples contain any holes, it is up to you to fill them in based on your current requirements, constraints, and needs. However, we will try to add some inspirational new features that you might not have thought about earlier that can open new doors when it comes to developing your application.

We can start by making a small list of criteria and requirements for making the feature successful both for our users and ourselves.

Mission statement aka pirate manifesto

• Should be type-safe
• Decouple and create clear boundaries between features
• Benefit the users and the developers
• Increase re-writability of our application

What makes navigation type-safe and why is it important? Well, if we play our cards right, this should add clarity to our navigation stack as both new and old developers should be able to figure out how UserA got from A to Z.

And what about decoupling, why is that relevant? Imagine having a ship with the bolts wedged together, it will make it unnecessarily hard to make repairs. The same goes for your application, with clear boundaries, it will be easier to repair or refactor (whichever word floats your boat).

The last two points are more side-effects and we will get to those later in this article. If things still sound vague, don’t worry, let’s get the show on the road so that we gain more clarity.

Destination

Let us start with a very basic model, we will start with making an enum and giving it a proper name. When we navigate the seven seas, we want to be able to put an X on the map to illustrate where we are going, however, X doesn’t make for a very descriptive model name so lets instead go with Destination. Yeah, I think that will do nicely. So our barebones model will look something like this.

Tidy. Now let us plot some X:es into our application.

But before we do that, let us take a quick step back and think about why an enum would be an appropriate choice instead of a regular struct or class. Enums are bound to a finite set of cases which would translate perfectly to our applications navigation stack as it is also finite. Enums are also super easy to extend by simply adding more cases to them. In addition, at least for the case of Swift, we can add one or more associated values to each case. This is super useful if we need to pass information from one place to another.

From a developer perspective, when using a decent editor, we will get code completion for all available cases which are both great for discoverability and overall developer happiness.

Last but not least, when we intend to use the enum, we do get the option to either unwrap the current value using an if statement but the preferred way would be to simply switch over the enum to cover all the cases for our current use case (pun intended). So if we leave one case unfulfilled, it will result in a compiler error rather than a runtime crash.

Can you smell that? That is the delicious fragrance of type-safety that we aim for, let us keep cooking!

This would tick off at least three (if not all) boxes in our mission statement.

To make this a bit less abstract and more fun, imagine that the application that we are building is a Pirate trading app, let’s call it Pirate Bay.

The user… err I mean… the scoundrel (or scruffy-looking nerf herder for all our space pirates out there) should be able to do the following:

• Have a home screen, a place to collect their thoughts and get an overall overview of current trades, etc.
• Scout the marketplace for treasures
• Look at individual items
• Check sellers and buyers profiles
• Manage their profile
• A login page
• A log out action
• Download user information
• And last but not least, a way to opt-out from the service

(Even if we are pirates, we need to align ourselves with GDPR to avoid walking the plank)

So let us take a look at what that might look like by extending our Destination enum.

That looks pretty neat.

By glancing at the enum, we get a sense of the size of our application. And if we are completely foreign and this is the first time we open the project, we can even read out the purpose of the app, all without adding a single comment to our very bare-bones implementation. Now that is some self-documenting piece of treasure right there.

But there is one thing that breaks the type-safety, can you spot it? Take a second before you continue, what could potentially go wrong here?

Both the item and profile case take raw String as its associated type, this could potentially lead to situations that we don’t want. Take for example if we try to navigate to an item using a profile identifier, this really shouldn’t happen, but with the current implementation, it could. Even if that would be highly unusual.

I’ve jinxed myself far too many times by uttering the following words: “That would never happen”.

So before we continue, let us quickly look at how that could potentially be fixed by taking our type safety to the next level and earning ourselves the pirates badge of honor.

The fix isn’t that hard to apply, we simply need to wrap our string-based navigation in another value type that is unique to that case (this might be a tad unique to Swift, but bear with us).

So instead of using String, let us introduce our value types, one for each case.

Here are some appropriate new types for our pirate application:

With the new types in place, let’s update our enum.

If we want to extend this even further, both Loot & Pirate could be protocols, that way our cases could tackle polymorphism without growing out of proportion and eventually becoming a Kraken.

Now that we know where we are going, we need someone to take us there. This brings us to the next piece of the puzzle.

Navigator

Every good ship needs a good captain

As many of you already know, vanilla navigation is done by either presenting on top of a view controller or relying on UINavigationController being the parent of your view controller.

Let’s take this vanilla example where we have a list of pirates and when you tap a pirate entry, you should display the details for the selected pirate. It might look something like this:

This works fine, however, remember rule number two in the pirate manifesto:

You don’t talk about pirate club, ops! … wrong franchise, I meant: Decouple and create clear boundaries between features, savvy?

As seen in the example, ListViewController needs to know about DetailViewController and its requirements. At first glance, this might not feel like a huge deal, the example isn’t a lot of code, but trust me land crab, the seas can be stormy and unfriendly. So when your application grows, and it will, you can quickly find yourself running out of ink while drawing your map. Making it feel hopeless to untangle, refactor, redraw or provide additional routes. Almost like working with something that is edged in stone, and we don’t want that.

So for our pirate application, we need the best of the best. We need the Navigator!

It doesn’t look like much yet so let’s fill in some blanks. As mentioned, the way to perform navigation is by using UINavigationController, so we will need one of those aboard our ship. However, we don’t need to expose that in our public API, the features shouldn’t really care as this is an implementation detail for our top dog class but alas one is needed.

Now that we have an opportunity to provide a solid public API for our app’s cornerstone, let’s make it easy enough that we can still reason about it even after a night of grog and looting.

We now have a super-easy way of handling navigation for our list and detail example, but before we move on, Let’s just take that example and apply our Navigator to it.

This example didn’t save us a lot of lines of code, but that is also not the point. What we did gain from this approach is that ListViewController no longer knows about DetailViewController without losing the ability to perform navigational tasks. In addition, just by reading the instance variable definition of the class, we can see without looking at any function bodies that this class can perform navigational tasks. This is highly underrated and the benefits become clearer as your code grows but the clarity of the controller will remain. The same might not be as true for the vanilla example that lacks the reference.

As for increased refactor-ability (if that is even a word), we could refactor the DetailViewController in isolation, without having to change anything in our ListViewController, as long as the contract between the view controller and use of Destination stays intact.

So far we have checked off the following criteria:

Type-safety
Leveraging from enum with associated value types, we can ensure that both ends uphold a contract when handing off information between controllers. It also defines a finite set of destinations that paints a beautiful map of our application.

Decouple and create clear boundaries

Adding the Navigator into the mix and giving it full control over what to present and where, offloads any excess knowledge that the controller used to have, just to get to where we were supposed to go. We can go as far as to state that navigation is a “fire-and-forget” type of deal for our controllers, which is well within the boundaries for any sea roaming scoundrel.

Increase re-writability of our application

By having clear boundaries between the cornerstone foundation and the features of the application, there is less to rewrite and fix up because we have fewer places where we create new instances of classes and structs.

Benefit the users and the developers

As developers, we gain type-safety, a more scalable foundation, something that is easier to rewrite or reroute. Everything mentioned should ultimately lead to a better application where there is more time to focus on the details.

This is all great, but I think that we can do better, don’t you?

For the users

Let’s revisit our previous implementations to see if we can’t take this to the next pirate-level.

All good things are three, so lets focus on the following things when trying to improve our already awesome application.

• State restoration
• Deep linking
• Improved crash reports

State restoration

One feature that can set an application apart is the use of state restoration. So when the application is manually closed by the user or forced quit by the system, the previous application state can be obtained and restored when the application is launched again.

In order to do this, we need something that can represent the bread-crumbs of the navigation steps that we can perform throughout the application. Luckily for us, we have Destination that holds their own unique value and can be translated into a navigation action. There are multiple ways to skin a ferret but the sake of simplicity and not to argue one is better than the other, let’s just make this happen with the built-in Codable protocol.

Conforming with our current example is super easy, we simply add Codable to all of our current models, like this:

We now gain the ability to both encode and decode individual or collections of Destination’s.

It couldn’t be easier, and we can now pick if we want to store it as Data or String. We can also decide if we want to store it in UserDefaults or directly to disk, both are valid options.

This is only the first part of the puzzel, we also need to keep a source of truth of the current navigation stack so that the application can save it at a moment’s notice. A natural place to keep this current stack is on the Navigator. Let’s modify it ever so slightly just to populate the collection of Destination’s when a navigation action is performed:

“wolde you bothe eate your cake, and have your cake?”

Easy-peasy pirate squeezy. But wait, we also need to update the current stack when the user pops view controllers of the screen. Sadly, there are no good delegate calls on UINavigationController to hook into, but fear not dear sea captain, we can leverage from inheritance which can let us have our cake and eat it too.

Now, all we need is to use this freshly brewed class and become the delegate, back to the Navigator:

A tad more code but now we route all invocations of both push and pop to our Navigator so that it is always in sync. From here on, it is up to you to find the best fit for your application on where you want to store and restore the navigation stack as your application relaunches.

“Kill two parrots with one stone”

Deep linking

Let us move on to the next bonus feature, which is deep linking. Right now, our navigator can only open one Destination at a time based on the current API. So by adding one convenience method on Navigator, we can improve the call-site implementations by providing a new function that takes a collection of Destination’s. This method may look something like this:

So if we wanted to build up the entire stack again, we can simply call it with X amount of destinations and voilá, we now have the same view hierarchy as before.

As for navigating using a URL scheme, well here you need to implement your own string parsing methods that will return the correct destination or destinations based on the URL. When those method(s) have produced the correct output, then simply pass the result into the newly created function.

Improved crash reports

Based on the state restoration and the way you implemented deep linking, we can now sprinkle a bit of extra spice into our crash reports, and provide a set of deep links that the application can interpret. If we attach these to crash reports, we get both breadcrumbs and a way navigate in the same way as the user did up until the crash occurred. This can give you great insight into what was going on before your ship got blown out of the water, and relying what happened can even help pinpoint the exact location where the first cannon ball hit the hull.

I hope this was helpful and I can’t wait to see what glorious vessels you will produce in the future.

When I was one,
I sucked my thumb,
The day I went to sea.
I climbed aboard a pirate ship
And the Captain said to me:
‘We’re going this way, that way,
Forwards
backwards,
Over the Irish Sea.
A bottle of rum to fill my tum
A Pirates’ life for me’.

Have a good one Mateys!

Seaworthy mobile applications know how to navigate was originally published in Fink Oslo on Medium, where people are continuing the conversation by highlighting and responding to this story.

One feature that iOS purists envy and the primary argument for alternative solutions to Swift is code injection or as others like to call it, hot reloading. It cuts down development significantly as you don’t need to recompile to see your changes. For developers that work closely with designers or have issues visualizing the result beforehand, it can be a game changer.

“With hot reloading, you can even run new code while retaining your application state. Give it a try — it’s a magical experience” — React Native README

Personally, this is feature is what makes React Native great. I know, there are more features that React Native (or insert any other alternative here) possesses but right now we are talking about code injection so bare with me. It opens up for being able to test different states at a glance; and with all the time it saves, you can focus on what matters, the things that set your app apart from its competitors.

So what if I told you that you could achieve hot reloading without jumping ship. A bright gentleman named John Holdsworth has made an application called Injection (not to be confused with dependency injection). The app is available for free in the Mac App Store.

InjectionIII on the Mac App Store

The application lives in the menu bar and observers whatever Xcode project you tell it to monitor. So the gist is that any file that changes will recompile and injected into your running application. What is does under the hood can feel quite magical, mainly because it is. John has done a great job of describing the process, and if you are feeling adventures, you can always jump into the source code as it is available on GitHub.

johnno1962/InjectionIII

Before we go any further, I just want to note that injection only works in the simulator, I suggest you build in the simulator and test on a device.

Playground-driven development that was made famous by the fantastic team at Kickstarter put a tremendous spin on app development. It meant that you could manipulate the state of your application without the need to rebuild and rerun it.

Each screen could have their playground so that you could quickly test and work with all states related to that screen in isolation. However, because the technique is dependent on your app being compiled as a framework, it means that you will have to recompile before you see your code changes appear. Playgrounds can be fast or slow depending on the apps sizes, my biggest concern with this approach is not the setup or the hurdles you need to jump over but rather the core stability of playground themselves.

The concept of playgrounds is excellent, being able to run and test code without the weight or overhead of a project. Sadly, it does not always deliver. If you are buying into playgrounds and using them for development, make sure you learn all the tips and tricks as you will find yourself in scenarios where you need to turn to blood magic to understand what is going on and more importantly, get it to work again.I don’t want to downplay anything that the Kickstarter team has done because they indeed have created magic. I’m not saying that Injection is superior or the defacto way here, but in my personal experience, it has always delivered why more stable results than playgrounds ever have.
Just like playgrounds, if you want to leverage for its full potential then learn how it what it does, how it works and what limits it has. I would recommend to read up on both techniques, find the one best suited to you. Perhaps combine them and create something truly magical.

There are some limitations with injection, one of them being that you cannot inject structs, extensions or final classes. Once you get past this, there is still a lot you can do to decrease your development time. For me, there are multiple entry points where injection truly shines, here are a couple of them.

The examples use Vaccine to set up injection.

To get the most out of code injection, you need be able to provide your application with a new instance of the class that you are injecting. A good point of entry for injecting code is to reinitialize your app at the application delegate level.

It increases the likely-hood of getting the desired effect of code injection as your root objects are recreated using the newly injected code. It also provides with a point of entry for displaying the target view controller(s) that you are modifying.

So what it means in practice is that you can push or present the relevant view controller directly from your application delegate cutting out the need to recreate the view controller stack by manually navigating to the view controller you are editing. Working with InjectionIII is very similar to how playground-driven works, without having to wait for the playground to load or recompile your app as a framework.

The devil is in the details and for every second saved, you get additional time to apply polish.

When applying injection to this app layer, you are free to change the bounds of the window which means that you can set the bounds to be a different device size. This opens up for testing multiple devices using the same simulator. Kickstarter has done a lot of great innovation in this area, so I suggest you head over and take a peek at what they did.

There is no secret that the majority of the work that we do usually end up in a view controller. That is probably the main reason for us often ending up with massive view controllers, but that is an unrelated topic.

The good thing with about view controllers is that you can quickly create a system around them because of the view lifecycle it inherits. Most of the set up for our view controllers happen in viewDidLoad. Because of this reason, we can do some preprocesses to clean up before we invoke the method again. What this means is that we can change our set up instructions and invoke them again and see the new behavior appear on the screen.

Working with views is relatively similar to view controllers, except that they don’t inherit the view lifecycle as view controller does.

So here we need to do some additional work to introduce a streamline. When doing vanilla programming you do a lot of work in the initializer, the issue here is that you can’t invoke the initializer again as it will only run once for the lifetime of a view.

The most straightforward fix is to create a method that is invoked directly inside of the initializer. The same method is then used as the responder for the injection notification. When wired correctly, we can change the code inside our view’s load method and set the changes reflected on the screen.

Because we don’t always create new instances of our views, we could end up in a scenario where we add additional constraints that will render the views layout constraints ambiguous.

The reason is that we add constraints that are conflicting or duplicated which the layout engine cannot figure out how to make satisfiable.

Fixing it does not take a lot of effort, you need to do your book-keeping by storing your views constraints in an array. When the load view method runs, we need to deactivate or remove the previous layout constraints before we add the new ones.

Take a look at the view example for details on how this could be implemented.
If you add new constraints on line 22, activate them and later store them in the layoutConstraints array, this should help to fix any ambiguous constraint warnings from occuring.

Making great animation sequences relies heavily on fine-tuning. What sets a great and tailored animation apart from using a regular UIView animation block is usually the fact that more love is put into having great timing.

You can learn a lot of tips and tricks on what generally looks good, but there is no one-size fits all if you want to stand out. You need to iterate to make the animation fit with the apps tone of voice.

When applying injection with animations, it helps to think about your code like an orchestra. Set the stage and use your injection point, the method that will be called when the file is injected to both reset the stage, cleaning up previous animations and applying new ones and watch your orchestra play your masterpiece. That way you can sit together with your fellow designers and together decide what looks and ultimately feels right.

You can also reset your animations by injecting your view controller.

Code injection can easily be applied to your data sources. Just like all your other objects, you need to listen to incoming notifications and reload with the same data that you already have when one arrives.

The easiest way is to call reloadData on your collection view or table view, that will invoke your cellForItemAt indexPath: IndexPath method and configure your cell with the newly injected code.

Debugging or live patching

Logic should be unit tested, and I can’t stress that enough. But there are situations where you quickly want to check the rendering of a state to see what happens if x is equal to y and not z and vice-versa. Layout algorithms can also be a lot easier to reason with using live results rather than simple unit testing, depending on what kind of person you are.

As a developer, it is your job to create an environment where you and your fellow designers can work together. The set up will define how rapidly you allow your team to move.

Minimizing the number of times, you need to recompile your app you open up for more fine-grained tuning of things like; animation timings, tweaking fonts, colors, line-heights or changing layout constraints. Anything that you or your designer friends want to iterate over.

Competitive advantage

Thinking outside the box and continuously improving your tools and best practices can give you a competitive advantage. Having great tools can also work as a stress reliever as repetitive or mundane tasks are more easily handled, it opens up for collaboration and fast iteration which will have a positive effect on the end product. The devil is in the details and for every second saved, you get additional time to apply polish.

Because injection works using notifications, there is some additional setup needed to get the desired output that you want.

To make things easier, I created a series of templates that have injection already enabled. Using templates can help you streamline the way you build views, controllers, models, etc. Templates are great for more than just adding injection

I strongly encourage creating your templates and incorporating them into your workflow.

zenangst/Xcode-Templates

I’ve been working a lot with injection over the years, and it has become an essential part of my workflow. So crucial in fact that I’ve invested time into making a framework to provide more natural way to implement injection in new or existing projects.

Seeing as there are different ways to use injection depending on which component you inject, different rules should apply.

Vaccine provides an easy way to load the injection bundle in your application delegate, has view controller extensions for recreating the view controllers hierarchy and necessary sugars on top of NSObject.
The framework does its best to cover all the areas mentioned above in a lean and straightforward way yet keeping it maintainable.

Vaccine is available via CocoaPods; you can find the repository here:

zenangst/Vaccine

Maybe injection is not for you, but you don’t know that unless you tried. If you find any neat ways of implementing this, be sure to hit me up on Twitter (@zenangst) as I’m super passionate about the subject. Also be sure to give a shoutout to John Holdsworth (@Injection4Xcode) as this wouldn’t even have been possible without his genius mind and all the hard work he has poured into the tool.

I want to end this article with a twitter quote from John Holdsworth himself.

Injection for Xcode on Twitter

Still not "Hot Reloading" #swiftlang in your #Xcode projects? You're running out of excuses.. InjectionIII is now available in the Mac App Store 😎 https://t.co/3bvr9fXgSp

Thanks for reading!

Code Injection In Swift was originally published in itch design on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we talk about security about iOS application, we usually think about things like SSL certificates, storing information securely in the keychain, etc.
This is all good, and it is super great that we have such a wide focus on these days. However, there is one small culprit that a lot of app makers seem to overlook, and I don’t blame them.

I’m talking about the multitasking feature that is built-in to the operating system. So what makes it a culprit? Well basically, if the user decides to leave your application, the operating system will take a snapshot of the current view controllers current state and save it as the placeholder for your application. But what if the screen that you just left has some personal information about you that you don’t want to leave the application. Maybe you’re using a bank application, and a colleague or friend borrows your phone, she or he will be able to read parts of the information that you last look at using that app. It might sound like I’m over exaggerating or making an issue out of a non-issue. Maybe, maybe not. All I know is that if I use an application that stores personal or sensitive information, I’d want it to stay within the application and not leak in any way, shape or form.

So, this is what we did to dash a bit of extra added security to our application.
Because we didn’t know exactly which screen should be secure or which would be fine to show, we took the path which tried to secure the entire application. Here is what we did.

When building iOS applications, you need to provide an application delegate. This class has methods that get invoked when the context changes for our application. The two scenarios that we will listen to using our application delegate are:

• func applicationDidBecomeActive(_ application: UIApplication)
• func applicationWillResignActive(_ application: UIApplication)

You probably already know as much and even if you don’t; you can probably guess when these methods are invoked. The first one gets invoked when our application became active and the latter one will be invoked when the user is leaving our application.

So to dash a bit of added security we will simply cover the current window with a blurred view so that prying eyes won’t see what is being displayed on the screen. Using blur is not the safest option, but for the time being, we only want to keep people out that have direct access to the phone while someone is borrowing it. If you want additional security, you could display the applications launch screen or a picture of a cat; it’s up to you.

Enough talk, lets look at the code.

As you can see, it is not a lot of code to make a barrier that blurs whatever is on screen. When the application resigns its active state, we add the visual effects view to the root view controllers view. We animate the alpha value to make the transition buttery smooth. When the application becomes active again, we reverse the animation and finally remove the visual effect view from the view hierarchy. You can play a bit with the blur effect to make it match your applications look and feel, we went with .light for this demo as it worked best with the background.

End result

Remember that just adding this little bit of security is not enough, you probably want to add a pincode screen and do all the other security related tasks that you normally do. This is just to stop your app from leaking information to the multitasking feature on iOS.

How to stop leaking information through multitasking was originally published in itch design on Medium, where people are continuing the conversation by highlighting and responding to this story.

When developing applications, there are loads of tools and techniques that can help you save time and make you more efficient. One such tool is templates, little snippets that give you a more concrete starting point for what you want to achieve. Xcode comes with some built-in templates but templates truly shine when you tailor them to your code style, pattern and other personal preferences. Lucky for us, Xcode supports this, but getting it set up can sometimes feel like practicing voodoo magic as Apple neglect to promote this hidden gem, and we result to blog posts to figure it out.

Creating your templates folder

Xcode looks for templates inside ~/Library/Developer/Xcode/Templates.
This folder does not exist out of the box so you will have to create it manually.
You can do that in the terminal by running the following command:
mkdir ~/Library/Developer/Xcode/Templates
Or navigate to your Xcode folder in Finder using ⇧⌘G — “Go to folder” and paste ~/Library/Developer/Xcode/

Inside your newly created templates folder, you can create subfolders to categories your templates.
At the time of writing, I went with one folder called Custom.

A good starting point for creating templates is to duplicate one of the existing ones. I’ve made my templates based on the Swift File.xctemplate

You can find it here:

/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File\ Templates/Source/Swift\ File.xctemplate

Creating your template

Xcode templates have their own file type called .xctemplate.
It works as a container for all your template related files.
A basic Swift template consists of four files.

• TemplateIcon.png
  This icon will be used in the template selector.
• TemplateIcon@2x.png
  Same as TemplateIcon.png but is used on Retina Mac’s.
• TemplateInfo.plist
  The property list holds additional metadata about your template, such as description, summary, kind, etc.
• __FILEBASENAME__.swift
  This is the template file that you will customize to fit your needs.

The __FILEBASENAME__ placeholder will be replaced with whatever you input in the template picker; this can also be used inside your template.

Here is what a simple UIView template could look like:

Snippets in templates

One thing worth mentioning is that you can use templates in combination with snippet placeholders. If you are familiar with the concept of Xcode snippets, you’ll know that for a specific snippet you can add placeholder tags that the user can navigate between and replace with the actual code. This helps speed up the process and makes your templates easier to work with.
You can add snippet placeholders to your templates by inserting them as <#MyPlaceholder#>. This will then be replaced with a macOS token element.

Examples

To share some inspiration, here are a few of my templates that I use on a regular basis.

Flow controllers

My flow controllers usually consist of more than one controller. Personally, I tend to “default” into making them a FamilyViewController.

UICollectionViewCell

This is not a very advanced template but seeing as I do all my UI components programmatically without interface builder, I always override the initializer and add my custom views there. This forces me to add the required initialize with coder function; the templates saves me the time it takes for the compiler to see that the method is missing and me having to invoke Fix all issues. It is not much, but everything counts in the long run.

UIViewController

This template simply implements the viewDidLoad method as this is where I tend to add the most of the setup for my view controllers and initializers are hard to make generic, especially if you rely on dependency injection.

As you can see from all my examples, my templates are very lean, some of them do little to nothing except taking the ___FILEBASENAME___ and use it as the class name. The reason for this is that I want them to be neat and tidy. I feel that if I make templates and need to remove a lot of things from them each time I’m about to use them, then they don’t serve their intended purpose. Too advanced templates are also more demanding to work with from a creative point of view, as it will require you to make decisions & think things through before creating your canvas, sometimes without a relevant context. I like my canvas to be free of clutter which makes them more inviting.

When you start using templates, you’ll quickly find that it can be quite challenging to find a good middle-ground between what is semi-niche and what is perfectly generic. But remember, there are no right and wrong with templates, they should be personal, create templates that fit your needs and make sense in your context. If they don’t work out, just change them until they do.

If you have any good tips that you’d like to share, just hit me up on Twitter and we can compare notes. You can reach me at @zenangst.

Creating your own templates in Xcode was originally published in itch design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Continuing with some more niche topics, let’s have a look at how we could rotate your tvOS application to work in portrait mode. So what is “portrait” in tvOS, well… the concept from an SDK perspective does not exist. None of the rotation-related methods from iOS made it over to tvOS, and for a good reason. With that said, there is still a small segment where it could be useful to have your tvOS application being rendered with more vertical than horizontal space. A good example of this is Panic’s status board application that was built back in 2013 using an iPad that would preferably be mounted on the back of the TV it was attached to. You could, of course, go with this option as well, but for our use case and this article’s topic, we will stick to using tvOS as the platform.

Before we tried to tackle this problem, we thought long and hard about how we could do this and still keep the application maintainable in the future. The first fear that stirred up was that this would affect how we write constraints, having to translate the layout in your head before writing it down in code. This felt like an unbearable scenario, so unbearable that we almost decided to ditch the idea of portrait entirely. After a small brainstorming idea on how to best tackle this, we came up with the idea to go down to the lowest (or highest) point in the hierarchy, more specifically the application’s window.

If we swap width and height, we end up with the correct frame measurements. However, the window was now misplaced. This is where our good friend transform made an entrance and saved the day.

The first thing that we did was to get the rotation right, for our use case, we had to rotate the screen -270 degrees. This was easily done with a CGAffineTransform. And voila, now we had the correct screen rotation. However, the screen was now somewhat misplaced.

To fix the position, we needed yet another transform to be applied to the window, this time a translation of the x and y coordinates. These values are easily calculated, simply take the width minus the height and divide it by two, do the same for the y-position but negate the value. We then create the translation and apply it to our already existing rotation transformation by calling .concatenating. Using this method we can combine the two transform into one and finally apply it to the window.

And there you have it; the application’s window now uses a portrait window size, it has been rotated and positioned to fit in the middle of your TV screen.
The kicker is that you can now use the same kind of constraints that you would normally apply to your views without having to think about the screen rotating. Except for one small detail that I’d like to highlight when it comes to over-scanning.

In the tvOS human interface guidelines, Apple mentions that should have used at least 60 for your top and bottom insets and 90 for your left and right insets. Now that you have rotated your TV screen, you should reverse these values to be on the safe-side when dealing with over-scanning. So 90 in top and bottom and 60 on for the left and right insets.

How to rotate tvOS into portrait mode was originally published in itch design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Generating QR codes might be a niché subject, but it can be nice to know how to generate QR codes on the phone rather than just scanning them using the phone’s camera, and generating them is surprisingly easy. Let’s have a look at a straightforward example where we create our QR code based on a string, and as a bonus, we will put some customization to it by splashing some colors to it.

First, of, let’s create our subclass of UIView so that we gain the ability to easily place our QR code where we want in the application.

The next thing that we need to do is to add a filter, more specifically a CIQRCodeGenerator CIFilter. This specific filter has been around since iOS 7.0, so it’s is not particularly new. For more information about available CI generator filters, you can head over to https://developer.apple.com/library/content/documentation/GraphicsImaging/Reference/CoreImageFilterReference/index.html#//apple_ref/doc/uid/TP30000136-SW142

The CIQRCodeGenerator filter

This particular filter takes two arguments:

inputMessage: The data to be encoded as a QR code. An NSData object whose display name is Message.

inputCorrectionLevel: A single letter specifying the error correction format. An NSString object whose display name is CorrectionLevel. Default value: M

Because the correction level is optional, we will stick with the default value of that key.

However, we need a public method on our class to set an input message to the generator. Let’s add the missing pieces and see where we end up.

The first thing you’ll probably notice is that we have added an image view to our QR code implementation. The reason is that we get a generated QR code as a CIImage and we need a place to show it on screen. We do the usual limbo to add the image view to the view hierarchy and set a frame to it.

As for the generateCode method, it takes a string, but internally, one of the first thing that it does is to transform the input string into data. This is then used as the input message for our QR code filter. We supply the data and expect a CIImage as the output of the filter. This is accessed using the .outputImage property on the filter. We take the value and create a new image and assign it to our image view that was mentioned earlier.

If you run this code in a playground, you’ll notice that the QR code in question is a bit blurry, so let’s fix that plus splash some color.

If you take this and add it to a playground, you’ll end up with something like this:

So here is what we did to achieve this result. To correct the issue with the image being blurry, we applied a transform filter and up the scale by ten. This is probably something that you’d like to tinker with to not sacrifice any performance, using a scale of ten is random to illustrate how the method works.

To set the color values that we want, we need to invert the colors and later mask the image so that the background becomes transparent.

For inverting, we use another CIFilter named CIColorInvert. This simply inverts the colors that were generated by the CIQRCodeGenerator, which are black and white. The input for that filter is the transformed image, and we use the key kCIInputImageKey, you’ll see this key being used when doing masking as well.

Now that we have an inverted image, it is time to apply a mask. For masking, we use a filter named CIMaskToAlpha. Just like the invert filter, it also takes an image as its input using the same key, kCIInputImageKey.

We are now done with a filter; it is time to put the pieces into place.
First, we set a tint color to our image view, this will be the color of the actual code. We proceed to set a background color to the actual image view; this will act as the background color for the code as we applied an alpha filter to our image.

Last put not least, it is time to set the generated image to the image view. Because we are working with the Core Image framework, we don’t have a UIImage yet. Lucky for us, UIImage as an initializer that takes a CIImage. The icing on the cake is when you set your UIImage to your UIImageView, you do that by adding .withRenderingMode(.alwaysTemplate). This last step is important as it will make the image adopt the tint color of the image view.

And there you have it; now you can generate your QR codes and personalize them by dashing your color schemes on them.

How to generate QR codes in iOS was originally published in itch design on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the last couple of months, I’ve had the pleasure of working on a tvOS application. Developing for tvOS is very similar iOS which made it quite smooth to work with from the get-go. After multiple iterations on one of the features, we stumbled on some performance hits with one of our collection views. Spending time in Instruments revealed a lot of potential optimizations that we could apply, they included layout attributes caching for our collection views, further optimizations to our scrolling algorithm, etc. All optimizations rendered fantastic results for everything except one collection view that just did not want to perform well. Everything performed a stunning 60 fps except for that one collection view. This quickly became a thorn in my paw, and I set out on a mission to figure out why this was happening.

I lost count on the number of times I clicked on the Profile button in Xcode. I started to strip away UI elements, dove deeper into the profile stack, and I finally had a suspect in my crime noir tale of optimizing for tvOS. All evidence pointed to UIProgressView being the culprit. Now that we finally had found is big baddy it was time to figure out how to solve the issue. But before we jump into the solution, I’d like to present a theory of mine to why this was happening. Because I don’t know the inner workings of UIProgressView, I cannot present my theory as facts, but if you follow along, I think you would agree that it makes sense.

I first perceived this as a bug on Apple’s part and was going to file a radar, but after some more thought, this is more a cost of the implementation that Apple provides which makes it a bad fit for us to use in this context. With that said, we did not see the same kind of frame drops on new Apple TV’s which means that this issue will fix itself over time. We couldn’t just sit around and wait for our users to upgrade their hardware so hence we went with rolling out our own solution that would be more tailored to our needs and scaled in the way that we want.

Because the UIProgressView is designed to work in as many situations as possible, Apple went with UIVisualEffectView. I understand this choice; unfortunately for us, as mentioned above, this didn’t scale well as we were showing ten to eleven views at once which all used this implementation. It gave us a frame drop of 20 fps or more, depending on the device. Also, our design didn’t have to rely on UIVisualEffectView as we added a gradient to ensure that the progress view would always be visible to the user. You could say that the vanilla implementation that Apple provides was over-engineered for our use case. There could be other reasons for it not performing well for us, the solution that we used to solve the issue was to make our own version of the progress view that was not backed by UIVisualEffectView.

Because we wanted this to be a drop-in replacement for UIProgressView, the public API was copied from UIProgressView. It made it easier to start using the view as we only had to change which class to use instead of updating all the method calls made to the class.

Our replacement consisted of two CALayer’s, one outer layer that represents the total progress amount and another inner layer that represented the current progress. The outer layer has a corner radius that is equal to half of the height of the progress view; this gives it the same shape as you would expect from a UIProgressView. For animations, we provide a CABasicAnimation when we call setProgress(_ progress: Float, animated: Bool = false) that is added to the inner layer.

The layer and the animation are wrapped up in a regular UIView to make it easier to work with as CALayer’s lack the ability to use constraints.

After dropping in this new progress view into our app, our application started reaching 60 fps again, and the users got the performance that they so truly deserve.

Knowing the exact position of a subview is a technique that can come in handy on multiple occasions. You might want to know if the view is visible to the user, perform an animation from the views initial position or restore the view to its original destination. There are plenty of use cases for this; you can probably think of dozens more. However, when you want to do this you can’t simply rely on the target view’s frame as that is only a part of its super-views coordinate system, this quickly causes issues depending on how you compose your view hierarchy. Lucky for us, both UIView and NSView have some methods to give us the desired results. If you read a previous article of mine about how frames work on macOS, you might remember that we briefly touched on coordinate systems.

So let’s dive in to see how we can convert frames between different coordinate systems.

The first thing that we create is a UIWindow. We give it a frame and later assign a root view to our newly created window. We give the root view a color so that we can more easily see where on view start and the other one begins.

Next is your view, this is meant to represent your custom view implementation. It gets a frame and a color and is added as a subview on the window. So far we have only written code to get the example up and running, nothing new and exciting.

Last but not least is the subview, it gets the same treatment as the other ones and is added as a subview to the view.

Now that we have our scenario set up let’s look at the method that the whole article is about, the convert(CGRect, to: UIView?) method.

If we examine the values that we get back from just accessing the view’s frame. It is the correct value inside the views coordinates space, but that doesn’t make it universally correct when trying to assemble these kinds of values in a context that expands to the outside of the views coordinate space.

What we want to achieve is to know the views exact position on the screen, not the position within the subview.

So by passing the current frame and pointing it to the desired coordinate space, we can now get the measurements that we need. You can switch to any coordinate system that you like; I picked the window as that has been the most relevant for me in the past.

When doing this in your implementation, accessing the view’s window is trivial. All UIView’s has an optional reference to the window it belongs to, if this value is nil it means that the view hasn’t been added to a window yet.

As a side note, this is just the tip of the iceberg; there are more of these kinds of methods that take points instead of a frame. Have a look at UICoordinateSpace for more information.

https://developer.apple.com/documentation/uikit/uicoordinatespace

The reason why these methods are also available on UIWindow is that it inherits from UIView which in turn conforms to UICoordinateSpace.

As you can see, this is straight-forward yet powerful, but what about macOS. Let’s have a look at another example with some macOS code.

The technique itself remains the same, as well as the result when converting. The only noticeable difference between the two examples is that it uses an NSView to represent the window. The reason for this is that NSWindow does not conform to PlaygroundLiveViewable.

Even if this might seem niché, this technique holds enormous value when reasoning about how to solve specific situations. I’ve used this method when optimizing scrolling performance of both scroll views and collection views, opting out from performing layout operations if the view is not visible on the screen. I’ve also used these kinds of values to define start and end positions for core animations. I’m sure that you can come up with more scenarios, the point is that knowing the technique expands your toolbox and the bigger toolbox that you acquired, the more natural is to find the best solution for your problem.

Hope you found this useful, for me, this has been life-saver countless times.

Converting frames between view coordinate systems was originally published in hyperoslo on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the past months I’ve been feeling a bit down, well that is probably the wrong word for it, uninspired is probably the right word. It isn’t a crisis of faith or anything like that, but I’ve been feeling that something has been lacking. Days became weeks and I realized that this problem wouldn’t fix itself. I got tired or waiting, so I had take action. If inspiration wasn’t going to find me, I was going to find it.

The plan of attack was to get exposed to new things. The conditions for this to work was that it had to be contextual to my profession, feel natural and last but not least, it should be fun. So this is what I came up with.

To get things off the ground, I simply set up a bunch of reminders for myself and made the tasks obligatory. Those far I have three semi-concrete action points that I want to do on a regular basis. Seeing that humans are creatures of habit, doing something repeatedly will eventually make it second nature. So the first thing on my list was, read an article. The subject doesn’t matter but read something, anything. I prefer Medium as my source of articles these days; I like the aesthetic of it, and they could be written by anyone from any field, writing about anything.

The second thing on my list is, check out new open source. The code doesn’t have to be new, but it has to be new to me. There are a thousand ways to skin a cat, looking at how other people solve similar problems that you face on a regular basis can be inspiring and fun. Knowing that there are more options than you can come up with yourself is never a bad thing.

The last thing on my list was to write something. As long as I can remember I’ve always enjoyed the art of writing, if it’s sharing a personal experience, giving someone praise or explaining the internals of a piece of code I just wrote. I see writing as an outlet for my thoughts, and if I don’t let them out, I start to feel “thick-headed,” and no one wants to feel like a hard drive with little disk space.

To conclude, the way I see it, my problem with not being inspired boils down to me waiting for it to happen rather than actively seeking it out. If you feel that your personal or professional life is lacking or you’re just feeling uninspired, try doing something about it. It might be easier than you think.

Seeking out inspiration was originally published in hyperoslo on Medium, where people are continuing the conversation by highlighting and responding to this story.