Lickability Blog

Animating Strikethroughs in SwiftUI

Ashli Rankin — Wed, 25 Mar 2026 00:00:00 GMT

While working on one of our internal tools, the design called for completed tasks in todo lists to be “struck through,” adding a bit of playfulness and physicality to the app. SwiftUI does provide a strikethrough modifier, but it is not animatable. For our tool, we wanted it to feel like it was being physically drawn, stroked from one end of the text to the other. What seemed like a simple feature turned out to be deceptively difficult if I wanted to implement it the right way.

Default implementation of strikethroughs in Swift vs. the intended effect.

Defining constraints to identify a solution

Before immediately researching a solution, I defined three constraints my approach would need to satisfy:

The stroke needed to span the entire view if the text grew or shrank with Dynamic Type.
The stroke had to span the entire text view, even when text wrapped to multiple lines.
Existing VoiceOver behavior had to be preserved.

First round of experiments

My first attempt used a Path as an overlay on the Text view. The drawback was that it didn’t account for multiline text or Dynamic Type, because I had no access to precise width information about the rendered text.

Path as an overlay on the Text view’s issues with multiline text.

Next, I tried a Canvas view overlay. This felt promising — a graphics context meant I could draw freely — but I still lacked precise information about the rendered text, such as line height, padding, and font size. It worked for single-line text but broke entirely when the text wrapped to multiple lines.

Canvas view overlay presented problems with animation and, still, multi-line text.

My search led me to Text.Layout, which provided access to the internal structure of a rendered Text view, broken down into lines, runs, and individual glyphs, as well as iOS 17’s TextRenderer protocol, which surfaces both the layout and a graphics context through a single required method:

Swift

func draw(layout: Text.Layout, in ctx: inout GraphicsContext)

The implementation iterates over each line, calculates how much of the strikethrough stroke should be visible based on a _progress value between 0 and 1, and draws accordingly. Progress is tracked cumulatively across lines so the stroke draws continuously from one line into the next rather than animating each line independently:

Swift

func draw(layout: Text.Layout, in ctx: inout GraphicsContext) {
    let totalLength = layout.reduce(0) { $0 + $1.typographicBounds.width }
    var accumulated: CGFloat = 0

    for line in layout {
        let bounds = line.typographicBounds
        let strikeWidth = min(max(totalLength * _progress - accumulated, 0), bounds.width)
         
        ctx.draw(line)

        if strikeWidth > 0 {
            let midY = bounds.rect.midY
            let startX = bounds.rect.minX
            ctx.stroke(
                Path { path in
                    path.move(to: CGPoint(x: startX, y: midY))
                    path.addLine(to: CGPoint(x: startX + strikeWidth, y: midY))
                },
                with: .color(color),
                lineWidth: lineWidth
            )
        }
        accumulated += bounds.width
    }
}

Conforming to Animatable is what makes SwiftUI interpolate the renderer between states rather than jumping straight to the final value:

Swift

var animatableData: CGFloat {
    get { _progress }
    set { _progress = newValue }
}

Once applied via the textRenderer modifier, the strikethrough animated perfectly on Text views. Then I tried it on a TextField, and nothing rendered. Setting a breakpoint confirmed draw wasn’t even being called. TextField doesn’t render its content as Text views internally.

Disappointing, but not disqualifying

The TextRenderer approach still satisfied all three constraints for Text views. I just needed to get creative about how to apply it to a TextField.

What if I overlaid a Text view on top of the TextField? The Text view would display the animated strikethrough, and I could set its foreground color to clear, keeping the TextField content visible underneath while the animation played on top.

This worked well in initial testing, but when I integrated it into the project, a subtle misalignment appeared: TextField tends to fit more content on a single line, while Text wraps earlier. This meant the first line of the TextField had no strikethrough, while the second line did.

To fix the alignment, I created a custom Layout that forces both views to use the same width. This ensures both the TextField and the Text view wrap at the same point, keeping the strikethrough in sync with the visible content. The tradeoff is a slightly narrower TextField, but that was acceptable for our use case.

Swift

struct TextFieldOverlayLayout: Layout {
    func sizeThatFits(proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) -> CGSize {
        guard let primary = subviews.first else { return .zero }
        if primary.sizeThatFits(proposal).width.isZero {
            let secondIndex = subviews.index(after: 0)
            return subviews[secondIndex].sizeThatFits(proposal)
        } else {
            return primary.sizeThatFits(ProposedViewSize(width: proposal.width, height: nil))
        }
    }
    
    func placeSubviews(in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) {
        guard subviews.count >= 2 else { return }
        for subview in subviews {
            subview.place(at: bounds.origin, proposal: ProposedViewSize(bounds.size))
        }
    }
}

In the view, the layout looked like this:

Swift

TextFieldOverlayLayout {
    Text(store.description)
       .foregroundStyle(Color.clear)
        .font(.system(.body, design: .rounded, weight: .medium))
        .lineSpacing(-1)
        .allowsHitTesting(false)
        .accessibilityHidden(true)
        .textRenderer(StrikethroughRenderer(store.isComplete, color: .primary))
                       
   Textfield()
       .foregroundStyle(Color.primary)
       .font(.system(.body, design: .rounded, weight: .medium))
       .lineSpacing(-1)
}

The end result

My final draft required research, a few dead ends, and ultimately combining TextRenderer, a clear Text overlay, and a custom Layout to produce something that satisfied my aforementioned criteria. It may seem like a lot of effort for a small detail, but I believe these are exactly the kind of details worth putting extra time into! The way it feels to use an app is just as important as the functionality of the app itself.

The final working result.

Our Work with RevenueCat

Team Lickability — Fri, 20 Feb 2026 00:00:00 GMT

As an independent studio of over 10 years, we’ve always been advocates for tools that empower small teams and solo developers. Enter RevenueCat: a company with a suite of tools for app developers that handles subscription management, billing, detailed analytics, and more—a match made in heaven for us! We joined RevenueCat as a premier partner in 2023 as a user of their tools, and to implement some of their SDKs into our own projects, so it was an honor when they came to us to develop their first official iOS app.

RevenueCat’s initial problem was obvious: they were a large, growing startup that empowered app developers by simplifying financials, but at the time had no official app themselves.

“They were laser focused on building better features and tools while doing developer outreach. They knew our track record, so it was an exciting opportunity for us to work with another client whose outlook and attention to detail gelled with ours. They could focus their internal efforts on bettering things for their users, and we’d implement those features down the road.”

– mb (Partner)

So now it’s time to build... but what does it look like to “officially translate into iOS”? Where do we draw inspiration?

“We’d been lucky enough to attend WWDC in Cupertino where we took part in a design lab put on by Apple. We wanted the app to be 100% at-home in and take full advantage of what iOS had to offer: widgets, universal links, and Swift Charts which had been newly introduced to SwiftUI. Sam did an excellent job designing the app, and special shout-outs should be made to friend of the team Joe for working with Brian on implementation.”

– mb

And in the ensuing years, we shipped an official iOS app, worked closely with RevenueCat on implementing brand-new features, and got to attend several awesome events put on by them. In 2025 alone we pushed 6 significant version updates, and we collected some of our favorite features here:

Too Much of a Good Thing: Scope and the Future of Apps

Team Lickability — Tue, 10 Feb 2026 00:00:00 GMT

A few years ago, Lickability alumnus Sam Henri Gold made a strong case for why your app doesn‘t need a chat feature. So much has changed in this short time; in the ensuing years, most tech sectors have seen huge financial swings, layoffs, and product development shifts (often with limited success), thanks largely to advancements and ballooning investments in AI. Public perception of AI still skews negative-neutral, but this hasn’t stopped many from feeling empowered to build due in part to AI putting no-barrier tools into the hands of talented, but less-technical, people. (See: Lovable, Claude Code, bolt.diy, etc.)

But even with this newfound promise that anyone can build anything, success is never guaranteed. What if you want to spin up an idea into a product you can sell to others? It’s easier now than ever, but also easier to stumble into the same — and more — pitfalls of unnecessary features.

This got us thinking: what do people even want out of apps in the frenetic landscape of 2026? What are product developers, designers, or even our prospective clients eager about adding to apps and software? Is everything becoming same-y “slop,” or is that an easy hand-wave?

Incessant Features and Scope

To learn what some of our prospective clients’ pitches have had in common, and how much they are (or aren’t) in touch with what the average user wants out of their app experience, we turned to our frontline team.

With AI being so massively popular, everyone wants to tout some kind of integration with the hopes of riding this wave. But while these tools are nearly ubiquitous now, the minutiae involved in their adoption and integration still isn’t fully understood by the average person.

I am seeing a lot of requests to “integrate AI chatbots” in the pitches we get, but people are not thinking any further on what model to use, how they intend to prompt it and the subsequent necessary pipelines, or even evaluating the drastically-differing costs to use said models. It’s fine to want to capitalize on new technologies, but people often aren’t considering what their end goals are when adding these features to their products.

– Tom (Sr. Account Manager)

Keeping scope in check continues to prove an issue for many. As mentioned before: AI has proven useful for technical and non-technical professionals to iterate and ideate very quickly, but can often lead to putting the cart before the horse and not knowing just how insecure, expensive, or deceptively-complicated proper integration will end up being.

Anything that brings in user-generated content. A great example is profile pictures / avatars. Clients want this but don’t know that this seemingly “easy feature” also necessitates bringing in moderation tools (manual or automatic) to secure against illegal or harmful content. This is an easy way to balloon scope but can sometimes be creatively worked around (e.g. user avatars as initials, pick from a pre-defined list of images, emoji etc.)

– Tom

Creative workarounds for curbing scope creep

A great example of giving users a sense of personal identity without needing to allocate time and money on content moderation is Transit‘s approach: randomly-assigned combinations of adjective-emoji usernames with a matching avatar.

This is, however, also an example of creativity thriving on restrictions, as it was once possible to pick your own custom username, with Transit removing the option in 2024 due to some users choosing hateful names and ruining the fun for everyone.

Building for Users

Even if you keep scope in check and set out to create an app with the intention of solving one problem, what doesn’t it need?

‘We’re going to need a chat feature, and a micro-social network, and a feed for people you follow...’ In your gardening app? People just want apps to solve problems or make things more convenient for them, especially lately. There’s already a proliferation of options for social media, not to mention the content moderation nightmare running your own could create. It may seem boring, but limiting your features and focusing on doing one smaller thing extremely well goes a long way for people.

– mb (Partner)

Realizing this problem with feature creep, we spoke with our internal operations expert for examples of software features devs and designers swear she’ll use, but she finds herself not using:

AI meeting notes are a big one for me, and it feels like they’re in everything now. I recognize that it can be helpful to have an extra backup since it can be hard to quickly take accurate notes while talking in a meeting, but I have never found it truly useful to me, and far from a complete replacement. I much prefer taking my own notes during meetings — it helps me stay focused, I have the context that an AI tool doesn‘t to determine what is important and what isn’t, and it’s often more valuable to pause and ask someone to repeat or clarify something they said than it is to look at notes that I didn’t write and realize I don’t understand something.

– Jillian (Project Manager)

Does every app have to be an everything app?

I feel like so many apps try to be everything and it tires me out. I’d rather have one really good calendar app than an app that has a calendar, a to-do list, a habit tracker, a focus timer, and an AI chatbot to coach you through it all. Just pick one thing and do it well.

– Jillian

Software like Obsidian operates on a philosophy of “closed-core, open-source plugins.” At its core, Obsidian is very sparse, and its in-house development is focused on providing users with a program that’s efficient, secure, and available on a number of platforms. Is there a feature you want but don’t see? Build it in yourself, or choose from a huge library of options. Someone might have already solved your problem for you! It has the ability to be everything for some people, and only just enough for others, but enables users to have granular controls over their experiences.

Things is just a solid, beautiful-looking to-do app I’ve been using for years. It does exactly what it says on the tin, and it has never failed me. Unlike a lot of other apps in that space, the closest it gets to co-mingling with other products is integrating with your calendar so you can see a list of your calendar events while looking at your to-do list for the day, which is all I need. And even then, it doesn’t show up where it isn’t welcome.

I also really like what the folks at !Boring do. They have a whole suite of apps in their style that each do one specific thing: a weather app, a calculator app, a timer app, etc.

– Jillian

Looking to the Future

The broad takeaway, from our perspective, is while it’s easy to fall into the trap of chasing trends or wanting your app to be everything at once, the best products with the most longevity are proven to be the ones with thoughtful, intentional scope.

GitHub Markdown Shortcuts

Michael Liberatore — Wed, 24 Sep 2025 00:00:00 GMT

This summer, Lickability held a brief retreat where engineers hacked together a few projects to scratch itches, learn new technologies, and work together. I took the opportunity to make a few shortcuts (that is, referring to Apple’s Shortcuts app) to boost productivity around my favorite thing: pull requests!

If you’ve been reading our blog for a while, you’ll already know I feel strongly about good pull request descriptions, and making things easier for reviewers. So while others toiled away in Swift, I got to work on three new shortcuts that our team has since worked into their daily routines. Before we get to those, a little history…

Baby’s First Shortcut

For as long as I‘ve been using GitHub, I’ve had a pet peeve about how enormously iPhone screenshots are rendered by default when attaching them to pull requests and issues. Sure, the screenshots are saved @2x, but that effectively results in double-sized images, massively interrupting the flow of text.

Over the years, I developed various strategies to combat this, including automated scripts that resized iPhone screenshots that were saved to my Desktop, but I was never happy with destroying the quality of images when in many cases the screenshots were used to highlight tweaks in designs that would benefit from pixel perfection. I sought a more robust approach. A few years back, dropping a screenshot into GitHub looked something like this:

Markdown

![IMG_E01132EEBBE](https://github.com/user-attachments/assets/c47aec88-87cc-4f8a-9a40-ba281d951e0b)

While we can’t specify a size in Markdown syntax directly, using absolute-beginner HTML, we can easily render the image at that URL at a more appropriate size using an img tag, since after all:

For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.

So with a very basic text transformation, we can limit the width of the rendered image within a pull request description or issue, maintaining the aspect ratio:

HTML

<img src="https://github.com/user-attachments/assets/c47aec88-87cc-4f8a-9a40-ba281d951e0b" width="300" />

I use a width of 300 for iPhone screenshots, regardless of device size, as I find it to be a nice balance between legibility within the image and not being too disruptive to surrounding text.

But you said you weren’t happy with destroying the quality of images! That’s right, straw man. The benefit of this approach is that the image quality is preserved, and the full-size image just a click or two away in your browser.

But isn’t that cumbersome to do for every image? Sure is, but like any engineer, I saw that as an opportunity to automate away the tedium of text transformation. With a bit of free time, I decided to dip my toes into Shortcuts to tackle this since, at the time, it was relatively new on Mac, and I wanted an excuse to try it out. Not long after, I had a working shortcut that could handle the resizing task with ease, conveniently located in the Services and right-click menus, even tackling multiple images at once!

Pretty nifty! If you think you‘d benefit from this, you can grab the shortcut from the link at the bottom of this post.

GitHub has since changed how it processes image uploads, and more conveniently provides an img tag on upload:

HTML

<img width="1179" height="2556" alt="Simulator Screenshot - iPhone 16 - 2025-09-09 at 15 57 27" src="https://github.com/user-attachments/assets/830ef400-8619-49a6-86e2-536690ac2d9b" />

So despite this being a convenient shortcut for years, it’s now much simpler to just delete the height parameter, and restrict the width parameter to a value of your choosing. Small bummer for my shortcut’s usefulness, but that’s a win for everyone. I still use the shortcut to this day, as I find it convenient to resize many images at once, but I do appreciate GitHub’s constant improvements to the text editing experience.

The New Shortcuts

In the intervening years, I noticed some tedious patterns creeping in, ultimately requiring me to take extra time to communicate my thoughts in pull request descriptions. I had been saving up some ideas for the next hackathon-style work event, and our retreat this summer gave me the opportunity I needed. In an afternoon, I created the shortcuts that follow, and I’ve been saving lots of time ever since!

Arranging Related Screenshots in Tables

I love Markdown tables for neatly organizing data. Historically, though, they’ve been a bit of a pain to type up manually, often requiring switching between Write and Preview modes to ensure you’ve got the syntax just right. Fortunately, GitHub recently introduced slash commands, including /table, which allows you to specify the number of columns and rows, giving you a great starting point to fill in your relevant data.

When writing PR descriptions, I‘ll often include multiple screenshots, sometimes “Before and After” comparisons, and in the spirit of not disrupting the surrounding text too much, I like to arrange these side-by-side. Using the /table slash command to neatly package the screenshots together is nice, but still requires a fair bit of manual manipulation, especially when resizing the images is also necessary. So I thought, why not create a shortcut to do all of the heavy lifting?

Now, with a single activation of my “Make GitHub Image Markdown Table” shortcut, I can take multiple screenshots, specify column headers, and arrange them in a beautiful table in seconds. I’ve even built in some conveniences, including a “Before and After” option that’s offered when exactly two screenshots are selected. And to build off of my first shortcut, image resizing is built in by default.

Wrap Details in a Toggle

Have a lot of optional background context to write? Screenshots and videos still taking up too much space, distracting from the main points you’re trying to get across? No problem. You can easily hide additional details behind a heading with a toggle used to show/hide your more verbose context.

This is accomplished purely with HTML tags, like the following:

HTML

<details>
    <summary>The boring details…</summary>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.</p>
</details>

While there’s a newly introduced /details slash command for this as well, I much prefer interacting with a lightweight UI over editing the text between HTML tags, if I can help it. Enter my “Wrap in Toggle” shortcut to save the day:

Wrap in Callout

If I had a nickel for every time another engineer looked at a neatly formatted callout in a PR description of mine and said “how’d you do that??,” I’d have… some nickels.

I’ve had this page bookmarked for a couple years, as I often forget the exact syntax and need a refresher. To streamline this — you guessed it — I created a “Wrap in Callout” shortcut. You know the drill by now: write some text, select it, run the shortcut, DONE.

Admittedly, GitHub pretty much steals all the thunder on this one with a new /alerts slash command, but I like the convenience of having all of my text manipulation shortcuts in one spot, and being able think text-first before deciding to move something into a callout / alert.

Just Give Me The Shortcuts!

Here they are:

To add them to the Services and right-click menus, open each shortcut, select the Shortcut Details inspector panel (1), the Details tab (2), and check Use as Quick Action, Services Menu, and Provide Output (3). You could also assign a keyboard shortcut if that’s more your style.

By all means, please let us know if you find these useful in your day-to-day GitHub adventures. Feel free to edit them, share them, or suggest improvements.

Predictive Code Completion in Xcode

Michael Liberatore — Wed, 11 Dec 2024 00:00:00 GMT

Like it or not, AI assistance in software development is here to stay for the foreseeable future. If you’ve embraced technologies like ChatGPT to answer coding questions, format mock data, or take the first crack at writing a new feature, you’ve likely seen an overall boost to your productivity. If you’re a Swift developer and you haven’t dipped your toes in just yet — either due to privacy and security concerns, or mixed results with generative AI in other contexts — you may want to take another look, as major players have now entered the ring that offer AI assistance directly within Xcode.

This year, Apple’s first-party offering, its privacy-focused Xcode Code Completion model was introduced, and is now out of beta. Following this, GitHub announced a public preview of Copilot for Xcode, ChatGPT opened an early beta of its Works with Apps feature that is Xcode-compatible, and Cursor (albeit in a separate IDE) is gaining steam in the community. In this post, we’ll look specifically at Xcode’s new code completion model, how to set it up, and what it can do to improve your productivity.

Prerequisites

To take advantage of Xcode’s predictive code completion, you’ll need to be up-to-date software-wise. The feature was introduced first in Xcode 16, and while Xcode 16 runs just fine on macOS Sonoma, the latest version of macOS (Sequoia) is required to use the code completion feature. Hardware-wise, you’ll need an Apple Silicon-based computer and at least 8 GB of memory, in addition to about 2 GB of additional disk space for the model itself.

So in summary, that’s:

macOS Sequoia or later
Xcode 16 or later
Apple Silicon-based computer
8 GB of memory
2 GB of free disk space

Installation

Xcode’s predictive code completion feature has all the advantages of being a first-party solution, including being dead simple to install. When launching Xcode 16 or later for the first time, you’ll see a window that allows you to select components to install right away. Check Predictive Code Completion Model and any platforms you’ll be using before clicking Download & Install.

Xcode’s first launch window, which includes a checkbox for downloading the predictive code completion model.

Don’t worry if you’ve opted not to download this on first launch. Simply navigate to Settings → Components → Predictive Code Completion Model, and click the Get button to download and install the model.

And that’s it! You can turn the feature off at any time by navigating to Settings → Text Editing → Editing and unchecking Predictive code completion.

Code completion in action

To take this new feature for a spin, we wrote an implementation of a “take home” code exercise that we’ve given engineering team candidates in the past. Nothing too complex:

Hit a specific endpoint to download photos
Display those photos in a scrolling grid

Immediately, we can see that Xcode’s predictive code completion has clear advantages to being built in, compared to the other AI-assisted code features we’ve tried. There will always be a barrier for third-parties to achieve what Apple can do, since they’re not bound by the limitations of Xcode extensions, or the need to run in an entirely separate interface. Xcode’s suggestions appear while typing, similar to snippets, completing the current line and suggesting more of an implementation to follow (truncated with “…”):

Xcode’s predictive code completion suggesting the type of a computed path variable declaration from a protocol. The implementation of the property is truncated with “…”

One stroke of the tab key will complete the line, and may suggest the body or implementation of the declaration:

Xcode’s predictive code completion suggesting the body of the computed path property.

If you’re satisfied with the suggestion, or if it provides a good enough starting point, one more tab will accept it.

Code predictions blend fairly well into your coding interface. However, I’ve found that they can be a bit visually distracting when you stop to think about what you’re typing and aren’t looking for suggestions. Constantly turning the feature on and off when you need vs. don’t need it is a non-starter for me, so I like to leave it on, and hope I’ll get used to the additional visual noise.

Suggestion quality

No AI-assisted coding tools can read your mind, and I highly recommend using them only as a start to get something working, and then refine the code manually. They’ll produce erroneous code, off-the-wall suggestions, and use bad practices at times. Xcode’s new code completion model is no exception — we shouldn’t expect it to get things perfect every time. It’s amazing that it works at all, but still, it can get frustrating to use if you expect too much.

Overall, I haven’t found it useful to rely on predictive suggestions for top-level declarations. Even with strict patterns in place in a codebase, and even with types that declare conformance to existing protocols, I very rarely find the suggestions useful. Again, it can’t read your mind, but you can’t be blamed for expecting more when there’s a lot of context to be gleaned from the rest of your codebase. For example, our Store protocol has several required properties and methods, and each store implementation follows a convention of a single @Published state property. That’s just too much to ask at this time, and we’d be better off simply using Xcode’s “fix-it” suggestions to add protocol stubs.

Xcode’s predictive code completion suggesting a workable start to a “store” class, but failing to follow patterns already set forth in the codebase.

Additionally, without more context in a Swift file than the default header, we frequently see Xcode’s predictive code completion try to introduce tests where they don’t belong. In this example, we’re trying to create a Photo type in a project with no prior test module whatsoever:

Xcode’s predictive code completion hellbent on suggesting test declarations in a file named Photo.swift.

We have a lot more success applying suggestions to small, missing implementations, and working carefully to refine them.

Xcode’s predictive code completion suggesting a Text displaying an Error and a Button to retry a network request within a SwiftUI view. It’s a good starting point.

Frequently, even within some quality suggestions, Xcode suggests snippets that include symbols that don’t exist. I don’t see this as too much of a problem, as in simple use cases, the suggestions tend to include types that simply don’t exist yet, and can somewhat serve as a suggestion to create them. Still, it’d be nice if it were sophisticated enough to create them for you. In the example below, the type PhotoRow doesn’t exist yet, but our properly factored final implementation of a photo list would likely use a specific type to wrap the layout of individual photos.

An accepted suggestion of a scrolling list of PhotoRows, a type that doesn’t exist in our codebase.

Xcode’s suggestions can be improved by pre-commenting expected logic in plain English. By adding a comment specifically mentioning “grid” and the number of columns, we get closer to the actual structure we want.

An early refinement attempt at getting Xcode’s predictive code completion to create a scrolling grid of photos. Xcode suggests a LazyHGrid initialized with columns. That API does not exist. Additionally, a parameter on the same line is not given a value.

With enough refinement of the comments, we can usually get Xcode to suggest something workable, but in simple cases like this that require multiple attempts, it’s hard to say whether we’re saving any time vs. writing the code ourselves.

By specifying “vertically scrolling grid” and “3 columns wide,” in our comment we were able to get Xcode to suggest a quality start to our photo grid.

The future

At the time of writing, Xcode’s built-in code completion model is far more limited in functionality than AI-assisted tools that work with other IDEs. But even if we’re late to the party as Apple platform developers, the future is looking bright. At WWDC24, Apple announced that Swift Assist would be coming later this year — Swift Assist provides an in-editor text field for the developer to make arbitrary requests to write code for you, with an emphasis on prototyping.

Screenshot demoing Swift Assist from Apple’s WWDC24 during Platforms State of the Union.

Is it worth using now?

I think so! For the time being, I’ll be using a mix of Xcode’s code completion for the basics, and I’ll keep ChatGPT in my dock and at-the-ready for broader and more complex assistance. Over time, I hope to be able to lean first-party, and use only Xcode’s built-in features. With Apple’s outsized focus on privacy and security, and the built-in nature of the features, I could look past some small shortcomings for the benefits of convenience. The pace at which competitors in the space are improving for other languages and IDEs does make me worry that Apple will struggle to keep up, but that remains to be seen.

RevenueCat App for iOS Launches

mb bischoff — Wed, 23 Oct 2024 00:00:00 GMT

Earlier this year, our longtime pals and partners at RevenueCat approached us about what it would take to build a dashboard app for iOS, and we jumped at the chance to work together. RevenueCat is the leading provider of subscription technology, helping developers create and ship great in-app purchase experiences, manage customer data, and grow their revenue. We’re big fans of the service and constantly recommend it to our clients looking to monetize their apps.

For years, a few third-party apps let developers easily check their stats on the go, but there has never been an official mobile app…until today. RevenueCat for iOS is designed to help developers manage their subscription business on the go. You can get real-time transaction notifications, track key metrics with widgets, and monitor app performance anywhere. The app is free and works with any RevenueCat account, whether you’re on a paid or free plan. Want to see it in action? Check out this blog post and introduction video from RevenueCat themselves:

The Process

At Lickability, we staffed a small team to conceive, design, and build a minimal 1.0 and ship it quickly. First, our senior product designer, Sam Gold, spent hours in SwiftUI and Figma prototyping a beautiful and simple UI that lets developers and product managers get the information they need fast and get back to what they do best: making great software. Jillian Meehan, our project manager, broke down Sam’s designs into easily understandable Linear tasks that could be delivered in weekly sprints.

Our developers, Brian Capps and Joe Cieplinski, worked together to build out the app and its related widgets and notification extensions over a few months and shipped builds early and often to a rapidly expanding crew of beta testers on TestFlight. We wanted the app to look and feel completely at home on iOS 18, so we built it entirely in SwiftUI with The Composable Architecture to keep things well-factored and testable. Plus, if we want to add a watchOS, macOS, or visionOS version in the future, we’ll be able to use the same codebase and easily add more platforms.

The Details

It wouldn’t be a Lickability app if it didn’t include lots of tiny details that make the experience just that much nicer. We support customizable widgets, notification previews, and deep password autofill integration. Plus, we tint the UI background with the flag of the country where a transaction took place, rotate our globe icon to show the region where the purchase came from, and even apply a subtle parallax effect to our flag artwork as you fidget with your phone.

As we expand the app’s featureset over the coming months, keep an eye out for even more whimsical touches that fit RevenueCat’s style of benevolent chaos. Remember when they sent socks to everyone whose app got rejected by Apple?

Available Now

If you’re a RevenueCat customer, download the RevenueCat iOS app on the App Store today. And if you run an app business that isn’t using RevenueCat yet, sign up and check out the product. If you need help integrating their SDK or building your own app, we’d love to help.

And once you have the app, we’d really appreciate an upvote on ProductHunt or a review on the App Store. It’s been an absolute pleasure working with the cool cats over at RC, and we can’t wait to keep shipping even more features that make our developers happy. 😸

iOS UI Libraries We Love

Andrew Harrison — Thu, 12 Sep 2024 00:00:00 GMT

We may be experts at writing apps here at Lickability, but we also know that a lot of really smart people are out there providing excellent reusable software, and we think it would be silly not to rely on their outstanding work. Here are some of our favorite third-party libraries we use to take our apps to the next level.

Pow

Animation is challenging—even more so when it’s outside the scope of first-party libraries. That’s why we love Pow and end up using it in most of the apps we develop. Pow provides an easy-to-use API for a wide variety of customizable and interoperable animations. Imagine trying to build the animation below from scratch by yourself:

Using just three lines of code with Pow, it’s incredibly simple to make this heart spray, jump, and wiggle!

Swift

.changeEffect(.spray { heart.foregroundStyle(Color.red) }, value: likes, isEnabled: isLiked)
.changeEffect(.jump(height: 44), value: likes, isEnabled: isLiked)
.changeEffect(.wiggle, value: likes, isEnabled: isLiked)

PhoneNumberKit

Almost every app that has you make an account deals with phone numbers, and they can get complex. Fortunately, PhoneNumberKit has your back and makes it easy to handle formatting and international localization with built-in country codes and flags. You can either use a completely custom text entry and use their utility functions to format the entry correctly, or use their built-in PhoneNumberTextField that handles it all. There’s no need to become an expert on how phone numbers work when they’ve already done the work for you.

Pulse

At a certain point of complexity, it can be challenging to figure out “what is the app doing right now?”—especially for networking. Pulse is a wonderful tool not only for capturing what’s happening with your URLSession requests but also for displaying it in an easy-to-understand way right in the app itself. This lets you dive into a problem immediately when it’s occurring, rather than having to work through console logs that may or may not exist yet. It’s also wonderful when a tester or product owner encounters a problem on their device because Pulse makes it easy to share those logs as well.

Credit: Pulse

The interface they provide out of the box is easy to understand, and makes it so much faster to track down what went wrong and when. You can even add your own custom logs that can be displayed intermixed with your network logs, to track down particularly challenging issues.

WhatsNewKit

Sometimes you just have to tell your users what a great job you’ve been doing on the app they love. WhatsNewKit makes it easy to display this information quickly and informatively, while still providing a great deal of customization. It also includes a built-in versioning system to make sure you’re displaying the correct information to the user for the current version of the app.

Credit: WhatsNewKit

With WhatsNewKit, you can focus on building new features instead of spending all that time figuring out how to tell users about them.

AcknowList

Last but certainly not least, here’s a tool for acknowledging the creators who have helped you make the app you wanted to. It’s important to give credit to our helpful third-party developers, and AcknowList helps you do just that by providing an easy way of displaying all those dependencies. Once it’s set up, it will automatically keep itself up to date as well, so you’ll never have to worry about it again.

Credit: AcknowList

AcknowList has an easy-to-use API for both UIKit and SwiftUI, so you only have to spend a few minutes to acknowledge the hundreds of hours these wonderful humans have saved you.

Morphology in Swift

Michael Liberatore — Tue, 03 Sep 2024 00:00:00 GMT

Morphology has been around for a few years now in Foundation, providing some seriously powerful conveniences for user-facing text, albeit with very little fanfare. With it, we can simplify logic around pluralization and gender as they relate to grammatical agreement, letting the system APIs do the heavy lifting. If you’ve heard of these APIs at all, you’re probably familiar with their headlining, and arguably magical, feature: inflection in interpolated strings.

Swift

// Produces the following in English depending on the value of `count`:
// - 0:  You have 0 new messages
// - 1:  You have 1 new message
// - 2+: You have 2 new messages
Text("You have ^[\(count) new message](inflect: true)")

If you’re not familiar with this, I encourage you to read through Jordan Morgan’s excellent post, Morphology in Swift, to wrap your head around this concise, yet powerful, concept.

That’s great, but my string doesn’t include a number 🤷‍♂️

You’ve come to the right place! We similarly struggled with wanting to use this feature without compromising what our designer had in mind for the UI. This is surprisingly difficult to search for, so congratulations on making it here.

When the user receives one or more messages, we want to let them know using natural language without displaying the count.

So is this possible with inflection and string interpolation? Yes… Kinda.

After scouring the internet, picking up hints from forum discussions, finding bits and pieces in Apple’s documentation (like Morphology.GrammaticalNumber), and leveraging the fact that Foundation is open source (see Morphology.swift), we found a working solution:

Swift

// Result: New Message ✅
Text("^[New Message](morphology: { number: \"one\" }, inflect: true)")

// Result: New Messages ✅
Text("^[New Message](morphology: { number: \"other\" }, inflect: true)")

What’s new here is the morphology structure. We haven’t been able to find sufficient documentation, but the aforementioned Swift forum discussion and some Apple-provided sample code put us on the right track. After all, if it’s possible to specify a partOfSpeech in this morphology structure, why not a grammatical number?

Through trial and error, we attempted to figure out exactly what to specify here. Since partOfSpeech works in the morphology structure, we’re reasonably sure we could use number, as both match their respective property names on Morphology itself. GrammaticalNumber has six cases we can choose from:

Swift

// From https://github.com/apple/swift-corelibs-foundation/blob/018d8ef5497d030d0bce19b84764012c211d927d/Sources/Foundation/Morphology.swift#L45-L52
public enum GrammaticalNumber: Int, Hashable, Sendable {
	case singular = 1
	case zero
	case plural
	case pluralTwo
	case pluralFew
	case pluralMany
}

So naturally, we tried to plug these in, using their symbol names directly:

Swift

// Result: New Message ❌
Text("^[New Message](morphology: { number: \"plural\" }, inflect: true)")

But that didn’t work.

Back to digging. If we look at the implementation of Morphology.GrammaticalNumber, we can see that it has a custom Codable implementation, specifying other names for each of these cases:

Swift

// From https://github.com/apple/swift-corelibs-foundation/blob/018d8ef5497d030d0bce19b84764012c211d927d/Sources/Foundation/Morphology.swift#L142-L168
extension Morphology.GrammaticalNumber: Codable {
    public init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        switch try container.decode(String.self) {
        case "one":   self = .singular
        case "zero":  self = .zero
        case "other": self = .plural
        case "two":   self = .pluralTwo
        case "few":   self = .pluralFew
        case "many":  self = .pluralMany
        default: throw CocoaError(.coderInvalidValue)
        }
    }
    
    public func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        switch self {
        case .singular:   try container.encode("one")
        case .zero:       try container.encode("zero")
        case .plural:     try container.encode("other")
        case .pluralTwo:  try container.encode("two")
        case .pluralFew:  try container.encode("few")
        case .pluralMany: try container.encode("many")
        }
    }
}

Assuming that Codable is used to read and write morphology (see MarkdownDecodableAttributedStringKey), we tried again using the encoded representation of plural, which is "other":

Swift

// Result: New Messages ✅
Text("^[New Message](morphology: { number: \"other\" }, inflect: true)")

And that gives us exactly what we want!

Great, so how should I use this?

This is where things get a bit complicated and less convenient. Using interpolation to provide the value for number in the morphology structure is not supported. See the following example:

Swift

// Result: New Message ❌
let number = "other"
Text("^[New Message](morphology: { number: \"\(number)\" }, inflect: true)")

So to extrapolate, we can’t compute the value to use for number based on a count value that we know, e.g. let number = (count == 1) ? "one" : "other", and then use it with interpolation to produce the desired result. We could interpolate the actual text and use conditional logic based on our known count, which works:

Swift

let text = "New Message"
if count == 1 {
    // Result: New Message ✅
    Text("^[\(text)](morphology: { number: \"one\" }, inflect: true)")
} else {
    // Result: New Messages ✅
    Text("^[\(text)](morphology: { number: \"other\" }, inflect: true)")
}

But syntactically, that’s far less than ideal as it defeats the purpose of this being a concise approach — not to mention that we haven’t covered edge cases like -1 in English, which should read singular (irrelevant to our UI, but still), nor have we set ourselves up for success with differing pluralization rules in other languages.

Maybe if we cover all six cases (Morphology.GrammaticalNumber), we can make some nice extensions out of this, starting with converting our known Int to a Morphology.GrammaticalNumber, then switching over that instead of using if statements like we did above.

Swift

extension Int {
    var grammaticalNumberValue: Morphology.GrammaticalNumber {
        switch self {
        case 0: .zero
        case 1: .singular
        case 2: .pluralTwo
        case 3: .pluralFew
        case 4...Int.max: .pluralMany // Is this even right???
        default: .plural // I don’t know???
        }
    }
}

Hmm… we have to ask ourselves some tricky questions here. What’s the difference between plural and pluralMany? Is pluralFew actually 3? if you take a look at Apple’s docs, they don’t help to disambiguate:

case pluralMultiple persons or things, as used for a grammatical number.

case pluralFewA small number of persons or things, as used for a grammatical number.

case pluralManyA large number of persons or things, as used for a grammatical number.

“Multiple”, “A small number”, “A large number.” We’d need more precision than that to continue with implementing extensions. After all, we need to supply the right grammatical number associated with any possible Int. If you do a bit of searching around this phrasing (e.g. two, few, many, and other) you might stumble upon The Common Locale Data Repository, or CLDR for short. Lingohub provides a nice chart that lists languages along with the values/ranges that belong to each category:

Source: Lingohub, Pluralization (p11n) - the many of plurals. There are more languages than appear in this screenshot.

The categories exactly match the cases available on Morphology.GrammaticalNumber, so if this is the standard Apple is using, our extension is inherently wrong. “Few” does not necessarily mean “3,” and other categories vary by language (see the official guidelines here). We can see that, suspiciously, English only has values specified for “One” and “Other.” Up to this point, we’ve only used one and other for our morphology number value. But surely, zero would work correctly, right?

Swift

// Result: New Message ❌
Text("^[New Message](morphology: { number: \"zero\" }, inflect: true)")

Wrong. In English, we’d expect the phrase to read “New Messages.” After all, you’d never say “You have 0 new message.” You’d say “You have 0 new messages.” So while perhaps the chart is right, our result is undesirable. But what about the first example in this post that actually uses the count in the string?

Swift

// Result: You have 0 new messages ✅
let count = 0
Text("You have ^[\(count) new message](inflect: true)")

It does work this way. It’s just sadly not the solution to our problem of trying to exclude the count from the string.

And just to be certain that we haven’t messed anything up syntactically (we are working with strings and stringly typed APIs after all), we can write a fully type-checked expansion of this:

Swift

let morphology: Morphology = {
    var morphology = Morphology()
    morphology.number = .zero
    return morphology
}()

let string: AttributedString = {
    var attributedString = AttributedString(localized: "New Message")
    attributedString.inflect = InflectionRule(morphology: morphology)
    return attributedString
}()

// Result: New Message ❌
Text(string.inflected())

But that doesn’t work either.

So rather than “how should I use this?”, perhaps the right question to ask is…

Should I even use this?

That depends on your specific conditions. Consider our working conditional example snippet from earlier:

Swift

let text = "New Message"
if count == 1 {
    // Result: New Message ✅
    Text("^[\(text)](morphology: { number: \"one\" }, inflect: true)")
} else {
    // Result: New Messages ✅
    Text("^[\(text)](morphology: { number: \"other\" }, inflect: true)")
}

We feel comfortable using this only if specific conditions are met and tested:

We know the user will never have a negative number of messages.
We know that the UI is not shown when there are zero new messages.
We know that this app will only be used in English and possibly other languages that solely utilize the “One” and “Other” CLDR categories.

So it’s a fairly limited use case. But is it better than the following?

Swift

if count == 1 {
    Text("New Messages")
} else {
	Text("New Message")
}

Not really. The best we could do is extract this conditional logic of one vs. other to an extension, provided that all use cases of our new API meet the general conditions discussed above.

Swift

extension Text {
    init(_ text: String, countToInflect: Int) {
        if countToInflect == 1 {
            self.init("^[\(text)](morphology: { number: \"one\" }, inflect: true)")
        } else {
            self.init("^[\(text)](morphology: { number: \"other\" }, inflect: true)")
        }
    }
}

Then, future use cases can be simplified:

Swift

// Result: New Messages ✅
Text("New Message", countToInflect: 0)

// Result: New Message ✅
Text("New Message", countToInflect: 1)

// Result: New Messages ✅
Text("New Message", countToInflect: 2)

But again, we want to make sure this is only used in situations where our very limited conditions are met. Extracting it to an easy-to-use extension runs the risk of someone using the extension without fully understanding its limitations and implications. If you choose to go this route, be sure to provide clear documentation.

Other considerations and disclaimers

While we can’t find specific documentation pointing to the encoded morphology structure to support the use case here, we don’t believe it to be considered usage of undocumented APIs in the “reject your app” kind of way. It’s just not documented well enough to infer the behavior discussed in this post. Attributes like inflect are commonly used in shipping apps and appear in WWDC sessions, and morphology: { partOfSpeech: \"noun\" } appears in Apple’s sample code. You can even create your own attributes to use in markdown syntax using MarkdownDecodableAttributedStringKey.
While the behavior seen when using the Morphology.GrammaticalNumber.zero was initially unexpected, given what we learned about CLDR, we don’t think this is a bug.
These morphology features are not supported in every language. Initially, only English and Spanish were supported. According to WWDC23: Unlock the power of grammatical agreement, the list of supported locales now also includes French, Italian, Brazilian Portuguese, European Portuguese, and German. If your app supports only a subset of these, and you put in adequate testing time, you can consider using this solution.
Automatic grammar agreement isn’t the only solution to pluralizing strings. String catalogs provide a robust solution for pluralization that’s compatible with far more languages.

In conclusion…

While this specific use case isn’t something we’ll reach for in every project, it’s always fun to have a hunch that something should be possible, dive deep down into the rabbit hole, and come out learning a whole lot more than you bargained for. Morphology in Swift is a complicated topic that’s made fairly easy to use through nice APIs. In the coming years, we hope to see more language support and improved documentation to reduce the number of caveats to consider before leaning on this powerful solution.

TL;DR

Is it possible to achieve automatic pluralization in Swift without a number appearing in the string?

Yes

Is it concise to do so?

Fairly:

Swift

Text("^[<#string literal or interpolated string here#>](morphology: { number: \"<#`Codable` string representation of a `Morphology.GrammaticalNumber` here#>\" }, inflect: true)")

// For example…
// Result: Dogs
Text("^[Dog](morphology: { number: \"other\" }, inflect: true)")

Does it work in every language?

Should I use it?

Only in carefully considered circumstances, and provided that the code savings are worth it to you.

The New Lickability

Team Lickability — Thu, 15 Aug 2024 00:00:00 GMT

Lickability has evolved a lot over the past 15 years. What started as a group of three friends grew into a company of great folks making apps that we’re proud of and that reach millions of people worldwide.

Our old logo, with the tried and true cursive “L”

In that time, the Lickability brand has grown alongside us — that classic cursive “L” accompanied us to different offices and website iterations, and adorned plenty of business cards, pins, stickers, and hoodies. We even put it on a custom ice cube stamp for company holiday parties! It has served us extremely well.

The circle “L” was everywhere

The Lickability of today is not the same Lickability that existed 15 years ago. The landscape of our industry has changed, and we’ve changed along with it. When iOS apps were just starting to take center stage, we carved out a niche for ourselves, crafting apps that stand shoulder-to-shoulder with the industry’s best. Now, our clients are looking toward us to help with more than apps — we shape design systems, build backends, and ship cross-platform software.

To compliment our evolution, it’s time for our brand to evolve, too. A little less than a year ago, we decided to start the search for the next version of Lickability. Today, it is officially here — it’s real, we love it, we’re excited, and we’re ready to share it.

The beginning

You may have seen the new logo somewhere already, and you’re probably reading this on our redesigned website. So while you get better acquainted with our new look, let’s jump back a few months to talk about the journey we took to get here.

It started, as many things do, with a Notion document. We put together a “Lickability Brand Brief” to use as a roadmap of where we wanted to go. It came in handy when we started reaching out to branding agencies to find the perfect partner.

We talked to lots of folks — we told them our story and explained what we were looking for — before meeting Radialinear, the wonderful Chicago-based studio that we ended up working with. They got to know us over a handful of weeks, helped us figure out who we wanted to be, and walked us through many possible versions of our new visual identity. We were lucky to partner with people who understood us so well.

The process

Working with a branding agency was pretty eye-opening! We knew we wanted to do a “brand refresh,” and we had our story packaged up in a nice little document, but it turns out it’s hard to distill 15 years of company history into the essence of who we are and how we want to present ourselves to the world.

Luckily, we were in good hands with Radialinear. We started with a “brand discovery” phase, where we got the whole team together for some collaborative exercises to help us figure out what “Lickability” means to each of us. We went into this project thinking we already knew our brand well, but we quickly learned that there was so much more to think about. This was a crucial first step, and it turned out to be a lot of fun.

After doing some more behind-the-scenes research to learn about our company, they helped us nail down our brand strategy & identity — our mission, our personality, and our core values. Then we were ready to get to the real fun part: the visuals.

The final moodboard

Some early concepts

We started by reviewing moodboards from Radialinear, pointing out the things we liked and didn’t like until we had a solid base of inspiration to draw from, including everything from 2000s Mac OS X to 1960s peace posters. From there, we spent a few weeks trying out different visual directions — shapes and colors, logos, typography, etc. — until all of the work finally culminated in a finished product. We found something that felt right.

The final form

This is the new Lickability. Except, not really — we are the same company as we were a year ago. But now we know ourselves a little better, we’re more confident in what we’re doing, and we have a shiny new logo to put on our business cards and stickers. (Time to order a new custom ice stamp!)

Our new logo

Our new glyph

We’re very glad we worked with Radialinear on this project. They made the whole process enjoyable, and we couldn’t be happier with the end result. Their founder, Amy, also left us with some nice parting words:

From our first conversation with the Lickability team, it was apparent that they care deeply about the people who interact with the apps they build. This passion, paired with their craft and playfulness, fueled a truly joyful brand design system. It also inspired their brand positioning statement: “People who love to build apps that people love.” This focus on the humanity behind digital products already set Lickability apart from the rest as a company, and now their brand reflects that.
Lickability is such a fun name, and inspired a lot of logomark explorations. The final logomark speaks to the name and its origins in a famous Steve Job quote, while also referencing progress, iteration, and app loading screens. The mark also balances the duality of Lickability – detail-oriented experts who are full of personality.
It’s not often we make a brand system that we wish we could steal for ourselves. We’re immensely proud of this work, and so thrilled to have partnered with the wonderful humans at Lickability.
Amy Schwartz, Radialinear

Our new typography guidelines, featuring Reckless Neue and ABC Diatype

Our new color palette

In the months since they handed us the deliverables, we’ve been building up our brand assets in the shadows, not yet ready to step out into the light and show off our new look. Turns out, rolling out a rebrand is not quite as simple as slapping a different logo on some stuff and calling it a day — there was a lot of work that still had to be done.

The first thing we did was change our Slack workspace icon. That’s how you know it’s serious. We also ordered a batch of new business cards for everyone, got some new pins and stickers to give out at conferences, and designed some new shirts for our Cotton Bureau store. If you have any of our old merch, congratulations — that’s a rare, vintage collectible now.

Redesigning our website has been the biggest part of the project. We’ll save the fun details for another day, but we’re happy to officially present the new Lickability.com! It’s been a real labor of love over the past few months, and it feels great to finally be able to show it off.

The future

We spent nearly a year figuring out how to evolve our brand into something that represents where we’ve been and where we‘re headed, and we’re proud of the result. Changing a logo that’s been with you for a decade is scary, and digging deep to refine the principles you use to do your work every day is even scarier. But it’s also really rewarding to get it right.

Lickability will continue evolving — it’s impossible not to when you have the chance to work alongside so many brilliant, passionate people. So, as we grow, we hope that this brand identity will grow with us as we tackle new, challenging projects and ship even better software.

Our WWDC24 wish list

Team Lickability — Thu, 06 Jun 2024 00:00:00 GMT

We shared our hopes and dreams with you before Apple’s developer conference last year, and now we’re back with a whole bunch more. Fingers crossed that all of our wishes will come true next week! 🤞

Sam Gold

There comes a time in every idea prototyping cycle when you face the facts and have to switch a SwiftUI List to a LazyVStack because List just won‘t cut it anymore.

So you either forge deeper and design around the limits of List, introspect some undesirable behavior away, or give up on List entirely and use some other container. Which is a shame; there are so many benefits to using a List when something is semantically just a List. Deletion controls, accessibility hints, swipe actions, headings, etc.
So my wish is full design control over Lists. No more goofy header size hacks, no more automatic implicit padding you can‘t get rid of, bridge the gap with the .onDelete modifier adding a delete accessory but not having an .onInsert for the green add button accessory. I should be able to use any stock UITableViewCell accessory from SwiftUI.

Oh, I forgot one thing: Siri default apps. I would love to just use Siri without having to stipulate “remind me to do something in Things” or “play this album on Spotify”.

Tom DeVuono

I’d like to see 3rd party watch faces, blood pressure readings for watchOS, and improved green bubble texts.

mb

I’m hoping that this year’s WWDC brings thoughtful integration of LLMs across Apple’s OSes, performance and reliability updates for core serves, and a few power-user tweaks I’ll use every day.

On iOS and iPadOS, my wishlist includes a Home screen redesign, customizable Lock Screen quick actions, and better notification management. I’m also looking forward to potential improvements in macOS, like a notifications redesign and Live Activities, as well as custom watch faces on watchOS.

For developers, I’m excited about the possibility of Xcode for iPad, a Copilot-like assistant in Xcode, and API access for local and cloud LLMs.
For the my full wishlist, check my blog post.

Michael Liberatore

This year, in addition to the hundreds of API treats I haven’t even thought of, I’m hoping for some solid developer quality-of-life additions.

At the top of my wishlist is integrated device mirroring in Xcode. These days, I do a lot of native Android development in addition to iOS, and one huge boost to my productivity is using Android Studio’s device mirroring feature. Don’t get me wrong, the iOS simulator is a godsend. But there are so many things it understandably can’t naturally do, requiring physical hardware (e.g. taking photos, tracking health metrics, etc). Android’s device mirroring allows you to always have your device’s screen streamed to your IDE, BUT! you can also interact directly with it using your mouse and keyboard, just like a simulator. I was blown away the first time I got to use this feature, and I think it’d make a great addition to iOS development workflows.

Like others, I’m also hoping for a first-party Copilot-like LLM integration in Xcode to speed up routine coding tasks and suggest approaches. I’m very curious to see if and how Apple aims to provide comparable results to competitors, but with a focus on privacy and reduced energy consumption.

Lastly, and not to sound like a broken record, I’d LOVE for stale, outdated errors in Xcode to be a problem of the past. Everyday I spend at least a minute questioning whether the errors in my issue navigator are real, or a fragment of former lines of code, and I sincerely hope those days will be behind us soon.

Jillian Meehan

I just want one thing this year: an actual “Now Playing” Home Screen widget. If you can show me whatever I’m listening to in other places — on the Lock Screen, on my watch, in Control Center on my Mac — then it shouldn’t be too hard to put that in a nice little widget, right?

More widgets in general is always my wish — how about some more widgets for Apple Health? Or the new Sports app?

Michael Amundsen

I really want to see SwiftUI APIs have a much parity as possible with their underlying UIKit types. If the underlying type has something exposed like say contentOffest, I should be able to easily access that in a SwiftUI List. That is a huge undertaking so even better yet, open source SwiftUI in the way they did with Swift so the community can help expand, fix, and improve upon it.

As a developer, make it so an iPad is relevant to my workflow. Ideally, I’d love for it to be viable to take an iPad into another room or place instead of my laptop and be able to continue my workflow.

I’ve been spending a lot of time in Android Studio as of late and it make going back to Xcode in some key areas difficult. The ability to integrate AI chat bots and suggestions both first party and third party would help a lot. Device mirroring and ability to control a physical device inside of Xcode like a simulator would be huge.

Your app doesn't need a chat feature

Sam Henri Gold — Tue, 07 May 2024 00:00:00 GMT

At Lickability, we get a dozen or so pitches for app ideas per week. I’ve noticed a worrying trend emerging throughout a fair number of these pitches: a chat feature.

On its face, it’s an obvious fix to whatever issue you’re running into. Trying to increase user engagement? Let users chat with each other inside the app. Community building? Mega group chats. Support and feedback channels? Sounds like a chatbot.

The cracks begin to show when rubber hits the road and we start thinking about things critically.

Chat is Noisy

At the very highest level, the core issue with adding a chat feature is that it dilutes the potency of your app. What makes an app sticky at launch is being really good at a very specific thing — not an app that immediately covers every possible base.

Imagine if Instagram, in its infancy in 2010, had tried to pack in everything from day one: messaging, photo sharing, video, stories, shopping, and live streaming. It would have sunk.

Instead, they started with a simple killer feature—transforming lousy cell phone photos into share-worthy images. The rest was drip-fed over 15 years. Instagram DMs didn’t even appear until four years post-launch.

Start with your core idea. Avoid drowning it in feature overload.

Chat is Insular

This may be obvious, but it’s worth stating: when you create an insular chat feature, you limit who you can chat with to only other users.

If one of your users finds something in your app that they really want to share with a friend, they first need to persuade them to download the app, sign up, possibly follow each other, and then share the content. At each step, the likelihood of the friend reaching the finish line drops by 15%.

But what’s almost 100% guaranteed is that if someone wants to share content in your app with a friend, they probably have that friend’s number or Messenger or WhatsApp or Telegram or Signal or Discord or Slack or Snapchat. And all of those apps support rich links. Engineering time is better spent getting that experience frictionless and great — meet potential users where they’re at.

Chat is Expensive

If your chat feature isn’t about sharing content, there’s a good chance there’s already a product or company out there that exists solely for your type of use case. For instance, if you need users to chat with support, Business Chat might be a good option. And it’ll almost certainly be magnitudes less expensive than building a bespoke chat feature.

I fully recognize this is counter to our bottomline as an app development agency, but removing a chat feature will save so much in your budget that can be better spent on things that your users would appreciate more.

For instance, plussing your app to make it a joy to use and have it work seamlessly with the system. Or adding first-class support for rich link previews like I mentioned above.

Chat is Messy

Scaling

As your app (hopefully) grows, you will need to scale the chat infrastructure up and up and up. And it’s not as trivial as throwing a more expensive AWS machine at it — there’s a reason why Meta has hundreds of people working solely on Messenger. Chat has a bunch of hard problems intrinsic to the nature of the product. Why would you want to be restrained by those problems if chat is just an afterthought?

Baggage

When you add a chat feature, you immediately take on the intrinsic baggage that comes with it. Where are you going to store messages? What about the attachments that could be orders of magnitude larger than a text message? How are you going to protect them? How are you moderating user-generated content for inappropriate behavior?

It’s a lot of heavy lifting for something that might not even align with your app‘s core value.

User expectations

Chat apps have gained a lot of features recently that users expect to be standard — reactions, in-line replies and threading, attachments, rich text. These features aren’t intrinsic, and a chat feature without those might end up feeling like a 2000s AIM client.

We have enough chat

It’s 2024. We have accounts everywhere. There are probably 100 apps on your phone, a good chunk of which can send notifications.

I wake up every morning and check Bluesky, Discord, Instagram, Mastodon, LinkedIn, iMessage, Snapchat, Threads, X, TikTok, Slack, my email, my Figma notifications, and my todo list inbox.

Your app‘s biggest draw might just be offering a sanctuary from notification overload, and offering a hyper-focused experience. Something that distills your secret sauce to its purest ingredients.

With all this in mind, these points are just guidelines. Convinced your chat feature breaks the mold? I’m all ears. Reach out, and let’s see what we can build together.

How to learn The Composable Architecture

Andrew Harrison — Thu, 18 Apr 2024 00:00:00 GMT

If you’re like us, it can feel a little daunting to pick up a new software architecture, especially once you’ve learned the ins and outs of another one already! Even if you aren’t planning on switching to or starting your app with a new architecture, it can be really beneficial to check out new ways of doing things. You never know what you might learn that might help!

This post is not an attempt to teach you how to use The Composable Architecture (TCA). Instead, we’re going to provide a good path for how to get started with learning the framework. The fine folks at Point-Free have done an excellent job with providing resources, but we know it can feel overwhelming to jump into something for the first time and not know where to start.

First, in order to use something, you need to know what it is! Fortunately, that’s answered pretty readily in the Readme of the Swift Composable Architecture GitHub page. Not only does it clearly define the What and Why of TCA, it provides a large number of examples, documentation, and other resources to help you really understand how to accomplish your goal of making a well-engineered app. We recommend at least reading the “What is the Composable Architecture?” section, and skimming through the rest to familiarize yourself with some terminology.

Next, if you’re looking for a practical way to start learning TCA, follow this great Getting Started guide. It walks you through the basics of building and testing a feature in an easily digestible manner. We find practical implementation of concepts to be a great way to solidify those ideas after reading. This guide not only illustrates the key concepts but also explains how testing works in TCA, which is a core benefit of this architecture.

Some of the concepts and naming standards are pretty different than what you might be used to from Apple tutorials on Swift or SwiftUI, like Reducer or Effect. It’s a good idea to take time to understand them in detail. Now that you’ve had a chance to learn and use some of those concepts already, we recommend following along with the first chapter of tutorials provided by Point-Free. It’s a great way to reinforce the ideas you’ve learned about, to make sure you understand the foundations you’re going to build upon.

Next is a video series called “A tour of the Composable Architecture,” which will give you a look at a number of important concepts through the lens of TCA, like navigation and persistence. This will be invaluable as you expand beyond the simple examples from the previous steps, and also provides the information in a different, more visual format if you’re not a text-based learner. Much of the video content is subscriber-only, but you can watch one video for free to get a taste — and we highly recommend subscribing if you’ve made it this far!

Finally, return to the interactive tutorials, focusing on Chapter 2 this time. This is a more in-depth look at navigation, and gives you insight into how to start handling more complex interactions between features and screens. This will help solidify a lot of what you’ve learned from previous sections.

Learning with a team

For other agencies, there are a few ways you can support your team as they learn together — you could open a Slack channel for people to ask & answer each other’s questions, watch videos together with a group discussion afterward, and work through coding challenges. Point-Free also has special pricing for teams of two or more people, so you can get everyone on the same subscription plan.

Wrapping up

To summarize, we recommend following these steps to start your TCA journey:

Check out the README to understand the fundamentals & terminology
Follow the Getting Started guide
Do Chapter 1 of the Point-Free tutorials
Dip into the video series
Do Chapter 2 of the Point-Free tutorials

All of these helpful resources will expose you to the core concepts of The Composable Architecture. Whether you’re someone who was already interested in checking out TCA or someone who hadn’t heard of it before, hopefully this gives you a little push into checking out something new!

Our Apple Sports design critique

Sam Henri Gold — Wed, 27 Mar 2024 00:00:00 GMT

A few weeks ago, Apple did a surprise announcement of Apple Sports, a new app for sports fans. We do internal design critiques quite often, but we noticed a few things worth mentioning for designers and developers thinking about modern iOS design practices.

This app remixes stock UI components in really interesting ways. We once heard someone say, “design your app for the current iOS version + 1.” So with that lens, we’ve been looking at what the design of Apple Sports can tell us about iOS 18.

Apple has been playing with navigation bars a lot recently. We could probably write a whole post about just the nav bar. Take a look at how it stretches during over-scroll and transitions to a squished state when collapsed:

Gradients are used a LOT in this app. This nav bar gradient effect is becoming pretty common throughout first-party apps as well — first with the iOS 17 Health app, then Journal, and now Sports. watchOS 10 is also full of gradients.

The Journal app is entirely gradients!

Take a look at the “Yesterday / Today / Upcoming” picker right above the list. This is functionally a segmented control, but they did not opt to use the stock style. Instead, they’re making heavy use of the system-provided vibrancy effect. The default control is blockier and stands out more, which wouldn’t make a ton of sense in this context where it isn’t a super important control.

If you’ve used the new iOS Design Library in Figma and noticed color styles like “Vibrant Secondary Dark,” you’ll see this effect emulated. This isn’t 1:1 with the actual iOS implementation, but it’s a good visualization.

In dark mode, a standard secondary label color is just off-white at 60% opacity. But the vibrant label styles are more complex — they let the background color shine through by stacking multiple fill colors with various blend modes.

There’s a lot of fun typography, too! Take a look at the score numbers — these use the system variable font features to make the weight bold and the width compact. We love messing with the font width axes for display type to see what effects we can achieve.

This is also the first time we can recall a super dense data grid in a first-party app. These are always a huge pain to construct, but they’ve implemented this really well. Take a look at what happens when you increase the Dynamic Type size, too:

Finally (and this is a big one): motion backgrounds. It’s easy for an app to feel lifeless when it’s just displaying static data, like the Weather and Sports apps. It’s really hard to get right, but they’ve implemented this animation quite well.

It’s hard to tell what’s going on, but here’s our guess: There are two color swatches where the exact gradation point shifts a little bit (maybe ± 10% from the middle). Highlights shimmer on top of that gradient. Then, underneath it all, this cloth texture we extracted from the app bundle is tiled and warped by a Metal shader.

Will iOS 18 include more apps with this jersey cloth texture? Almost certainly not. But to make your app feel ahead of the curve, you gotta (and excuse the cheesiness) skate to where the puck is going to be. And the puck is headed towards a lot of gradients, motion, and remixing the nav bar in fun ways.

Monetizing your app with Superwall

Team Lickability — Tue, 27 Feb 2024 00:00:00 GMT

You may already know us as a RevenueCat partner — now, we’re adding a new partnership with Superwall to the mix so we can do even more to help our clients monetize their apps.

👋 Meet Superwall

It is a truth universally acknowledged that if you want to monetize your app, you’re going to need a paywall. That’s where Superwall comes in: using one of their many templates, you can build and deploy beautiful paywalls easier than ever before. Once the Superwall SDK is set up in your app, all it takes is a few clicks on their dashboard to customize your paywalls with their drag and drop editor — no app updates required.

As an added bonus, they’ll use their expertise to help you craft your first unique paywall for free:

Superwall has built hundreds of paywalls for clients and has a unique vantage point on the industry. As a token of gratitude for signing up, we create a paywall for each customer, using best practices we’ve picked up along the way.

— via the Superwall documentation

🐱 What about RevenueCat?

Good news: Superwall & RevenueCat play well together, so you can use them both to manage your in-app subscriptions with no problems. (Psst, did we mention we’re also a certified Premier Partner of RevenueCat?)

🏁 Getting started

If you’re an indie developer looking to add a paywall to your iOS app, we highly recommend checking out Superwall’s three-step guide to getting up and running. For design inspiration, it’s definitely worth browsing the hundreds of examples they’ve collected in this paywall gallery.

15 Years

mb bischoff — Mon, 12 Feb 2024 00:00:00 GMT

It’s wild to think about, but Lickability has now been in business for fifteen years. What started as two high school students building apps together over iChat AV has grown to a team of ten talented engineers, designers, and operations folks creating beautiful software used by millions of people.

I covered the first ten years of our history a previous blog post, which focused on our start as a small product team and growth into a small studio. The last five years of our story have been shaped by a global pandemic, and our resilience and ingenuity as the industry has matured.

2020

2020 was the year we learned how to be productive as a fully remote team. In response to the pandemic, we closed our office and started using Zoom, held virtual happy hours, and released Buildwatch to help developers track and reclaim their time spent compiling.

We hired our first full-time designer, Sam Gold. And we worked with incredible clients like Clubhouse, Pair Play, Mixtiles, and Fountain to ship new mobile experiences that were informed by the pandemic and helped people find friends, dates, and jobs online as the world remained locked down.

2021

As we closed our office and transitioned to being fully remote, we experimented with more ways to engage with the wider developer community with our live show Club Mobile, #iOSDevTips thread, talks at universities, and WWDC Discord.

We continued our long-running partnership with The Atlantic and took on new projects with clients like Mastodon and Flavrs, where we got to own both design and development. In May, we shipped another new app of our own, Scorecard , for tracking scores in tabletop games.

2022

Our first company retreat in Brooklyn brought the team together in person, and gave us space to reconnect and plan for the next fifteen years of Lickability. Our engineers spoke at conferences around the world as the community began gathering IRL again, we redesigned our key documents , and dropped a playlist containing years of music recommendations that power our teams.

Ken joined the engineering team full-time, and our client roster grew to include Loop Golf, MusicSketch, and Direct Affect, broadening our experience in the sports, music, and philanthropy industries.

2023

Taking the energy from Config and bringing it to New York, 2023 saw the launch of our Design Friends meetup, where we invite designers and developers to hang out and talk shop once a month at one of our favorite local establishments. We also hosted our first webinar on choosing the right technology for your mobile app, launched the Soft Serve newsletter to share insights and links from around the web, and prototyped an app idea within visionOS .

We shipped App Audit as a way for us to get started working with teams more quickly, and we became both a RevenueCat partner and recognized by Clutch as one of the best app development studios in the country.

Onward

Lickability continues to be my favorite place I’ve ever worked, and the only way to keep it that way is to keep improving the way we work together — just as we have over the last decade and a half. To keep treating our people and customers with respect, building software that feels as good as it looks, and having fun doing it.

Thanks for all of your support over the years in building this studio. If you’d like to work together on building better software, I know just the team who’d love to help.

Mastering App Intents: Querying Made Easy

Ashli Rankin — Thu, 01 Feb 2024 00:00:00 GMT

App Intents are one of the most powerful features on iOS, but there is no clear pattern for sharing data and logic between your app and your App Intent. In this post, we will be building a simple to-do list to show how to share data between your app‘s existing data model and an App Intent. We will be focusing on a single item: marking a task in the list as complete. The GitHub repository of this project can be found here if you would like to code along!

Getting started

Let’s start by creating a new file in the Xcode project called CompleteTaskIntent. In this file, create a struct called CompleteTaskIntent, and conform it to the AppIntents protocol. For a more in-depth look into the components for setting up App Intents, you can visit my previous post.

Note: To conform to the AppIntents protocol, you need to add a title and the perform method.

Your file should look similar to this:

Swift

struct CompleteTaskIntent: AppIntent {
        
  static var title: LocalizedStringResource = "Complete Task"
        
  func perform() async throws -> some IntentResult {
      return .result()
  }
}

If you run the above logic in Xcode, open the Shortcuts app, and tap the + button to add a new shortcut, you should see this intent displayed under the “Apps” section of actions to add to your shortcut.

Adding parameters

Now, let’s add our first property: the date.

Swift

struct CompleteTaskIntent: AppIntent {
    
  @Parameter(title: "Date")
  private var date: Date
        
  static var title: LocalizedStringResource = "Complete Task"
        
  func perform() async throws -> some IntentResult {
      return .result()
  }
}

You may notice that date is a non-optional parameter. In this context, we are indicating to the system that this is a required parameter.

Now, lets add our second parameter: the task. Create a new parameter for your task like we did before — this time, the type of parameter is TodoTask.

Swift

struct CompleteTaskIntent: AppIntent {
    
  @Parameter(title: "Date")
  private var date: Date
        
  @Parameter(title: "Task")
  private var task: TodoTask
    
  static var title: LocalizedStringResource = "Complete Task"
        
  func perform() async throws -> some IntentResult {
      return .result()
  }
}

This code doesn‘t compile!

The system is not aware of our app’s data model, so this code does not compile. To expose this “custom data type” to the system, we must put it in a form the system can recognize. In the App Intents framework, the way we do this is to create a new model conforming to the AppEntity.

An interface for exposing a custom type or app-specific concept to system services such as Siri and the Shortcuts app.

– Apple

Once we’ve conformed our model to this protocol, the code will compile.

Apple recommends creating another structure representing the parts of your data model that your intent will supply the information to.

For this exercise, we will extend our data model to conform to the AppEntity protocol. You can add this code to a new file, or to the file containing the data model.

Swift

extension TodoTask: AppEntity {
        
  struct TaskQuery: EntityQuery {
      func entities(for: [Self.Entity.ID]) async throws -> [Self.Entity] {
          return []
      }
            
      func suggestedEntities() async throws -> Self.Result {
          return []
      }
  }
        
  var displayRepresentation: DisplayRepresentation {
      return .init(stringLiteral: "\(title)")
  }
        
  static var defaultQuery: TaskQuery = TaskQuery()
        
  static var typeDisplayRepresentation: TypeDisplayRepresentation = .init(name: "Task")
}

To conform to the AppEntity protocol, we need to implement three properties:

displayRepresentation: DisplayRepresentation: This property defines how the custom type will be displayed in the UI. You can specify the title, subtitle, synomyms and image.
defaultQuery: EntityQuery: This provides the default query to be used when querying and retrieving entities with Shortcuts and Siri. When trying to resolve a parameter, the system will perform these queries to provide entities to be used by the UI.
typeDisplayRepresentation: TypeDisplayRepresentation: A short, localized, human-readable name for the type.

Creating a query

Let’s take a closer look at query creation. According to Apple‘s documentation, when the system needs to retrieve one or more specific instances of an app entity, it asks you to provide a relevant query type — these queries are used at parameter resolution times. When we create our queries, they must conform to the EntityQuery protocol, which has two required methods illustrated below:

Swift

/// The required methods of EntityQuery
struct TaskQuery: EntityQuery {
    
  func entities(for identifiers: [Entity.ID]) async throws -> [TodoTask] {
        return []
  }
            
  func suggestedEntities() async throws -> [TodoTask] {
        return []
  }
}

entities(for identifiers: [Entity.ID]) async throws -> [TodoTask]: This method retrieves entities by their identifiers. Entities that do not match the identifiers will be skipped.
func suggestedEntities() async throws -> [TodoTask]: According to Apple, this method returns the initial results shown when a list of options backed by this query is presented.

Let’s continue — the aim of this intent is to provide a list of tasks for the user to choose from. Lets implement our query, starting with the suggestedEntities method.

Currently, our query object has no notion of the selected date. In order to bridge this gap, we have the handy property wrapper @IntentParameterDependency, which allows us to obtain the intent and its properties. It can be used on objects which conform to DynamicOptionsProvider.

Add the code below to the TaskQuery section above, and build:

Swift

struct TaskQuery: EntityQuery {
        
  @IntentParameterDependency<CompleteTaskIntent>(
      \.$date
  )
  var completeTaskIntent
        
  private let taskManager: TaskManager = TaskManager.shared
  private let calendar = Calendar.autoupdatingCurrent
        
  func entities(for identifiers: [UUID]) async throws -> [TodoTask] {
      return try await suggestedEntities().filter { task in
          return identifiers.contains(task.id)
      }
    }
        
  func suggestedEntities() async throws -> [TodoTask] {
      guard let selectedDate = completeTaskIntent?.date else {
          return []
      }
            
      let startDate: Date = calendar.startOfDay(for: selectedDate)
      let endDate = calendar.date(byAdding: .day, value: 1, to: startDate)!
            
      let foundTasks: [TodoTask] = await taskManager.fetchTasks()
      let filteredTasks: [TodoTask] = foundTasks.filter { task in
          task.createDate >= startDate &&  task.createDate < endDate && !task.isComplete
      }
      return filteredTasks
  }
}

For our querying logic within the suggestedEntites() method above, we ensure the selected date is present. If it isn’t present, we return an empty array. We then get the start of the selected date, and create the end date by adding one day to that. With this logic, we are trying to set up the window that queried tasks with fall within. Then, we also make sure the tasks returned have not already been completed, ensuring we have the most accurate data presented to the user. We then update the entities(for identifiers: [UUID]) method. In this method, we use the suggestedEntites to return the tasks that match the identifiers provided by the system.

Adding a task

At this point in the process, we haven’t created any tasks, so when we run the app or try to execute the intent, we won’t see any options provided.

Let’s change that! Run the app and tap on the plus button on the main screen. A modal view will present itself — add a task there. You should see the task presented on the list once added.

Now that we’ve added a task, let’s execute our intent. Open the Shortcuts app and follow the video below to execute the intent:

You may have noticed that tapping the option in the presented menu does not mark the task as complete in the app. If you take a look in the CompleteTaskIntent.swift file within the perform method, you‘ll see we haven’t added any logic to be executed after the parameter resolution phase has taken place.

Swift

func perform() async throws -> some IntentResult {
    return .result()
}

In the Tasks folder, there is a file called TaskManager that has the ability to add a task to the database. Add this as a property to this object. We will create a new instance of this object within our intent — in the context of Shortcuts and Siri, there is no way for us to inject it as a dependency. (In other contexts, such as within the widget or in the main application, we may be able to inject the TaskManager as a dependency.) The intent file should now look like this.

Swift

struct CompleteTaskIntent: AppIntent {
    
  @Parameter(title: "Date")
  var date: Date
        
  @Parameter(title: "Task")
  private var task: TodoTask
    
  static var title: LocalizedStringResource = "Complete Task"
        
  private var taskManager = TaskManager.shared
        
  @MainActor
  func perform() async throws -> some IntentResult {
      taskManager.markTaskAsComplete(task: task)
      return .result()
  }
}

Now, when you execute the shortcut and select a task once you return to the app, that task will be completed. To make our user experience a little nicer, lets add a view to confirm that the task has been marked completed.

To achieve this, lets create our confirmation view by adding this code to the intent file:

Swift

private var successConfirmationView: some View {
  VStack {
      Image(systemName: "checkmark.circle")
          .foregroundStyle(.green)
          .imageScale(.large)
          .font(.largeTitle)
      Text("Task Completed")
  }
}

To ensure our intent doesn’t crash, we will update our perform method return type to include ShowsSnippetView:

Swift

@MainActor
  func perform() async throws -> some ShowsSnippetView {
    taskManager.markTaskAsComplete(task: task)
    return .result(view: successConfirmationView)
}

Now we can call the result method and pass the successConfirmationView as a parameter.

The app can now open once the task is executed. By default, the value of openAppWhenRun is false — if you’d like to open the app after the task has been executed, update this value to true.

Wrapping up

In this blog post, we’ve explored the intricacies of creating an App Intent for our simple to-do list application. Starting with the basics, we delved into how to define and handle parameters such as the date and task selection, and then integrated them into our app‘s data model. Our journey included conforming to the AppIntents protocol, dealing with the nuances of custom data types, and understanding the importance of entity queries in the AppIntents framework.

As we have seen, integrating App Intents requires a thoughtful approach to app architecture and a deep understanding of both the app‘s data model and the AppIntents framework. However, the payoff is a more streamlined and efficient user experience.

For those who are looking to further explore this topic or apply these concepts in their own projects, I encourage you to experiment with different types of intents and explore how they can be tailored to fit the unique requirements of your app. The possibilities are endless!

Designing Mastodon’s reply safety features

Sam Henri Gold — Thu, 07 Dec 2023 00:00:00 GMT

Lickability has been Mastodon’s design partner since 2021, when we helped design their first-party iOS app (and more recently, their Android app). In 1.0 for each of those apps, there have been the expected safety features — mute, block, and report. But those are very direct and technical tools. Don’t get us wrong, those features are critical to having some level of safety on any online platform. But their reach is limited to what you see, which, by definition, puts the onus on the person who needs it. If someone is bothering you, you’re required to block or mute them.

With two million active users, Mastodon facilitates thousands of conversations regularly. We’d like to see each one be incredibly fruitful, but things are bound to go downhill for any number of reasons. Maybe someone discovers a post by following a hashtag and inappropriately replies with a familiar tone. Maybe they reply in a way that detracts from the main point. Maybe they didn’t realize they’re replying to a post from over a year ago. They might not be malicious, but their reply could feel unwelcome to the recipient all the same. Moreover, blocking/muting/reporting might not be the right “level” of response for this type of interaction.

There was certainly room for a different type of safety feature. We started by looking at other products that allow writing public replies and comments on content.

Competitive research

Back in 2019, which was roughly 400 years ago, Instagram announced an “intervention” feature that combined a prompt with a send delay to give you a chance to cancel sending a comment before it actually went through.

Credit: Instagram

Twitter rolled out a similar experiment that asked users to rethink sending a tweet “if it uses language that could be harmful.”

Credit: Twitter

And YouTube is currently testing their own version of this prompt.

Credit: YouTube

Twitter and Instagram both prompt after you’ve drafted a post that they find to be harmful, while YouTube (and Twitch, for that fact) prompts prior to writing anything — everyone gets the YouTube sheet the first time they comment on a channel.

Instagram’s prompt is the only one where the tone is centered around the product (“Keep Instagram a Supportive Place”) and not the interaction itself. It primarily depends on how much personal resonance the user feels with Instagram, the platform. Feel about that how you wish.

Drafting our prompts

With these references in mind, we started drafting our own prompts. With apologies to Gavin Nelson for being my placeholder user in our initial design concepts:

We liked YouTube’s approach for a few reasons:

You haven’t drafted anything yet, so if you decide against writing a reply altogether, you haven’t wasted any time.
The primary action is, in both cases, to proceed to commenting. We don’t want to hinder conversation, we just want to make the conversation higher quality. In contrast, the action Instagram’s prompt wants you to take is “don’t send this after all,” and Twitter weights their three actions equally.
We wanted to move fast, and since this prompt is happening entirely on device, it does not involve any sort of tone analysis that might tax the hardware.

But this wasn’t exactly right. The copy for the old post prompt didn’t sit right with me. It tells the recipient about the logic gate (post.monthsSincePublished >= 3 ? showPrompt() : simplyDont()) and makes them fill in the blanks. When showing the draft to a few people, we got feedback that the non-mutual prompt is just a wall of text and doesn’t provide any color on who you’re about to reply to. Our next iteration shortened the rule list and included an abbreviated user profile as an inset card.

For final changes, we made the profile photo larger (you should know who you’re interacting with!) and included four lines of text: the first two lines of their bio, and the first two custom fields (key-value pairs). We’ve noticed that people tend to put pronouns or their job title in their custom fields, which gives the prompt recipient some background to avoid potentially misgendering someone or explaining something to an industry expert.

Our final design.

Design learnings

The announcement and rollout went well, with the people who this was designed to help expressing their interest in this feature. It was picked up by the media and was a gay ol’ time.

There were also Opinions in the replies to the announcement post, to be sure. A few people mentioned an interstitial prompt is poor UX and increases cognitive load & friction. But when the feature goal is safety, we’re not really designing for people to cruise through the product — we’re designing to mitigate potential damage. Making things frictionless and letting people think less would be counter to what we’re trying to achieve.

That said, the design above likely isn’t the final final iteration that will stick around for the long haul. We’re still keeping an eye on how people interact with this feature and making changes accordingly.

Successful UX design has often been characterized as design that disappears and gets out of the way to let the user do their thing. It’s partially why Mac OS X’s Aqua interface got toned down over the years from sharp pinstripes to gray gradients:

Credit: 512pixels.net

But thoughtful UX design is willing to step out from the shadows and make itself known if it might benefit the greater good.

Creating your first app shortcut

Ashli Rankin — Thu, 02 Nov 2023 00:00:00 GMT

In iOS 16, Apple released the AppIntents framework to allow developers to more easily integrate their app actions with the system. App actions can be used in various parts of the system like the Shortcuts app, Siri, and Spotlight. Before the AppIntents framework was released, we used SiriKit to communicate our actions to the system — but this had a higher barrier to entry due to little documentation & resources.

One of my favorite features of creating app actions with AppIntents is the ease of prototyping. I can go from an idea to a functioning action in under an hour. With this guide, I‘ll walk you through how to create your first app action for the Shortcuts app.

Before we begin, let’s look at what we’ll need to do to create a simple shortcut:

Conform to the AppIntent protocol.
Add a description
Add your parameter(s)
Handle user input in the perform method

Conform to the `AppIntent` protocol

Start by conforming to the AppIntents protocol. This can be done by giving the action a title, then adding the perform method.

Swift

import AppIntents

struct AddTaskIntent: AppIntent {

  static var title: LocalizedStringResource = "Add task"

  func perform() async throws -> some IntentResult {
    return .result()
  }
}

title: The title of the shortcut to be displayed in the shortcuts app. perform(): The perform method carries out the intent action. For example:

It can carry out any persistence after you’ve acted on the input the user provides.
It disambiguates responses to the user if the system finds ambiguity due to multiple values.
It displays views which are shown to the user once an action has been carried out.

If you want to open the app once the action has been executed, set the openAppWhenRun property to true.

First task completed!

Add a description

A description describes the purpose of the intent — it is an optional property, but we‘re going to add one here as the next step.

Swift

import AppIntents

struct AddTaskIntent: AppIntent {

  static var title: LocalizedStringResource = "Add task"
  static var description: IntentDescription? = "This action allows you to add a new task to your to-do list "

  func perform() async throws -> some IntentResult {
    return .result()
  }
}

Add parameter(s)

In this example app, we want the user to add a task by typing it into a text box or speaking to Siri. To make that happen, we’ll add a parameter to capture user input. Parameters can take many types, from primitives to more complex types such as IntentPerson. For a comprehensive list of possible parameter types, refer to this documentation page.

Swift

import Foundation
import AppIntents

struct AddTaskIntent: AppIntent {

  @Parameter(title: "Task")
  var task: String

  static var title: LocalizedStringResource = "Add task"
  static var description: IntentDescription? = "This action allows you to add a new task to your to-do list "

  func perform() async throws -> some IntentResult {
    return .result()
  }
}

We can add other properties to the parameter property wrapper, such as:

description describes what the property represents. The description added to your parameters will be displayed in the description of the app action.
inputOptions describes how we’d like the input to be styled when using the Shortcuts App. It has properties such as keyboardType, capitalizationType, multiline , autocorrect and others.
requestValueDialog describes the exact phrase we’d like to be spoken in an audio context.
requestDisambiguationDialog describes the phrase we’d like spoken in case of multiple values — to disambiguate between them, Siri will ask the user to choose between the various values.

Our parameter was added as a row below the title. We can make this nicer by adding a ParameterSummary. A ParameterSummary is a sentence that represents the intent and its parameters. Apple recommends that we provide parameter summaries to make the user interface more streamlined.

Swift

import Foundation
import AppIntents

struct AddTaskIntent: AppIntent {

  @Parameter(title: "Task")
  var task: String

  static var title: LocalizedStringResource = "Add task"
  static var description: IntentDescription? = "This action allows you to add a new task to your to-do list "

  static var parameterSummary: some ParameterSummary {
    Summary("Add \(\.$task)")
  }

  func perform() async throws -> some IntentResult {
    return .result()
  }
}

In this example, if you run the shortcut, a text field will be displayed. Tapping “done” dismisses it, but no further interaction occurs.

The system treats your parameter as required or not based on the inclusion of ?. If you don’t add a ? mark, the system prompts the user for input — with the ? mark, the system would continue the execution of the action. If you’d like to request a value for the parameter, use .needsValueError() with the dialog you’d like the system to use to prompt the user.

needsValueError(_:)Returns a restartPerform error with context to request a value from the user for this parameter and re-perform the intent with the new values.

— Apple

Swift

import Foundation
import AppIntents

struct AddTaskIntent: AppIntent {

  @Parameter(title: "Task")
  var task: String

  static var title: LocalizedStringResource = "Add task"
  static var description: IntentDescription? = "This action allows you to add a new task to your to-do list "

  static var parameterSummary: some ParameterSummary {
    Summary("Add \(\.$task)")
  }

  func perform() async throws -> some IntentResult {
    guard !task.isEmpty else {
      throw $task.needsValueError("What task value would you like to add?")
    }
    return .result()
  }
}

Handle user input in the perform method

After establishing what user input you expect, you need to handle what happens when the action is performed.

In this example app, there is a need to persist the input in a task that will be stored locally on the device. In this perform method, the task is created and then persisted. Afterward, a Text view is displayed on successful persistence.

Swift

import Foundation
import AppIntents
import SwiftUI

struct AddTaskIntent: AppIntent {

  @Parameter(title: "Task")
  var task: String

  static var title: LocalizedStringResource = "Add task"
  static var description: IntentDescription? = "This action allows you to add a new task to your to-do list "

  static var parameterSummary: some ParameterSummary {
    Summary("Add \(\.$task)")
  }

  private let persistenceController: PersistenceController = .shared

  @MainActor
  func perform() async throws -> some ShowsSnippetView {
    try persistenceController.addTask(Task(title: task, createDate: .now))
    return .result(view: Text("Task added successfully"))
  }
}

The perform method is executed when the system has resolved all the parameters your code needs to successfully execute its functionality. When implementing logic in the perform method, the logic you add must perform the necessary work that returns the value to the system. This result could include a value that a shortcut can use in subsequent connected actions, dialogue to display or announce, and a SwiftUI snippet view, among other things. If it doesn’t make sense for your intent to return a concrete result, return .result() to tell the system the intent is complete.

If your intent manipulates the app’s user interface, annotate perform() with @MainActor to make sure the function executes on the main queue.
Apple

Note: When we are specifying values to return from the perform method:

If you are returning a SwiftUI View, specify your return type as ShowsSnippetView.
If you are a returning value from the perform method, specify ReturnsValue<T>, and specify the type you wish to return in parentheses. If you provide this value without the type, it will crash your app.
If you would like Siri to speak the output, return ProvidesDialog specifying what output Siri should speak.
If you want to return multiple types of output, specify each type separated by &. For example: ShowsSnippetView & ProvidesDialog & ReturnsValue<T>.

Now that we‘ve completed all the steps, we have the scaffolding for an intent! Using this knowledge, we can also build more complex use cases — we’ll take a look at that in this post .

Useful tips for implementing TipKit

Michael Amundsen — Thu, 19 Oct 2023 00:00:00 GMT

With the launch of iOS 17, I was excited to take advantage of Apple‘s new framework TipKit, and it just so happened I need to implement an onboarding style tip system for a client at the same time. From everything I’ve learned so far, here are my 5 tips for using TipKit.

Tip 1: Customize TipView‘s background, corner radius, or image size

TipView has many of its own view modifiers for customizing how it displays. One of the first gotchas I ran into was trying to change the background color of an inline tip. Normally, you’d use a view modifier like .foregroundColor (which has been replaced by .foregroundStyle) to style the background. Unfortunately, that doesn’t seem to work here — I quickly discovered that you have to use .tipBackground or .tipViewStyle.

Swift

TipView(tip)
    .tipBackground(.blue.opacity(0.25))

As of right now, the tip specific view modifiers for TipView are: .tipImageSize, .tipCornerRadius, .tipBackground, and .tipViewStyle.

Tip 2: Customize the `Text` of the tip directly in the `Tip` itself

Interestingly enough, to customize things about the text of the tips, you apply the view modifiers directly to the Text that is returned as part of conforming to the Tip protocol. Any modifier that customizes Text while returning a Text will work here e.g. .foregroundStyle.

Swift

struct ExampleTip: Tip {
    
    // MARK: - Tip
    
    var title: Text {
        Text("Here is a tip")
            .foregroundStyle(.red)
    }

    var message: Text? {
        Text("Tap \(Image(systemName: "ellipsis.circle")) to explore other ways to join.")
    }
}

Tip 3: Customize the `Image` of the tip with standard view modifiers

Unlike Text, in order to customize the color of the icon used in the TipView, you can use the common view modifiers like .tint.

Swift

TipView(tip)
    .tint(.pink)

Tip 4: You can only configure `Tips.configure()` once per life cycle

Apple has provided ways to tell TipKit to .showAllTipsForTesting(), .showTipsForTesting([ExampleTip.self, ExampleTip2.self]), .hideTipsForTesting([ExampleTip.self, ExampleTip2.self]), .hideAllTipsForTesting(), and .resetDatastore(). You need to call these before you call Tips.configure() — and based on the docs, you should call that on startup. From my tests, any additional calls after that first Tips.configure() will not result in changes.

Swift

struct TipDebuggingApp: App {
    
    var body: some Scene {
        WindowGroup {
            ContentView()
                .task {
                    try? Tips.resetDatastore()
                    try? Tips.configure()
                }
        }
    }
}

Tip 5: Build a debug or testing menu for tips in your app

In my specific use case, I needed to build a special debugging tips menu to allow testers to play with how the tips would appear in the app (e.g. inline vs. popover). It took me a couple tries to get this working well.

I found it more reliable to call Tips.resetDatastore() instead of trying to show and hide specific tips with .showTipsForTesting([ExampleTip.self, ExampleTip2.self]) and .hideTipsForTesting([ExampleTip.self, ExampleTip2.self]).

Swift

struct TipDebuggingApp: App {

    var body: some Scene {
        WindowGroup {
            ContentView()
                .task {
                    try? Tips.resetDatastore()
                    try? Tips.configure()
                }
        }
    }
}

I then set up a view that would allow you to select which tip would be shown, and whether it‘s shown inline or as a popover.

Swift

struct TipDebugView: View {
    @AppStorage(AppStorageKey.showTipsInPopover) private var showTipsInPopover: Bool = false
    @State private var selection: Set<String> = []
    
    private let tips: [any Tip] = [ExampleTip(), ExampleTip2(), ExampleTip3()]

    var body: some View {
        VStack {
            List(tips, id: \.id, selection: $selection) { tip in
                tip.title
            }
            .environment(\.editMode, .constant(EditMode.active))
            .navigationTitle("Tips")
            .onChange(of: selection) { _, newValue in
                UserDefaults.standard.set(Array(newValue), forKey: AppStorageKey.selectedTips)
            }
            .onAppear {
                if let selection = UserDefaults.standard.value(forKey: AppStorageKey.selectedTips) as? [String] {
                    self.selection = Set(selection)
                }
            }
            
            Toggle(isOn: $showTipsInPopover) {
                Text("Display relevant tips as popovers?")
                    .bold()
            }
            .padding(.horizontal, Grid.medium)
            
            Spacer()
            Spacer()
        }
        .background(Color(uiColor: .systemGroupedBackground))
    }
}

Because I used Tips.resetDatastore(), any and all of my tips would show if they didn‘t have a rule customizing how they’re presented. I did want this behavior for testing, but only when a tip was selected. The solution for this is uglier code than I would have liked, but it work well from a user standpoint.

Swift

let tipSelections = UserDefaults.standard.value(forKey: AppStorageKey.selectedTips) as? [String]

if !showTipsInPopover {
    let tip1 = ExampleTip1()
    
    if tipSelections?.contains(where: { $0 == tip1.id }) == true {
        TipView(tip1)
    }
}

Swift

let tipSelections = UserDefaults.standard.value(forKey: AppStorageKey.selectedTips) as? [String]
let tip1 = ExampleTip()

if UserDefaults.standard.bool(forKey: AppStorageKey.showTipsInPopover), tipSelections?.contains(where: { $0 == tip1.id }) == true {
    Button("Example button") {
        // I perform some action.
    }
    .popoverTip(tip)
} else {
    Button("Example button") {
        // I perform some action.
    }
}

I’ve provided a sample project of the debugging menu here, along with a video of the debugging.

I also found a couple of good examples from Jordi Bruin‘s TipKit-Examples repo, which is more up to date than Apple‘s own sample project.

Choosing the Right Technology for Your Mobile App

Team Lickability — Mon, 16 Oct 2023 00:00:00 GMT

Have you heard? Next week, we’re doing our first webinar!

A few of our staff iOS engineers will be co-hosting the webinar to guide you through the landscape of app development frameworks and options. We’ll explore the distinctions between native and cross-platform development, delve into & compare and contrast key cross-platform technologies like Flutter and React Native, and provide examples to help you match your app project with the perfect technology.

If you haven’t signed up yet, you can check out the details and RSVP here. We can’t wait to see you!

Conferences Condensed: NSSpain 2023

Ashli Rankin — Wed, 11 Oct 2023 00:00:00 GMT

Last year was my first time attending NSSpain — I met so many amazing, uplifting people who were super encouraging, and that empowered me to submit my talk to be considered as a speaker this year. I was elated to be selected to speak at the conference, and excited to bring my unique insights to NSSpain.

Along with my own talk, there were several talks I really enjoyed this year. Here’s a look at a few of my favorites.

Run LLMs and diffusion models on Mac & iPhone

Pedro Cuenca

I haven’t played around with LLMs outside of using whisper.cpp to build a quick app that records audio input and translates it to text, which was pretty cool. But one thing that I noticed was the size of the model file — I was curious about how I could reduce the size, so this talk piqued my interest.

Pedro was focused on getting started with using CoreML to add a large language model to your apps, and running diffusion models in apps. He also delved into the pain points of trying to convert PyTorch models to CoreML models. He took us through his journey of debugging when the conversion process crashed and providing a fix for the issue. By investigating and implementing that fix, he made a huge community impact by further allowing others to convert their PyTorch to a CoreML model.

I was also happy to see that Pedro created an app called Diffusers, which allows you to try creating your own AI-generated images from prompts. I’ve played around with Midjourney a bit, and enjoy passing in prompts to see what would come of it, so Pedro’s app was interesting to me.

2 Hours, 2 Days, 2 Weeks

Jordi Bruin

When starting a side project, I always spend so much time thinking about the designs of an app, or trying to make it feature complete, bug-free, and “perfect.” And I become so consumed by these processes that I never ship anything.

Jordi’s talk highlighted that iteration is also an option when developing apps. Starting with something small and imperfect can be powerful in getting something out — and then you can add more to it later.

Jordi has a “2 hours, 2 days, 2 weeks” rule. He explained that when he thinks of an idea, he asks himself if the main concept can be prototyped in 2 hours. If it can, he then spends 2 days getting it into a state where he can test it and distribute it to friends and family. After that, he gives himself 2 weeks to polish and ship the app to the App Store.

He also told us about how he built a team to help with scaling his most popular apps. This was important to him, because he wanted ensure his existing apps were getting the attention they deserved while still leaving time to solve new problems.

One of the main takeaways from this talk for me was that it’s important to lower your expectations when building side projects. It is okay not to have a perfect product before you launch.

Building UI components with SwiftUI

Kasper Lahti

In this talk, Kasper showed the considerations he made when creating custom SwiftUI components — demonstrating swipe actions specifically. He discussed the fact that many components in SwiftUI are customizable, but swipe actions are not as flexible. For example, he has come across cases where the swipe action’s font is different from the font used in the rest of an app, making it look inconsistent.

Kasper’s talk touched on some of the pain points when building custom components, like maintaining large files, which can be tedious if something breaks in a new software release. Finally, he took us through the process of creating a swipe action. He showed some of the code considerations that went into creating his custom swipe action.

This talk taught me not to be afraid to dig into the documentation — you can build complex UIs with SwiftUI, you just need to explore.

Demystifying App Intents: A beginner’s guide

Ashli Rankin

My talk was about why having shortcuts is important for apps, and how I created one based on a problem I had — I spoke about my weight loss journey and using apps to track my progress. I also touched on how to go about creating a simple AppIntent, and we went through the process of using SiriKit.

Then, I talked about why apps should have shortcuts by highlighting that if your app saves people time, it reduces distraction and is more accessible. Finally, we went over some ways to ensure users get the most out of the intents we built by making them discoverable and accessible through prompts — which is important, because anyone should be able to easily use our apps.

This was my first time speaking at a conference, and the whole experience has been extremely liberating for me. I’m so glad I got the opportunity to attend NSSpain again — looking forward to the next one!

What We Love About Android Development

Michael Liberatore — Thu, 07 Sep 2023 00:00:00 GMT

At Lickability, we’re best known for crafting beautiful iOS and Mac apps. Many of our employees have been working on Apple platforms long enough to remember the transition to Objective-C 2.0. Or the transition from manual reference counting to garbage collection (remember??) to ARC. From Objective-C to Swift, from Swift 2 to 3 (that one took us a while 🥵)… you get the picture. In the early days of Lickability, we often needed to turn down work from clients looking to simultaneously build out both iOS and Android apps due to subcontractor availability and the gaps in our own knowledge on platforms other than Apple’s.

Years ago, we decided to address these gaps. If you’re an avid reader of our blog, you may associate Lickability solely with Apple, but we also love Android development. Over multiple internal and client projects, our team has built up a wealth of native Android and Flutter development knowledge, and we’d like to start sharing our experiences on our blog to gauge interest in future musings about how things work on “the other side.”

To kick things off, here are some of our favorite aspects of Android development that Apple platform developers might find interesting in contrast.

Architecture

Which primary architecture or design pattern is your go-to for Mac and iOS projects? If you like to keep things simple, maybe you’ve stuck with MVC throughout the years. Or maybe MVVM strikes your fancy. VIPER? Are you working in SwiftUI? Do you use The Composable Architecture? (We do, and we love it.)

Things work a bit differently on Android, as these decisions come from the top. Rather than providing the platform APIs and leaving it up to the community to determine which architecture pattern is best, Android provides Jetpack libraries (in short, libraries that help you to write better, modern code, following suggested architecture best practices), and an absurdly good and detailed architecture guide. Take a moment to skim through that guide, and some of the pages that it links to. Does your neck hurt from aggressively nodding along to headings like “Single source of truth” or “Unidirectional Data Flow”? Ours does. Yes, we collectively have one neck.

This architecture guide, and the libraries that support it, take away a lot of the guesswork for newcomers and experienced developers alike. When spinning up a new iOS project, we find ourselves missing this level of direction from Apple. And while you’re still free to use any patterns you wish, sticking with the best practices, and never being confused about what is the best practice, will get you very far, very quickly.

As an aside, we love that ViewModel is a Jetpack-provided type, and its importance in both separation of concerns and its crucial role in the Android lifecycle. You won’t find us arguing about its definition while working on this platform.

Enforced Conventions

On Apple platforms, we’ve established good organizational conventions like using asset catalogs for colors and images and organizing our localizable strings in a sensible manner. However, much of this isn’t strictly enforced, and it‘s up to us to document project or team-specific best practices, or enforce them with additional tools and linters. On Android, the IDE has your back, from creating a sensible project folder structure, to cleaning up individual lines of code.

Suppose a developer hardcodes a string in a layout. That’s a simple warning with an auto-fix to move it to the created-by-default strings.xml resource file. Android Studio does everything it can to help you in situations like this.

Are you not following accessibility best practices like properly describing images or using too-low-contrast text? The IDE knows, and will tell you.

You’ll even get help with basic syntax conventions without the need to configure any 3rd-party linters.

And these are just a few small examples. We comfortably rely on the IDE for this type of help throughout the day. Newcomers to our Android projects find it extremely valuable for staying productive in an unfamiliar environment, and it helps the rest of us when reviewing code, knowing that the tools have given the developer a leg up, allowing us to focus more on logic than proper adherence to conventions.

Hands-on Tutorials

Apple has been doing great work lately with their series of interactive tutorials. Take a brief look through the SwiftUI Creating and Combining Views tutorial. It’s pretty incredible. I wish we had this level of interactive tutorials when we were just starting out! It’s hard to argue that individual first-party Android tutorials are better or more polished than these, but they definitely beat out Apple in terms of comprehensiveness.

Android codelabs contain detailed walkthroughs on just about any topic you might need help with when starting your Android career, or familiarizing yourself with something new. Take for example the Android Basics in Kotlin course pictured above. This course is divided into 6 high-level units, each comprised of multiple pathways that consist of multiple videos, codelabs, and quizzes. Each codelab walks you through a specific concept in great detail as you work through sample projects. Concepts are explained very clearly, and if you’re a hands-on learner, you’re in luck, because you’ll be writing a lot of code.

So if you’re just starting out, or you need a refresher on a more advanced topic, codelabs have you covered.

Editor Speed

I’ve said some nice things about features in the IDE, but ultimately it’s a non-native looking and feeling application, and I’d be lying if I said jumping between Xcode and Android Studio makes for smooth transitions. I’m often tripped up while navigating between files, or frustrated when I expect a platform standard to apply, like option-clicking a folder in an outline view to expand all subfolders. I prefer native, and I prefer Xcode, but that doesn’t mean it’s purely a slog to edit code in Android Studio.

In fact, I find the actual code editing experience extremely nice, which you’ll spend a lot more time on than fiddling with vertical tabs, maximum heap size, and other unfamiliar frustrations.

The speed of auto-completion and auto-importing is impressive.

Technically, Xcode supports auto-importing, but in practice, I’ve only seen it work sporadically (I should file feedback…). Especially as the project size grows, I find myself waiting on Xcode to catch up to what I’m thinking. When writing Kotlin, auto-complete suggestions feel instantaneous. The editor waits on me. Android developers aren’t necessarily spoiled here, as many IDEs are this quick. We’re just used to one that takes a while.

Conclusion

So what do you think? Have we jumped the shark here on our blog by discussing a competing platform, or would like to hear from us more about our dabbling in non-Apple technologies? Let us know what you think. And of course, if you or your company need help building an Android app, reach out, because we do that too!

Plussing your iOS app

Sam Henri Gold — Mon, 28 Aug 2023 00:00:00 GMT

SwiftUI is really good. (Stop booing me, I’m right.) However, there comes a time when you may look at your app and think, “this reeks of SwiftUI.” System-provided list layouts, the same typography, the same colors as every other app.

Listen, those are fine defaults. It’s why those design choices are defaults — because they look fine and your users already understand them. But there comes a time when you want to go the extra mile. Friend of The Company™ Jordan Morgan calls the apps that do this “best in class.” I call it plussing: taking a perfectly fine starting point and extending it with some easy wins. It’s your app, plus a little extra spice. It’s like having a coffee and then adding a touch of your favorite flavoring or syrup. It‘s the same base drink, but with a little something extra to make it special.

Plussing is a broad term and how you achieve it is ultimately up to you. My background is in design, so we’ll explore spacing, typography, color, and some lesser known features of system controls you can use to enhance your app in small but meaningful ways.

You can use all of these tips without any additional libraries. Just you, your Xcode project, and the open road. Let’s begin.

🔭 Spacing Systems? Far Out.

Design systems are so, so easy to use on the web. That’s Storybook’s whole thing. On native platforms — iOS especially — it’s more difficult to customize standard views. A slider, for instance, only lets you change the track color. But there are some things you can do to make your design more cohesive by employing a global set of values.

At Lickability, we typically use an exponential grid for spacing and sizing, which helps us make sure our layout remains balanced.

Swift

enum Grid {
    static let extraExtraSmall: CGFloat = 2
    static let extraSmall: CGFloat = 4
    static let small: CGFloat = 8
    static let medium: CGFloat = 16
    static let large: CGFloat = 32
    static let extraLarge: CGFloat = 64
}

struct CircleButton: View {
    var body: some View {
        Button(action: { }) {
            Image(systemName: "plus")
                .font(.system(size: Grid.large))
                .foregroundColor(.white)
                .frame(width: Grid.extraLarge, height: Grid.extraLarge)
                .background(Color.indigo.gradient)
                .clipShape(Circle())
                .shadow(color: Color.black.opacity(0.2), radius: Grid.small, x: 0, y: Grid.small)
        }
    }
}

Lovely.

Base 2 exponential values are nice because it makes mental math easy when I’m designing, but you can (should?) experiment with different values. I replaced the grid with a modular scale with base 2, ratio: 3 (2, 6, 18, 54, 162) and got a dramatically different visual rhythm:

More spacious than any apartment I can afford.

🎨 Elevating Aesthetics with Color Grading

When I was a kid, I wanted to get into cinema post-production. Now, I draw rectangles and write blog posts about drawing rectangles. Things have not gone to plan. But my brief stint in cinematography made me see the value in using subtle color adjustments to set the tone of the scene — or, in this case, create a more harmonious interface.

By default, the system-provided neutral colors (like secondarySystemFill) carry a blue tint. But if your app’s accent color is, say, pink or green, you still get slightly blue background colors, secondary labels, and shape fills. The difference some manual color adjustments can make is lovely.

For extra credit, you can replace the primary label colors (black or white) with off-black and off-white values. I generally avoid using pure black in designs since it overpowers everything else, it limits what you can do with depth (you can’t put a shadow on pure black, for example), and reducing the contrast between pure black and pure white helps mitigate halation.

The battery savings touted by “OLED black” is greatly overstated — the difference it makes is a fraction of a percent per hour.

🔠 Typography Tweaks for Fun and Profit (and Security)

When creating views with usernames or email addresses — contexts that are susceptible to homoglyph attacks — I’ve started employing this trick to make some of the similar-looking characters more distinct.

The system font has a stylistic alternative set of characters under kStylisticAltSixOnSelector for this exact purpose. Take a look at the sample text here and notice the uppercase i, lowercase L, and the digits.

It’s not easy to use this (luckily I found this helper function), but I got a blessing from an Apple engineer in a WWDC lab that doing this is kosher:

Swift

extension UIFont {
    func fontWithFeature(key: Int, value:Int) -> UIFont {
        let originalDesc = self.fontDescriptor
        let features:[UIFontDescriptor.AttributeName: Any] = [
            UIFontDescriptor.AttributeName.featureSettings : [
                [
                    UIFontDescriptor.FeatureKey.featureIdentifier: key,
                    UIFontDescriptor.FeatureKey.typeIdentifier: value
                ]
            ]
        ]
        let newDesc = originalDesc.addingAttributes(features)
        return UIFont(descriptor: newDesc, size: 0.0)
    }
    
    func fontWithHighLegibility() -> UIFont {
        return self.fontWithFeature(key: kStylisticAlternativesType, value: kStylisticAltSixOnSelector)
    }
}

struct ContentView: View {    
    var body: some View {
        Text("...")
            .font(Font(UIFont
                    .preferredFont(forTextStyle: .title2)
                    .fontWithHighLegibility()
            ))
    }
    
}

On the topic of typography, the system provides a number of different font styles, all of which afford you the nice things that the standard system font does: line heights that fit in nicely with SF Symbols, proper Dynamic Type adjustments for free, variable weights, and support for the Bold Text accessibility setting.

I’m a fan of New York (serif) for a classier look. Take a look at the Books app for how Apple balances serif titles and sans serif body text.

🫥 Empathy in Design: Handling Empty States

Quick, which app has finished loading content?

I wanted to title this section “Empt-athy in design” but it didn’t read well.

Honestly, this is my biggest pet peeve: when I don’t have any content in a section of an app and, instead of the app telling me that I don’t have any content, I find myself staring at a blank screen with no indication that it’s no longer loading.

If you’re targeting iOS 17 or later, this is drop-dead easy — just use ContentUnavailableView. Otherwise, I’m begging you to just slot in an empty state view. Nothing fancy, just a big SF Symbol, a headline, and some body text. Maybe a plain button or two.

≡ Menus are Really Good, Actually

Where it makes sense, you can convert buttons to menus with a primary action. These menus work by performing the primary action on tap and opening the context menu on long press. And it’s all provided by the system!

If you’ve got a button in your navigation bar for “New Task,” you can use a menu there. The primary action would create a default task, and you can put the more niche items under the menu (”New Location-Based Task” or “New Date-Based Task”). Of course, use your best judgement here — but it’s a great little addition that not a ton of people know about.

When creating the actual menu, options should be written in a way that don’t require explanation beyond the menu label itself. But if you need to provide additional information on a menu item, you can! It’s hidden, but one of our engineers discovered that you can add a second text view in a button’s label parameter.

🔍 Details Matter and Matters Detail

Those are just a few ways that came to mind when plussing your app from a visual design and user experience standpoint. But I recognize most of you are developers, and there are so many more ways to plus beyond design. You can plus your app further by optimizing performance, integrating more system accessibility features like the rotor and dynamic type, and auditing text fields to add content hints so autofill works correctly. While you’re at it, check if you’re using the right keyboard type.

While SwiftUI provides a solid foundation, it‘s up to you to give your app that extra sparkle. Your users will appreciate the unique design elements, making your app feel like a premium experience rather than just another SwiftUI app. After all, it’s the small things that count in creating a standout app. So go ahead, start plussing! If you need me, I’ll be here figuring out a better header for the empty state section.

Introducing ObservableConverter

Brian Capps — Tue, 22 Aug 2023 00:00:00 GMT

At WWDC 2023, Apple introduced the brand new @Observable macro, a simple way to define a type with properties that will automatically update SwiftUI views when they change, replacing the ObservableObject protocol and @Published properties. This new feature is great, but what should we do with all of our old types that use ObservableObject and outdated property wrappers like @StateObject, @ObservedObject, and @EnvironmentObject? To kickstart this conversion in Xcode, we at Lickability started writing a small tool and are releasing the first beta today: ObservableConverter.

ObservableConverter is a Swift command plugin that, when installed from Xcode 15, makes converting from ObservableObject to using @Observable literally just a few clicks after adding the dependency. Select your target in the project navigator, right click, and select Convert Target to Use @Observable. It will update your ObservableObjectclasses, convert all the old property wrappers, and make some view modifier updates. From the plugin’s executable, we make use of Apple’s SwiftSyntax to get a view of the syntax tree for each file and make some safe replacements and modifications. Once you run the conversion, you can simply remove the dependency entirely!

The tool is still very much in beta, so while it covers converting from the use cases Apple covered in Discover Observation in SwiftUI, there are many more nuanced and advanced cases that will require making some decisions on what’s best for your code. We plan to support some of those cases in the future, but for now we hope this is a nice place to start when adopting the new @Observable macro! Feel free to file feature requests or bugs.

In-App Purchases with RevenueCat on visionOS

Brian Capps — Mon, 14 Aug 2023 00:00:00 GMT

With Apple introducing Apple Vision Pro at WWDC 2023, we’ve been incredibly excited to start building apps in a brand new paradigm: spatial computing. While we’ve been having fun putting the simulator through its paces building visionOS apps, we’ve also been thinking about how to monetize our apps to make them sustainable in the future. However, while there are plenty of available resources on RealityKit, Reality Composer Pro, and many of the technical aspects of building a visionOS app for Vision Pro, there are few on how purchases work or what they even look like!

When it comes to offering in-app purchases, our team loves using RevenueCat, which is the best platform for purchases and subscriptions across mobile and the web. They integrate well with Apple platforms, with native SDKs for each platform, and visionOS is no exception. For this process, we’ll be setting up a super simple in-app purchase on RevenueCat, integrating their SDK, and showing the product to the user for purchase on the visionOS simulator. If you’ve already got your app set up on RevenueCat, feel free to skip down to the integration. Now, let’s immerse ourselves. 🥽

RevenueCat Setup

First, we’ll want to set up our purchase in App Store Connect and associate it with our app on the RevenueCat website. For this post, we made a brand new app and added a brand new in-app purchase product in App Store Connect:

Next, you’ll connect this product to RevenueCat. After signing up for or logging into an account on their website, create a new project or use an existing one. Add your App Store app with an app name and bundle ID, and then scroll down and add your App Store Connect API Key using RevenueCat’s instructions.

With this set up, it’s time to associate our Apple in-app purchase with RevenueCat’s notions of products and pricing. Go to Entitlements and add a new one with an ID and a name. Click into the new entitlement and select Attach. Select “Add a new product,” choose “Import Products,” and you’ll see that the Apple in-app purchase product can be automatically pulled in for you! Attach this product to the entitlement, and you should now have both a product and an entitlement for the purchase.

We’ll take one more step to allow RevenueCat to fetch all of our products for us, so we don’t have to hardcode any of their information into our app. We’ll set up a RevenueCat offering, which represents a selection of products offered to the customer on your paywall, by creating a new one with an identifier and description. Click into the newly created offering and add a package with an identifier and description, and then click into that to attach a product. Once that’s done, we’ve got a single offering with a single product, and we are ready to integrate into visionOS.

visionOS Integration

With our project and offerings set up in RevenueCat, we can now integrate the SDK with our visionOS app. To bring the SDK into our app on Xcode 15 (beta 6, as of this writing), we’ll use Swift Package Manager and point it at the main branch to make sure we have the latest updates while in beta.

Now, we can call import RevenueCat to use the SDK! Let’s do so, and then make a super simple loader for the in-app purchase products from RevenueCat that we’ll use in our SwiftUI view. To do that, we’ll make an @Observable class called ProductLoader, and we’ll call out to RevenueCat to load the offerings that we just set up. Once they are loaded, we’ll get the associated product IDs and store them in a property for later use:

Swift

@Observable
final class ProductLoader {
    private(set) var identifiers: [Product.ID] = []

    @MainActor
    func loadProducts() async {
        do {
            let offerings = try await Purchases.shared.offerings()
            let productIDs = offerings.current?.availablePackages.map { package in
                return package.storeProduct.productIdentifier
            }
            self.identifiers = productIDs ?? []
        } catch {
            // Handle errors
        }
    }
}

Finally, we’ll add this loader as a @State property to our view, and we’ll show the new StoreView from Apple with the loaded product IDs when the user taps a button:

Swift

struct ContentView: View {
    @State private var isPresentingStore = false
    @State private var productLoader = ProductLoader()
    
    var body: some View {
        NavigationSplitView {
            List {
                Text("Item")
            }
            .navigationTitle("Sidebar")
        } detail: {
            VStack {
                Text("Hello, world!")
                
                Button {
                    isPresentingStore = true
                } label: {
                    Text("Show In-App Purchases")
                }
                .disabled(productLoader.identifiers.isEmpty)
            }
            .navigationTitle("Content")
            .padding()
        }
        .task {
            await productLoader.loadProducts()
        }
        .sheet(isPresented: $isPresentingStore) {
            StoreView(ids: productLoader.identifiers)
                .frame(alignment: .front)
        }
    }
}

And there you have it! Running this code, we’re now dynamically loading our available products, showing them using Apple’s StoreView on visionOS, and enabling RevenueCat features such as analytics, A/B testing, and cross platform compatibility.

Detecting Collisions with RealityKit in visionOS

Mikaela Caron, Brian Capps — Thu, 10 Aug 2023 00:00:00 GMT

We’ve been experimenting with visionOS lately at Lickability, and it’s been a lot of fun to learn and share our progress online as we go. Detecting whether two entities have collided with each other was one of the first things we wanted to do when developing for Vision Pro. We can accomplish this with RealityKit, but does it look any different on visionOS? Let’s break it down:

First, let’s imagine we have two entities — one cube and one sphere — created with a visionOS project, using volume initial scene, without an immersive space. (I’m using Xcode 15.0 Beta 6 for this demo, all code is subject to change.)

We want to know if our objects collide, and a straightforward way to do that would be to move one object into another — so let’s drag the sphere into the cube.

Adding collision components

To move the sphere, we need to set up the proper components and add a DragGesture. It already has an Input Target component and Collision component set up in the sample, as noted in the session Build spatial experiences with RealityKit, and both of these components are necessary to drag an entity. The cube also needs a Collision component so we can detect when the sphere has collided with it.

If you’re not sure which collision shapes to use, you can view them in Reality Composer Pro by going to Viewport → Check Collision Shapes.

This isn’t super useful when the collision shapes match the entities, but if we change the collision shape of the sphere to be a box, it’s more defined:

Moving the sphere

Next, we want to create a DragGesture in our ContentView with the following steps:

Reference the sphere entity outside of the make closure in the RealityView
Find the sphere entity in the scene
Target the entity with the DragGesture
Change the position of the sphere when the drag changes

Swift

struct ContentView: View {
    
    @State private var sphere: Entity? // 1

    var body: some View {
        VStack {
            RealityView { content in
                if let scene = try? await Entity(named: "Scene", in: realityKitContentBundle) {
                    content.add(scene)
                    sphere = content.entities.first?.findEntity(named: "Sphere") // 2
                }
            }
            .gesture(
                DragGesture()
                    .targetedToEntity(sphere ?? Entity()) // 3
                    .onChanged { value in
                        guard let sphere, let parent = sphere.parent else {
                            return
                        }
                        
                        sphere.position = value.convert(value.location3D, from: .local, to: parent) // 4
                    }
            )
        }
    }
}

Now our sphere can move! 🥳

Detecting collision

Once our sphere can be moved around, all we have to do to detect collision is subscribe to a CollisionEvent on the sphere:

Create the subscription to CollisionEvents.Began for the sphere.
Store the subscription as a @State property so that it sticks around

Swift

struct ContentView: View {
    
    @State private var sphere: Entity?
    @State private var subscription: EventSubscription? // 1

    var body: some View {
        VStack {
            RealityView { content in
                // Add the initial RealityKit content
                if let scene = try? await Entity(named: "Scene", in: realityKitContentBundle) {
                    content.add(scene)
                    sphere = content.entities.first?.findEntity(named: "Sphere")

                    // 2
                    subscription = content.subscribe(to: CollisionEvents.Began.self, on: sphere) { collisionEvent in
                        print("💥 Collision between \(collisionEvent.entityA.name) and \(collisionEvent.entityB.name)")
                    }
                }
            }
            .gesture(
                DragGesture()
                    .targetedToEntity(sphere ?? Entity())
                    .onChanged { value in
                        guard let sphere, let parent = sphere.parent else {
                            return
                        }
                        
                        sphere.position = value.convert(value.location3D, from: .local, to: parent)
                    }
            )
        }
    }
}

That’s it — now, we’re tracking when the sphere collides with the cube! This event tells us when the two begin colliding, but you can also track when collision ends by subscribing to CollisionEvents.Ended.

If you want to see where we went from here, we documented our visionOS progress in a thread here and on Mastodon. You can also check out our sample project on GitHub.

5 years of Clutch

Team Lickability — Wed, 19 Jul 2023 00:00:00 GMT

It‘s been five years since we wrote this blog post about being named one of the top mobile app developers in the country, and even longer since we first started using Clutch to showcase reviews from our clients.

A lot has happened since then. We‘ve worked with lots of new clients on new projects. We’ve gained new team members, gone fully remote, and gotten together for our first company retreat. We‘ve dedicated many hours to strengthening our design & development skills to continue delivering the best work we can — we’ve even started working with visionOS. 👀

Through all of that, we have remained one of the top app developers on Clutch. In fact, we‘re currently ranked in the Top 10 mobile app developers in New York!

For the uninitiated, Clutch is a platform where clients can publish reviews on B2B companies they‘ve worked with. This means our high placement in these listings is a direct result of our clients writing positive reviews of our work — which means a lot to us.

We‘d like to thank each and every one of our clients whose effort & initiative have helped lift us in the ranks of the app development industry. Your reviews paint a picture of what it’s like to work with us, and are an excellent resource for new clients looking for a trusted partner.

Conferences Condensed: WWDC23

Team Lickability — Tue, 27 Jun 2023 00:00:00 GMT

Another year, another WWDC in the books. This year, we were lucky enough to have a mix of people attending the conference in-person and people meeting in NYC to watch sessions together. We‘ve compiled a list of a few of those sessions that we really loved — let us know what your favorites were!

🥧 Explore pie charts and interactivity in Swift Charts

In this session, Apple introduced significant enhancements to the Swift Charts framework. These include the addition of pie and donut charts, and improved interactivity features such as selection and scrolling. The new SectorMark, integral for creating visually captivating pie and donut charts, enables effortless depiction of part-to-whole data relationships. Moreover, the enriched interactivity features provide a more intuitive and user-friendly way to navigate and explore data. This addition equips developers with a fresh approach to present information in an engaging, user-friendly manner. As a result, Apple has really rounded out the SwiftCharts framework, cementing it as a more comprehensive and robust toolkit for data representation.

🚀 Demistify SwiftUI Performance

During WWDC week, I focused my attention primarily on SwiftUI updates while waiting for the visionOS SDK to become available. While there were many fantastic sessions on our favorite UI framework, my favorite was Demystify SwiftUI Performance.

Lately, “Demystify” sessions have been incredibly strong, so much so that I always search the session list once the names become available each year for “demystify”, and prioritize what I find. Demystify SwiftUI Performance is no exception to this recent trend. It offers another peek behind the curtain to better understand minor code level changes and their impact on your app’s performance. SwiftUI is mysterious, for better or for worse. Many developers we work with still struggle to wrap their heads around result builders, and at many times, SwiftUI feels like magic to those of us who have spent more than a decade writing mobile UI imperatively. While this magic can be great for newcomers and for simple use cases, I strongly recommend taking any opportunity to wash some of it away and develop a deeper understanding of how things actually work under the hood.

Demystify SwiftUI Performance joins our list of “mandatory prerequisites” that we share with any developers we work with on SwiftUI projects, alongside its excellent, earlier counterpart, Demystify SwiftUI from WWDC21 (I wrote about this session here). Even if you’re a SwiftUI expert, I urge you to watch this year’s session, as you’re bound to learn something new that will help to shape the way you write UI.

— Michael Liberatore

📸 Embed the Photos Picker in your app

If your app deals at all with a user’s photo library, even if you only need access for them to choose a profile photo, you’re likely going to watch this session. Apple has done a fantastic job with the new APIs for customizing the photo picking experience that’s sure to make your users’ experiences more streamlined and less fatiguing from permission prompts. Embedding the photo picking experience into your own views is so simple, and with Apple-provided subtle user messaging around what your app actually has access to, I think users will be much happier all around. This short session demos a lot of the embedded photo picker’s customization options, and after viewing, I’m sure you’ll come away wanting to upgrade your photo-picking code right away.

— Michael Liberatore

✨ Animate with springs

This session was probably my biggest surprise of WWDC23. Often Friday sessions are a bit less foundational to new technologies than ones earlier in the week, but this one was jam-packed with incredibly detailed and useful information about how spring animations work and some of the nice quality-of-life changes for them coming in the next releases. Jacob expertly employs straightforward examples at just the right times to show how complex topics like springs — and new APIs like gesture velocity — can improve animations across any app. He‘s able to describe the new spring animation APIs that make it easier than ever to get a natural-feeling spring animation, while also going under the hood to describe the math behind it all without putting you to sleep. The beauty of a well-done WWDC talk is taking complex things that feel magical and describing how they work in an understandable and memorable way, and that’s what makes this one so good.

— Brian Capps

🥽 Develop your first immersive app

The newest platform by Apple, visionOS! If you’re wanting to get started with spatial computing this is the place to start. Peter goes through every step to get started from creating a new Xcode project, how to use the Simulator for Vision Pro, using Reality Composer Pro, and lastly using entity targeting.

I love how this is truly an introduction that you can follow without watching any other visionOS sessions. He explains new vocabulary like windows and volumes, and notes which sessions to watch to dive deeper into each topic. Throughout the session he notes best practices for visionOS, like always starting the user in a window with clear entry and exit controls so people can decide when to be more immersed in the content. As opposed to moving them into an immersive space without their knowledge.

I’m super excited to use the Vision Pro after just seeing the possibilities with the simulator.

— Mikaela Caron

🎨 Design with SwiftUI

The debate about “should designers code” has been raging for years. The question has sparked so many Twitter threads from some of the most insufferable thought leaders silicon valley has to offer. This session seemed like the loudest “Yes” from Apple to date.

Even more than a “yes”, it‘s about embracing the world of dynamic prototyping. It‘s not about designers becoming full-fledged developers or taking over coding responsibilities, it’s about using SwiftUI‘s dynamism in ways static tools like Figma cannot match.

Static mockups are great and I am overjoyed that Apple now has official design resources for Figma, but a prototype is worth a thousand words. And there‘s no better place to prototype than in the environment your product will actually be running in, where you can make it as rich as you want. Haptics, device sensors, shaders(!!), it’s all there. The only question is how far you want the prototype to go.

The future of interface design is backed by code written by designers. I apologize in advance to anyone who has to review my messy PRs.

— Sam Gold

🌏 Apple Developer Center session

My favorite session at WWDC 2023 was the in-person session presented at the Apple Developer Center. While it wasn’t recorded, I took notes on it and made them available here for anyone who wasn’t able to attend in person. In the session, John Geleynse introduced everyone to the Developer Center and its capabilities on a virtual tour. Then, Apple engineers from the visionOS team gave us a deeper look a the visionOS SDK and did live demos of building visionOS apps, using ARKIt, and RealityKit. We even got to see how Reality Composer Pro works and how to integrate hand tracking into full space experiences.

Afterward, we all got to chat with the evangelists and engineers over some light refreshments and explore a little more of the beautiful new space built for developers to collaborate directly with Apple.

— mb Bischoff

How to install iOS 17 simulators in Xcode 15

Michael Amundsen — Wed, 07 Jun 2023 00:00:00 GMT

Since the publishing of this post, official Apple docs have been published on this topic, which also offer instructions on using xcrun simctl runtime add from the command line to install simulator runtimes, which may save you some time.

TL;DR:

Shell

xcode-select -s /Applications/Xcode-beta.app
xcodebuild -runFirstLaunch
xcrun simctl runtime add "~/Downloads/ios_17_beta_simulator_runtime.dmg"

If you‘re like me and download new Xcode versions from the developer portal, you may have run into trouble this time around. Xcode 15 comes in multiple parts: Xcode itself and the simulators you want to install. Unfortunately, I wasn’t sure where I was supposed to install those simulators.

After a lot of googling, I finally found an answer in the developer forums that worked for me, so I put together a quick video to help other people out.

Right click on the Xcode 15 Beta application and select Show Package Content.
Double click to open the iOS_17_beta_Simulator_Runtime.dmg file
Inside the simulator dmg file, find the Runtime folder. This is the folder we are going to copy into Xcode.
Place the Runtime folder at Developer → Platforms → iPhoneOS.platform → Library → Developer → CoreSimulator → Profilesinside the Xcode 15 beta Show Package Contents
1. If you move the Xcode-beta application to the Application folder, you can use Finder to go to /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles.
Restart Xcode if you already have it open, and your iOS simulators will be there

And just like that, your simulators are installed.

If you want, you can also redownload the simulators through Xcode instead of doing this — but I found it failed a lot. Hopefully, this will all get smoothed out once everyone isn‘t trying to download everything at the same time. 😅

Our WWDC23 hopes and dreams

Team Lickability — Thu, 01 Jun 2023 00:00:00 GMT

It‘s just about time to start thinking about what we might see at Apple’s developer conference next week! We asked our team to share their biggest wishes and predictions for the event, from SwiftUI APIs to interactive widgets on iOS. Here are our picks — what are yours?

Michael Liberatore

From a development perspective, the things that I hope for the most this year are a holistic revamp of navigation APIs in SwiftUI, overhauled error reporting in Xcode to mitigate false errors sticking around, and flooding Xcode Cloud with features to make it as compelling as Buddybuild was. I would also love to see Apple’s answer to the rise in large language models, and whether Siri will become super powered.

For keynote goodies, I’d love to see an iPhone SE in the 13 mini form factor, and compelling reasons to be excited about the much rumored headset. I also want to BELIEVE that the Mac Pro is still coming!

mb Bischoff

I’m hoping that in addition to new Mac hardware and the rumored headset, Apple spends this year at WWDC working on adding quality-of-life features across their platforms.

On iOS, my wishlist includes interactive widgets, a real Passwords app, snoozing and scheduling in mail, and redesigns of the Home Screen and Calendar app. I’m also hoping this is the year for custom watch faces on watchOS.

For developers, it’d be great to see a GitHub Copilot-like feature integrated into Xcode that preserves developer privacy, a version of Xcode for iPad, and more effort to make SwiftUI reach API parity with UIKit.

Sam Gold

I’ve got four weird feature requests for things that have been bugging me for a while.

On iOS, I’ve had this feedback (Radar 49404087, FB7830265) open for years: use a multiply blend mode for the highlighter annotation tool. Right now, it just overlays highlighter ink with a dropped opacity, which makes text look all muddy:

A great addition to the system-wide share sheet would be a way to strip out tracking parameters and boiler-plate text when sharing links and text from apps (FB9845096). Given Apple’s focus on privacy over the last few years, this feels like a no-brainer. Here’s what TikTok gives me to share around — it’s absurd:

On the Mac, I’d love a way to screen record at lower quality (FB12070699). I often want to do a quick screen recording to text to someone or send in Slack, but it defaults to a super high quality, and I have to either wait for a 60MB video to upload to Slack or open the terminal to run it through ffmpeg. Just gimme a Low/Medium/High quality picker in the Command+Shift+5 floating bar!

Finally, in the watchOS Control Center, just show me the battery percent of my phone (FB12069584). If I’m on the couch and my phone is charging across the room, I want to see when I can unplug my phone.

That’s it. I’d put up a PR of these myself but Apple told me I’m not allowed to look at the source code for their operating systems. Whatever.

Jillian Meehan

Since I’m not a developer, I mostly look forward to the exciting iOS updates every WWDC — I like the fun, flashy stuff. I don’t have many specific wishes (although I’m seconding all of mb’s QOL requests) but I’m very interested in seeing what kind of enhancements widgets get across the board.

As a recent Reminders convert, a true dream come true for me would be for scheduled reminders to show up in Calendar. (Yes, I know Fantastical has this feature. I love it. I want more of it.) And why stop there? I want to be able to easily attach things from Mail and Notes and Files to my reminders. Apple has some pretty great apps, but I think it’s a shame that they don’t play as well together as they could.

One more thing: I’ve heard the rumors about a new journaling app, and I’m all for it. I’ve never really clicked with any other journaling app, so I’m curious to see what they’ll do.

Conferences Condensed: iOS Conf SG

Mikaela Caron — Tue, 02 May 2023 00:00:00 GMT

To kick off 2023, I headed on a time-traveling journey to Singapore, flying across multiple time zones and over 9,000 miles! iOS Conf SG brings together developers from around the world to learn from one another and find opportunities for collaboration. I had so many exciting new experiences on this trip, and made lots of new memories—here are some of my favorites.

🚀 Thursday: Async/Await Workshop & Kickoff

On Thursday, we started with a workshop! Daniel Steinberg walked us through how async / await works and how it’s used in different scenarios. We had a lovely lunch break, and then got right into the opening kickoff.

Erin Weigel’s talk, Experimentation for Engineers, really made us think about how we can contribute to both the customer experience and business results as engineers. She talked about the linear workflow vs. conversion design process, and how A/B testing can lead to unexpected results.

Later, Jordi Bruin wrapped up the day by showing us his 2-2-2 method for creating apps, which he’s used to ship over 20 apps in two years. The method goes like this:

Spend two hours on a very basic prototype proving that you can make the app, with very minimal functionality.
Spend two days refining that prototype to be more usable for yourself and possibly others.
Lastly, spend two weeks to round it out and prepare to launch to the App Store.

I’ll be using this method from now on to validate my ideas without getting caught up in the details.

☕️ Friday: Talks, Demos, & Coffee

Friday was the big day! I started the day with my talk, What’s an App Without Data?—where I explored where to save data both locally and in the cloud, broke down some of the different situations you might run into, and went over how to choose the right database for your app.

A table with lots of coffee

Afterwards, Paul Hudson demonstrated to us that (for now 😅) ChatGPT is not going to be taking our jobs—after three iterations, it wasn’t able to recreate a clock SwiftUI view that mimics the one on the Home Screen.

After a quick coffee break, Paul Hudson, Tunde Adegoroye, Erin Weigel, and I were on a panel called More Than Code: Rooting Yourself in the iOS Community. We discussed being content creators, contributing to the community, and how anyone at any skill level can get involved. mb Garlington, a developer who has unfortunately passed on, was a great example of someone who had a big impact—he hadn’t spoken at a conference, published a book, or created a YouTube channel, but he was someone who was willing to help any other developers get into the tech community. You don’t have to be a speaker or a content creator—you just have to want to help others.

To round out the conference, Adam Bell gave a great overview and implementation of building responsive interactions, showing us that it’s the details that can make your app feel more responsive and polished. Having unresponsive scrolling and gestures, or not reacting to touches immediately, can make an app feel broken—Adam showed us how to fix those issues.

🤝 Community

iOS Conf SG was voted as the Best Conference in the Hacking With Swift community awards in 2021—and for a good reason! There were so many amazing talks that I can’t even mention them all here, but you can check out their playlist to see the rest.

The community emphasis throughout the conference was unmatched. The organizers started and ended the conference emphasizing the importance of socializing with others and making new connections. You never know—you might find your next business partners or beta testers at a conference!

We’re a RevenueCat partner!

Team Lickability — Thu, 13 Apr 2023 00:00:00 GMT

Lickability is now a certified Premier Partner of RevenueCat’s Agency Partner Program—which means we can provide even better service to our clients, helping them to integrate and manage in-app subscriptions more efficiently.

So, what is RevenueCat?

RevenueCat is a powerful tool for app developers looking to add subscriptions to their app. It takes care of all the complexities of in-app purchases, such as managing subscriptions, handling billing, and providing detailed analytics, so developers can focus on building their app. With RevenueCat, app developers can easily add subscriptions to their app and start generating revenue.

How can we help you?

If you’re an app developer looking to add subscriptions to your app, Lickability’s got you covered. With our expertise in app development and our new partnership with RevenueCat, we can help you integrate and manage subscriptions in your app seamlessly. We’ll work with you to understand your needs and help you choose the best subscription model for your app.

Not convinced yet? Here’s what our friends at RevenueCat have to say:

The mobile subscriptions market is growing. According to data.ai, worldwide app revenue grew by 8% in 2022, while in the US it grew by 16%. This growth showcases the resilience of the subscription business model, even in the face of the challenges seen in other corners of the tech industry. What is clear from the data is that there is an enormous growth opportunity for mobile businesses to take advantage of recurring revenue models — and more mobile businesses than ever will be looking for easy and frictionless ways to implement recurring subscriptions.

– Truman So, Head of Partnerships at RevenueCat

Get in touch!

We’re super happy to be a Premier Partner with RevenueCat, and can’t wait to see what opportunities this collaboration will bring. Get in touch with us today and learn more about how we can help you implement subscriptions in your app with RevenueCat? Let’s work together to make your app successful.

Conferences Condensed: 360iDev 2022

Team Lickability — Fri, 10 Mar 2023 00:00:00 GMT

In August, we attended 360iDev, a long running iOS and macOS developer conference based in Denver, CO. Regrettably, this was the last 360iDev conference after over a decade. Here’s a look back at some of our favorite talks from the conference and what we learned from them!

🔌 Generating Code and Other Mischief with Swift Package Manager Plugins

Ellen Shapiro

Ellen started off by giving us an overview of how we got here. How did plugins become part of the package manager, rather than the IDE? In 2013, there was Alcatraz; in 2016, with Xcode 8, there were source extensions; and finally, in 2022, we now have command plugins and build tool plugins with Xcode 14.

Command plugins are the simpler of the two. They can be invoked either by the command line or from the Xcode menu. When using command plugins, be sure you know what they’re doing, because they can change your code in a way you may not have intended!

Build tool plugins are designed to be run automatically on every build—it’s a package embedded into .xcodeproj, and the plugin is then added to the Package.swift. This is what people are generally referring to when they talk about “Xcode plugins.”

Don’t build your plugin and the package you’re testing it against in the same repo!

There are still quite a few limitations with plugins. First, as a user, always make sure you know what plugins are doing—don’t just click “Enable All” when running them. And when developing them, keep in mind that there’s no UI for your users, you can’t make network calls, and you can’t share data between plugins.

— Mikaela

☁️ Choosing the Right Cloud Database For Your Indie iOS App

Mikaela Caron

Surprise: we sponsored part of 360iDev by contributing this talk, from myself!

In my talk, I reviewed what a database is, and the big decisions that need to be made when choosing which one to use as an indie iOS developer. I compared three different cloud databases: Firebase, AWS Amplify, and Vapor with PostgreSQL. The question “how to choose the right database” is based on three main considerations: pricing, data, and authentication.

After evaluating each of the cloud databases with those considerations, we still have that question—“which database do we use?” To better understand when to choose which database, I reviewed different scenarios an indie app developer might face, and what the best cloud database option for each scenario might be.

Wrapping up the talk, the question remains—*“which one is the best*for an indie dev?” Personally, I chose Firebase, because AWS Amplify’s pricing is confusing and Vapor requires more backend knowledge and maintenance that may not be the best use of your time.

In the end though, it doesn’t really matter—as Justin (the keynote speaker) said, “all of the code is ephemeral, you can choose whichever you want,” and you’re probably going to change it later.

— Mikaela

🔋 SwiftUI Performance for Demanding Apps

Aviel Gross

It’s hard to believe SwiftUI is already three years old, and now has relatively mature APIs that can be shipped in production. SwiftUI is highly performant with the right architecture in place!

Aviel’s talk was about how we can shift our mindset from imperative to declarative thinking. He also elaborated on how existing UIKit apps are structured, along with how to leverage some of the best features of SwiftUI—from publishing changes with ObservableObject for state management to avoiding redundant view updates. This talk is chock full of good SwiftUI resources and patterns!

— Daisy

⏩ Automating with Fastlane: Tips, Tricks, and Best Practices

Josh Holtz

Josh is truly an inspiration for anyone that has a fear of public speaking. As a person with a disability—a bad case of migraines—I so appreciated his candidness when he mentioned his speech impediment. His talk was incredibly well done!

If you’re an iOS or Android developer, you’ve probably heard of Fastlane at some point. Josh went over the basics of Fastlane and how to use it within Xcode and the CLI. The most notable part of this talk is the Fastfile, a Ruby file that takes care of things like incrementing build numbers, archiving an app, capturing screenshots, and uploading to TestFlight and the App Store. Josh gave us some nifty tips on how to make the Fastfile more reusable and composable, all in a live demo that syncs all the necessary code signing certificates and provisioning profiles.

— Daisy

Redesigning our documents

Thomas DeVuono, Sam Henri Gold — Thu, 01 Dec 2022 00:00:00 GMT

Between Learn with Lickability sessions, attending conferences, and asking our friends for advice in our “everybody” Slack channel, we’re always looking for ways we can level up our game here at Lickability. Here in Salesland (as we so fondly refer to it in our team meetings), our latest improvement is a ground-up redesign of all the documents we use during our sales process, and today we’d like to walk you though the why‘s, how’s, and (preliminary) results of this project.

Our sales process

First, here’s a high level overview of our sales process. We divide the stages of our pipeline as follows:

📨 Lead comes in—via our website, a personal contact, social media etc.
📞 Initial call to determine if it’s a good fit for both parties
🧮 Estimate the project with our engineers & draft a proposal
🗣 Proposal walkthrough with the client
🤝 Share formal contracts, legal review, and negotiation
✍️ Signatures and project kickoff

If you want the full explainer, check out our How We Do Sales post.

The docs & how we use them

For each of the stages of our sales process, we have a collection of documents that we may send to clients. These include formal contracts with lots of legal and business terms, like our Statements of Work or Services Agreements, and supporting documents like proposals, summaries of our work, or design showcases.

We store the documents in our shared Google Drive as templates, and we customize them for each client. When creating a new document for a client, an account manager fills out the appropriate template with the information needed, and it is reviewed and approved by our operations, engineering, and finance teams using the Wrangle Slack app. If everything checks out, it goes on its way.

We present our documents in a variety of ways, but most commonly we walk clients through them together over Zoom. When formal contracts are ready to be reviewed, those are sent out to the appropriate folks either via email (if we expect some legal back and forth) or DocuSign (if everyone is happy and ready to sign).

Here’s a list of our most used and important documents:

Proposal: Arguably the most important document we will send to a client. This is our chance to explain how we would approach their project, what they can expect to happen as it progresses, and the benefits of choosing Lickability as a partner.
Statement of Work: This document is a formal restatement of the proposal and defines important project terms like what’s in scope, what assumptions have been made, and payment terms.
Services Agreement: This document goes hand in hand with our Statement of Work and defines important business and legal items such as Intellectual Property, Termination, and Confidentiality
Amendment: This is used when we need to make small changes to a Statement of Work, such as extending the project term or adding folks to a project.
Contractor Agreements: We also have a slew of documents we use when working with fellow agencies or independent contractors, and we give them the same care and effort we would a client.

Why update our docs?

A question that came up when we were thinking about starting this project was, “why should we spend time doing this?” Our old documents were easy to prepare, clients gave us positive feedback on their simplicity, and we were successfully closing deals with them. However, they were a few years old and showing their age, plus it was a chance to show off our design chops to clients right at the start of our conversations with them.

We’re big on Steve Jobs quotes around here (ever wondered where the name Lickability comes from?), and one was particularly front-of-mind when starting this project:

When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.

Although our Statement of Work documents are barely marketing tools, we want to show clients that we sweat the small stuff, even if it goes unnoticed. To that end, we put a lot of care into the details: the paper’s subtle red tint, using all the typographic tricks in the book (like the № sign in lieu of “#” or “Number”), and laying out section headers in the margins like magazines do.

The research, finding inspiration, and the design process

Finding reference material was challenging, since other companies tend to be fairly cagey about sharing the minutiae on their internal tools. Branching out to find seasoned documents (not just glossy Dribbble templates) from different sectors proved to be difficult, but we were able to find a handful from other agencies we’ve worked with, which was certainly helpful to assess what works and what doesn’t. With those notes in mind, and only a number of guard rails in place, it was time to get to work.

Since we’re a fully-remote team, getting immediate feedback on design drafts was paramount. For this, we used a dedicated Slack channel and a shared Google Drive to keep everything in one place. As Sam made design changes, he called out the ones he felt less certain on and people from all different functions around the company helped suggest changes. Cross-function collaboration is invaluable for design tasks like these—we worked together to tailor the designs to Tom’s presentation style, and our Ops team offered fresh eyes on the copy to make sure the tone wasn’t too sales-y.

Typography for Lawyers was an invaluable resource throughout the design process. Since Sam’s background is in product design, it helped inform many decisions regarding hierarchy and layout in this different context.

Old vs. new

Previously, our documents were in format purgatory—partly Word format, partly Google Docs. This made it difficult to export them nicely as either. Additionally, the formatting was baked in and extremely fragile. For example, bullet points were created using a series of spaces, dashes, and more spaces instead of using standard word processing lists. This meant that any changes could cause the document to reflow in unexpected ways, since line breaks were used instead of just letting lines wrap.

Editing lines with forced line-breaks creates unexpected wrapping.

Invisible characters in our old documents. Note the forced line breaks after each line and the string of spaces after each header.

Another issue was that they were designed to be printed, but we‘re a digital studio selling digital services to companies that value their digital presence—print is the least important medium at this point. This gave us the opportunity to take some visual liberties and inject more of our brand. We could worry less about printers cutting off the edges or wasting ink with a subtle paper tint color.

All of our new documents are Google Docs-native, making doc-specific feedback a breeze both internally and when we sent it out to third parties for review. (By which we mean lawyers and no other examples.)

We can also use quality-of-life features like Google‘s date chips and the outline view. They’re designed digital-first but gracefully degrade—exporting nicely to Word, Pages, and PDF. They‘re still A4 size so if it does get printed, printers will know how to handle it (rather than one long, seamless PDF that would print out as a thin strip on a single sheet).

Most importantly, the new docs elevate the client’s brand to the same level as ours, and are unmistakably us.

Our results

So, how have our shiny new documents been received? In short, fantastically! Clients tell us they love the simplicity and clarity of how we structure the information, the care and attention to detail in our design, and that we include their logo front and center. All of this combined makes the documents easier to share, present, and communicate their meaning.

Design is never finished, so we’re continuing to refine the templates to meet the needs of ourselves and our clients. Right now, we’re working on adapting the design language of the new documents into an agency overview slide deck. We can’t wait for you to see the final product. You should totally reach out to us if you’d like a personal overview. 😉

We Like Widgets!

Team Lickability — Thu, 03 Nov 2022 00:00:00 GMT

It‘s been a while since we shared our home screens and watch faces here—so long, in fact, that those blog posts look a bit like time capsules now. So we figured it was time for an update. Here‘s a new look at our digital layouts, including all the widgets and complications we’ve welcomed into our lives in the past few years.

Tom DeVuono

I like to keep my lock screen pretty simple and avoid widget overload. Weather is my favorite widget and the one I find most useful, so it’s always front and center no matter where I am. For the lock screen, I also added the upcoming meeting widget, which is great for work. I round out the top with UV Index, ’cause the sun is a deadly laser.

For the watch, again, keeping it pretty simple. I really like the new astronomy choices, and the little animations it does when I raise my watch are fun.

Home screen layout and widget choices remain the same, just a new wallpaper that matches the lock screen. My home screen is the only page I run— everything that’s not on there I get to with Spotlight search.

Sam Gold

I’m bored out of my mind looking at these screenshots of my phone, but that’s by design. I’ve been trying to use my phone less throughout the day, so I’ve demoted (most) of my social apps to the app library…except Twitter. If I lose Twitter, I’d have to pick up a different vice to fill the void.

My home screen icons are mostly tools to do something, which I’ve found helps to trick my brain into viewing my phone as a utility rather than a recreational object. Widgets have been huge in this regard—I don’t even need to open apps to see what I want to know, and it dramatically reduces my screen time.

There’s not much to note for my lock screen. My brother is at school overseas, so I’ve got a world clock as a reminder to not text him at 2AM his time. I’ve been using this original iPad wallpaper as my lock screen wallpaper since 2012 and it’s the objectively correct wallpaper. A bit of detail at the bottom, but nice and clear at the top for my widgets.

Michael Liberatore

Not much has changed in the last four years regarding my primary watch face. I’m still using the Modular (previously known as Infograph Modular) face, and most of my complications are the same. I’ve swapped out weather conditions for Nike Run Club’s complication to quickly see my number of miles run in the current month. This gives me the extra nudge I need to keep my streaks on track. I’ve also switched from multicolor to orange, which unapologetically matches the garish accents on my new Apple Watch Ultra and its Orange Alpine Loop.

I’m still trying to figure out which widgets I want to live on my lock screen throughout the day, but for now, I’m pretty set on this setup during my sleep schedule. This collection of widgets gives me 99% of what I ever need when either going to bed or waking up. At night, I can quickly glance at my lock screen to see tomorrow’s first event using Fantastical’s “Up Next” widget. I can easily suppress my anxiety about whether my alarm is set thanks to the bonus alarm time that’s present on the lock screen during a sleep schedule, or even change the alarm if tomorrow’s first event is earlier. Overcast’s “Icon” widget allows me to quickly jump into the app to start a podcast without other distractions in the way (I fall asleep to podcasts). Finally, when initially waking up, the first thing I want to know is the temperature and conditions for my morning dog walk, which I can now see without unlocking my phone if I wake up before my alarm goes off and my morning summary appears. My background and text colors are a bit boring here, but that’s intentional for my sleepability.

mb Bischoff

My home screen and lock screen change with my eight different focus modes, but here’s what they look like during work. Artwork by one of my favorite illustrators, David Lanham, reminds me not to take things too seriously. Widgets from Fantastical, Streaks, OmniFocus, and CARROT Weather show me the information I most often need at a glance. And I’ve got quick access to the apps I most frequently launch throughout the day to catch up on messages like Slack and Messages, jot down note with Drafts and Logseq, or take a break on Instagram and Twitter.

Jillian Meehan

I also have a few different home screen + lock screen situations depending on what focus mode I‘m in, but this is what I see the majority of the time. On my lock screen, I’ve got widgets from Fantastical, CARROT Weather, and Streaks—plus the adorable pixel pal widget from Apollo.

My home screen has a few widget stacks working overtime—each stack has about five different widgets that I cycle through. Aside from the ones you see here (Fantastical, Spotify, and OmniFocus) a few of my favorites are the Forest time distribution widget, a small Streaks widget showing my next four tasks, Notion widgets linking to my most-used pages, and Pinterest widgets that show a random pin from a selected board (for the vibes). In my dock, I‘ve got Discord and Messages for quick communication, and a sort of all-in-one shortcut that I use to create new OmniFocus tasks or open frequently used apps.

I have a pretty simple modular watch face—I can see the current weather from CARROT & my next event from Fantastical, and I have quick access to Spotify and the Home app.

Andrew Harrison

This is my Lock Screen, but I’m not even on iOS 16 yet soooo...

Our first retreat

Jillian Meehan — Tue, 09 Aug 2022 00:00:00 GMT

Lickability has been fully remote for a while—we started (temporarily, we thought) working from home in 2020, which turned into us officially shutting down our office last September and making our first remote hire sometime later.

Being a remote company certainly has its benefits, but it also has tradeoffs—namely, the fact that we don’t get to see each other in person very often anymore. When we shut down the office, we knew we needed a plan to get everyone together a few times a year. A few months ago, we started planning our very first company retreat.

Planning

First, we had to figure out where to host it. This was easy—most of the company is located in or near NYC, and we wanted to keep things relatively simple for our first time. After evaluating a few hotels in the area based on meeting space availability, price, and proximity to things in the area, we landed on the Wythe Hotel as the site for our retreat.

Before we could book anything, we also had to decide when and how long the retreat should be. We wanted to have enough time for it to feel meaningful without taking too much time and energy away from anyone. Two to three days felt like the right balance—an evening to check into the hotel and have dinner together, a full day for team activities, and a morning for people to check out of the hotel and spend a bit more time together before heading home.

Once the dates and location were locked down, all that was left to do was plan what was going to happen when we actually got there. Corporate icebreakers have never really been our style, and we didn’t want the retreat to feel like work. But we also don’t have a lot of opportunities to get the whole team together in person, so we wanted to take full advantage of that.

In the end, we decided to use one day for work-related team activities—like a hackathon—and one day to get out of the hotel for some fun stuff. After throwing in a few dinner reservations and making sure all necessary travel was booked, we were ready to go.

How it went

After months of planning, it was cool to see everything finally come together as people started checking into the hotel Wednesday night. After everyone got settled, dinner at the hotel restaurant was the first thing on our agenda.

Some of us met up in one of our hotel rooms before dinner!

On Thursday, we booked the Cooper Room at the Wythe for the full day—it’s a cozy cellar space with plenty of room for team activities over brunch (which was delicious, by the way).

Our brunch buffet

After a great Learn with Lickability presentation from Brian, Ken, and Michael Liberatore in the morning, the engineers split into groups for a hackathon while the rest of us did some brainstorming for future product ideas. These are the kinds of activities that work best if you can get everyone together in person—having the ability to work side-by-side and bounce ideas off of each other is fun, and definitely helps facilitate creativity.

A very fun & busy day

The last day of the retreat, Friday, was our “fun stuff” day. After checking out of the hotel in the morning, we met up at Sip & Play, a board game cafe. Many rounds of games later, about half the team got together for our last event: Beat the Bomb, a very competitive, fun, and messy escape room.

The winners vs. the losers

What we learned

I think it’s safe to say the first Lickability retreat was a success! It was great to get everyone together in person after being remote for two years—and if the post-retreat survey we sent out is any indication, everyone seemed to have a fun time.

Now that we’ve been through it once, it’ll be a bit easier to plan the next one. We’ll have a better sense of what types of activities people like, what the schedule should look like, and where we could have been a little more efficient.

Our morning at Sip & Play

On the other hand, there’s still lots to experiment with: we need to figure out how often we want to have retreats, how long they should be, and where we should hold them. We don’t want to do the same thing every time, but we also don’t want to take huge risks—there’s always a balance.

I think I can speak for the rest of the company when I say I’m really looking forward to our next company retreat, whatever it ends up looking like. It can sometimes be rough not getting to see your coworkers very often, but having an excuse to plan a few days of fun together definitely makes up for it. Here’s hoping there are many more retreats in our future!

(As for making the switch to working remotely, that’s still going really well—and we’ll talk more about it in a future blog post. 😉)

Conferences Condensed: WWDC22

Team Lickability — Thu, 16 Jun 2022 00:00:00 GMT

It‘s that time of year again—we always look forward to a week full of design and development talks from Apple. This time around, a few of us were able to meet up in person to watch the Keynote together, in addition to streaming and chatting about sessions in Discord like we usually do. Out of all the videos our team watched this week, here are a few that stood out as our favorites.

📊 Design app experiences with Charts

I’ve been a fan of Nicholas Felton for over a decade, and I mostly knew him as the creator of the beautiful Feltron Annual Reports. So it was a pleasant surprise to me that he now works at Apple as a designer primarily focused on data visualization with charts. In this talk, Nicholas walks through when developers should use charts in their UIs and gives a bunch of useful tips on how to progressively disclose and explore data with both static and interactive charts built in the new Swift Charts framework. I imagine I’ll be returning to this talk many times as I start to think through more charts in apps like Buildwatch.

– mb Bischoff

🎨 Compose custom layouts with SwiftUI

This session introduced fantastic new layout capabilities that bring UICollectionViewLayout-like flexibility and transitions to SwiftUI, and fill in some gaps for more common layouts that were more difficult to achieve with the lack of layout constraints.

While the entire session was fantastic, what stood out most to me was ViewThatFits. This new API was touched on during Platforms State of the Union, but in this more detailed session, we see its use in context with more of the new layout features. It doesn’t get a lot of screen time, but it still proved to be my most 🤯 moment this year. It’s very often that a designer will ask us to make adjustments like “if we run out of horizontal space, just remove this purely decorative component, or this supplementary label”. Seems simple enough, but it’s not—until now! Without using complicated layout math, lots of text measurement, or relying solely on the very broad size classes as layout breakpoints, we can now swap between layouts only when we need to, and the API for it couldn’t be simpler.

– Michael Liberatore

🗺 Explore navigation design for iOS

I love all the design talks that happen at WWDC every year. This year, my favorite talk was (again) about design—this time focused on navigation design for iOS. Navigation design encompasses how things behave, where things belong, and how things work. And good navigation, as this talk highlights, is often unnoticed so the user’s focus is on the content of the app.

The talk went over best practices for using tab bars, hierarchical navigation, and modal presentations. Tab bars should reflect your information hierarchy, and can tell a story about what the app can do, even without the content of the app. Hierarchical navigation is used to push users between pages of content that becomes more specific as you move down the hierarchy. And modal presentations are useful for focused, self-contained tasks. Watch the talk to learn more about the best practices for using each!

– Thomas DeVuono

🖥 Use Xcode for server-side development

Swift, but on the server! Seeing Apple use Vapor, a community-built server-side Swift framework, in a WWDC session is very exciting! I’ve done some Vapor development on internal projects and seeing Apple recommend it lets us know that it’s here to stay. This introduction session shows how a server project can be in the same Xcode project as the iOS code, and how it can be deployed to Heroku. The Vapor docs give more in-depth instructions, but this session is a great introduction to what’s possible.

– Mikaela Caron

✍️ Writing for interfaces

When you know their power, words are a force to be reckoned with. In this talk, Kaely Coon and Jennifer Bush cover how to use them effectively in your app through the PACE framework:

Purpose

Consider the purpose of the screen you’re writing—what should someone know at that moment?

Anticipation

It helps to write copy as if you’re having a conversation with the person on the other side of the screen. A conversation has an organic flow where participants vary their tone and can anticipate what’s next.

Context

Context and timing is a huge part of writing effective copy. For a navigation app, for example, the person will (hopefully) not be directing their attention toward your app. Write time-sensitive copy that’s short without sounding terse.

Empathy

Write for everybody, regardless of region, language, or how someone interacts with their device. If your app targets a defined audience, speak to that audience without leaving anyone out.

Designers and front-end developers, take note. These lessons, while practical, extend far beyond iOS or even UX writing. They can be applied to web apps, emails, or interoffice signs on how to use a frustratingly-designed elevator.

– Sam Henri Gold

Conferences Condensed: 360iDev

Daisy Ramos — Thu, 02 Jun 2022 00:00:00 GMT

Last August, I got the chance to attend 360iDev, a long running iOS and macOS conference based in Denver, Colorado. After a two year hiatus from attending in-person conferences, I was excited to see a conference in action again. Since WWDC is right around the corner, here’s a refresher on some SwiftUI focused sessions—enjoy!

SwiftUI.View: Codable – Transforming SwiftUI to JSON for a fully backend driven UI

Florian Harr

Florian starts by explaining the flexibility of SwiftUI static views via parameterization and dynamic screens with shipped views (also known as as optional or conditional views). Since SwiftUI views are structs they can automatically synthesize Codable features for encoding and decoding JSON as long as the underlying properties also conform to Codable. Florian provides a neat demo for this which can be found here.

Async Await and more in Swift

Cameron Deardorff

Cameron starts off with an example of error prone completion handlers, the complexity for scale, and the inevitable pyramid of doom.

This talk goes over the familiar paradigm of async/await around error handling with throwing functions. Async/await isn’t limited to functions—they can be used with property getters and initializers. This talk also goes over the ergonomics of structured concurrency around async let and the ability to run in parallel with Task along with the hierarchy of Task. Fun fact: you can use a Task.Handle as a replacement to storing Combine’s AnyCancellable to cancel a task and avoid any unnecessary background processing. Cameron also dives into shared mutable state with actors. This talk goes in depth around different use cases where you might want to use these features.

Multi-platform Development, the SwiftUI Way

Malin Sundberg

Malin gives a delightful talk with a tour of Vancouver, Canada! Malin goes over the intricacies of developing a multi platform app for time tracking and invoicing, Orbit. This talk goes over the expectations of writing a SwiftUI app and the necessity to split views into components for reusability along with legacy code use cases. It also includes compiler directive examples within view modifiers and efficient ways to use them. Malin emphasizes the point that SwiftUI isn’t a write once, run everywhere solution but more of a learn once and apply to different platforms framework. This talk also goes over how to leverage UIKit within SwiftUI via protocols like UIViewRepresentable and UIViewControllerRepresentable for more complex layouts, and using coordinators for communicating changes and handling interactions like transitions in a page view controller.

Navigating DocC

Ellen Shapiro

Ellen starts off with what C stands for in DocC, which is Compiler! Since the documentation compiler is tightly integrated with the swift compiler. At Lickability we document everything, so I was super excited to try this since Ellen mentioned how simple it is to use existing swift docs to generate a DocC version via the Xcode menu Product → Build Documentation. That will generate docs that look exactly like Apple’s via their documentation viewer:

Fancy! This talk also goes over how to add links to your types via a double back tick, e.g. AvatarImageView. That will also trigger autocomplete since the swift compiler is used. DocC also accounts for typos in case types are misspelled which would trigger a warning. A caveat in symbol linking is that you can‘t link to anything outside your library’s context. Linking for specific enum cases isn‘t supported yet either. Ellen goes over the extensive limitations in DocC, including linking within related frameworks or even the standard library. Any public extensions of types that are not initially declared in your framework will not have documentation generated, which can be a pain point if you use extensions heavily. Ellen goes over how to view a DocC archive file by looking at the package contents, and explains that under the hood this is running as a Vue.Js instance—interesting! Since this conference talk, Apple has open sourced DocC.

Summary

Since this conference, we‘ve been using a handful of these SwiftUI features at Lickability. It’s always exciting to see talks like these using SwiftUI in production or in testing!

Conferences Condensed: Extreme Ownership Muster

Mikaela Caron — Tue, 03 May 2022 00:00:00 GMT

Last October, I went to Las Vegas to attend Extreme Ownership Muster, a leadership conference by Echelon Front. The center of this conference is a book called Extreme Ownership, written by Jocko Willink and Leif Babin. The book shows scenarios Willink or Babin faced as Navy SEALs, the leadership principles that come out of those examples, and then how those same principles can be applied to business—the conference followed a similar format during each session.

⚔️ Laws of Combat

Speakers: Jocko Willink, Leif Babin, JP Dinnell, and Dave Berke

The conference kicked off with the Laws of Combat. These are the principles to being a leader—they build off of each other and work together to accomplish the mission. Those laws are:

Cover and Move — It’s all about the team. If the team fails, everyone fails.
Simple — Everything must be simple. The objective, instructions, everything. It’s up to the leader to ensure the team understands the task.
Prioritize and Execute — Prioritize tasks and do them. Debrief after everything, and figure out how do it better the next time.
Decentralized Command — Give your team the power to make decisions so you can focus on the big picture. The team should not only understand what to do but why they’re doing it. The leader is able to detach and focus on the strategic objective.

The Laws of Combat are to be followed in order, and after hearing that, it made sense to me. You must first be a team, cover and move, before you can have decentralized command where the team can autonomously execute tasks without needing explicit approval for every step. I think The Laws of Combat are a great starting point for any leader.

🧮 Strategic vs Tactical Thinking

Speakers: Jocko Willink and Leif Babin

Next, we covered two different ways of thinking. Strategic thinking is all about long term goals, and tactical thinking is about short term goals. You can be making continuous tactical wins, but if they don’t help the strategic objective, they‘re useless. Take a step back and recognize, analyze, and react. You don’t want to have a tactical victory that comes with a strategic failure.

As a leader, you must think both strategically and tactically. I’ve never thought about this before—you can make tactical wins, but when those don’t help you strategically, they won’t make a difference and you need to pivot. Detaching yourself from the situation and observing is a superpower. If you’re too close, you may miss the big picture.

🔍 Decision Making & the OODA Loop

Speakers: Dave Berke

In this talk, we covered the OODA Loop—a method created by John Boyd for taking in information, processing it, and using it to make a decision. This method has four steps:

Observe — Gather information from various different places: your customers, your competition, your team, etc.
Orient — Put that information into context and turn your raw data into useful information. Your past experiences can help you predict the future. This is Boyd’s most critical part of the loop.
Decide — This is where you start to take extreme ownership. You shift away from the science of the loop and start leading.
Act — This is the most important step: implementing your plan.

This loop repeats, and observations or feedback from previous plans and actions are used to reorient yourself and make new decisions and actions.

Me meeting Jocko Willink and Leif Babin, the authors of Extreme Ownership and founders of Echelon Front.

Extreme Ownership Muster covered some interesting methods for approaching leadership, both in life and in business. If you‘re interested in learning more, you can check out the books written by the Echelon Front team that put together the conference!

Every Screen in Your App Should Be a Scrolling View

Michael Amundsen — Wed, 23 Mar 2022 00:00:00 GMT

In this blog post, I’m going to tell you why every major screen in your application should be embedded in a scrolling view.

Wait, what? Not everything in my application needs to scroll! I used to agree with you—but I’ve learned over the past five years that that‘s almost always the wrong assumption.

I’m going to highlight why almost every screen in your app should be embedded in something like UIKit’sUIScrollView, UITableView, or UICollectionView; or SwiftUI’sScrollView, List, or Form .

What is a “screen”?

Screens are what a user sees on their device. They are high level containers that contain various UI elements related to a specific task. In an app like Slack, each of the tabs on the tab bar is a screen—as well as each channel you open.

To oversimplify it from a code standpoint, most UIViewControllers represent the screens of your app. In SwiftUI, it’s harder to draw a destination. Views can be a container for the whole screen while also being made up of smaller Views, like a LoginView having a TextField view.

What are some parts of an app that may not scroll?

I’ve found that most developers don’t naturally set up screens like onboarding, login, and signup to scroll. I think this is mainly because these screens tend to have pretty simple UI with minimal content.

Now, let’s look at three main reasons why these screens should scroll—even though they may not look like they need to.

Keyboard

In the case of screens like login and signup, you’ll often have to deal with the keyboard being on screen. The user should be able to interact with the content while having the keyboard up. Being in a scroll view allows you to adjust the content inset or have it automatically handled depending on what implementation you picked.

Device Size

As Apple continues to introduce new device designs with various screen sizes, it’s hard to design a screen that fits and looks good on both an iPhone 13 Pro Max and an iPhone 13 Mini. Being in a scroll view gives you the flexibility to keep your preferred design for the larger devices, and instead of making a custom one for smaller devices, it can scroll when it needs to.

Dynamic Type

Accessibility shouldn’t be optional, so your app should support Dynamic Type throughout the interface. Woah there, that sounds like a lot of work!

If you architect all your screens to be in scrolling views, a majority of the work to support Dynamic Type is already done. As the user adjusts the type size to fit their needs, the view can shrink and grow, allowing itself to scroll if you run out of space.

Example

Now that you know why a simple screen should scroll, I’ll walk you through an example of taking a basic sign up screen and allowing it to scroll if needed.

Here, you have a view for signing up. There are text fields for email, password, and password confirmation. There is also a sign up button.

At first glance, you might consider building this with a UIStackView that has a couple UITextFields and a UIButton. Alternatively, in SwiftUI, you may build it with a VStack that includes a few TextFields and a Button. Here’s what it looks like on an iPhone 13 Pro Max vs. iPhone 13 Mini with an increased Dynamic Text size:

We’ve got a problem!

UIKit

You could convert this view over to using UITableView or UICollectionView but the content isn’t really being reused, which is one of the main benefits of those classes. I’d like it to scroll, but I don’t need all those optimizations. That’s where you can use good old UIScrollView. You can embed your UIStackView in a UIScrollView, and you’re already almost finished with supporting Dynamic Type in this screen.

Xcode has added the Content Layout Guide and Frame Layout Guide when constraining UIScrollViews in iOS 11+. You can constrain the content, the UIStackView, to the contentLayoutGuide top, bottom, leading, and trailing to define the scrollable area. You can then constrain the UIStackView ’s width to the frameLayoutGuide so that it only scrolls vertically. That’s it—your content can now scroll as it shrinks or grows!

SwiftUI

Depending on the styling of the screen and what version of SwiftUI you are using, you could potentially build this with a Form. You can then place the few TextFields and a Button in it. That’s it—your content can now scroll as it shrinks or grows!

Recap

Even the simplest screens in an app should be architected to allow for scrolling. That way, you generally don’t have to think about supporting the keyboard, different device sizes, or Dynamic Type. Your screens become more flexible and can continue to work as they change over the lifetime of the app. Making every single screen in your app scrollable will benefit you and your users—I hope I’ve convinced you to give it a try!

Our Favorite Apps of 2021

Team Lickability — Thu, 16 Dec 2021 00:00:00 GMT

We are, as you can probably guess, big fans of iOS apps here at Lickability. So here‘s a small selection of the apps we loved the most this year—some are new, some are just new to us, and some are old staples that we’re still enjoying.

🩺 Gyroscope

Gyroscope calls itself an “OS for your body,” and while that’s a pretty big claim, it isn’t far off. The app blends your health data, location data, sleep tracking, and even time tracking from RescueTime into a dashboard for your body and mind. I’ve used it extensively in the last year to get better sleep, work out more, and improve my nutrition. And with new features like AI food scanning and even human coaches, it just keeps getting better.

— mb Bischoff

💬 Duolingo

I discovered that you can use the Apple pencil on Duolingo to write in different languages during the exercises. I‘ve known from growing up that the only way I learn a language is if I write it and now I can do that 100% in this app instead of having to use a notebook at the same time.

— Michael Amundsen

💸 Copilot

Copilot gives my a simple and beautiful overview of my finances, and helps me see where my money is going. It is snappy, beautifully designed, and a breeze to setup and use. Budgets and categories are created automatically, and the only work I have to do is review the data and make decisions.

— Tom DeVuono

🎮 GameTrack

This year, I upgraded from a spreadsheet to using GameTrack to track which video games I’m currently playing, want to play next, have finished, or have abandoned.

I used to tinker with the idea of building an app for myself to solve this problem, but in recent years, GameTrack has shown great commitment to new features and improvements, so I’m more than happy to give it a spot on my home screen. I especially like its statistics features, which include “Year In Review” at the perfect time to decide on my game of the year. The icing on the cake: it also works on Mac!

— Michael Liberatore

🚀 Power E*TRADE

With meme stock mania this year, I upgraded my trading experience from Etrade‘s normal app to Power E*TRADE. It‘s a lot more specialized and has tons more data at your fingertips. I particularly like the paper money account you can set up through it to “practice” trading.

— Michael Amundsen

⛳️ TheGrint

I use TheGrint as my score keeper and GPS app for golf. The app is simple to use, fast, and allows me to keep track of a fair number of stats for free. The GPS portion is great when playing unfamiliar courses and the added social features help me engage with my friends when they do well.

— Tom DeVuono

📵 Opal

I downloaded Opal in an effort to reduce my screen time and use social media more mindfully. Opal lets you set up schedules for when to block certain apps, and if you‘d like to take a break from that schedule, you are prompted to type out a reason why you absolutely need to use Twitter for 5 minutes. I can‘t say I’ve fully succeeded in reducing my screen time on a regular basis, but I‘ve enjoyed using the app either way.

— Jillian Meehan

Closing Our Office

Jillian Meehan — Thu, 09 Dec 2021 00:00:00 GMT

Three years ago, we wrote this blog post:

A few months ago, all seven of us were sitting side-by-side in a small co-working office. We had enough space for our desks and computers, but that was about it. Not exactly ideal. So, we decided to do something about it and started the search for a new office.

We went from tiny coworking spaces to a full-sized office, and spent months working to make it feel like our own. We filled it with furniture, snacks, new team members, and friends. We had company game nights and weekly Everybody Meetings and coffee breaks there. We appeared on TV there. We celebrated 10 years of being a company there. And we had a pretty fun last holiday party there.

But all good things come to an end. At the beginning of 2020, our entire team (like much of the world) started working from home, not knowing when we‘d be able to return to the office. We switched to virtual meetings and game nights, perfected our at-home setups, and tried to plan for the eventual reopening of Lickability HQ.

Finally, in the early summer of this year, our team was fully vaccinated and ready to see each other again. We implemented our COVID safety policies, moved some furniture around, and invited everyone to come into the office if and when they wanted to. And while it was nice to see each other again and spend time in our old spot, it was clear by the end of the summer that the future of Lickability looked a lot different from pre-pandemic Lickability.

Adjusting to working from home after spending every day commuting into an office with the rest of your coworkers is tough. But adjusting to going back into the office after spending over a year working from home is just as hard. So as excited as we were to be able to reopen our office, we quickly found that we weren‘t getting nearly as much use out of it as we used to, with a lot of the company choosing to continue working from home most days of the week.

When our lease was up in September, we decided not to renew it. Instead, we‘re committing to making Lickability a great remote place to work. We‘re continuing to help our team members build setups they love at home, planning virtual team lunches and other ways to stay connected with each other, and looking into options for drop-in spaces so we can meet up (or just get out of the house) occasionally. And we also just made our first fully remote hire!

It‘s bittersweet to say goodbye to our office—moving into that space was such an important part of Lickability’s history, and we have so many good memories there. But this is an important step forward for us, and we‘re excited to see where it takes us.

Designing Mastodon’s App

mb bischoff — Thu, 07 Oct 2021 00:00:00 GMT

At Lickability, we’ve long been interested in the power of social networks, which is why we’ve worked on apps like Houseparty, Tumblr, and Clubhouse over the years. But there are few social networks where we’ve built a presence. In 2018, we joined Mastodon—a decentralized open-source social network from Eugen Rochko (aka Gargron). And in 2021, Eugen came to us to design the official Mastodon iOS app. Then in February, the team released 1.0 of Mastodon for iOS on the App Store to much fanfare and rave reviews.

While there have always been many third-party iOS apps for Mastodon on the App Store, Eugen wanted us to create a native first-party application that showcased what’s unique about Mastodon while also focusing on bringing in entirely new users. The app incorporates many of Mastodon’s signature features: robust privacy controls, custom profile fields, content warnings, polls, and custom emoji for each Mastodon server.

Our designer, Sam Gold, drew inspiration from Mastodon’s existing web application, Apple’s Human Interface Guidelines, and decades of social media network design to craft something that looks at home on iOS but still feels like Mastodon. The app works in both light and dark mode and makes extensive use of context menus and haptics to feel fast and modern. Plus, it’s peppered with whimsical illustrations of actual mastodons from artist Dopatwo.

Working with the team at Mastodon and their development team at Sujitech was an absolute dream come true for us as longtime fans of the network’s ethos and ethics. And we’re not done yet. We’ve still got plenty of new features for the app up our sleeves in future releases, so stay tuned to the Mastodon blog and Patreon for updates.

Whether you’ve never used Mastodon before or you’re a longtime fan, download the app and find your community. Follow your friends and discover some new ones.

5 Questions to Ask Before Building an App

Thomas DeVuono — Mon, 16 Aug 2021 00:00:00 GMT

At Lickability, we‘ve helped lots of folks build and ship great apps. Because of this, many times when people meet with us for the first time, they ask us if there’s anything they‘re forgetting when thinking about starting work on their 1.0.

Here are 5 of the most important questions we think you should ask yourself before starting to build your app.

What are your goals?

First and foremost, you should think about your goals for the app, as these goals will drive many of the other decisions you‘ll have to make down the road.

Is the purpose of the app to make money right away, maybe by selling access to a product, service, or experience? Or is the goal to simply acquire users in order to validate the idea and prove product market fit? Are you looking to develop a prototype, launch an MVP and iterate on your idea (maybe even in a private beta), or launch a fully polished 1.0?

Setting realistic and obtainable goals at the start of your app-building journey will give you a solid foundation on which to make future decisions and make many other questions clearer to answer.

What platforms will you support?

For some folks, the answer here may seem easy...support all the platforms! But, depending on the goals you‘ve established when answering the previous question, that may not be the right answer for your project.

When thinking about mobile apps, there are two main players: iOS and Android. But with this simple choice comes many other decision points, such as whether to write the apps natively or use a cross-platform technology. For folks that are starting from scratch, our recommendation is to pick a single platform to nail the experience first. This is usually the quickest and least expensive option, and allows you to get your product out in the world to start getting feedback from users.

If one of your goals is to reach as many people as possible at launch, then supporting both platforms out of the gate may be best. If this is the case, you‘ll have a choice to make about how the app is created. If performance and polish are important to achieving your goal, writing the app natively for each platform is your best choice, as it lets you take advantage of everything the hardware and system OS has to offer. If cost and speed are the main factor, taking advantage of a cross-platform technology (in short, one codebase for both platforms) may be the right call. However, a word of caution we like to make our clients aware of is that using cross-platform technologies is not as simple as getting two apps for the price of one. You’ll still have to consider differences in design across supported devices, and you‘ll need some native code to make specific features work on each platform.

In addition to the mobile platform you choose, you may want to evaluate if supporting other platforms for tablets and wearables makes sense. Finally, don‘t forget the other technologies in the stack that will power your app—a content management system to add content to the app, a backend for user accounts, and user analytics and crash reporting to monitor performance.

What can you do yourself and what do you need help with?

Building a mobile app from scratch is hard work. It would be wise to perform a self-evaluation of what your capabilities are, both in skill and in available time. This will help you put together a clear list of what work you can take care of in-house and what help you‘ll need to seek out.

Some services to keep in mind:

Design
Frontend & Backend Development
Project Management
Product Management
Customer Support
Marketing/Social Media

This process also leads well into the next important question...

What is your budget?

One of the most difficult (and most important) questions to answer revolves around the triple constraints: time, cost, and scope. This project management triangle applies to any project you could ever undertake—from redoing a kitchen sink in your house to building the next Facebook.

Time can be reduced by adding more engineers to the project (and adding cost) or reducing scope. One thing to keep in mind here is that there are diminishing returns on adding engineers to lower the development time, as only so much work can be done in parallel.

Scope will largely be determined by the goals for the app. As much as we may want to include every feature possible, the reality is you might have to make some difficult decisions here. However, don‘t forget that you can always add more features later in the app’s roadmap.

Mobile app development is expensive, so keeping costs in check is an important factor. Generally, reducing scope is the most effective way to reduce costs, but increasing development time can also be a good way to save a little bit of money.

Putting together your budget is also a good time to think about your funding. There are several options to fund a project, that all carry their own pros and cons. You could raise venture capital funds, crowdfund your idea on platforms such as Kickstarter, look for angel investors, seek out funding from friends & family, or bootstrap the project yourself to name a few possible solutions.

What are your plans after the app is released?

Finally, take some time to think about your post-launch plan. Software is never perfect and always changing, so what will your plan be for maintenance & bug fixes? When users finally get to play with your app, they will have feedback. How will you address this feedback and provide support for customers who need it? Are you prepared to support your app if it explodes in popularity? What about additional feature development, whether that be items on your roadmap or user requested features? Do you plan on taking over ownership of the app, hiring a full-time team, or continuing to use a partner?

Answering these questions should put you well on your way to bringing your idea to life. Whether you need help answering these questions yourself, or you are ready to get started, we‘d love to chat with you and help however we can!

Automating App Store Screenshots

Daisy Ramos — Mon, 02 Aug 2021 00:00:00 GMT

Why are screenshots important?

You’re probably here because you might be shipping to the App Store soon or are coming close to App Store submission. 🚀 Truly an exciting part of the app creation process! One very important part of the App Store submission process is taking screenshots of key features in your app. Screenshots help potential users visualize what functionality to expect when downloading your app for the first time. Taking screenshots can also be a very time consuming part of the process—luckily there is a nifty tool from Fastlane to help automate this process called snapshot.

Getting started with Fastlane

You’ll need to have Xcode command line tools installed, but in case you don’t, entering this command via Terminal should do it:

Shell

xcode-select --install

Fastlane can be installed through multiple clients including Homebrew:

fastlane can be installed multiple ways. The preferred method is with Bundler.
Fastlane's setup documentation

These are the instructions from the documentation:

Install Bundler by running gem install bundler
Create a ./Gemfile in the root directory of your project with the content

Shell

source "https://rubygems.org"
gem "fastlane"

Setting up Fastlane snapshots

Running this command will generate the Swift SnapshotHelper and Snapfile necessary for configuring metadata related to your screenshots:

Shell

fastlane snapshot init

The generated Snapfile will look similar to this:

You’ll have to change the SchemeName to the project test target name. For reference we’ll also drag the SnapshotHelper Swift file to the UI test target folder, although it can remain anywhere in the project directory.

If you’re curious about which APIs are used for the snapshots, you can read more about how XCUIScreenshot is used for generating screenshots. The SnapshotHelper also helps scale the snapshots based on device orientation and size using UIGraphicsImageRendererFormat.

Based on the platforms your app supports, the device list can expand or decrease. For now we’ll choose iPhone 12 Pro Max, iPhone SE (2nd generation), iPad Pro (12.9-inch) (4th generation) to generate the snapshots in the Snapfile.

You can also also download additional simulators or change the device list to match the simulators available. Otherwise Fastlane will produce an error when attempting to set those values.

For simplicity we’ll set up the Snapfile like this:

Swift

# Uncomment the lines below you want to change by removing the # in the beginning

# A list of devices you want to take the screenshots from
 devices([
   "iPhone 12 Pro Max", 
   "iPhone SE (2nd generation)",
   "iPad Pro (12.9-inch) (4th generation)"
 ])

 languages([
   "en-US"
 ])

# The name of the scheme which contains the UI Tests
 scheme("FastlaneSnapshotsUITests")

# Where should the resulting screenshots be stored?
 output_directory("./screenshots")

# remove the '#' to clear all previously generated screenshots before creating new ones
 clear_previous_screenshots(true)

# Remove the '#' to set the status bar to 9:41 AM, and show full battery and reception.
 override_status_bar(true)

Setting up Xcode

We made an Xcode project with all of the examples shown in this post. You can find it right here.

An important part of the Fastlane automation tool for snapshots is setting the UI test target to build and run like this:

Configuring the UI test

Next, we’ll need to set up the UI test code with an XCUIApplication instance along with a helper function from the SnapshotHelper like this:

Swift

private var app: XCUIApplication!

override func setUp() {
    super.setUp()
    continueAfterFailure = false
    app = XCUIApplication()
    setupSnapshot(app)
    app.launch()
}

One thing to note here is that UI tests can be time consuming depending on the complexity and architecture of your app. In order to create meaningful App Store screenshots, you’ll need some variation of mock data. When building Scorecard we found launch arguments super useful to help differentiate the UI test at app launch. Then you can simply add an extension like this to detect the launch argument:

Swift

extension UIApplication {
    
    /// Checks the command line arguments for the current process to see if a UI test is running.
    public static var isUITest: Bool {
        return CommandLine.arguments.contains("-UITests")
    }
}

For simplicity, the demo project contains a SwiftUI List, avatar image, stepper, and label for the stepper count. I’ve also included a navigation item to display a text field alert to change the title of the list. The SnapshotHelper we covered earlier contains this function that takes the screenshot and append a name to each one:

Swift

/// - Parameters:
///   - name: The name of the snapshot
///   - timeout: Amount of seconds to wait until the network loading indicator disappears. Pass `0` if you don't want to wait.
func snapshot(_ name: String, timeWaitingForIdle timeout: TimeInterval = 20) {
    Snapshot.snapshot(name, timeWaitingForIdle: timeout)
}

The UI test code will then look something like this:

Swift

func testTakeSnapshots() {
    snapshot("1-GameView")

    let coordinate = app.tables.otherElements.firstMatch.coordinate(withNormalizedOffset: CGVector(dx: 0.9, dy: 0.5))

    for _ in 0...5 {
        coordinate.tap()
    }
    snapshot("2-StepperIncremented")
    app.navigationBars.firstMatch.buttons.firstMatch.tap()
    app.textFields.firstMatch.tap()
    snapshot("3-Alert")
    app.textFields.buttons["Clear text"].tapElement()
    app.typeText("Taboo")
    app.buttons["Dismiss"].tap()
    snapshot("4-GameChanged")
}

Generating the snapshots

After confirming that this builds and tests succeed for each device in the Snapfile list, we’ll run:

Shell

bundle exec fastlane snapshot --verbose

The --verbose flag is great for identifying build or test failures. This might also take a few minutes. ⏳

Once the snapshots are generated you’ll see a nice results table indicating success or failure.

You’ll also see a local html file with the snapshots in the /screenshots directory.

These look fine but they’re unframed. Luckily Fastlane has another nifty command line tool to frame these screenshots into iOS device frames called frameit.

Using Frameit

You’ll need to download the frames first:

Shell

bundle exec fastlane frameit download_frames

Then:

Shell

bundle exec fastlane frameit

After that runs, navigate to the screenshots directory and you can see that those framed screenshots were added separately.

From Fastlane’s advanced frameit usage documentation:

With frameit it's possible to add a custom background and text below or above the framed screenshots in fonts and colors you define.
Fastlane

To make this possible we need to create a json file named Framefile with the following structure:

JSON

{
  "device_frame_version": "latest",
  "default": {
    "title": {
      "font": "./Fonts/SF-Pro-Rounded-Bold.otf",
      "color": "#FFFFFF"
    },
    "padding": 50,
    "show_complete_frame": false,
    "stack_title": false,
    "use_platform": "IOS"
  },
  "data": [
    {
      "filter": "1-GameView",
      "background": "./red.png"
    },
    {
      "filter": "2-StepperIncremented",
      "background": "./blue.png"
    },
    {
      "filter": "3-Alert",
      "background": "./yellow.png"
    },
    {
      "filter": "4-GameChanged",
      "background": "./green.png"
    }
  ]
}

In the docs, the general parameters are listed with a description indicating if it’s optional or mandatory. The background key is mandatory and must be an image file, e.g. png, jpg. I’ve included some sample colors in the screenshots folder along with a custom font.

Notice how the filter key includes the named screenshots from the UI test. We’ll use that key to associate it with a title in a title.strings file like this:

Yaml

"GameView" = "Keep score of your favorite games";
"StepperIncremented" = "Watch the scoreboard update in real time";
"Alert" = "Modify games on any device";
"GameChanged" = "Track play history with sessions";

Then run:

Shell

bundle exec fastlane frameit

The result: framed screenshots with the parameters we defined!

Conclusion

Fastlane’s snapshot and frameit automation tools are incredibly useful for App Store screenshots and App Previews. It’s easily integratabtle through the command line and Xcode. This setup and configuration can be adopted into new or existing Xcode projects. Like many software tools, these can also be improved. For instance, the titles can only be one color—it would be nice if there was some attributed support for highlighting specific text. Having the background colors as image files work well, but having extended configurations for hex or RGB strings would be more customizable. Nonetheless, we’re fans of the Fastlane tool suite and hope this post helps in your app submission process!

How to recover and export your quotes from Quotebook

Team Lickability — Tue, 06 Jul 2021 00:00:00 GMT

Unfortunately, we no longer develop or actively support Quotebook and we removed it from the App Store years ago.

With the release of iOS 14.5, Apple had to update many older apps so they could continue to run. To download a copy of Quotebook that you can open in order to export your quotes:

Attach your device to your computer and use Finder (on macOS) or iTunes (on Windows) and copy your .quotebook files to your computer as a backup
Confirm that you were using iCloud syncing for Quotebook in the Settings app (Settings → Your profile at the top → iCloud → Confirm that the switch next to Quotebook is on)
Uninstall Quotebook from your device
Redownload Quotebook from the App Store “Purchased” list by searching for it
Open the app and wait for iCloud to sync (this can take up to 20 minutes)

To export your quotes from Quotebook and move them to another system:

Open Quotebook
Tap the settings gear in the top left
Tap “Backup & Restore”
Tap “Export CSV”
Choose “Email”
Email the CSV to yourself

I hope this helps you regain access to your quotes, and if you have any trouble or further questions, don‘t hesitate to reach out. Thank you so much for being a longtime customer, supporter, and user of Quotebook.

Conferences Condensed: WWDC21

Team Lickability — Tue, 22 Jun 2021 00:00:00 GMT

Another year, another great WWDC. The Lickability team watched a lot of videos from this year‘s conference in our Discord—but here are a few that we loved the most.

Demystify SwiftUI

Many Lickability engineers have taken the leap into SwiftUI on client and internal projects, so needless to say we were eager to watch any sessions that focused on this year’s improvements to the framework. However, the session that stuck out to me the most wasn’t focused on the introduction of new APIs. Demystify SwiftUI has re-shaped the way I think about building SwiftUI views, with a focus on performance and correctness.

SwiftUI promises the ability to describe your UI and let the framework figure out the best approach to build, render, and animate it. In practice, however, having an understanding of exactly how its performant view diffing works, including view identity and the lifetime of view state, is essential for efficient output, accurate animations, and preventing tricky bugs. Until now, this was simply (educated) guesswork about what was going on under the hood, so it’s so nice to finally have the answers on how to rely on SwiftUI’s strengths. After this session, you may think twice about unnecessary branching and type-erasing with AnyView!

— Michael Liberatore

Make blazing fast lists and collection views

iOS 15 introduces prepareThumbnail(of size: CGSize) for efficiency with large images that can scale and prepare an image to a smaller size. Which saves a lot of CPU time and memory.

Swift

// Using prepareThumbnail
// Initialize the full image
let profileImage = UIImage(...)
// Set a placeholder before preparation
posterAvatarView.image = placeholderImage
// Prepare the image
profileImage.prepareThumbnail(of: posterAvatarView.bounds.size) { thumbnailImage in
  DispatchQueue.main.async {
    self.posterAvatarView.image = thumbnailImage
  }
}

At one point or another, almost every iOS developer comes across image loading performance bugs or hitches. This new API looks like a promising enhancement for asynchronous content in collection or list views.

— Daisy Ramos

The process of inclusive design and The practice of inclusive design

The design talks at WWDC are always my favorite, and this year was no exception. The pair of talks on inclusive design were incredibly well thought-out looks at the axes of inclusion that designers can and should consider when designing apps and their intersections. While we often talk about accessibility as one of these areas, but Apple took time to cover religion, race, class, gender and sexuality and how they impact the experiences our users have in apps. There’s even a new Inclusion section in the Human Interface Guidelines.

— mb Bischoff

Mines a two-parter: The practice of inclusive design and The process of inclusive design. Here are some of my takeaways:

Reach the largest audience by being inclusive
You want a user to feel like you designed your app with them in mind
Design is not just how the app looks; it’s the content (words, images, audio, video, and accessibility features you implement)

6 practices

Tell diverse stories
Avoid stereotypes
Adopt accessibility
Localize for culture
Use color mindfully
Encourage self-expression

Inclusive design is better for everyone

Empower and delight
Inclusion is a journey
Build diverse teams and empower them
See differences as an asset
Budget time and space to think inclusively, it doesn’t come for free

— Thomas Devuono

🐞 Insidious Bugs #3: Apple App Site Association File Identifiers

Michael Amundsen — Tue, 25 May 2021 00:00:00 GMT

The Bug

When creating an apple-app-site-association file, the documentation says to use your Application Identifier Prefix followed by the Bundle Identifier for your appIDs key.

{
  "applinks": {
      "details": [
            {
              "appIDs": [ "ABCDE12345.com.example.app", "ABCDE12345.com.example.app2" ],
              "components": [ ... ]
            }
        ]
    },
    "webcredentials": {
      "apps": [ "ABCDE12345.com.example.app" ]
    }
}

Because I was not sure where to find our Application Identifier Prefix, I decided to watch the WWDC 2019 What‘s New in Universal Links video. It tells you:

The prefix may or may not be equal to your Team Identifier. Check the developer portal to confirm your app identifier.

In addition, I decided to check out WWDC 2020 What‘s new in Universal Links to make sure I had the most up to date information. It tells you:

The entitlement mentions your web server‘s domain name, and the web server mentions your app’s Application Identifier.

At this point, I was confused at what the difference between your App Identifier and Team Identifier was and wasn‘t sure where to get the answer.

Team Identifier is an identifier associated with your membership through the Apple developer program.

App Identifier is an identifier associated with the specific app on your developer account.

Following the first video, I went to the developer portal and found our Team Identifier in the membership section.

I used it in our apple-app-site-association file. The file was deployed and I went to the app and try out Password AutoFill and Universal Links requests. Nothing worked, yet the apple-app-site-association file passed validation. I was left wondering why.

The Solution

Hidden in the WWDC 2019 video I mentioned, they say:

The prefix may or may not be equal to your Team Identifier.

Depending on when the application you are working on was setup, your Team Identifier and App Identifier may or may not be the same. If your Team Identifier and App Identifier are not identical, the app will make Password AutoFill and Universal Links requests with the App Identifier instead, resulting in the feature not working.

To validate what identifier you need to use, visit the Identifiers tab of the Certificates, Identifiers & Profiles section of the developer page for your application.

In the list, find your Bundle Identifier and click on it in the list.

I had no idea that you could click on these items, because there is no indication that the items are selectable.

On this page, you will see App ID Prefix which is the value you must use for the apple-app-site-association file. The prefix may or may not be equal to your Team Identifier.

Example of App Identifier that is not the same as Team Identifier

Example of App Identifier that is the same as Team Identifier

Swap that out, deploy that to the web server, and test out Password AutoFill and Universal Links requests to see that they now work.

How We Got There

We came across this bug while working with a client. After a lot of validation and back and forth with our client‘s website team, we decided to look at the console logs the app was printing out when trying to make Password AutoFill requests. (Note: you must test on device for this feature to work.)

Upon going to a screen where we expected Password AutoFill, we noticed at the time the console was printing out an error saying that it could not complete the Password AutoFill request.

2021-05-21 12:59:49.798251-0400 Authorization failed: Error Domain=AKAuthenticationError Code=-7089 \"(null)\" UserInfo={AKClientBundleID=\"BUNDLE IDENTIFIER HERE”}

After discovering what I believe is a hidden page in the developer portal, we noticed that our app did not use the Team Identifier as its app‘s identifier. We had our client’s website team update the file to include the proper App Identifier, and now everything works!

Scorecard is Here

Team Lickability — Mon, 03 May 2021 00:00:00 GMT

Our team at Lickability has been working on a new iOS app called Scorecard, and it‘s available on the App Store today!

Scorecard is an app that makes it easy to track scores in your favorite games. Just enter the name of the game, add players, and start playing! As points are earned, watch as the scoreboard updates instantly to show who’s winning. Do you love playing games with friends and family, but hate fiddling with tiny pencils, notebooks, or dice to keep score? Scorecard was designed just for you.

If you enjoy playing the same games periodically, Scorecard lets you start new sessions with a single tap. While you’re playing, you can group players into teams, start new rounds, total up your scores, and even AirPlay the scoreboard to your TV. Once you’re done, pick a winner and celebrate your victory by sharing the final tally with your friends on social media.

More features we love

Sync your games to iCloud so they’re available on all your devices
Match each player’s mood or game piece with a custom color
Tap a score to access a built-in calculator to do more complex math
Snap a photo or choose an avatar for everyone in your group
Score points highest-to-lowest or vice versa, depending on the game rules
Long press on the app icon to resume a recent game or start a new one
Play at any time of day or night, with full support for dark mode

Thanks! ❤️

We want to say a special thank you to our friends and beta testers for their support, and to Jeremy Swinnen for designing Scorecard. We couldn‘t have made this without any of you.

If you want to give Scorecard a try, you can download it right here. Once you play around with it a bit, we‘d love to know what you think! Leave us a review on the App Store or send us suggestions on Twitter.

And if you want to learn even more about Scorecard, take a look at our website to see all the fun things you can do with it!

Welcome to Club Mobile

mb bischoff — Thu, 01 Apr 2021 00:00:00 GMT

We’re huge fans of the audio medium at Lickability. Lots of folks at the company listen to podcasts during work and in their free time as a way to relax, learn, and laugh without the additional stress of screens. And we’ve long pondered the idea of introducing a podcast of our own to talk about our thoughts on the design and development of great apps, but something was always missing: you!

At the end of February, we launched an experimental audio show on Clubhouse, a rapidly growing audio social network and an app we’ve been lucky enough to work on a bit. Clubhouse is designed as a space for casual, drop-in audio conversations—with friends and other interesting people around the world. From even that first episode, the thing that immediately struck us was how fun it was to interact live with our audience, answer questions, and share our favorite tips and tricks with folks listening. Now it’s become a fixture of our week. Every Friday at 4 PM ET, we put on our AirPods and talk about the topics that are top of mind.

So far we’ve recommended apps as software sommeliers, discussed localization best practices, chatted about how to hire great engineers, and surveyed the landscape of continuous integration services. In every single one of these live conversations, we’ve invited folks in the community to share the stage with us where you’ve taught us new things and helped us cover the topics in even more depth. And since all of these conversations are live and ephemeral, we can be totally honest about our feelings on certain technologies or problems without worrying about making sure they’re updated as the industry changes.

Our Clubhouse show has gone from an experiment to a great new way to connect with folks who are interested in working with us or working for us, and we’re excited to continue hosting great conversations with our community, so we’ve given it a permanent home as a Clubhouse club. It’s called Club Mobile, and over 300 designers, developers, founders, and students from all over the world have become members and followers, to be notified each week when we go live.

This Friday, our engineers will be discussing the ins-and-outs of different iOS layout technologies, but we’re always thinking up new ideas for new topics to discuss. If you have anything you’d like to hear about or need an invite to Clubhouse, send us a message on Twitter at @lickability and it may just turn into a live show sometime down the road. Welcome to the club! ✌️

How To Learn Swift

Marc Aupont — Tue, 16 Mar 2021 00:00:00 GMT

Learning a new programming language can be a very challenging concept to most if you haven‘t done it before. In today’s day and age, there are a plethora of resources that provide some level of training or practice. But where do you get started? Well, you‘ve come to the right place! The ideal reader for this post is someone who has heard all kinds of nice things about Swift and the Apple ecosystem and wants to get started learning the language. By the end of this post, you should have a structured approach to learning Swift while also being provided suggested tools and resources to assist in the process.

So, you have finally decided that you are ready to learn! Now what? In order to help make this post applicable to as many people as possible, I am going to detail how I learned Swift with the hopes that you will be able to pick and choose what works for you. The techniques listed can be applied to Swift or any other programming language.

What‘s your learning style?

When taking on the challenge of learning a new programming language, one of the first things you should do is establish or figure out your learning style. By investigating the way you learn best, you‘ll be able to fine-tune your learning and get the most out of it. If you’re like me, you might be picking up the new language while working a full-time job and time is of the essence. This means you need to be very pragmatic with your time and effort. I discovered early on that I am a very visual learner, so I focused my efforts on finding video content that taught the core concepts of Swift with examples. I came to this discovery because of how frustrated I was when I read docs and they didn‘t make sense to me. I was missing the ability to connect the dots. However, when I watched video content, I was able to pick up on other cues that helped me develop a connection between the theoretical and the practical use case.

If you are unsure about your learning style, there are several tools that can assist with this. While doing some research for this post I found the Learning Style Assessment and it confirmed for me everything I already knew about myself. I highly suggest completing the assessment if you are having trouble determining your learning style. Once complete, you will be presented with your learning style as well as suggestions for how you should study or consume content.

Resources to learn from

When I identified my learning style, I started on my journey to find resources that best complemented this style. My initial reasoning for learning Swift was to build impactful and useful apps. With that in mind, I started with project-based learning. One thing to be mindful of is there is a difference between learning Swift and learning iOS. On one hand, you are learning a programming language, on the other, you are learning how to use frameworks and libraries using that language. Over the past few years, Swift has become useful for things like scripting, server-side use, as well as IoT (Raspberry Pi, Arduino) use cases. When deciding which resources are best, keep in mind the end goal of how you would like to use Swift.

Below are some of the resources I‘ve used:

Hacking With Swift

Hacking With Swift run by Paul Hudson is one of the most comprehensive sites there is when it comes to learning swift. He has several books that are free and paid as well as the 100 Days Of Swift challenge. What I like the most about the 100 Days of Swift are the corresponding quizzes. It‘s fairly easy to just read through something and think that you understand it, so taking a quiz on the subject ensures you’ve retained the knowledge.

We Heart Swift

I found this cool little tool when I was searching for ways to learn Swift and I found it very helpful because they have lessons and quizzes that you can take.

Udemy

This is one of my favorite resources because of the variety and cost of courses provided. Although I had issues with the mobile app, it was one of the only apps with offline access to videos. This feature alone kept me on the platform because I could download the content and watch it on the train when I had little to no internet access. I used Udemy mostly for the project-based learning approach where I will find a course that has interesting projects but also has very good “Swift language” concepts as part of the course. Here are some of my criteria when deciding which course to purchase on Udemy:

What is the star rating and how many students have left ratings? Regarding this, you have to be careful because it can be misleading. Some instructors have 4 or 5-star ratings but a very small sample size. If their sample size is small, be sure to read the actual text of the ratings to get a better idea of the quality of the course.

Evaluate the Table of Contents Is this course going to teach me Swift, iOS, or both? Depending on where you are in your journey, you may have already learned the basics of Swift and are looking to supplement your learning by building actual projects. Some courses focus simply on projects while others include a section solely dedicated to learning the Swift programming language. As I stated above, there is a difference between learning Swift the programming language, and something like UIKit to create your user interface and such. If it‘s a comprehensive course, this will be called out in the outline or table of contents.

Use focused search terms If you are looking for a course that is focused on teaching Swift, be sure to use that plus the version in your search term. At the time of writing this post, the current version of Swift is Swift 5.

Youtube

I made heavy use of youtube during my early learning days and still do. My favorite aspect of Youtube are the sheer number of videos available and the recommendation engine that suggests certain videos after completing one. I discovered several new channels in this way. Below are a few of my favorites for folks that are new to iOS and Swift:

Unwrap

This is a cool open sourced app created by Paul Hudson and is the perfect tool for learning on the go. I believe when learning a programming language you need to CODE EVERY DAY. Depending on your circumstance, it may not always be easy to sit in front of a computer. In those cases, apps like this one are really straightforward and give you a concise means of focusing on learning the Swift language. This app has video and text-based content with interactive quizzes and lessons.

Mimo

This is another one of my favorites when it comes to passively learn in those moments where you cannot be in front of a computer. The interesting part of this app is that it‘s not specific to Swift and has several other programming languages available to learn.

The 5 sources method

In the process of learning, I came across a methodology that still serves me well to this day. I learned about this in a roundabout way while purchasing several Udemy courses. I noticed a pattern that with each course I took, there were certain topics that an instructor would teach, that made absolutely no sense to me, but then I‘d visit another course, and it would be explained in such a way that made perfect sense. It was then that I realized that anytime I don’t understand something, it‘s not my fault, it’s the instructors‘ fault. What I mean by this is that your brain works the way it works, and your learning style is what it is. Unfortunately, everyone’s teaching style may not match your learning style. This is not a knock on the instructor per se, you just need another angle.

My solution to this problem was to always find 5 sources of competing information when studying a topic. These sources don‘t need to be from the same platform but you can do that if it is easier for you. For example, let’s say I‘m learning about for loops, the goal would be to find 5 competing resources that teach for loops and just that alone. What I would be searching for is how to make the information I‘ve found compete with each other. I would search for similarities in the teaching and what the core concepts that they each share. By doing that, I would have a much more well-rounded understanding of the subject at hand.

Summary

Learning a new programming language and can be fun and stressful at the same time. I found that what worked for me was to first figure out my learning style and then use the techniques mentioned above to really maximize my study time. As stated above, the key is to have a very regular study schedule and code every day. In order to achieve that, you need the right type of resources to fill in the gap. If you apply the 5 sources method, you‘ll have a multitude of resources that you can pick from to enhance your learning. In times where you are on-the-go, be sure to try out the mobile apps listed above to keep the knowledge fresh in your mind while testing how well you retain it.

Building a Customizable UITextField with Combine

Daisy Ramos — Tue, 09 Mar 2021 00:00:00 GMT

Customizing text fields is a critical feature of almost every mobile app. We often use them when we need a user to fill out text as part of a form. Because we use them so often, we’re always trying to find ways to optimize implementing them in our app’s user interface.

Here is an example of a customized text field that has additionally inset text and an icon on the right:

Building a Customizable Text Field

To help us build a similar text field that is customizable, we’ll start by subclassing UITextField.

To achieve setting custom insets we‘ll need to override a few methods, specifically the bounds of the text field’s label. Overriding textRect(forBounds:) and editingRect(forBounds:) will yield the results we want:

Swift

/// Used to inset the bounds of the text field. The x values is applied as horizontal insets and the y value is applied as vertical insets.
private var centerInset: CGPoint = .zero {
    didSet {
        setNeedsLayout()
    }
}

// MARK: - UITextField

override func textRect(forBounds bounds: CGRect) -> CGRect {
    insetTextRect(forBounds: bounds)
}

override func editingRect(forBounds bounds: CGRect) -> CGRect {
    insetTextRect(forBounds: bounds)
}

private func insetTextRect(forBounds bounds: CGRect) -> CGRect {
    let insetBounds = bounds.insetBy(dx: centerInset.x, dy: centerInset.y)
    return insetBounds
}

We talked about adding custom views in the text field as well. Since we modified the bounds of the text field‘s label we’ll need to consider the adjusted insets. Similarly to the overridden methods above, we‘ll need to override rightViewRect(forBounds:) like this:

Swift

/// Sets padding for the `rightView` from the text field's edge.
private var rightViewPadding: CGFloat = 0 {
    didSet {
        setNeedsLayout()
    }
}

override func rightViewRect(forBounds bounds: CGRect) -> CGRect {
    var rightViewRect = super.rightViewRect(forBounds: bounds)
    rightViewRect.origin.x -= rightViewPadding
    return rightViewRect
}

The frame of the right view‘s rectangle is also adjusted to include some padding. Since we have a foundation set up for the right view all that is left is to populate it. UITextField doesn‘t have a method like setImage to instantiate an image view for us like a UIButton would. Setting the right view with a UIButton will suffice. Here‘s what that would look like with some optional properties like text and tint color:

Swift

private let rightAccessoryButton: UIButton = UIButton(frame: .zero)

/// Sets padding for the `rightView` from the text field's edge.
private var rightViewPadding: CGFloat = 0 {
    didSet {
        setNeedsLayout()
    }
}

/// Sets an image for the `rightView`.
private var rightViewImage: UIImage? {
    didSet {
        rightAccessoryButton.setImage(rightViewImage, for: .normal)
        rightViewMode = rightViewImage != nil ? .always : .never
    }
}

/// Sets text for the `rightView`.
private var rightViewText: String? {
    didSet {
        rightAccessoryButton.setTitle(rightViewText, for: .normal)
        rightAccessoryButton.setTitleColor(rightViewTintColor, for: .normal)
        rightViewMode = rightViewText != nil ? .always : .never
    }
}

/// Sets tintColor for the `rightView`.
private var rightViewTintColor: UIColor? {
    didSet {
        if rightViewImage != nil {
            rightAccessoryButton.tintColor = rightViewTintColor
        }
        
        if rightViewText != nil {
            rightAccessoryButton.setTitleColor(rightViewTintColor, for: .normal)
        }
    }
}

private func commonInit() {
    rightView = rightAccessoryButton
    rightViewMode = .never
}

Setting the rightViewMode will notify the text field when the right view overlay should appear. We also need to update the insetTextRect(forBounds:) with the additional right view padding and width of the right view:

Swift

private func insetTextRect(forBounds bounds: CGRect) -> CGRect {
    var insetBounds = bounds.insetBy(dx: centerInset.x, dy: centerInset.y)
    insetBounds.size.width -= rightViewPadding + rightAccessoryButton.bounds.width
    return insetBounds
}

Configuring the customized text field

Applications typically use a standardized design pattern (such as MVP or MVVM), which mostly derive from conforming to the separation of concerns principle. How do we handle text field customization and responding to user initiated actions while separating logic?

The core of this subclass contains several properties. It looks like we can make use of a view model as the main source of configuration for the text field. So far we have the center inset and padding properties but we could benefit from adding a right view object along with the text field properties:

Swift

/// The view model containing information necessary for configuring the display of the view. 
struct ViewModel { 
  /// The properties that can be applied to the right view. 
  struct RightView { 
    /// The optional image for the right view. 
    var image: UIImage? 
    /// The optional text for the right view. 
    var text: String? 
    /// The tint color of the text and image. 
    let tintColor: UIColor? 
    /// The padding between the accessory text and edge of the text field. 
    let padding: CGFloat } 
  /// The text. 
  var text: String? 
  /// The color of the text. 
  let textColor: UIColor? 
  /// The placeholder text. 
  let placeholder: String? 
  /// Sets the center inset of the text field. 
  let centerInset: CGPoint 
  /// The optional `RightView` to display on the `rightView` of a `UITextField`. 
  var rightView: RightView? }

This is also a perfect use case for taking advantage of Apple‘s Combine framework. Pre-Combine, the text field responses could have been handled with closures or delegates. UIKit does not provide Combine support by default, so to simplify some of the following logic we‘ll use a 3rd party framework, CombineCocoa, for the UIKit publishers we need.

Installing CombineCocoa with Swift Package Manager

Adding a dependency via Apple‘s built in Swift Package Manager is quite easy. In Xcode, simply select File → Swift Packages → Add Package Dependency. There, you will be prompted to enter a package repository url where you can add the CombineCocoa GitHub url. Selecting next will default to the latest release tag from the repository. After confirming the package options you should now see the dependency added in the project navigator:

Adding Combine publishers

We did a lot of customization with the text field subclass we created. Let‘s address event handling and responses to the right view button.

Since CombineCocoa is a wrapper around UIKit, there are built in publishers we can use. We‘ll focus on textPublisher for text changes in the the text field and controlEventPublisher(for:) for control events from the button.

These publishers can be added at initialization:

Swift

private var cancellables = Set<AnyCancellable>() 
private func commonInit() { 
  rightView = rightAccessoryButton 
  rightViewMode = .never 
  
  rightAccessoryButton.controlEventPublisher(for: .primaryActionTriggered) 
  .sink { 
         self.rightAccessoryButton.isSelected.toggle() 
  } 
  .store(in: &cancellables) 
  
  textPublisher 
  .sink { text in 
         self.viewModel?.text = text 
        } 
  .store(in: &cancellables) 
}

Since the publishers are exclusive to private properties we‘ll need another one for accessing the selected state of the button. CombineCocoa’s ControlProperty property publisher offers a very useful solution for this. We could initialize this generic publisher with a specific control event and key path:

Swift

/// Called when the right accessory's enabled value has changed. 
var rightAccessoryButtonEnabled: AnyPublisher<Bool, Never> {
                                                            Publishers.ControlProperty(control: rightAccessoryButton, events: .primaryActionTriggered, keyPath: \.isSelected) 
  .eraseToAnyPublisher() 
}

Now that we‘ve included the rightAccessoryButton‘s publisher we need to subscribe to the values it emits. In the DemoViewController this can be set up at viewDidLoad():

Swift

override func viewDidLoad() { 
  super.viewDidLoad() 
  
  customTextField.rightAccessoryButtonEnabled.sink { [weak self] isSelected in 
    guard let self = self else { 
      return 
    } 
    self.customTextField.viewModel?.rightView?.image = isSelected ? .unlocked : .locked
    self.customTextField.isSecureTextEntry = !isSelected 
} 
  .store(in: &cancellables) 
}

Adding @IBInspectable

After all these additions to customize the UITextField subclass there is another option to extend these properties to Interface Builder. To better visualize this in Interface Builder, let‘s mark the properties as @IBInspectable. This will allow us to edit those properties in the attributes inspector in Interface Builder. In code, that looks like this:

Swift

/// Sets the center inset of the text field..
@IBInspectable private var centerInset: CGPoint = .zero {
    didSet {
        setNeedsLayout()
    }
}

/// Sets padding for the `rightView` from the text field's edge.
@IBInspectable private var rightViewPadding: CGFloat = 0 {
    didSet {
        setNeedsLayout()
    }
}

/// Sets an image for the `rightView`.
@IBInspectable private var rightViewImage: UIImage? {
    didSet {
        rightAccessoryButton.setImage(rightViewImage, for: .normal)
        rightViewMode = rightViewImage != nil || rightViewText != nil ? .always : .never
    }
}

/// Sets text for the `rightView`.
@IBInspectable private var rightViewText: String? {
    didSet {
        rightAccessoryButton.setTitle(rightViewText, for: .normal)
        rightAccessoryButton.setTitleColor(rightViewTintColor, for: .normal)
        
        rightViewMode = rightViewText != nil || rightViewImage != nil ? .always : .never
    }
}

/// Sets tintColor for the `rightView`.
@IBInspectable private var rightViewTintColor: UIColor? {
    didSet {
        if rightViewImage != nil {
            rightAccessoryButton.tintColor = rightViewTintColor
        }
        
        if rightViewText != nil {
            rightAccessoryButton.setTitleColor(rightViewTintColor, for: .normal)
        }
    }
}

And in Interface Builder, it should look like this:

Since we have all the inspectables set up in Interface Builder, we can go a step further and have those values set up as the default view model, and then take a look at what the project‘s Interface Builder generates from the inspectables:

Swift

override func awakeFromNib() {
    super.awakeFromNib()
    viewModel = ViewModel(text: text, textColor: textColor, placeholder: placeholder, centerInset: centerInset, rightView: .init(image: rightViewImage, text: rightViewText, tintColor: rightViewTintColor, padding: rightViewPadding))
}

Results in Interface Builder

Running the project without having modified the view controller will reveal that the properties have been set directly from the Interface Builder:

Summary

Being able to set up inspectable properties directly in Interface Builder allows for more flexibility and clarity when composing reusable views. The source of truth in the view model also allows us to set default properties. In this post, we learned how simple it is to set up a chain of Combine publishers. We also leveraged an older feature like IBInspectable and paired it with a newer technology like Combine. We hope this provides useful insight on how to implement these reactive changes in your existing apps.

The Atlantic App—A Mobile Revival

Team Lickability — Thu, 18 Feb 2021 00:00:00 GMT

Everyone knows The Atlantic

It’s an American magazine & institution, founded in 1857 in Boston, Massachusetts. It started as The Atlantic Monthly, a scholarly & cultural magazine of leading writers.

Thinkers like Ralph Waldo Emerson, Emily Dickinson, and Henry Wadsworth Longfellow—all expressing cultural commentaries on topics like the abolition of slavery, education and other major political issues of the day.

Fast forward to today…

The Atlantic still publishes opinions at theatlantic.com. And, of course, daily coverage & analysis of breaking news, politics, education, technology, health, science, and culture.

But here’s the thing…

They had an iOS app—in need of a facelift

Like so many companies, The Atlantic had a mobile app in 2017. Billions of people in the world were using their smartphones everyday. So readers expected to stay informed—no matter where they’re at. The gym, The Village, while driving (uh-oh).

However, the Atlantic app had some issues.

Users had a tough time logging in. Saved articles vanished—poof. It lacked some key features. Not enough downloads. Too many poor reviews. And support requests piling up.

The UI looked squished on modern devices. This mobile design reflected poorly on the Atlantic’s prestigious brand.

So why not just fix all that?

Whoever developed it could certainly make everything right, right? Well…

The Atlantic hired a vendor to write their initial app. After a couple product iterations, that relationship deteriorated. And they didn’t have the in-house expertise to perform updates themselves.

Plus, the app was written in Objective-C, a rapidly aging programming language. Even worse, The Atlantic didn’t own the source code. So the app became neglected. And lonely. With no tech-TLC to speak of.

So sad.

The Atlantic reached out to Lickability

The Atlantic knew of us from our work & success with The New Yorker Today app. So The Atlantic talked with, learned from, then hired us to solve their iOS woes.

First, we developed a plan. We understood The Atlantic’s pains & needs. Created estimates for each feature. It became clear to all—The Atlantic needed a new iOS app to keep up with (and beat) the competition.

Next, we led the way to develop a structured process. We set up weekly meetings, GitHub projects, and a Slack channel for ad-hoc conversations.

Then, two of our developers travelled from NYC to DC to sketch & define the APIs over the next couple days. These APIs became the connective tissue between The Atlantic’s data and the new mobile app.

Lickability was swift to (strongly) suggest Swift

And The Atlantic was quick to listen. Why the Swift programming language to rewrite the app? Because… Swift is easy to write. Runs fast. Crashes less. And, is widely known in the iOS development community.

All this empowered The Atlantic to never be locked in to a vendor to maintain their own app & code.

Other goals achieved:

A vendor with media experience
A native iOS app that rendered beautifully on iPhone and iPad
Showcase their magazine issues, sections, and settings
Smooth process to login, subscribe, and link subscriptions
Allows users to save articles for later reading
Wide accessibility—including for people with dyslexia & users needing large type
Push notifications for new stories & issues, with deep-links into the app
Increase revenue using subscriptions instead of discreet purchases
Be recognized as a great app by getting great reviews
A partner they could trust to add new features & fix existing problems

While building the app, we worked closely with The Atlantic. We showed & shared progress daily. Implemented continuous integration with BuddyBuild. Worked with the team to perform ongoing QA testing. Staged design reviews and visual QA with the design team. And beta-tested with existing users.

In The Atlantic’s own words, Lickability…

Paid attention to the details. Was very proactive. Incorporated feedback while pushing back as needed. Cared as much as we did. Felt like a true partner.

Lickability delivered on time, offered proactive suggestions for improvement, and took pride in their work.
Betsy Cole, Executive Director, The Atlantic

By the numbers

App Store reviews average 4.7 stars with 1.5K ratings
#5 in the Magazines & Newspapers Category
#10 in News
#3 in News & Politics Magazines
#1 in Literary Magazines
Featured by Apple as App of the Day

Need a makeover for your app?

Like we did with The Atlantic app? We’re here for you and your business.

Citizen—Improving Their App Building Skills

Team Lickability — Thu, 18 Feb 2021 00:00:00 GMT

Citizen is on a mission

It’s to make the world a safer place for everyone.

Citizen believes stronger communities are safer communities. Where people can access information quickly, share effortlessly, and connect easily. Where people can watch out for each other.

How? With a smartphone app that brings public information to everyone’s attention—in real time.

So people can protect a neighbor, prevent a tragedy, and count on one another. To create a safer world for each other, with each other.

Not much to not like about that.

They had an app, loads of downloads, loads of users

All good stuff, right? Not so fast. With all that, growing pains show up, too.

As their user base grew, so did their engineering team. But Citizen was relatively new to the NYC tech scene. They didn’t have an established network to recruit senior candidates from.

They did a great job bringing in developers, but needed a Senior iOS engineer to lead the way.

Otherwise, processes and practices would break down as the organization scaled. They had millions of users—and wanted millions more.

They struggled with code reviews. Too many bugs got stuck instead of squashed. Features piled up for the dev team. They launched too few features in each release. The code base was in danger of becoming spaghetti-like. And, they lacked the experience to make the most of in-app purchases.

Citizen needed a pro to help streamline their engineering processes. They looked and looked for their hero for several months. As mentioned, it’s harder (and costs more) to hire senior talent.

They found Lickability

“Why look any longer?” “Why pay so much?” “Why not learn from the best?” Okay, maybe we got a little excited about that last one. But these were the thoughts of the leadership at Citizen.

We worked with Citizen to understand their pains, their needs, and their vision. Together we determined they could use a nudge to keep up with the pace of their users’ excitement, too.

More features released faster. More bugs fixed sooner. More people working better together. With a leader to augment their existing pool of quality talent.

Say hey to Andrew—Partner at Lickability

We build apps all day, every day. We’ve seen and solved these same problems, over and over. Part of our business is to help others do the same for their business and apps.

It made sense for Citizen to work with Andrew. Why?

He had the biz and tech experience for leading and advising. Required little time to ramp up and fit right in. Had the mindset to lead by example, not by authority. And…Citizen could save big $$$ over the long term by contracting vs. hiring.

Then, after 11 months, they could remove this charge from the books, while keeping the lessons learned—forever.

Eleven months later—from ‘arg’ to ‘ahhh’

Developing software is hard…and expensive. It. Just. Is. Even more so when your business can’t keep up with all the features your users want (and are willing to pay for).

We helped Citizen by sharing and showing a set of repeatable processes to carry on their already great work:

Refined their engineering practices by learning from the outside
Enhanced their expertise to build features more quickly
Unclogged their pipeline to ship more features per week
Improved processes to capture, fix, and release bugs quicker
Built rapport with the team by balancing on-site vs. remote work
Showed slick ways for design to hand off assets to engineering
Set up continuous integration to test new features on all company phones
Documented how to sustain their new improvements

Check out a few of the features we helped deliver:

Emoji Reaction Palette with beautiful animations
Magic Moments to creatively show and highlight top news items
Re-wrote Follow Locations feature to know what’s going on nearby
UI and backend to accept payments for subscriptions
Citywide Incidents for users to be briefed on events—instantly
News tab—the first things users see for their city
Share an Incident to keep others safe from fires, gunmen, and arriving aliens

Andrew rode off into the tech-sunset…

Feeling good about leaving Citizen in better shape. With new ways to… review code. Squash bugs. Plan, build, and release code. Hire better. Ship faster. And integrate processes and people to live more peacefully at work. And more prosperously in their business.

In Citizen’s own words, Lickability…

“We’re super pumped about Andrew's work and our success. We became more focused and efficient. So much so, we were able to develop these iOS features in an Android app. Thanks, Andrew, for your patience, attention, experience and skills to help us be better and go faster.”
Wiktor Macura ∙ Head of Engineering at Citizen

By the numbers

130K app reviews

4.8 stars average rating

#4 Overall

#1 in News

2+ billion alerts

5+ million users

20 cities & counties

Want to build up your in-house, mobile dev skills?

Like we did with Citizen? Got an app? Got a team? We can help.

Dynamic Type & In-App Font Scaling

Daisy Ramos — Thu, 11 Feb 2021 00:00:00 GMT

The Dynamic Type feature allows users to choose the size of textual content displayed on the screen. It helps users who need larger text for better readability. It also accommodates those who can read smaller text, allowing more information to appear on the screen. Apps that support Dynamic Type also provide a more consistent reading experience.
Apple's Developer Documentation

Since iOS 7, Apple has provided users with the ability to adjust the size of displayed content in your apps. Most content-driven apps support this feature seamlessly. This provides great support for every reader, but what if you want to provide extended scaling? What occurs behind the scenes, and what caveats (if any) are presented? You’re probably here because you need to support Dynamic Type or possibly build your own font scaling system, and we can help you.

First, let‘s take a look at the weight, size, and leading values for each text style in the default content category size (Large). The text style will determine the scale factor needed to support Dynamic Type.

Weight, size, and leading values for each text style at the default Dynamic Type size from Apple’s Human Interface Guidelines on Typography

Next, let‘s take a look at the Dynamic Type settings in iOS Settings, which can be found either under Accessibility or Display & Brightness. The “Larger Text” setting below is in Accessibility → Display & Text Size → Larger Text.

Setting up Dynamic Type

Luckily, in order to support Dynamic Type with system fonts, all we need are a few lines:

Swift

let textLabel = UILabel()
textLabel.font = .preferredFont(forTextStyle: .headline)
textLabel.adjustsFontForContentSizeCategory = true

There‘s also an option to set the “automatically adjusts font” flag in Interface Builder.

In Interface Builder, the Dynamic Type option to automatically adjust fonts applies only to text styles or scaled fonts returned by UIFontMetrics. It has no effect on custom fonts set in Interface Builder.
Apple's Developer Documentation

Notice how we didn’t set a custom font on the label but instead relied on the system font. There isn‘t much that is required to support the built-in system scaling.

As we saw above in the default content category size, the text styles are scaled at different sizes. In some cases you may want to provide font sizes that aren‘t listed. How can we support Dynamic Type if we want to use a custom font and size in our app?

Custom Font Scaling with `UIFontMetrics`

So, how can we guarantee our font size will be met with the Dynamic Type requirements? In order to observe changes, we will need to subscribe to UIContentSizeCategory.didChangeNotification.

This sounds simple enough, but what if we have multiple screens to observe? It doesn’t seem very optimal to register for the same notification on each view controller. If your app is primarily navigation controller-based, a way around this would be to subclass UINavigationController. We would simply iterate through the array of child view controllers (and their children) to set the preferredContentSizeCategory and override the trait collection to scale our custom font. Our notification to observe dynamic font size changes would look like this:

Swift

NotificationCenter.default.addObserver(self, selector: #selector(overrideChildrenContentSizeCategories), name: UIContentSizeCategory.didChangeNotification, object: nil)

The key here is to override the view controller‘s trait collection with the correct UIContentSizeCategory whether it‘s user selected or the current preferredContentSizeCategory. That looks something like this:

Swift

// Overrides the font cateogry to be used.
override func addChild(_ childController: UIViewController) {
    super.addChild(childController)
    
    overrideContentSizeCategory(childController)
}

func overrideContentSizeCategory(_ child: UIViewController) {
        
   // Local storage
   let preferences = Preferences()
        
   let contentSizeCategory: UIContentSizeCategory
        
   // Whether to use the user-selected content size category or the system one.
   if preferences.shouldUseUserSelectedContentSizeCategory, let userSelectedContentSizeCategory = preferences.userSelectedContentSizeCategory {
       contentSizeCategory = userSelectedContentSizeCategory
   } else {
       contentSizeCategory = UITraitCollection.current.preferredContentSizeCategory
   }
        
   // The setting to scale the font.
   let traitCollection = UITraitCollection(preferredContentSizeCategory: contentSizeCategory)
   setOverrideTraitCollection(traitCollection, forChild: child)
}

All that‘s left is to apply the font as a type of UIFontMetrics.

If you use a custom font in your app and want to let the user control the text size, you must create a scaled instance of the font in your source code. Call `scaledFont(for:)`, passing in a reference to the custom font that's at a point size suitable for use with `large`. This is the default value for the Dynamic Type setting. You can use this call on the default font metrics, or you can specify a text style, such as `headline`.
Apple's Developer Documentation

Applying this to our label above would look like this:

Swift

if let customFont = UIFont(name: "Roboto-Italic", size: 17) {
    textLabel?.font = UIFontMetrics(forTextStyle: .headline).scaledFont(for: customFont)
}

Let‘s see what this looks like for a standard UILabel.

This is all that‘s needed to scale custom fonts with Dynamic Type. Sometimes in content-driven apps there is a need for web technologies for complex layouts / styles. Let’s see if we can support Dynamic Type and web-driven content via WKWebView.

Dynamic Type and `WKWebView`

Sometimes apps need to display HTML content in a WKWebView. What do we need to do to make sure the typography in the web content can scale with Dynamic Type? Let‘s add an HTML and CSS stylesheet snippet like this:

HTML

<html>
    <head>
        <meta charset="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" />
        <link rel="stylesheet" href="stylesheet.css">
    </head>
    <h4> Hi, we’re Lickability: a software studio in NYC that builds apps for clients like Jet, The Atlantic, Meetup, and more.</h4>
    <body>
    <p>We combine expert engineering with a touch of magic. The result? Beautiful, high-quality apps our clients (and their customers) love. ❤️</p>
    </body>
</html>

CSS

@font-face {
    font-family: 'RobotoMono';
    src: url('RobotoMono-Regular.ttf');
    font-style: normal;
    font-weight: normal;
}

html {
    font-family: 'RobotoMono';
}

Unfortunately, this doesn‘t work unless you specify an Apple system font like -apple-system-body. But we want the web view styled with the one in the HTML file. If we take what we learned above and apply that to our HTML styling it should look something like this:

Swift

func reloadWebView() {

    // Setting a placeholder font since the font is loaded through CSS. The font now relies on the system to scale our custom font after calling `scaledFont`.
    let scaledFont = UIFontMetrics(forTextStyle: .body).scaledFont(for: .preferredFont(forTextStyle: .body), compatibleWith: traitCollection)

    guard let localHTMLURL = Bundle.main.url(forResource: "example", withExtension: "html"),
         let htmlString = try? String(contentsOf: localHTMLURL) else {
         return
    }
            
    // A quick way to style html without modifying the css stylesheet.
    loadHTML(withFont: scaledFont, htmlString: htmlString)
}

private func loadHTML(withFont font: UIFont, htmlString: String) {
        
    let fontSetting = "<span style=\"font-size: \(font.pointSize)\"</span>"
    webView.loadHTMLString(fontSetting + htmlString, baseURL: Bundle.main.bundleURL)
}

Since we‘re using a web view we need to override traitCollectionDidChange(_:) since the UIContentSizeCategory has changed and call reloadWebView() there.

Swift

override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
   super.traitCollectionDidChange(previousTraitCollection)
   reloadWebView()
}

We’ll see this example in action in the next section when we learn about environment overrides.

Environment Overrides

Luckily we can debug this without leaving the simulator. You can find that in Xcode via the Debug → View Debugging → Configure Environment Overrides. There you will see a switch to toggle text and a Dynamic Type slider to adjust the font. This is what that looks like when running the example app.

Conclusion

We observed how Dynamic Type works for native and web-based UI components. We also learned how UIFontMetrics offloads some of the work needed to scale custom fonts. Maybe one day we‘ll see built-in custom font support for web views, but for now, UIFontMetrics is a viable solution for font scaling.

Aloe Bud—A Gentler, Kinder App

Team Lickability — Thu, 28 Jan 2021 00:00:00 GMT

Say hey to Serenity Discko

Photo by Heather Sten from Wired.

Serenity (they/them) has been a social media professional for years. As an employee, a consultant, and now… as an entrepreneur. Back in 2016, they also did social media and voter registration work for Hillary Clinton.

That’s when everything changed.

In their own words, “While working on the campaign, time management took a back-seat to work, and things like remembering to brush my teeth or drink water became really difficult.” Life got tough. Leaving the house, staying hydrated, even eating a full meal felt like a battle. “My emotional and physical wellness hit an all-time-low,” they said.

They knew others felt the same—with their own struggles, just getting through the day.

So they got to work.

Serenity needed a better self-care app

Sure, mediation apps like Headspace and Calm were gaining buzz in this space in 2017. But these apps, and other popular options, required expensive subscriptions and were too medically focused. That whole clinical vibe was impersonal and b-o-r-i-n-g.

There were other health-reminder apps but they sounded like mean, nagging robots. Who needs to be beaten down for reminders to brush your teeth? To breathe? Or to check in with a loved one?

Nope, Serenity wanted an app that was free to use. And personable. Something that nurtured support for people struggling with mental health challenges.

But it cost big $$$ to build an app

And they surely didn’t want to rely on the build-it-and-they-will-come approach. That’s fantasy. Plus, where would they get the money?

First off, Serenity created a Twitter bot as an MVP approach—to gain and gauge interest. People liked the idea and responded in droves. Clearly, lots of folks wanted self-care reminders that lived on their phones.

So then, maybe it was time to kick off a Kickstarter campaign? Hmmm, but how much money should they raise? And then what do they do with it? They had no experience building apps. Ah, but wait…

Serenity contacted their friends at Lickability

We had worked together years back at Tumblr. Serenity came to us with excitement…and questions.

How much will it cost to build an app? How long will it take? How will they generate revenue?

We answered all that—because we’re product experts, too.

Voilà—a successful $50K Kickstarter campaign to build a new app. And the name Aloe Bud was born—Aloe for its medicinal properties, and Bud to express something on its way to full bloom. And, of course, an app that will be your bud.

This app would encourage users to stay on top of their daily routines—gently. Whether reminding them to shower. To meditate. Or take their medication.

So we went for it!

First, we developed a plan. We met with Serenity to understand their vision. White-boarded & brainstormed features. Suggested a buy-once-keep-forever model for in-app purchases. Found and hired a designer. Then created estimates and timelines to bring everything into view.

Next, we helped raise money. Determined realistic deliverables for the Kickstarter campaign. And, promoted it using our own social media channels.

We then developed a structured process. Set up weekly meetings, GitHub projects, and Slack channels for ad-hoc conversation. And led in-person training to help Serenity create and publish new content.

Next up—build the app. We kept Serenity informed by showing and sharing progress regularly in design reviews. Set up continuous integration using BuddyBuild. Helped them perform QA testing on every build.

All of the above created a robust environment to test and revise the app. Not only did Serenity perform QA, so did the Kickstarter backers. We involved them. Incorporated their feedback. They became Aloe Bud’s beta testers… and new buddies. Cool, huh?

Aloe Bud came to life

Serenity had some personal struggles in life. They were not alone. But their love and vision put an app into the world—one that was missing. One that offered:

A kind, self-care, iOS app to make people feel good, not guilty or shameful
Gentle, freemium reminders to build healthy habits
Premium reminders they could buy and/or create themselves
Journaling to help users capture their thoughts and feelings
Illustrations and animations to bring the app to life
An app within their Kickstarter budget of $40K (though they raised $50K)

We wrote Aloe Bud using the Swift programming language. Why Swift? Because… Swift is easy to write. Runs fast. Crashes less. And, is widely known in the iOS development community. This empowers Serenity to be in control of the code and not be bound to any single vendor.

In Serenity’s own words…

“I was mentally sick while building Aloe Bud. Yet, I received tremendous support from the Internet and from the Lickability team. I highly recommend Lickability for all iOS projects. They built Aloe Bud with me—it was a great experience.”
Serenity Discko ∙ Founder of Aloe Bud

By the numbers

2.2K app reviews
4.8 stars average rating
#8 in Health & Fitness
App of the Day on the App Store
Over 1.2M unique users
9.1M reminders created
7.8M tasks completed
Lots of good press, too—including in Wired Magazine

Need some TLC for your app?

Like we did with Aloe Bud? That’s what we’re here for. Let’s talk.

Banks Suck

Brian Capps — Wed, 02 Dec 2020 00:00:00 GMT

Banks suck. The financial industry is full of hidden and predatory fees, outdated software, and horrific customer support. From defrauding customers with millions of fake accounts to facilitating crimes against humanity across the globe, the banking industry in particular is an irredeemable blight on this planet that will find every way to extract the most money possible from you and your business, often illegally or unethically. When it came time for our small business to switch banks, being clear-eyed about the state of this industry made for a daunting but ultimately fruitful search for a place to keep our hard-won earnings. Here‘s why and how we did it.

Local Man Ruins Everything

Many years ago, when we were young and naive, we decided to open a small business bank account with Citibank since they had a close local branch and solid online reviews. This decision turned into years of pain, frustration, and fees. As our business grew, so did our frustration—but so too did the cost of switching to another institution. Other banks had similar fees and services, comparable ethical entanglements, and software that was nearly as bad. However, the issues with Citibank kept mounting.

Citibank‘s website is unreliable and at times unusable for basic operations; their data doesn’t play nice with our bookkeeping software, Xero; and their customer support often creates more problems than it solves. And on top of all that, just as small businesses desperately needed their help the most during a global pandemic and recession, they decided to streamline PPP loan applications only for their largest businesses so that they could collect the most fees before they opened a single application for any other business. After this, we knew there was no way we could remain at Citibank—and so it was time to switch, no matter how much effort it would take.

Gathering Information

There are over 4,500 banks in the United States, and likely tens of thousands of different accounts to choose from. In order to compare a variety of banks and account types but also to limit the scope of the search, we compiled a list of 42 bank accounts based on several sources: lists of the top business bank accounts, recommendations from our peers, recommendations from our accountant and bookkeepers, and every Xero Banking Partner that would integrate well with our bookkeeping software. Once we had a list of accounts, we went to work gathering all the data we could possibly need for comparisons.

After the Truth in Savings Act was passed and enforcement was transferred to the Consumer Financial Protection Bureau, banks now need to disclose every fee for an account in what‘s called a schedule of fees. Using these publicly-available schedules of fees and information on the web, we devised shared categories we could use to compare each of our potential new banks, such as the type of account, monthly fees, interest, wire fees, and many more. Coming to a comprehensive total of 30 data points for each account, we needed a way to log, compare, and analyze this data, and as any self-respecting nerd knows: there‘s no better tool for this kind of structured information than a spreadsheet.

Criteria

To avoid bias toward any particular account, we decided to set the criteria for qualifying as a “finalist” before entering even a single piece of data into our spreadsheet, and used pivot tables to filter the relevant accounts in real time as they were entered. Here‘s the relatively lenient criteria that we decided was important to our business:

🤝 Xero Integration

Xero compatibility was a huge priority for us, as it could affect how much time is spent on bookkeeping and the quality of entries that we use to analyze all of our financial data.

🔐 FDIC Insurance

If anything happened to the financial institution, we wanted our funds to be insured by the federal government, up to federal limits. These accounts are safe bets that in almost all cases do not lose value.

💸 PPP

This was a really simple standard: if the bank prioritized large clients over smaller ones with PPP applications, that was not a bank we wanted to do business with. Any bank that would use funds meant to help small businesses to instead enrich themselves on large business fees is simply not a safe place to park your cash reserves as a small business.

📱 iOS App

This was the most minor of all the criteria, but since we‘re a mobile-focused company that specializes in making great iOS apps, we wanted to work with a company with at least a decent app. This can also sometimes be a proxy for software quality across the board, as lack of investment in mobile can be an indicator of sub-standard software elsewhere.

Once it was all said and done, we ended up with a massive spreadsheet with 1,260 individual entries. We then set up statistics for the entries showing the types of accounts (mostly checking), two-factor authentication (mostly SMS), insurance type (almost all FDIC), and more, with a few pie charts to illustrate the breakdown. Finally, we rounded up the finalists based on the criteria above, to some surprising results.

Finalists

Even with very simple criteria for entry, our list of bank account finalists ended up being quite exclusive: only six met the threshold to become finalists. Of those, we cut half for lack of features, nonexistent two-factor authentication, and lack of adoption. We signed up for the remaining accounts and went to work evaluating them. Here are the three that made the cut:

🏦 Azlo

Azlo was the bank we saw appear most on “best small business bank account” lists across the internet. They had almost no fees, mentioned a Xero integration, and had friendly branding.

🏦 Brex

Brex is a popular credit card company for startups, but their relatively new Cash account was also interesting to us. It also had almost no fees, the interface seemed pleasant, and their account was a “cash management account,” where a portion could be in a checking account and a portion could be invested to potentially make a greater return. We also liked that they supported accounts with custom access for bookkeepers.

🏦 Mercury

Mercury is a startup-focused bank account that came highly recommended by our accountant. They had the lowest fees of all, a beautiful interface, and were a Xero Partner. They supported customized access accounts for bookkeepers and other types of users, and when signing up you receive both a checking and savings account.

Winner

After getting a chance to use all of the above for a few weeks, the choice became clear: the bank account for us was Mercury. Azlo‘s website and app were clunky and difficult to use (they’ve since done a full redesign); Brex‘s Cash account features were a bit too limited for our use case; and Mercury was easy to use, sent much more frequent and higher quality data to Xero, had powerful debit card controls, and had the best iOS banking app I’ve ever used.

If you‘re doing a similar comparison, or just want to check our work and look at some of the statistics, we’re publicly releasing the spreadsheet that we used to compare banks. The data is accurate as of mid-2020, so may already be out of date in some cases. If you think it would be useful to you, feel free to duplicate and use it for your own comparison! Just remember this fact that we had to learn the hard way: banks suck. But at least your small business bank account doesn‘t have to.

Swift on Raspberry Pi Workshop: Part 3

Marc Aupont — Fri, 20 Nov 2020 00:00:00 GMT

This is the third and final post in our three-part series about setting up a Raspberry Pi to build a distance measurement system for an autonomous car. In Part 1 of this series, we set up a basic circuit to control LEDs via the Raspberry Pi; and in Part 2, we started controlling those LEDs using Swift. If you‘re coming to this post first, I recommend checking out those posts first.

In this post, we‘re going to get started by adding a speaker to our circuit to make a sound.

Adding a speaker to our circuit

If you examine the picture below, you‘ll see an example circuit with the speaker connected. This circuit also has a few extra LEDs that we’ll use in our final circuit. For now, let‘s focus on connecting the speaker. For this, I’ll use ports 9A and 10A on the breadboard. You can use whichever ports you like. I‘m also going to use GPIO 17 (pin #11) on my Raspberry Pi to supply the voltage. For the ground connection, I’ll tap into my ground rail on the breadboard.

In Part 1, we used pin #9 from our Raspberry Pi to supply a ground connection to our breadboard. In order to use this ground, I‘ll use a jumper wire to go from the ground rail to port 9A. Then, I’ll connect a wire from GPIO 17 (pin #11) of my Raspberry Pi to port 10A of my breadboard. These connections are all we need to supply power to any port on row 10 A–E, as well as ground to any port on row 9 A–E. The final step is to place your speaker on any port in rows 9 and 10 A–E.

Controlling the speaker with Swift

Luckily for us, our speaker is a simple polarized component just like our LED. This means that it has a positive and negative side. In order to emit a sound, we just need to supply voltage to the positive side while grounding the negative side. The speaker will then make a sound as long as voltage is supplied. To make the sound stop, we just cut off the voltage or set it to low (0).

If you recall how we controlled our LED in the previous section, we will control our speaker in a similar fashion. Let‘s evaluate the code example below.

speakerLed.swift


import SwiftyGPIO

// SwiftyGPIO configuration
// 1
let gpio = SwiftyGPIO.GPIOs(for: .RaspberryPi3)

//2
guard let led = gpio[.P2] else {
    fatalError("Could not initialize led.")
}

//3
guard let speaker = gpio[.P17] else {
    fatalError("Could not initialize speaker.")
}

//4
led.direction = .OUT

//5
speaker.direction = .OUT

//6
led.value = 1

//7
speaker.value = 1

Sets up our GPIO pins to be used.
A reference to the LED controlled by GPIO 2.
A reference to the speaker controlled by GPIO 17.
Here we set the direction of the port. In this case, we are saying that the direction of GPIO 2 should be .OUT as in output. This means we want to output a signal/voltage from this pin.
Sets the direction of GPIO 17 to be an .OUT as well.
This sets the value of GPIO 2, which references our LED, to 1 or High. In layman‘s terms, this turns on the LED.
This sets the value of GPIO 17, which references our speaker, to 1 or High. This emits a sound from the speaker.

If you build and execute this code on your Raspberry Pi, you should hear a sound coming from your speaker, and your LED should be lit.

Introducing the HC-SR04 Ultrasonic Sensor

Now that we know how to control a speaker and LED, we can leverage that knowledge to tie them into the final component of our system. This is by far the most complicated part—up to this point, we have been working with simple 2-pronged polarized components, but the HC-SRO4 has 4 prongs:

VCC – This is our voltage pin. Here we supply the sensor with 5 volts. This is slightly more voltage than our LED and speaker require.
Trig – This is our trigger pin. We use this pin to broadcast a sound wave.
Echo – This is our echo pin. We use this pin to listen for the reply of the sound wave we broadcasted earlier.
Gnd – This is our ground pin.

To measure distance, we are going to emit a sound, wait for a response, and measure the time it takes to get that response. This will allow us to know how far an object is from us. Writing the logic for this in Swift can be a bit tricky, so we are going to leverage the help of a package called HCSR04.swift.

If you have been following along with me, your project navigator should look like the image below:

With that code in place, we can now add some logic to our main.swift file and incorporate our HC-SR04 sensor. I‘ve also added a few extra LEDs to my circuit so that we can have our full monitoring system. See the code below:

speakerLedHCSR04.swift

import SwiftyGPIO
import Foundation

// SwiftyGPIO configuration
// 1
let gpio = SwiftyGPIO.GPIOs(for: .RaspberryPi3)

//2
guard let redLED = gpio[.P2] else {
    fatalError("Could not initialize red led.")
}

guard let yellowLED = gpio[.P3] else {
    fatalError("Could not initialize yellow led.")
}

guard let greenLED = gpio[.P4] else {
    fatalError("Could not initialize green led.")
}

guard let speaker = gpio[.P17] else {
    fatalError("Could not initialize speaker.")
}

//3
redLED.direction = .OUT
yellowLED.direction = .OUT
greenLED.direction = .OUT
speaker.direction = .OUT

//4
redLED.value = 0
yellowLED.value = 0
greenLED.value = 0
speaker.value = 0

//5
let sensor = HCSR04(usedRaspberry: .RaspberryPi3, echoConnectedPin: .P22, triggerConnectedPin: .P27, maximumSensorRange: 400)

//6
while true {
    do {
        let distance = try sensor.measureDistance()
        print("The distance is: \(distance)")
        switch distance {
        case 0..<5:
            print("Red zone")
            redLED.value = 1
            speaker.value = 1
            yellowLED.value = 0
            greenLED.value = 0
        case 5..<10:
            print("Yellow zone")
            redLED.value = 0
            speaker.value = 0
            yellowLED.value = 1
            greenLED.value = 0
            
        default:
            print("Green zone")
            redLED.value = 0
            speaker.value = 0
            yellowLED.value = 0
            greenLED.value = 1
        }
        Thread.sleep(forTimeInterval: 0.6)
    } catch {
        print("There was an error: \(error.localizedDescription)")
    }
}

Let‘s go through what the code is doing:

In this step, we are initializing our GPIO pins.
Here we are creating references to the various pins that correspond to our LEDs. These pin assignments directly reflect the cables that connect back to my Raspberry Pi as well as the connections on the breadboard.
Here we set the direction of our ports. In this case, all of our LEDs are functioning as outputs because they are transforming voltage being supplied to them versus providing some sort of input voltage back to our Raspberry Pi.
In this code block we ensure that every component starts in the off position. This ensures that our LEDs and speaker all start in the same state regardless of the state they were left in when the program last exited.
This line sets up our HC-SRO4 sensor. This is possible because of the code that we copied in from the library. The pins specified are specifically based on the ports that my sensor is plugged into.
1. Note: The maximum sensor range value is an arbitrary value that I chose based on the ranging distance listed on the box of the sensor. The maximum range is 500cm, but I decided to use 400cm to limit any chances of error.
This is where all of the distance measurement happens. We first create an infinite while loop so that our sensor is continuously monitoring as long as the program is running. Our sensor has a method called measureDistance() that returns a Double in centimeters of the estimated distance. We then use a switch statement over that distance returned to determine what we want to do:
1. If the distance range is between 0cm and 4.9cm, we consider this our “Red zone”. If we are in this zone, we want to turn on the red LED as well as the speaker.
2. If the distance range is between 5cm and 9.9cm, we consider this our “Yellow zone” and turn on the yellow LED.
3. If the distance range is anything else, we consider this our green zone and turn on the green LED.

In order to ensure that the sensor has time to process the measurements, we sleep the thread or pause for 0.6 seconds in between each measurement. With all of that in place, you now have a fully function distance measurement system written in Swift!

Summary

In this series, we learned how to work with a breadboard, resistors, LEDs, HCSR04 sensor, buzzer and a Raspberry Pi to create a system that can measure differences. Our first step was to build a basic circuit that we could control with no Swift involvement, allowing us to verify that our connections are good and that we‘re not making a mistake in Xcode or in the transfer of our code. In Part 2, we introduced Xport and started writing Swift code to actually drive the logic on our board. Finally, we added a HCSR04 sensor to the equation so that we could measure distances and interact with the speaker and LEDs. Remember, most components require a (0) or a (1) to turn them off or on. With that knowledge, you can write some interesting logic that can interact with hardware based on the state of certain sensors.

I had a tremendous amount of fun hosting this workshop, and met so many awesome developers from all over the world. However, the proudest moment for me was being able to have my firstborn son present to see Daddy in his element. The Raspberry Pi is an amazing device for all ages, and after the workshop, my son was anxious for us to build a project together. If your target group is children, you can also use programs like Scratch to control your circuits. I highly recommend visiting the projects page on the official Raspberry Pi website for ideas.

Swift on Raspberry Pi Workshop: Part 2

Marc Aupont — Wed, 18 Nov 2020 00:00:00 GMT

This is the second post in a three-part series about setting up a Raspberry Pi to build a distance measurement system for an autonomous car. In Part 1, we set up a basic circuit to control LEDs via the Raspberry Pi. In this post, we‘ll cover how to create the external build system we need to build and transfer code from a computer to our Raspberry Pi and start writing some Swift.

Using Swift to control the LEDs

We’ve built our circuit and verified that everything is hooked up with the WiringPi library. This is nice, but wouldn’t it be even nicer to use Swift to control our circuit? To do that, we’ll need to first create an external build system, and then create a Swift executable package.

Creating an external build system

The external build system will help us transport and build our Swift package on the Raspberry Pi. In the past, I used Swish to sync my code to the Pi. Being that it is no longer maintained, it doesn‘t work quite right with the new structure of Swift packages. To help with this, I created a similar script using SPM called Xport.

We‘re going to use Xport to perform a rsync between our computer and the Pi—Xport uses SSH to establish a connection with the Pi, which requires us to provide a username and password every time we connect. Because we‘re using Xcode to execute this script, we’ll need to set up passwordless SSH access to create a trusted connection between our computer and the Pi. Here‘s what we need to do:

Step 2

Launch Xcode and create a new project. I‘m going to call mine RemotePiBuild. Be sure not to use any spaces.
For the project template, select Cross-platform and External Build System.
Follow these instructions to set up passwordless SSH access. To ensure that it‘s set up properly, try to SSH into your Pi—if you’re still prompted to enter a password, you may need to store your RSA key to your keychain with this command: ssh-add -K ~/.ssh/id_rsa
Once you‘re able to connect without entering a password, we can move on to creating our swift package and writing our Swift code!

Step 3

Creating the Swift executable package

We‘ve built the external build system that will sync and build our package to our Raspberry Pi, but we don’t have a package yet. That package is the Swift code that will be executed on the Pi to control our circuit.

To get started, we are going to make use of the Swift Package Manager to create our package. With Xcode 12, you can create one from Xcode and manage your dependencies from there. From within your project, go to the Xcode menu and select File, New, Swift Package.

Once you have reached the screen below, give your package a name—I‘m going to call mine LEDControl. At the bottom of the screen, be sure to select your external build system project under the Add to section to ensure that your package is part of the build system project.

At this point, our project is created and we need to install our dependencies. We are going to use SwiftyGPIO to write the Swift code that controls our GPIO pins. Go to your Package.swift file, and add SwiftyGPIO. The result should look like this:

Now, let‘s add the code that is going to turn on our LED. In the Sources\LEDControl directory create a file called main.swift. Add the code in the photo below to the main.swift file:

First, retrieve the list of GPIOs available on the board. In this particular case, I am using the Raspberry Pi 3, but multiple board types are supported.
Once we have the list of GPIOs, we can get a reference to the ones we want to modify. In our case, we are interested in GPIO 2.
The next step is to set the direction of our pin(s). In this scenario, we set the GPIO 2 pin as an output pin so we can emit a 3.3V signal from it. This is how we will power our LED.
The final step is where we set the pin to high or (1). This turns on the LED.

Building the code

Now, we are ready to build and compile our code on the Raspberry Pi. This is where Xport is going to come in. Before we do this, lets complete the configuration of our build tool so that it can communicate with our Pi. Select the RemotePiBuild workspace and then the RemotePiBuild target. This will bring up the External Build Tool Configuration with a few fields to fill out. Here is how we will fill them out.

Build Tool – /usr/local/bin/xport. This is the path where Xport is installed.

Arguments – <username> <hostname>. The username value is the username from your Raspberry Pi. The default is pi. The hostname value is the IP address of your Pi.

Directory – This is the path for your Swift package.

Once you have correctly filled those fields with your information, press CMD + B to build the project and kick off the script responsible for transferring and building our newly created package on the Raspberry Pi. This script will copy over our package to the Xport folder on the Raspberry Pi. At the moment, it doesn‘t actually execute or run the script, so we will need to manually do that from our terminal window.

Go ahead and remote into your Raspberry Pi via the terminal with the command ssh <username>@<hostname>. From here, we‘ll navigate to the directory our project was transferred to. By default, Xport puts the completed project in ~Xport/<ProjectName>/ where ProjectName is the name of your external build system project. In my case, this is ~Xport/RemotePiBuild/. If I were to list all files in this directory via the ls command, I can see my actual Swift package, LEDControl.

Change into that directory with the command cd LEDControl. From this directory, we can type the swift run --skip-build command, which will build our project, download any dependencies, and execute our code. If all works well, your LED should be on!

If you want to turn the LED off, go back to Xcode, change the LED value to 0, and build the project. The build process will transfer our updated files to the Pi where we can repeat the steps above to execute the new code. From this exercise, you can see how to manipulate multiple components just by updating their values from 0 to 1. We will see more of this in the next post, when we work with our speaker and distance sensor.

What‘s next

So far, we‘ve learned how to configure our Raspberry Pi and build a small circuit on a breadboard. In Part 3 of this series, we‘ll integrate a speaker component, as well as the HC-SR04 sensor to measure distances.

Swift on Raspberry Pi Workshop: Part 1

Marc Aupont — Tue, 10 Nov 2020 00:00:00 GMT

The Raspberry Pi is a fun little device that everyone can learn from. From robotics to home automation, you can use it to do just about anything. In September 2019, I hosted a workshop at try! Swift NYC where we used a Raspberry Pi to build a distance measurement system for an autonomous car.

How does this distance measurement system work? Essentially, we will measure the distance between an object and an HC-SR04 sensor. If we are far enough away from the sensor, a green LED will light up; if we get closer, a yellow LED will light up; and if we get too close, a red LED will light up and a speaker will emit a warning sound.

This is the first post in a three-part series about that workshop—today, we’ll cover how to set up a basic circuit that controls LEDs via the Raspberry Pi. Let’s start building our system!

What you‘ll need

To put the full system together, you‘ll need the following parts:

Breadboard – This will act as the circuit board for our system, connecting all of our components so they can interact with one another.
Raspberry Pi – This will be the brain of our system. I used a Raspberry Pi 3 Model B+, but you can certainly use a Pi Zero or any other model.
LED Kit – If you are hosting a workshop, you‘ll need multiple LEDs for each person to use. This kit is what I used in the workshop and it includes 100, 200-ohm resistors to protect the LEDs.
Active Buzzer – This will be the speaker that alerts us when we get too close to the sensor.
HC-SR04 Ultrasonic Sensor – This sensor uses sonic waves to measure the distance of an object.
Resistors – For this experiment, we need both 200-ohm resistors for our LEDs and 1K ohm resistors for our ultrasonic sensor circuit.
PL2303TA USB to TTL Serial Cable Debug Console Cable – This cable is optional, but useful for workshop-like environments where you don‘t have access to a monitor to connect the Raspberry Pi to. It allows you to establish a serial connection between your computer and the Raspberry Pi, which will allow you to communicate with the Pi without having a network connection or monitor.

For software, you‘ll need the following:

Xcode – I am currently using Xcode 12. We will use Xcode to write our Swift code and send it to the Raspberry Pi.
Swish – This is a simple script for remote building your Swift projects on a Linux machine, such as a Raspberry Pi. If we didn‘t use this script, we would need to develop completely on the Raspberry Pi or manually copy all of our files from our MacBook to the Raspberry Pi.
Fritzing – This is an open-source hardware initiative that makes electronics accessible as a creative material for everyone. I used it to mock up the circuit designs to make the workshop easier to follow, as you‘ll see below.

Connecting to your Raspberry Pi

You‘ll need to install Swift on your Raspberry Pi, which I covered in a previous blog post. But first, you‘ll need to connect to your Raspberry Pi. You can do this by attaching a monitor, keyboard, and mouse—but it would be very difficult to set up 20 monitors for a workshop, so to work around this, you can connect to the Pi using the USB to TTL serial cable listed above:

Step 2

Install a driver
Follow the tutorial found here and enter a few commands. I had mixed results, but this is by far the quickest way to connect to a Raspberry Pi without a monitor. Once you‘re connected, your terminal window should look like the image above.
To get your Pi on the network, launch raspi-config and use the prompts to select network options and specify an SSID and password. (If you know the credentials for the WiFi network you‘re connecting to ahead of time, this method to connect to a “headless” Pi also works very well.)
Enter the command ping raspberrypi.local to get your Pi‘s IP address to connect to it. For more help, check out the official docs here.
Once you have your IP address, you‘re ready to create an SSH session to communicate remotely with your Pi. Type ssh pi@<YOUR_IP_ADDRESS> into the terminal and select YES at the next prompt to validate whether or not you trust the connection.

Once you‘re connected to your Raspberry Pi, you’re ready to rock and roll! Now, we can start to build our circuits on the breadboard.

Building the circuit

Parts of the circuit

To build our circuit, we’ll first need to have a basic understanding of the parts we’ll be using.

The breadboard is the glue that connects all of our components. Mine is broken up into three sections: the two outer sections are our power grids, with + and − representing the positive voltage and ground, respectively. The middle section, where our circuit will live, has columns labeled A–J and rows labeled 1–63. Between columns E and F, there is a bridge that splits the middle section in half.

An example breadboard

We‘ll power our circuit through code with a General Purpose Input Output pin. GPIO pins can be set to low (0) or high (1)—a majority of pins provide a voltage of 3.3V when set to high.

Our LED is just a semiconductor that converts electricity into light. We provide the power, and it provides the light. This is a polarized component, which means we‘ll provide power to one side and ground to the other.

We could connect the LED directly to our power source, but it‘s best practice to protect it from being “burned out” or overpowered by using a resistor, which limits how much current flows through the LED. In my workshop, I used the 220-ohm resistor that came with my LED kit.

How to build the circuit

Building our circuit

First, provide a ground connection to the breadboard by plugging a jumper cable from GPIO pin #9 on the Raspberry Pi to the − column on the breadboard.

Instead of connecting to the + rail, connect a jumper cable from GPIO 2 (pin #3) to port 16A (row 16, column A) on the breadboard—this will provide power to every port in row 16, shown by the green dots in the example image above.

Next, insert a resistor into the circuit to limit the flow of current across our LED. Installing our resistor horizontally on row 16 before our bridge will cancel it out—so I’ve installed it vertically, from port 16C to 20C, to continue our connection down to row 20.

Now, connect the anode (the long, positive side of the LED) to port 20D and the cathode (the short, negative side of the LED) to port 21D.

Remember: Earlier, we provided a ground connection from our Pi to the ground rail of the breadboard via a jumper cable. This connection completes our circuit—our LED is now grounded by pin #9 and powered by GPIO 2 (pin #3).

To add a second LED: connect a jumper cable from GPIO 3 (pin #5) to port 25S on the breadboard, connect a resistor from 25C to 30C, and connect the LED to the breadboard just like we did before—with the anode connected to the row that the resistor is terminated at, and the cathode connected to the ground rail of the breadboard.

Testing your circuit from the command line

By default, the WiringPi library is installed with the Raspbian OS image. This library provides a very easy means of testing your circuit without any configuration or third party software. If, for example, you wanted to test the LED connected to GPIO 2 (pin #3), you could enter the following commands:

gpio -g mode 2 output – Sets GPIO 2 pin as an OUTPUT pin.

gpio -g write 2 0 – Sets the GPIO 2 pin LOW or OFF.

gpio -g write 2 1 – Sets the GPIO 2 pin HIGH or ON.

We specify the port after the mode keyword or after the write keyword. With that knowledge, you can use the library to test any port you like.

What‘s next

In Part 2 of this series, we‘ll create the external build system we need to build and transfer our code from our computer to our Raspberry Pi, and get started writing some Swift code to control our LED.

How We Do Sales

Thomas DeVuono — Thu, 15 Oct 2020 00:00:00 GMT

Part performance art, part science, and part relationship managment—sales is a complicated process, and it can differ drasticly depending on the people involved and the goals of the organization. There is no one silver bullet technique that works for every person, every time.

To hone mine, I’ve relied heavily on learning from others in the industry, analyzing and adopting best practices, and experimenting with new technologies and techniques that others have found success with. Now that I‘ve gotten some experience under my belt, I’d like to share Lickability’s sales process in the hopes it may be a guide to someone else’s success. A rising tide raises all boats, after all. ⛵️

The Sales Stigma

When you think of sales, what‘s the first thing that comes to mind? Maybe movies like The Wolf of Wall Street or Glengarry Glen Ross, filled with fervent speeches about doing whatever it takes to beat the competition and get someone to sign on the line that is dotted? Or maybe comedy accounts like Corporate Bro, depicting the daily grind of “slanging software,” the humor and horror of cold calling or emailing, all while preaching the mantra of S.A.D.N.E.S.S. (Sales Are Dope Never Ever Stop Selling), a favorite of mine.

I wasn’t always acutely aware of all the stereotypes and stigmas surrounding the profession and those who practice it. Sure, I’ve heard the warnings of pushy car salespeople who pressure you into buying something—but when I went to buy a car after landing my first job out of college, it was a pleasant, straightforward process. Even in the context of high-dollar corporate sales, when I was an engineer in my previous role, all of my interactions with sales professionals were generally easy and informative experiences.

When I joined Lickability as an account manager, I quickly learned that not everyone sees sales professionals in the positive light that I do. In the beginning of my career, I was hesitant and a little embarrassed to tell people I worked in sales, afraid that they would see me as the stereotypical pushy, aggressive salesperson. But after having spent some time practicing with and learning from others in the industry, I’ve realized that sales isn’t actually about closing at all costs—it’s really about helping people, and that‘s nothing to be ashamed of.

How We’re Different

Our two-person sales team at Lickability enjoys and jokingly uses some sales memes from time to time, but we choose to operate outside of those common stereotypes to give our prospects and clients the best experience possible. To us, this means a low- or no-pressure experience, especially in the early stages of a deal’s progress; being honest about what we can deliver, instead of making promises we can’t keep; and giving a potential customer as much information as possible to help them make the right decisions.

The way we act and communicate with clients is driven by the way we view our sales process: we look at each potential deal as a true partnership, so when we work together, we’re in it for the long haul. For example, every communication a client receives from us has a personal touch. While we do have some email templates for frequently asked questions or scheduling meetings—and we‘ve leveraged AI like ChatGPT to help generate creative ideas for emails and social media posts — we mostly use them as a base and customize them to each individual client and situation.

The partnerships we strive for have to be a two-way street—we want both of us to succeed. When we meet a client for the first time, we pay attention to see if we will work well together and believe in what we’re going to build. We also take the happiness of our engineers into account: will they enjoy the project, will they learn something new doing this, are the project expectations clearly defined? While we’d like to work with every client we meet, sometimes it’s not a good fit, and bringing that up as early in the process as possible is a key point in keeping sales honest.

How We Sell

Our sales process is constantly changing as our company evolves, but here is how we currently operate:

Lead generation

Our process starts with lead generation, both inbound and outbound. For inbound, we rely on referrals from previous clients, visits to our website and blog, and our own personal networks. For outboud, we use cold emails, social media posts, and cold outreach (Text, Twitter DM, Slack DM) to others in the development community. We also sometimes run ads on our favorite podcasts!

Initial discovery call

When a lead comes in, we usually begin with a 30 minute discovery call. This gives us a chance to make introductions, get to know each other a bit, and discuss goals and scope. We always communicate clear action items afterwards, whether that’s a client sending us information to review or for us to get a proposal together.

Estimate

A typical next step is for the sales team to bring the information we gathered from our initial client meeting to our product design and engineering teams, in order for them to give an estimate on the work. The estimation includes figuring out what kind of team we want to put together for your project and how many weeks we‘ll work on it.

Proposal

When the estimation is complete, the sales team takes the information provided by engineering and writes a full proposal that we present to the client, typically over Zoom. We like to do this so that we can explain our thought process, point out assumptions, and answer any immediate questions the client may have.

Negotiation

After the client has had some time to review the proposal, we continue discussing and adjusting until everyone is satisfied with the scope of the project. From there, we create a Statement of Work and begin the contract negotiation process. During this process we also review the terms of our full Services Agreement, which covers everything from the hours we work, confidentiality, ownership, payment terms, etc.

Closing

When negotiations have finished, we finalize all the paperwork and send it to the client for electronic signature via Docusign. If all goes well, the client will sign and we’ve closed the deal and begin a project!

Onboarding

After the ink is dry, sales begins the onboarding process. The first step is sending out some onboarding forms so that we can get logistical information (such as meeting times, slack access, and invoicing) and engineering information (style guides, PR process). Sales takes this information and begins syncing up Lickability’s project team with the client‘s team. We also schedule a project kickoff to make face to face introductions and officially begin the project.

Keeping up the relationship

As the project progresses, sales takes a bit of a back seat so Lickability‘s designated project lead can run the show. But we keep track of how the project is coming along, help with invoicing, and remain available as a familiar point of contact for the client. We also keep an eye on the progress of the project and check in with the client periodically about project extensions, additional projects, or maintenance contracts.

How We Learn

At Lickability we are constantly learning and trying to get better at our jobs by hosting cross-team learning sessions, evaluating new software tools, and attending or speaking at conferences. We are always looking toward our community and industry for ways we can be better. From iOS developer communities, shared Slack channels with fellow agencies, friends and colleagues, our own #everybody channel, we aren’t afraid to ask for help and learn what we can do better.

Work With Us

So that’s our sales process in essence. If you’d like to share some of your own experiences and advice, or just talk shop and see if we can learn from each other, hit me up on Twitter. And if you are thinking about your next software project and all this sounds like your ideal experience, then great! Let’s get the conversation started.

This article has been updated as of June 1 2023

Meet Buildwatch

Team Lickability — Tue, 29 Sep 2020 00:00:00 GMT

After a decade of making software, we‘re releasing our first paid developer tool today on the Mac App Store. Say hello to Buildwatch—a menu bar app that keeps an eye on your compile times throughout the day.

We‘ve been building apps in Xcode for years, and we wanted a tool that would show us how long all that building takes over time. That tool didn’t exist, so we did what we do best: we made our own. Buildwatch shows you, in just a glance, how much time you‘ve spent building in Xcode each day and how many times you’ve built your apps. We designed and developed it exclusively for macOS with support for power users, a focus on privacy, and plenty of exciting things to come in future releases.

Clicking the watch icon in your menu bar reveals a graph that breaks down your hour, day, or week by how much time you‘ve spent compiling your projects. Hover over any segment for a deeper look at the data behind it. Opening the “More info” window gives you even more control to break down your stats by totals, averages, and schemes. Plus, you can inspect your build times for the month, the year, and all time.

We hope Buildwatch gives developers more insight into how their time and resources are being used throughout the app development process, helping you make decisions about equipment and fix bottlenecks. If you develop apps for Apple platforms, we think you‘ll love our menu bar utility as much as we do.

Thank you to all of our beta testers for their feedback and support while Buildwatch came to life, and a special thanks to Ken Ackerson and Sam Gold for partnering with us on development and design.

Learning with Lickability

Jillian Meehan — Fri, 04 Sep 2020 00:00:00 GMT

Every Wednesday morning, we congregate on a Screen call for an hour—not to have a meeting that really could have been an email, but to learn. We call it Learn with Lickability.

Learn with Lickability is our weekly dedicated time for one of us to teach the rest of the team about something interesting, whether it‘s related to iOS development or not. Sometimes it involves live demonstrations of fun things you can do with UIStackView, and sometimes it‘s a detailed look into our process for finding and switching to a new business bank account. I once did a presentation about different methods of project management, and I’m planning an upcoming session about how to use Notion. Any topic is fair game. Here are a few of the topics we‘ve covered recently:

UIStackView / Auto Layout
Practical Combine
Swift Naming
AVAssetResourceLoaderDelegate
Generics / Associated Types
Property Wrappers
SwiftLint
Debugging

Why do we do it?

What‘s the point of taking time out of everyone’s day for something like this? Sure, maybe that hour a week would be better used for something else. And maybe the time it takes to actually prepare for a talk is time that we “should” be using to build apps. So, why do we do it?

Learn with Lickability gives us structured time to expose ourselves to unfamiliar topics, learn new things, and practice teaching others. Because it‘s completely optional to either attend or lead a session, we can be certain that the topics we’re covering are interesting and important to both the person teaching and the people learning—which means it‘s well worth our time. A love for learning may not be one of the five flavors of Lickability, but it‘s pretty close.

Learn with Lickability is also a great excuse to come together as a team for something a little more fun than the average standup or client meeting. With everyone working remotely, it‘s hard to replicate the atmosphere of having casual chats in the office together, and there are less opportunities for us to feel like a team. Learn with Lickability, along with virtual game nights and team lunch Google Meet calls, is one of the ways we’ve been able to stay connected from afar.

How do we do it?

We schedule future Learn with Lickability topics a few weeks in advance so people have time to prepare their presentations on Lickability Fridays. On the morning of, we post that Wednesday‘s topic in our #learn-with-lickability Slack channel, along with a link to the video chat.

We‘ve been using Screen for Learn with Lickability because it‘s great for screen sharing presentations or demos. The only downside is that we can’t add a link to the call in our weekly calendar event, but the Slack integration makes it easy to start or join a call right from the #learn-with-lickability channel.

Learning new things and teaching others should be an integral part of your work, even and especially if you‘re working remotely. I look forward to Learn with Lickability every week, no matter what the topic is—because watcing a live demo or listening to someone explain something they find interesting is such a joy.

If you do something like this at your company—or if you want to start, which we highly recommend—let us know how it goes! We‘d love to hear from you.

Conferences Condensed: WWDC20

Team Lickability — Thu, 09 Jul 2020 00:00:00 GMT

We look forward to WWDC every year, and we know you do, too. As much as we missed seeing all of our pals in San Jose for the conference, we still had a great time watching sessions online and chatting with familiar faces and new friends in our Discord. Keep reading to hear a bit about some of our favorite videos this year.

Advances in UICollectionView

So much of what we do on a daily basis involves the meticulous formatting of data to look great in performant scrolling lists. Several of this year‘s WWDC sessions focused on new technologies that make that possible in both UIKit and SwiftUI, and I couldn‘t be happier. Advances in UICollectionView provides a great overview of the new technologies that enable enhancements to lists in UIKit. Hello UICollectionViewListCell and goodbye UITableView. You‘ll definitely want to bookmark all of the 2020 sessions referenced in the session for a deeper dive: Advances in diffable data sources, Lists in UICollectionView, and Modern cell configuration.

— Michael Liberatore

Add custom views and modifiers to the Xcode Library

The promise of adding custom views to the Xcode Library goes way back to Xcode 3 with Interface Builder plugins. But this year, Apple brought that idea to SwiftUI via two new protocols called LibraryContentProvider and LibraryItem.

No longer will we toil trying to get @IBInspectable to work as intended. Now it’s so simple to create a new SwiftUI view and have it show up with sample data right inside the Xcode Library. But Apple didn’t stop at views—they even made it possible to expose custom Modifiers as well. As Anton, the talk’s presenter, put it, this will allow us to discover and learn about all the controls in our apps‘ design systems much more easily and visually than just reading the source code.

— mb Bischoff

Build trust through better privacy

This was a great presentation on how Apple handles user privacy. The talk goes over the four key pillars of privacy, what they mean, and how you can implement those best practices into your app to build trust with your users. Here are a few of my takeaways:

On-device processing

When user data is sent off-device for processing, a user loses control over that data
Apple is continuing to improve Core ML to integrate machine learning models into your app, to keep processing on-device rather than on a server
Taking advantage of the tools Apple provides is a good way to minimize the data that is processed off-device

Data minimization

We should aim to show respect for a user‘s data and ask for as little of it as possible—only ask for what you need
Again, Apple is providing new tools to make this easier
- Limited Photos Library: a user can define which photos they want to share, instead of sharing all of their photos
- Share approximate location, rather than exact location
- QuickType to suggest contact details, rather than asking for access to all user contacts
Limited access doesn‘t mean limited functionality

Security protections

Apple is adding Encrypted DNS protocols that are natively supported

Transparency and control

Put users in control of their data
Inform users about when, how, and why their data is being collected
- Updates to the App Store Product Page can let users easily see what data an app collects before downloading
- You also need to declare this for any third-party SDKs you use

— Tom DeVuono

Embrace Swift type inference

Leveraging type inference is a fundamental way to learn about generics in Swift. Often we can overlook ways to compose objects in a large project—type inference allows us to omit explicit type annotations without compromising type safety. This is also why we can create complex interfaces within SwiftUI with just a few lines of code, since it relies heavily on type inference at the call sites.

I really appreciated the speaker’s cadence in this talk, since this concept dives into how the Swift compiler infers concrete types without explicitly specifying them.

— Daisy Ramos

Installing the macOS Big Sur beta on a new partition

Marc Aupont — Mon, 22 Jun 2020 00:00:00 GMT

Big Sur has just been announced, and you‘re itching to give it a shot. But wait—you have plenty of apps to support and work to do. Is it worth the risk of things not working or crashing? Probably not. In this blog post, we are going to look into how to install the latest OS without disrupting your current setup.

Installing the profile

The first step is to go to the Apple Developer Portal and download the macOS Big Sur beta profile. Installing the profile will give us the ability to download the latest OS and put it on our hard disk of choice.

Once the download is completed, we‘re ready to prepare the partition where we will install it.

Creating a new partition

There are two potential ways to do this: creating a new volume, or creating a new partition. That said, there seems to be a small catch with creating a new volume, as seen in the tweet below, so we are going down the path of creating a new partition because of the potential upgrade issues.

This caveat is buried deeply enough in the macOS Big Sur release notes that a lot of people are going to be bit by it. Creating a new volume in an existing APFS container had become the de facto best way to install a second OS. pic.twitter.com/BscbELxj6Q

— Daniel Jalkut (@danielpunkass) June 23, 2020

The purpose of creating a new partition is so we can install the beta on our machine without disturbing our current OS and setup. As exciting as it may be to try out the latest OS, it‘s still in beta and can have unexpected results. By creating a new partition, we are creating a separate “bubble” to work in that doesn’t affect the current bubble that we use for work.

To create a new partition, launch Disk Utility and select the Partition button. From here we can press the + button to create a new partition

After that, all we need to do is provide a name and size for our partition. In the example below, we used the name Macintosh HD Beta and specified a size of 100GB for the partition.

Press the + button to add a partition.

Specify the size and name of your partition and select apply.

This alert shows you which partition will be added, and which partition will shrink to make room for it.

Select continue to begin partitioning your hard drive.

Once we apply the changes, our partitions will be resized in order to accommodate all partitions within our disk.

Once the partition has been added, it will show up in the menu on the left, as you can see in the screenshot below.

Installing Big Sur

Now that we have our new partition created, we‘re ready to install macOS Big Sur. At this point in the installation process, you should be at the screen where you need to select which hard drive to install on. This is where we select our newly created Macintosh HD Beta partition. To complete the install, perform the following steps:

Select the Show All Disks button
Select Macintosh HD Beta
Select Install

Step 1

Step 2

Step 3

That‘s it! Once the installation process is complete, you’ll be able to run Big Sur on the new partition.

Booting into macOS Big Sur

To boot to your new partition, perform the following steps:

Shut down your Mac
Press and hold the option key while powering up
Select the partition you want to boot from

If you want to automatically boot into your new macOS Big Sur installation, you can set this in System Preferences via the Startup Disk. Once this is set, your Mac will automatically boot into whichever option you selected when you restart.

When you switch back to your Catalina partition, you may see an “Incompatible Disk” alert that looks like this. All it means is that your Catalina partition is seeing the Big Sur partition and doesn‘t understand it. It won’t cause problems for either OS.

Removing the beta profile

Once you‘ve installed the beta profile to download the OS, you probably don’t need it on your main machine anymore. To remove the profile, perform the following steps:

Go into System Preferences and select Software Update
From there select details underneath the Software Update
Once selected, you‘ll be able to select Restore Defaults, which will restore your computer‘s regular update cycle. When you want to install new beta updates, you can do that from your new Big Sur volume instead.

Summary

That wraps it up! At this point, you should have everything necessary to play around with the beta while maintaining the normal state of your machine.

If you‘d like to see a quick video of the whole process, check it out below!

And if you‘re interested in building some Mac apps, get in touch! We‘d be happy to help.

Getting Started with UICollectionViewCompositionalLayout

Michael Liberatore — Wed, 17 Jun 2020 00:00:00 GMT

At WWDC 2019, Apple introduced and later documented an unbelievable API for building complex layouts with ease. UICollectionViewCompositionalLayout promised to simplify collection view layouts using a more declarative approach without the need to subclass to achieve customization—and it delivered. Our team has been making use of compositional layouts ever since, and we’d like to help you get started as well.

Back to Basics

For years, UICollectionViewFlowLayout , a UICollectionViewLayout subclass, helped us to achieve simple line-based layouts with little configuration, and with little customization required to perfectly create a common grid layout. More advanced customization often meant subclassing UICollectionViewFlowLayout, or creating your own layout by subclassing UICollectionViewLayout directly. We’ll start by reviewing how to build a grid with a flow layout, and then show you how to achieve the same design using a compositional layout while exploring the new APIs. Then, we’ll expand on our compositional layout solution while introducing some of the more powerful new features.

A basic grid built with UICollectionViewFlowLayout.

Our flow layout and compositional layout will use the exact same data source. It’s just a standard, everyday UICollectionViewDataSource that returns a cell for each square photo we want to display. The photos are categorized into sections, but that won’t come into play just yet.

Swift

extension PhotosDataSource: UICollectionViewDataSource {
    
    // MARK: - UICollectionViewDataSource
    
    func numberOfSections(in collectionView: UICollectionView) -> Int {
        return sections.count
    }
    
    func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        return sections[section].items.count
    }
    
    func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        guard let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "PhotoCell", for: indexPath) as? PhotoCell else {
             return UICollectionViewCell()
        }
        
        let photo = sections[indexPath.section].items[indexPath.item]
        cell.viewModel = PhotoCell.ViewModel(identifier: photo.identifier, imageURL: photo.thumbnailURL)
        
        return cell
    }
}

We also need to register our cell under the reuse identifier used by our data source. In this example, our cell comes from a nib named PhotoCell.

Swift

collectionView.register(UINib(nibName: "PhotoCell", bundle: nil), forCellWithReuseIdentifier: "PhotoCell")

The flow layout is fairly simple to set up. In the screenshot above, we can see 5 points of spacing between cells, both vertically and horizontally, as well as 5 point margins surrounding the layout.

Swift

let flowLayout: UICollectionViewFlowLayout = {
    let layout = UICollectionViewFlowLayout()
    layout.minimumInteritemSpacing = 5
    layout.minimumLineSpacing = 5
    layout.sectionInset = UIEdgeInsets(top: 5, left: 5, bottom: 5, right: 5)
    return layout
}()

Our cell layout is uniform. Every item is the same size, and we want exactly three items in every row. Since that size will change dynamically to fill the horizontal space on various screen sizes, we can’t simply set itemSize once upfront. Instead, we’ll implement the following UICollectionViewDelegateFlowLayout method to provide a size based on the width of the collection view’s current bounds.

Swift

extension PhotosCollectionViewController: UICollectionViewDelegateFlowLayout {

    // MARK: - UICollectionViewDelegateFlowLayout

    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {
        let width = collectionView.bounds.width
        let numberOfItemsPerRow: CGFloat = 3
        let spacing: CGFloat = flowLayout.minimumInteritemSpacing
        let availableWidth = width - spacing * (numberOfItemsPerRow + 1)
        let itemDimension = floor(availableWidth / numberOfItemsPerRow)
        return CGSize(width: itemDimension, height: itemDimension)
    }
}

In this implementation, we calculate availableWidth based on how much of our width will be taken up by margins and inter-item spacing (assuming we use the same value for both for simplicity) and subtracting it from the width of the collection view’s current bounds, then evenly dividing availableWidth by the number of items we want per row. If we ever wanted to change the number of items per row, we only need to change numberOfItemsPerRow and the rest of the layout will work as is.

And that’s it! Well… sort of. There are a few more adjustments we’d have to make for our layout to be perfect. Right now, if we rotate to and from landscape, our layout doesn’t properly invalidate, and we end up with a different number of items per row.

Our flow layout after rotating the device :(

We can fix this in a number of different ways. We could detect when our view’s bounds change, and make the appropriate call to invalidateLayout(). We could subclass UICollectionViewFlowLayout and override shouldInvalidateLayout(forBoundsChange:). We could place some random combination of invalidateLayout() and reloadData() in various UIViewController methods, cross our fingers, and hope it doesn’t affect any animations we may want to add in the future 🤞 (we’ve all been there).

But wouldn’t it be nice to just describe our layout upfront and not deal with any of that? If only we knew how to use that shiny, new declarative API.

Understanding `UICollectionViewCompositionalLayout` by Example

Forget everything you know about collection view layouts! Okay, well… not so fast. But we do need to think a bit differently about traditional section- and item-based layouts. In our flow layout, a section was comprised of multiple items, laid out in horizontal lines that were stacked vertically.

Diagram of a flow layout with items laid out in horizontal lines within a section.

UICollectionViewCompositionalLayout introduces groups, a powerful layer conceptually nestled somewhere between sections and items that we must understand to fully unlock their potential. For now, just know that a layout is comprised of sections, sections are comprised of groups, and groups are comprised of items and optionally other groups. We won’t nest groups within other groups just yet. Take a look at how our layout can be modified to incorporate groups.

Diagram of a compositional layout with items nested in groups within a section.

Sections and items described in a compositional layout correspond 1-to-1 with the sections and items of our collection view data source. Groups, however, don’t have a data source equivalent, nor do they render content like items/cells. They’re used solely to describe the layout of our items within a section.

In the diagram above, each group represents a horizontal line of our layout. We’ll get fancier in a bit, but for now, we’ll structure our first compositional layout in this manner. Speaking of our first compositional layout, let’s get started on that now. We’ll want to create our layout using the initializer init(section:), which takes an NSCollectionLayoutSection as a parameter. Note that NSCollectionLayoutSection simply describes the layout of any section in the layout we’re creating. We’re not adding any data to the collection view here, as that’s the responsibility of the UICollectionViewDataSource.

Swift

let section = NSCollectionLayoutSection(group: group)
let layout = UICollectionViewCompositionalLayout(section: section)

Oh, but we need to declare that group. That’s right…because a layout is comprised of sections, which are comprised of groups, which are comprised of groups and items. Let’s work backwards from here.

A group is represented by a NSCollectionLayoutGroup. To create one, we need to describe its size relative to its containing section, specify whether we want it to lay items out horizontally or vertically, and describe the items it will contain. We’ll use the class function NSCollectionLayoutGroup.horizontal(layoutSize:subitems:) to do this, since we want each group to lay out its items horizontally, but first we need to understand sizing.

Sizing is accomplished by describing groups and items in relation to their respective container’s size. More specifically, the size of a group can be described relative to its containing group or section’s size, and the size of an item can be described relative to its containing group’s size. To mimic our flow layout, we want to use the full section width to lay out three items in each group. To do so, we can easily describe the width of our group using NSCollectionLayoutDimension. More specifically, we can create this using the NSCollectionLayoutDimension.fractionalWidth(_:) class method, passing 1 to indicate that we want our group width to be 1 x the containing section’s width.

Swift

let widthDimension = NSCollectionLayoutDimension.fractionalWidth(1)

We also need to provide a height dimension. Effectively, we want our groups to be as tall as our items, but we haven’t yet specified anything about item size just yet. Thinking ahead, we know we want to lay out 3 items horizontally in each group, and we know that our items are square (that is, their height equals their width). In our flow layout, we divided our available width by 3 to determine the item width and height, and we can do the same with fractionalWidth(_:).

Swift

let heightDimension = NSCollectionLayoutDimension.fractionalWidth(1/3)

Remember, though, that we’re defining our group size right now, not our item size. Currently, our groups just happen to be the same desired height as our items. Putting this all together, we create an NSCollectionLayoutSize with our width and height dimensions, and use that to initialize our group. We then use our group to initialize our section, and our section to initialize our layout as we saw before.

Swift

let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalWidth(1/3))
let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitems: [item])

let section = NSCollectionLayoutSection(group: group)
let layout = UICollectionViewCompositionalLayout(section: section)

It’s extremely powerful that we’re able to describe height relative to the container’s width, and vice versa. Since our list scrolls vertically, we can’t really describe our group height in terms of the section’s height, as the section’s height is dependent on the number of items in our data source, and that has nothing to do with our group size. Sometimes, you may want to specify a specific, non-container-relative width or height. You can do so using NSCollectionLayoutDimension.absolute(_:). Similarly, for self-sizing groups and items, you can use NSCollectionLayoutDimension.estimated(_:) and the actual dimension will be computed during layout.

We now need to define our layout’s items, which we used to create the NSCollectionLayoutGroup above. Items in the layout are represented by NSCollectionLayoutItem, and just like groups, they are initialized with an NSCollectionLayoutSize. Now that we know how sizing works, this should be easy. Each item is as tall as its containing group (which we’ve already sized appropriately), and we want 3 items laid out horizontally in each group, so our item width will be a third of its containing group’s width.

Swift

let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1/3), heightDimension: .fractionalHeight(1))
let item = NSCollectionLayoutItem(layoutSize: itemSize)

Our layout only uses a single NSCollectionLayoutItem because our cells are uniformly sized, but we could (and later will) create a group with multiple items. For now, we put everything we just learned together to create a complete layout:

Swift

let compositionalLayout: UICollectionViewCompositionalLayout = {
    let fraction: CGFloat = 1 / 3
    
    // Item
    let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(fraction), heightDimension: .fractionalHeight(1))
    let item = NSCollectionLayoutItem(layoutSize: itemSize)
    
    // Group
    let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalWidth(fraction))
    let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitems: [item])
    
    // Section
    let section = NSCollectionLayoutSection(group: group)
    return UICollectionViewCompositionalLayout(section: section)
}()

And that’s it. Our entire layout is declared up front. Our sizing logic from UICollectionViewDelegateFlowLayout is no longer required, as that behavior is already captured in our layout declaration. Let’s take a look.

Our first attempt at a compositional layout. We’re almost there…

Ok, that’s not quite it, but we’re close. We didn’t account for margins and item spacing like we did in our flow layout. Remember that in our flow layout, we needed to mathematically determine how much total horizontal spacing our layout required to determine our item size, and we also needed to specify minimumInteritemSpacing, minimumLineSpacing, and sectionInset to get everything working perfectly. Achieving similar results in our compositional layout is quite simple by setting insets on item and section.

Swift

let inset: CGFloat = 2.5

// after item declaration…
item.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)

// after section delcaration…
section.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)

Note that we use 2.5 instead of 5 because each item gets this padding, so an item next to another item or a section edge will have a combined padding of 5. Also, we don’t have to calculate how much total horizontal space is required per row. Our .fractionalWidth(1/3) still works because our spacing is accomplished via content insets, so our item width and height, including insets, are still one third of the width of our containing group. The content (cell) is simply inset within this size.

Our compositional layout now matches our flow layout!

✨ Now our layout is perfect. Not only does it properly maintain 3 columns when rotating our device back and forth, but the layout properly adjusts to respect the leading and trailing safe area margins without any additional code!

The same compositional layout in landscape, inset by the safe area.

Using UICollectionViewCompositionalLayout, we successfully matched the design of our flow layout using only a few lines of code, and we even fixed some bugs along the way. But that’s not all we can do with a compositional layout. We’re just getting started.

Supplementary Items

We’ve accomplished a basic layout of our cells, but if you’ve worked with collection views before, you might know that your data source is also capable of vending reusable supplementary views to create things like headers, accessory views, and the like. So how do those fit into compositional layouts? Before we get there, let’s add a method to our data source to create a view we’d like to use as a header for the sections in our collection view.

Swift

extension PhotosDataSource: UICollectionViewDataSource {
    
    // MARK: - UICollectionViewDataSource
    
    // …

    func collectionView(_ collectionView: UICollectionView, viewForSupplementaryElementOfKind kind: String, at indexPath: IndexPath) -> UICollectionReusableView {
        guard let headerView = collectionView.dequeueReusableSupplementaryView(ofKind: kind, withReuseIdentifier: "HeaderSupplementaryView", for: indexPath) as? HeaderSupplementaryView else {
            return HeaderSupplementaryView()
        }
        
        headerView.viewModel = HeaderSupplementaryView.ViewModel(title: "Section \(indexPath.section + 1)")
        
        return headerView
    }
}

Here, we’re simply returning a reusable instance of a basic header view class that we created and specifying its title as “Section” followed by the section number.

Just like we did with our PhotoCell, we’ll need to register HeaderSupplementaryView with our collection view.

Swift

collectionView.register(UINib(nibName: "HeaderSupplementaryView", bundle: nil), forSupplementaryViewOfKind: "header", withReuseIdentifier: "HeaderSupplementaryView")

And now we’re ready to incorporate this into our layout. For a flow layout, you’d either set headerReferenceSize or implement collectionView(_:layout:referenceSizeForHeaderInSection:) as part of your UICollectionViewDelegateFlowLayout conformance. It’s just as simple to accomplish in a compositional layout.

First we need to create the layout-equivalent of our supplementary view, that is, the component that describes the header in our layout declaration. Look no further than NSCollectionLayoutBoundarySupplementaryItem. We’ll simply create an instance and set it on our NSCollectionLayoutSection. Sizing works the same way as our items and groups, using NSCollectionLayoutSize. Then, we just need specify the element kind under which we registered, and .top or .bottom for the supplementary view’s alignment (note that we’d choose .bottom if we wanted this to be a section footer).

Swift

let headerItemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .estimated(100))
let headerItem = NSCollectionLayoutBoundarySupplementaryItem(layoutSize: headerItemSize, elementKind: "header", alignment: .top)
section.boundarySupplementaryItems = [headerItem]

With these three lines of code, our layout now supports headers!

Compositional layout with supplementary header items.

It’s just as easy to make these headers and footers “float” as you scroll by setting pinToVisibleBounds to true.

So what else can we display with supplementary items? Well… pretty much anything you want. NSCollectionLayoutBoundarySupplementaryItem is actually a subclass of NSCollectionLayoutSupplementaryItem. Using this class directly, we can easily control the sizing and positioning of supplementary views by attaching them to items and groups. A common example is displaying a badge on specific items, as demonstrated in the docs. Let’s use a similar approach and add a banner to the bottom of specific items. We’ll have the banner read “NEW” and it will extend beyond our item’s visible bounds.

First, just like we did for our section header items, we need to provide a reusable view from our data source. We’ll modify our data source method to check the element kind, and return a configured instance of the appropriate view.

Swift

func collectionView(_ collectionView: UICollectionView, viewForSupplementaryElementOfKind kind: String, at indexPath: IndexPath) -> UICollectionReusableView {
    switch kind {
    case "header":
        guard let headerView = collectionView.dequeueReusableSupplementaryView(ofKind: kind, withReuseIdentifier: "HeaderSupplementaryView", for: indexPath) as? HeaderSupplementaryView else {
            return HeaderSupplementaryView()
        }
        
        headerView.viewModel = HeaderSupplementaryView.ViewModel(title: "Section \(indexPath.section + 1)")
        return headerView
        
    case "new-banner":
        let bannerView = collectionView.dequeueReusableSupplementaryView(ofKind: kind, withReuseIdentifier: "NewBannerSupplementaryView", for: indexPath)
        bannerView.isHidden = indexPath.row % 5 != 0 // show on every 5th item
        return bannerView
        
    default:
        assertionFailure("Unexpected element kind: \(kind).")
        return UICollectionReusableView()
    }
}

Our banner is backed by a simple nib-based view, NewBannerSupplementaryView, that displays the “NEW” label and sets a background color and border. This data source method must return a non-optional UICollectionReusableView, so even though we don’t want one on every item, we must provide one. The docs state:

If you do not want a supplementary view in a particular case, your layout object should not create the attributes for that view. Alternatively, you can hide views by setting the isHidden property of the corresponding attributes to true or set the alpha property of the attributes to 0.

Since we’re not in the business of subclassing UICollectionViewLayout anymore, we’re not controlling the creation of attributes, so we use the isHidden approach here. For demonstration purposes, we set our data source up to show this supplementary item on every 5th cell.

Again, we have to register our nib under the reuse identifier and element kind we just used.

Swift

collectionView.register(UINib(nibName: "NewBannerSupplementaryView", bundle: nil), forSupplementaryViewOfKind: "new-banner", withReuseIdentifier: "NewBannerSupplementaryView")

And that brings us to the layout updates. We’ll be creating an NSCollectionLayoutSupplementaryItem with the initializer init(layoutSize:elementKind:containerAnchor:).

layoutSize is an NSCollectionLayoutSize, nothing new. But it’s worth mentioning that when using fractional width and height, the values are relative to the associated item or group you will be attaching the supplementary item to. We want our banner to be slightly wider than the item it’s attached to, so we’ll use a fractional width of 1.1. We can simply fix the height to a value that looks good, in this case 30, but could also use .estimated just as easily and let Auto Layout do its thing.
Similar to our header, elementKind needs to match the string we used in our data source and nib registration. In this case, that’s "new-banner".
Lastly, we have containerAnchor, which is of type NSCollectionLayoutAnchor. It’s initialized with a set of edges (NSDirectionalRectEdge), and optionally a fixed or fractional offset from that edge. It determines where on our item or group to attach the supplementary item. We are going to attach it to the bottom, with a y-offset of 10 so that it extends below our item as well.

We want a larger inset on all of our components so our banner has some additional room to extend beyond our items’ bounds, so we’ll replace 2.5 with 8. The following shows the supplementary item and item declaration. Note that the item declaration now makes use of supplementaryItem. The group and section declarations remain the same as before, but without the header supplementary items.

Swift

let inset: CGFloat = 8
                        
// Supplementary Item
let layoutSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.1), heightDimension: .absolute(30))
let containerAnchor = NSCollectionLayoutAnchor(edges: [.bottom], absoluteOffset: CGPoint(x: 0, y: 10))
let supplementaryItem = NSCollectionLayoutSupplementaryItem(layoutSize: layoutSize, elementKind: "new-banner", containerAnchor: containerAnchor)

// Item
let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(fraction), heightDimension: .fractionalHeight(1))
let item = NSCollectionLayoutItem(layoutSize: itemSize, supplementaryItems: [supplementaryItem])
item.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)

And the results?

Compositional layout with item-based supplementary items.

We’ve now seen how to add various kinds of supplementary items to our compositional layout, but the customization doesn’t stop there.

Decoration Items

In addition to supplementary items, we can customize our section layout with decoration items. This will allow us to easily add backgrounds to our sections. The background view we’ll create is quite simple (a gray rectangle with a corner radius), so we’ll do it in code.

Swift

/// A basic supplementary view used for section backgrounds.
final class BackgroundSupplementaryView: UICollectionReusableView {
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        layer.cornerRadius = 8
        backgroundColor = UIColor(white: 0.85, alpha: 1)
    }
}

Perhaps surprisingly, we don’t need to update our data source or register this view on the collection view. We’ll handle registration directly on the layout. And speaking of the layout, in order to accommodate the background view, we’ll want to inset our section a bit more to display more of the new background, so instead of using our uniform 2.5 for all of our spacing like we were before, let’s specify a new value for our section contentInsets.

Swift

let sectionInset: CGFloat = 16
section.contentInsets = NSDirectionalEdgeInsets(top: sectionInset, leading: sectionInset, bottom: sectionInset, trailing: sectionInset)

In our layout declaration, we simply create a new decoration item for our background using NSCollectionLayoutDecorationItem.background(elementKind:), inset it a bit, and set it on our section.

Swift

let backgroundItem = NSCollectionLayoutDecorationItem.background(elementKind: "background")
let backgroundInset: CGFloat = 8
backgroundItem.contentInsets = NSDirectionalEdgeInsets(top: backgroundInset, leading: backgroundInset, bottom: backgroundInset, trailing: backgroundInset)
section.decorationItems = [backgroundItem]

We then register it on the layout itself after we create it.

Swift

let layout = UICollectionViewCompositionalLayout(section: section)
layout.register(BackgroundSupplementaryView.self, forDecorationViewOfKind: "background")

Now our background decoration view is ready.

Compositional layout with background decoration items.

And that’s all there is to it!

Section Provider

We’ve now successfully customized our layout using supplementary and decoration views, which opens a world of possibilities. But so far, our sections have been uniform. After all, we describe each section the same way, with a single NSCollectionLayoutSection, which is fairly limiting. Thus far, we’ve only used init(section:) to create our UICollectionViewCompositionalLayout, so we need to explore another API.

To provide a different layout on a section-by-section basis of a compositional layout, we need to create a UICollectionViewCompositionalLayoutSectionProvider. A section provider is simply a closure that is passed a section index and environment information, and returns an NSCollectionLayoutSection. Instead of init(section:) we need to use UICollectionViewCompositionalLayout’s init(sectionProvider:).

First, we’ll very lightly refactor our initial layout declaration with headers to use this initializer. We simply put all of the item, group, and section setup into the section provider closure.

Swift

let compositionalLayout = UICollectionViewCompositionalLayout(sectionProvider: { (sectionIndex, environment) -> NSCollectionLayoutSection? in
    let fraction: CGFloat = 1 / 3
    let inset: CGFloat = 2.5
    
    // Item
    let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(fraction), heightDimension: .fractionalHeight(1))
    let item = NSCollectionLayoutItem(layoutSize: itemSize)
    item.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)
    
    // Group
    let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalWidth(fraction))
    let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitems: [item])
    
    // Section
    let section = NSCollectionLayoutSection(group: group)
    section.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)
    
    // Supplementary Item
    let headerItemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .estimated(100))
    let headerItem = NSCollectionLayoutBoundarySupplementaryItem(layoutSize: headerItemSize, elementKind: "header", alignment: .top)
    section.boundarySupplementaryItems = [headerItem]
    
    return section
})

Things will look identical to how they did before, but now we’re ready to customize each section based on the section index and environment. To illustrate this, we’ll make a simple change to incorporate the section index. We’ll simply add the section index to the current number of items in each row (3). So for example, the first section (index 0) will have 3 items in each row, the second section will have 4 items in each row, the third section will have 5 items in each row, etc. We only need to change the declaration of fraction.

Swift

let itemsPerRow = sectionIndex + 3
let fraction: CGFloat = 1 / CGFloat(itemsPerRow)

And let’s see how it looks.

Compositional layout with an increasing number of items per row in each section.

Note that we’re using the same items and groups in each section, just with slightly tweaked metrics, but you could very well use entirely different item and group layouts on a section-by-section basis if your design calls for it.

We can also use the environment parameter of the section provider to customize our layout. The environment is an NSCollectionLayoutEnvironment, and provides us more context about the container that we can use to make decisions about how we want to layout our items, groups, and sections. The container property on the environment gives us information about the content size and insets of the layout. We also have access to traitCollection, which allows us to easily make use of the layout’s size class and the screen’s scale factor. We’ll use the trait collection’s horizontalSizeClass to determine the number of items to display in each row. For horizontally-regular environments, like full-screen iPad layouts, we’ll display double the number of items per row. For horizontally-compact environments, we’ll keep it at 3. All we need to do is change our itemsPerRow.

Swift

let itemsPerRow = environment.traitCollection.horizontalSizeClass == .compact ? 3 : 6
let fraction: CGFloat = 1 / CGFloat(itemsPerRow)

And just like that, our layout scales nicely for different environments!

Compositional layouts in different horizontal size classes.

Nested Groups

Once you’ve gotten used to building layouts using UICollectionViewCompositionalLayout, you’ll likely find it much easier to accomplish the things you used to do with UICollectionViewFlowLayout, often with much less code. So far we’ve played with a few bells and whistles that flow layouts don’t support right out of the box. It’s now time to break away from a uniform, flow-like layout and build something that would’ve previously required subclassing UICollectionViewLayout.

When creating NSCollectionLayoutGroups, we’ve previously only supplied one item to the subitems parameter. This is because all of our items within our horizontal groups were uniform in size and insets. However, our layouts can consist of any number of unique NSCollectionLayoutItems we’d like. But as we previously alluded to, we can also nest groups within our groups. If you haven’t figured it out already, groups are just a special kind of item that allow the nesting of other items. In fact, NSCollectionLayoutGroup is a subclass of NSCollectionLayoutItem, so it’s not just a coincidence that we can modify size, spacing, and insets the same way.

Let’s try to build a more complicated layout using multiple items and nested groups. It’ll look like the following.

Diagram of a compositional layout with multiple items and nested groups.

At this point, we know all of the major parts that compose a compositional layout, so we’ll work forward instead of backwards, starting with the items. In our diagram, items fall into two categories in terms of sizing relative to their containing group:

The larger items take up half the width of their containing group, and the full height.
The smaller items take up the full width of their containing group, and the full width.

We already know how to use NSCollectionLayoutSize to specify fractional widths and height, so let’s define these items.

Swift

let largeItemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.5), heightDimension: .fractionalHeight(1))
let largeItem = NSCollectionLayoutItem(layoutSize: largeItemSize)

let smallItemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalHeight(0.5))
let smallItem = NSCollectionLayoutItem(layoutSize: smallItemSize)

Now we move onto the groups. Let’s start with the nested group first. Unlike the previous groups we’ve used, the nested groups lay items out vertically. Well, good news! NSCollectionLayoutGroup.vertical(layoutSize:subitems:) works exactly like its horizontal counterpart. Since we’ve already specified that we want the large item to take up half the width of the containing group, we have half of the width left for our nested groups. We want two of them, side-by-side, so we’ll make each of them take up a quarter of the containing group’s width, but use the full height. This vertical group only contains one type of item, the smallItem that we defined above.

Swift

let verticalGroupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.25), heightDimension: .fractionalHeight(1))
let verticalGroup = NSCollectionLayoutGroup.vertical(layoutSize: verticalGroupSize, subitems: [smallItem])

Finally, we need to declare our outer group. This group contains a large item next to two nested groups, laid out horizontally. The group itself takes up the full width of its containing section, but its height is a bit trickier. Again, we know the large item takes up half the width of its containing group (which is the outer group). Since it’s a square, we want its height to match. Much like we did with our first compositional layout, we’ll define this group’s height relative to its container’s width. More specifically, its height is equal to half of its width. So… not that tricky.

Swift

let outerGroupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalWidth(0.5))
let outerGroup = NSCollectionLayoutGroup.horizontal(layoutSize: outerGroupSize, subitems: [largeItem, nestedGroup, nestedGroup])

Finally, we’ll use this outer group to create our section, and create the the compositional layout from our section:

Swift

let section = NSCollectionLayoutSection(group: outerGroup)
return UICollectionViewCompositionalLayout(section: section)

So how’s it look?

Compositional layout with multiple items and nested groups.

Hey, not bad! Everything is exactly where we expect it to be.

You may have noticed that we specified three items in subitems for our outerGroup declaration:

Swift

NSCollectionLayoutGroup.horizontal(layoutSize: outerGroupSize, subitems: [largeItem, nestedGroup, nestedGroup])

This does match what we see on screen, but we didn’t have to repeat items in our subitems array in our first compositional layout that had three items laid out horizontally, so what gives?

When using NSCollectionLayoutGroup.horizontal(layoutSize:subitem:) and NSCollectionLayoutGroup.vertical(layoutSize:subitem:), the subitems that you provide will repeat, in order, in the respective direction until the next subitem wouldn’t fit. So if our group specified only [largeItem, nestedGroup] for its subitems, the next horizontal item after a large item and a vertical nested group would be the large item again. And since we’ve already eaten up 75% of the horizontal space in the group, we wouldn’t be able to fit another 50%-width item. So it’s necessary for us to specify all three items/groups in this order, otherwise we’d end up with this:

Compositional layout with only two items specified per outer group: largeItem and nestedGroup. Empty horizontal space fills the rest of each outer group.

Before we call this layout complete, let’s spruce it up with the same insets and headers that we used before. The completed layout is as follows:

Swift

let compositionalLayout: UICollectionViewCompositionalLayout = {
    let inset: CGFloat = 2.5
    
    // Items
    let largeItemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.5), heightDimension: .fractionalHeight(1))
    let largeItem = NSCollectionLayoutItem(layoutSize: largeItemSize)
    largeItem.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)
    
    let smallItemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalHeight(0.5))
    let smallItem = NSCollectionLayoutItem(layoutSize: smallItemSize)
    smallItem.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)
    
    // Nested Group
    let nestedGroupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.25), heightDimension: .fractionalHeight(1))
    let nestedGroup = NSCollectionLayoutGroup.vertical(layoutSize: nestedGroupSize, subitems: [smallItem])
    
    // Outer Group
    let outerGroupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalWidth(0.5))
    let outerGroup = NSCollectionLayoutGroup.horizontal(layoutSize: outerGroupSize, subitems: [largeItem, nestedGroup, nestedGroup])
    
    // Section
    let section = NSCollectionLayoutSection(group: outerGroup)
    section.contentInsets = NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)
    
    // Supplementary Item
    let headerItemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .estimated(100))
    let headerItem = NSCollectionLayoutBoundarySupplementaryItem(layoutSize: headerItemSize, elementKind: "header", alignment: .top)
    section.boundarySupplementaryItems = [headerItem]
     
    return UICollectionViewCompositionalLayout(section: section)
}()

And the result?

Compositional layout with nested groups with insets and section headers applied.

*chef’s kiss*

Orthogonal Scrolling

Now for the main event. The most amazing feature of compositional layouts.

Have you ever had to build a vertically scrolling table view or collection view where some of the rows also scroll horizontally? You know, a gallery of sorts. Take the App Store for example:

App Store: A gallery-style horizontally scrolling list within a vertically scrolling list.

We refer to this behavior as “orthogonal scrolling”. That is, part of our layout scrolls along the opposite axis of the scrolling container. In this example, part of the layout scrolls horizontally in a vertically scrolling container.

How would you build this? I can’t tell you how many times I’ve nested horizontally scrolling flow-layout collection views inside of vertically scrolling table views. Scroll performance and view hierarchy architecture be damned!

What if I told you that you can achieve this behavior, allowing sections of your collection view to scroll horizontally within a vertically scrolling list without incurring a massive performance hit. What If I told you that you wouldn’t need to embed collection views inside of other cells? What if I told you that you could achieve this with One. Line. Of. Code.? Okay, okay. I’m exaggerating. OR AM I?

In one 👏 line 👏 of 👏 code 👏, we can set the orthogonalScrollingBehavior on a section to achieve exactly what we want.

Swift

section.orthogonalScrollingBehavior = .groupPaging

That’s it. Applying this to the layout we created in the last section produces the following results:

Compositional layout with orthogonal scrolling behavior applied.

🤯

We used the groupPaging behavior, which allows for swiping to scroll to, and immediately rest on, the next or previous group in the section. If we wanted to scroll continuously without paging, we could use continuous. There are several more options to choose from, and chances are, you’ll be able to achieve the exact behavior you’re looking for, with One. Line. Of. Okay, you get it.

Bonus Round

We’ve kissed UICollectionViewFlowLayout goodbye. We’ve built layouts that previously would’ve required subclassing UICollectionViewLayout. We’re going to take a look at one final API that doesn’t get quite as much attention, but is definitely capable of unlocking more customization that might keep you from reaching for that old UICollectionViewLayout subclassing approach.

NSCollectionLayoutSection has a visibleItemsInvalidationHandler property, documented as follows:

A closure called before each layout cycle to allow modification of the items in the section immediately before they are displayed.

Well, how could we use that? However you want, really. Play with it! Experiment! Animate your items!

Previously, I was no stranger to subclassing UICollectionViewLayout and overriding layoutAttributesForElement(in:) to do fun, fancy things, like scale cells so that they’re larger as they approach the center of the screen. No more.

Let’s start with a slightly modified version of our first layout again. We’ll ditch the item insets, add some additional spacing at the top of each section, and use continuousorthogonalScrollingBehavior.

Swift

let compositionalLayout: UICollectionViewCompositionalLayout = {
    let fraction: CGFloat = 1.0 / 3.0
    
    // Item
    let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalHeight(1))
    let item = NSCollectionLayoutItem(layoutSize: itemSize)
    
    // Group
    let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(fraction), heightDimension: .fractionalWidth(fraction))
    let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitems: [item])
    
    // Section
    let section = NSCollectionLayoutSection(group: group)
    section.contentInsets = NSDirectionalEdgeInsets(top: 100, leading: 2.5, bottom: 0, trailing: 2.5)
    section.orthogonalScrollingBehavior = .continuous
    
    return UICollectionViewCompositionalLayout(section: section)
}()

Now, let’s play around with visibleItemsInvalidationHandler. This closure passes an array of the visible items, represented by NSCollectionLayoutVisibleItem, the current scrollOffset, and the layout environment, like we saw earlier in our section provider. We’ll use this information to calculate the horizontal distance of each visible item from the center of the container. Then we’ll scale each visible item, so that when they’re in the center, they’re larger than their normal size, and when they’re closer to the edges of the screen, they’re smaller.

Swift

section.visibleItemsInvalidationHandler = { (items, offset, environment) in
    items.forEach { item in
        let distanceFromCenter = abs((item.frame.midX - offset.x) - environment.container.contentSize.width / 2.0)
        let minScale: CGFloat = 0.7
        let maxScale: CGFloat = 1.1
        let scale = max(maxScale - (distanceFromCenter / environment.container.contentSize.width), minScale)
        item.transform = CGAffineTransform(scaleX: scale, y: scale)
    }
}

So with just a little bit of math, we achieve… whatever this is!

There’s a lot of power packed into this API, and like the other APIs we’ve explored, it can help to eliminate your need to write your own UICollectionViewLayout subclass.

Conclusion

We’ve come a long way since UICollectionView’s introduction in 2012. Apple and third-party developers have continued to push the envelope with increasingly complex layouts in their apps that look and work beautifully. Emulating these complex layouts over the years proved to be frustrating, and not for the feint of heart. It takes a lot of hard work to assess these complications, and completely rethink the tools we use to build our user interfaces. While it might not be quite as fundamentally impactful as Swift UI in the longterm, UICollectionViewCompositionalLayout is an amazing, feature packed API that addresses the needs of modern app developers.

Please consider this my love letter to Apple. I’m just… so impressed. 💌

Understanding Creational Design Patterns

Ashli Rankin — Tue, 26 May 2020 00:00:00 GMT

Welcome to the third and final part of our series on understanding design patterns in iOS development. In previous blog posts, we explored structural and behavioral design patterns. In this post, we‘ll take a look at a few examples of creational patterns, which allow us to create interfaces in our applications.

🔨 The Builder Pattern

This pattern is composed of three types: the director, the product, and the builder. The director takes the inputs and coordinates with the builder. The product is the complex object we are trying to create. And the builder accepts step-by-step instructions and handles the creation of the product.

To learn more about the builder pattern, I recommend reading John Sundell‘s explanation. He covers the core ideas behind the pattern, pros and cons of using it, and a few examples we can look at.

🏭 The Factory Pattern

This pattern allows us to create objects without exposing how they are made. We can use this method when we are not sure what exact types and dependencies the code should work with.

We can also use this method if we want to give users of our framework a way to extend our internal components. This method is beneficial because it allows us to avoid tight coupling between the creator of the object and the concrete products. It follows the single responsibility principle by moving the object creation code to one place, ensuring that our object only has one responsibility. It also adheres to the open/closed principle, because it allows us to introduce new types into our code without breaking existing code.

📏 The Prototype Pattern

This a creational pattern that allows an object to clone itself. It‘s especially useful when creating a new instance of an object is expensive. Further, this method is useful because it allows all the properties and methods to be carried over when cloned, which is useful when subclassing is not practical.

You can give default values to the type which will be cloned and set these values after cloning. The prototype pattern is beneficial because it allows you to clone objects without coupling to their concrete classes, and complex objects may be created more conveniently.

1️⃣ The Singleton Pattern

Before exploring the world of singletons, I thought they were the greatest thing ever created. By creating a singleton, we ensure that a class has only one instance, allowing us to control access to some shared resource. It also provides a global access point to that instance.

Some benefits to this pattern are:

The singleton instance is created only when it is requested for the first time.
You gain access to the instance globally.

However, some drawbacks to this pattern are:

It is not very thread-safe.
It can be difficult to test.

In the snippet above, we create a class with a private initializer—private, because we only want there to be one instance of this class. We created the property shared which will be the only point of access to the instance of this class.

🩹 Dependency Injection

An alternative to the Singleton pattern would be dependency injection. As the name suggests, we are injecting our objects with the dependencies they need to function.

Injecting your objects with its dependencies has a major advantage because it makes our objects fully testable. The easiest example of this comes from mocking/stubbing our networking layer.

Constructor/Initializer Injection

In this method of injection, we pass the dependency on initialization of the class. We also will need to create a read-only property inside of the class which will store a reference to the initialized property.

Property Injection

We can use this property in cases where we do not have access to the object‘s initialization but we do have access to how the desired property is initialized.

In the below snippet of the iceCreamDetailedViewController we have a property name which is set when the mainViewController segues here.

Method Injection

Consider this method if you only want to use this property once. You can pass the dependency as a parameter of a method.

Ambient Context

This method should be used for universal dependencies that are being shared alongside multiple object instances, logging, and analytics of a caching mechanism. It should only be used sparingly, because it could cause implicit dependencies and global mutable state.

👋 That’s all, folks!

This concludes our three-part series on exploring design patterns in iOS development. If you missed the other two, or just want a refresher, go back and take a look at Understanding Structural Design Patterns and Understanding Behavioral Design Patterns for more.

Tooling at Home

mb bischoff — Wed, 01 Apr 2020 00:00:00 GMT

In the midst of the COVID-19 global pandemic, Lickability moved all its operations remote on March 10th. At this point, we’ve had a few weeks of working together remotely to figure out what works best for our little studio. While there are lots of great guides on how to work remote from companies like Notion, Zapier, and Slack, we thought share some of the specific tools we’re using to make this easier for our team. Hopefully, if you’re a newly remote employee or manager, you’ll see something here that can help smooth out a part of your workflow.

💬 Slack

I know it’s been said many times, many ways, but Slack is great for keeping us all on the same page when we’re spread out physically. We’ve made a few small changes to our Slack Workspace that help it do that even better.

New Statuses

Our fancy new statuses in Slack.

When we went remote, we changed the suggested status options for all of our employees in Slack to these 5 options. Now, with a quick glance in the sidebar, it‘s easy to see whether someone’s available to pair program or if they’re munching their lunch (which is, for some reason, always pancakes).

Google Calendar Integration

We’re big G Suite users at Lickability, and folks in different parts of the company have meetings at lots of different times with clients all over the world. Lots of us now use the Google Calendar Slack App to automatically set our status to “🗓In a meeting” when there’s an event on our Google Calendars. Never be stuck wondering why someone hasn’t responded to your message again.

🖥 Screen

We’ve long been looking for the perfect tool for remote pair programing, since Google Hangouts is far too laggy for our engineers’ tastes.

It turns out that the team behind our previous favorite, Screen Hero, recently left Slack and started working on a worthy successor. It’s called Screen and we’ve been using and loving the beta for a few weeks. Screen is the fastest screen sharing solution on the market, it works with multiple participants, and it even lets you drawn on or take control of the sharer’s screen if and when you need to. Plus, the team at Screen has been really receptive to our feedback and are improving the product every day. Try it out if you need to pair program at a safe social distance. It’s free while it’s in beta!

🎨 Scribble

Friends of the company Bridger Maxwell and May-Li Khoe have been churning out great updates to their fun, fast, and super useful shared whiteboard app, Scribble. Right now we’re using a company shared board to doodle on and make each other smile throughout the week, but we also plan to use this app (which has incredible support for the Apple pencil) for architecture meetings. With everyone in the office together, we used to stand around a physical whiteboard and diagram out solutions to technical problems—and now we have a great way to replicate that on our iPads.

🐙 GitHub for Mobile

I like the rainbow one.

Finally, our pal Ryan Nystrom and his team at GitHub just shipped the app we’ve been waiting nearly a decade for: GitHub for Mobile. With this on our home screen, it’s easy to triage our GitHub notifications, review pull requests, and even merge them right from our pocket computers. The app is an incredibly polished 1.0 and we can’t wait to see even more of GitHub’s many features incorporated into this beautiful product. Check out the custom icons if you want to dress it up a bit! GitHub Mobile is available now for iOS and Android.

I hope that tour of some of our newest tools was remotely helpful. 😉 What are some of the tools you or your team are using to stay connected while you’re out of the office? Let us know on Twitter at @lickability.

Understanding Behavioral Design Patterns

Ashli Rankin — Thu, 26 Mar 2020 00:00:00 GMT

Welcome back to our design patterns series. In the first part of this series, we discussed six structural design patterns. In this second installment, we will be looking at behavioral patterns. Behavioral patterns allow our objects to communicate with each other, whether it be one-to-one or many-to-one.

The Delegation Pattern

I remember when I first heard of a delegate, introduced to me as a way of allowing objects to communicate with one another. The initial obstacle I had when working with delegates was creating a distinction between delegates and protocols.

A protocol is a set of requirements that every type which conforms to it is expected to implement. A protocol contains declaration detail, not implementation details. Delegates are implemented using protocols and are useful because they establish a one-to-one method of communication between objects. (It should be noted that in situations where a single closure can be used to communicate changes to an object, delegates may be overkill.)

The Observer Pattern

Unlike delegation, this pattern allows our objects to communicate in a one-to-many relationship. Here are some of the observers used in iOS:

Notification Center

According to Apple, this native API is a mechanism that enables the broadcasting of information to registered observers. You should consider using this API if you have multiple objects that need to listen for the same change, without those objects having a direct connection to each other. It‘s also useful if that change has to be observed repeatedly.

There are a few downsides to using this pattern—for one, it is not very easy to track bugs. Unlike delegation, notifications and their observers have an indirect relationship. This can make it harder to track down where a notification is coming from or where it‘s being observed. Additionally, the object that sent the notification and the objects that listen for the changes must know about the notification name and userInfo. Further, there is no deterministic order to how objects listening to changes receive these notifications.

Key-Value Observers

With key-value observers, one type can observe the properties of another type to find out about changes to the observed type‘s state. These kinds of observers can provide an easy way for information to be synced between objects, and can provide an easy way for us to obtain a new value and the previous value of a property.

What’s next

This is by no means a complete list of behavioral patterns, but it‘s a good place to get started. In the third and final installment of this series, coming soon, we’ll take a look at creational patterns.

Testing Push Notifications in the iOS Simulator

Marc Aupont — Tue, 10 Mar 2020 00:00:00 GMT

With the release of Xcode 11.4, Apple has given us the ability to test push notifications in the simulator. Before this, testing push notifications required using a physical device and a lot of extra work. In this post, we are going to go over a few of the ways you can test push notifications on your simulator without ever having to involve an actual device, starting with the simplest path and looking at tools for more advanced uses toward the end.

Initial Setup

In order for any of this to work, you have to do some minor preparation. For starters, make sure you have Xcode 11.4 installed. At the time of writing this post, Xcode 11.4 beta 3 was recently released. Everything that I will display and test will be based on that version of Xcode. For more information on what’s available, check out the release notes here.

To begin, launch Xcode and create a new project called PushTest. It doesn’t matter if the project is based on SwiftUI or a storyboard, but I chose to use a storyboard for this example.

Once you have created the app, go to your AppDelegate.swift file. Here, we are going to add the lines of code needed to display notification alerts on our device. First, lets create our UNUserNotificationCenter object. Add this code to your didFinishLaunchingWithOptions method:

Swift

let notificationCenter = UNUserNotificationCenter.current()

This object was introduced in iOS 10 and is the central object for managing notification-related activities for our app.

Now we need one more line that requests authorization from the user to display our notifications:

Swift

notificationCenter.requestAuthorization(options: [.alert, .sound]) { granted, error in
  // handle permissions here
}

Our completed code will look like this:

Swift


func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    // Override point for customization after application launch.

    let notificationCenter = UNUserNotificationCenter.current()
    notificationCenter.requestAuthorization(options: [.alert, .sound]) { granted, error in
        // handle permissions here
    }

    return true
}

With that in place, we have everything we need to start displaying our notifications!

The Simplest Path

Xcode has provided us with some “drag and drop” functionality that should make testing a breeze! Essentially, you can drag an APNS file onto your simulator and trigger a notification that way. The hardest part about that whole process is creating a properly formatted APNS file. For a guide on creating the file, check out the Xcode 11.4 Beta 3 Simulator New Features. For the sake of speed, we are going to create the file using the nano editor, but feel free to create it in your text editor of choice.

Create an APNS file

First, launch the terminal and type the following command:

nano payload.apns

This will create a new file called payload.apns and launch the nano editor. Here are Apple‘s requirements for the file:

The file must be a JSON file with a valid Apple Push Notification Service payload, including the “aps” key. It must also contain a top-level “Simulator Target Bundle” with a string value that matches the target application‘s bundle identifier.

In the screenshot above, you can see that I’ve set my “Simulator Target bundle” to the bundle ID for my app, and set my “aps” key to a very basic payload. For more information on the necessary keys to create a payload, read here.

Once you have added the code above press CTRL x on your keyboard to exit the nano editor. When asked if you want to save your changes, press Y to proceed.

When prompted for the file name you would like to save-as, press enter to continue with the existing file name, which in our case is payload.apns.

🎉 That‘s it! We are now ready to test our remote notification. But first, in order to use this method, there are a few prerequisites:

You have run your app at least once and selected Allow for the push notification permissions.
You have minimized your app to the background—at the moment, we don’t have code in place that would display notifications while our app is in the foreground, so you‘ll need to go to the Home screen.

There you have it! With a simple drag and drop of the payload.apns file into the simulator, the notification alert displays.

Helpful Tools

Up to this point, we’ve been able to test this feature with very little work. The hardest part so far is making sure the formatting is correct for your payload.apns file. Once that is correct, testing a push notification is as simple as dragging the file onto your simulator. However, since the announcement of this feature, there have been a few tools created to help with this process.

Poes

One of those tools is called Poes. Poes is a Swift command-line tool that helps you send push notifications to the simulator. Once you have it installed, sending a push notification is as simple as typing the following command:

poes send com.marc.PushTest

The cool thing about this tool is that you no longer need to worry about trying to format your JSON payload. Via the command line arguments, you can provide the text and body of your push notification. In the gif above, you can see that I‘m just using the default values provided by Poes for the body and title of the push notification.

I really like the simplicity and ease-of-use of Poes. For more information, check out the creator Antoine van der Lee’s blog—especially his post about using it for push notification testing.

Control Room

Control Room is the Tesla of tools at the moment, in my humble opinion. Control Room is a macOS app written by Paul Hudson that lets you control the UI appearance, status bar configuration, and more for iOS, tvOS, and watchOS simulators. It wraps Apple’s own simctl command-line tool, so you’ll need Xcode installed. The thing about this tool is that it serves multiple purposes, while also providing a notification editor that lets you build your notification payload.

To use Control Room, clone the GitHub repo to your PC and run the Xcode project. If you already have a simulator running, you can use the Default option to run your tests. Simply select your application‘s bundle identifier in the list of options and press the “Send Push Notification” button.

As you can see above, it’s really easy to send notifications using Control Room. If you press the “Open Notification Editor” button, you can customize your notifications further, including providing data for rich notifications. While these are all items you could do with Apple’s simctl command-line tool, Control Room allows you to do all of it in a GUI editor.

TL;DR

In this post, we created a basic project that we used to test remote notifications. We looked at the simplest path, which involved dragging an apns file onto our simulator without having to install any dependencies or use separate tools. This method works very well for quickly testing and does not require any specific tools or versions of macOS.

On the other hand, we also discussed Poes and Control Room as alternative tools for testing. Both of these tools are written in Swift which is another plus. Poes is a command-line tool that lets you send a push notification in one line via the terminal, and Control Room is a macOS app that lets you control your simulator in various ways while also doing things like sending a remote notification. In general, I really like this new feature in Xcode, and it can be used in all sorts of different scenarios.

A Lawyer and an Accountant

mb bischoff — Wed, 15 Jan 2020 00:00:00 GMT

Starting Lickability 10 years ago was relatively simple on paper. As 19-year-olds, Brian and I hopped on LegalZoom, filled out some form fields, and presto—our company was born. If you’re thinking of starting a company today, tools like Stripe Atlas make it even easier. But at a certain point of seriousness and profitability, you can’t get away with outsourcing all of your corporate administration to a robot.

Once your company is off the ground, there comes a point when you need to hire professionals to help manage the bureaucratic mazes of contracts and taxes. Today, I’m going to tell you about the two most important professionals to hire, how to do it, and the folks we recommend working with in case you need a referral. 😉

Hire a Lawyer

Software is complex. As developers, it’s our job to wrangle that complexity and present something easily understandable to our customers so they can get their job done. A good lawyer will do that for you with a similarly byzantine system: the law. As Emily Croy Barker pointed out in her New York Times opinion piece in 2013, it’s not absurd to think of lawyers like wizards. She writes, “In the end, magic is another form of power, and lawyers understand power. That’s what they do. The law regulates the powers of different parties — of the state, of private individuals and of corporate bodies — and a lawyer’s task is to find ways to enhance, exploit or rein in those powers.”

Before Lickability had a lawyer, we were piecing our contracts together from Google searches, boilerplate template libraries, and favors from friends who were smart enough to have already hired a lawyer. That all changed when we watched this now-famous Creative Mornings talk by Mike Monteiro, one of the founders of Mule Design in San Francisco. In the talk, Mike appears with his lawyer (and friend) to answer questions from the crowd about how to get paid for their creative work. Mike says that he loves his lawyer because he saves them money. This was a lightbulb moment for us years ago. We always thought of lawyers as a costly expense, rather than an investment in the company’s bottom line.

If you have a great lawyer that understands software, I’d love a recommendation. Mentions and DMs work. Thanks!

— mb Bischoff (@mb) July 31, 2015

After that, we asked Twitter for recommendations, had a few initial conversations, and eventually hired Greg and his firm Mavronicolas Law Group via our pal Kyle Bragger. Over the last five years, Greg and his team have helped us negotiate dozens of contracts, filed our trademarks, and kept an eye out for our interests in many ways throughout the years. We all sleep better and do better because of their partnership. As soon as your company starts facing even minor contractual or legal questions, invest in a great lawyer. It’ll pay off in spades.

Hire an Accountant

With the contractual out of the way, let’s discuss the financial. As your company starts to make some cash, you’ll need to maintain your books, file, and pay your taxes. If you’re like Lickability, with founders living in multiple states and clients all over the US, this can get complicated really fast.

We went through a number of accountants before settling on the one that makes the most sense for us. Andrew Carroll (aka CFO Andrew) was recommended to us by friend of the company, Sam Soffes. What’s different about Andrew’s model is that he isn’t just there for you at tax time; he partners with freelancers and companies year-round.

Andrew has taught us a lot over the years: the difference between accrual and cash based accounting, passthrough income vs. C corporations, and how much cash we should keep in the bank to run the business. And because he’s also a financial advisor, we can ping him in his Slack with random personal or corporate finance questions whenever they strike throughout the year.

If your company is already making a profit, it’s time to hire an accountant. You’ll be glad you did when they help save you money with tax credits, deductions, and avoiding fees by filing correctly and on time.

Bonus: Hire an Ops Person

If you’re at the size where you’ve already got a lawyer and accountant you love, consider all the administrative and operational stuff you deal with every week that makes it harder for you to run the company. If it’s enough work that it’s bugging you, it might be worth talking to someone who‘s really good at dealing with operational and administrative tasks. Before we hired our own Operations Associate, we worked part-time with the wonderful and hyper-organized Kathy Campbell. Give her a ring, and she’ll sort out all your admin.

Conclusion

Your job as a founder or CEO is to run your company and make your customers happy, not to do every little thing by yourself. Work with the pros who will save you time and make you money. Hire a lawyer, hire an accountant, and (if you’ve got room in the budget) get some help with your operations. Trust me, you‘ll be glad you did.

Our Favorite Apps of 2019

Team Lickability — Wed, 08 Jan 2020 00:00:00 GMT

We haven‘t shared our favorite apps with you in a while, so as we begin the new year, this feels like a good time to give a shout-out to a few of our recent favorites from 2019. Some of these apps were new to the App Store last year, and some were just new to us, but all of them are fantastic.

✈️ Flighty

Friend of Lickability Ryan Jones and his team released Flighty this year, and it is hands down one of the best apps for frequent fliers. The best push notifications in the business, delay forecasting, and a design that feels pro and fits perfectly on iOS. If you fly more than a few times of year, get Flighty. You can thank me when you get to your destination.

– mb Bischoff

🤖 Apollo for Reddit

Apollo is my most used app and my go-to when I want to get info on breaking news, keep tabs on the communities I care about, or just browse some dank memes. I really enjoy the user experience and it is my preferred way to view and interact with reddit content. The developer Christian frequently interacts with the community and is constantly releasing updates and new features. I started with Apollo Pro and upgraded to Apollo Ultra this year to unlock some cool features and support the ongoing development.

– Tom DeVuono

📖 We Read Too

My wife and I regularly use We Read Too to find new books for my son to read, and it helps a lot with discovery. Plus, it‘s written by Kaya Thomas, who is also awesome!

– Marc Aupont

🃏 Card of Darkness

Card of Darkness launched with Apple Arcade, and despite the deluge of quality iOS games hitting the service simultaneously, I couldn’t shift my focus away from finishing every last level. The rules and mechanics are simple enough to pick up right away, but become difficult enough to stay interesting throughout. And the art. THE ART. Pendleton Ward’s involvement had me hooked from the very beginning.

– Michael Liberatore

🎵 Sayonara Wild Hearts

Sayonara Wild Hearts, available via Apple Arcade, is a music album and a rhythm video game in one. I really enjoy the music, and I love rhythm games, so it‘s perfect for me. Plus, it’s very queer and the art style is pleasing to me.

– Michael Amundsen

🧠 Youper

2019 was the year I got really into mood tracking, both as a way to journal and to check in on my mental health on a regular basis. Youper has made a big difference in the way I recognize and process my emotions, and it‘s become an essential part of my daily routine. Every day, I tell the app how I’m feeling and what external factors are contributing to my mood, and it helps me walk through why I might be feeling the way I’m feeling.

– Jillian Meehan

A New(er) Look for The Atlantic

Brian Capps — Wed, 11 Dec 2019 00:00:00 GMT

Everyone loves receiving a good grade. Seeing a giant, red “A” at the top of an assignment is such a great feeling—in fact, that‘s the same grade we would give The Atlantic on the new look they debuted a few weeks ago. They redesigned their brand from top to bottom—with a bold, red “A” logo to match—and in the process took a whole new look at how they approach news on mobile. Naturally, we jumped at the chance to help them build it.

The Atlantic 6.0 may seem a bit familiar to users of the previous version—the general structure is similar, but it also includes some huge changes. The most vital update is on the very first screen, which has a completely new Today tab: a guide to the stories that matter each day, with thoughts and articles curated by a team of mobile-specific editors. It is a confident and unique approach to presenting the day‘s news, focused specifically on readers with devices in their pockets. This shift coincided with a full rebranding of The Atlantic, with new fonts, icons, colors, story presentations, article layouts, and account management, among just some of the updates.

We built The Atlantic to feel right at home on iOS 13. With the design team at The Atlantic, we worked to make every screen look great in dark mode, including dark variants for images on story lists. If you‘ve logged into The Atlantic on Safari, we auto-fill your information when logging into the app with iCloud Keychain. Articles should load faster and saving your position within them should be more reliable. And, for our fellow nerds: under the hood we’re even making use of Apple‘s all-new compositional layouts and diffable data sources in addition to standardAppearance to provide a solid foundation for future work. (Want some help making sense of them all? Get in touch!)

Screenshots of the new Atlantic app

We also fundamentally believe that people of all abilities should have the opportunity to comfortably use the software we build, especially when it comes to journalism. The Atlantic made accessibility a priority on this project, and we worked hard to make the iOS app completely accessible, from full VoiceOver and Voice Control support to thoughtful support for Smart Invert preserving image colors. We checked every color in the app through Apple‘s accessibility tool to make sure the colors included in the app contrast each other for maximum legibility, and we included both system and in-app control for dynamic type sizes.

It was a pleasure working with our friends at The Atlantic once again on this project. We are so proud of the new release, and it was only possible due to their strong vision and smart decisions about where the company is headed. We were able to move quickly, work with the latest technologies, and make an app that looks and functions in a modern way, thanks to their team of smart and kind people. The Atlantic has a whole new look, but more importantly it has a new approach to news on mobile, and we hope that you love it as much as we do.

Download the app today to see it all in action!

Understanding Structural Design Patterns

Ashli Rankin — Fri, 06 Dec 2019 00:00:00 GMT

If you are like me and have a year or less of experience developing iOS apps, there might be some concepts that you use in code without realizing what they are or why you‘ve used them—I’m talking about design patterns. These patterns allow our app‘s codebase to be more readable and resilient, help guide us when structuring our apps, and allow us to create objects and govern how those objects communicate with each other. Chances are, you’ve used many of these patterns without realizing it—like MVC, MVVM, Singleton, and Observer.

Design patterns are quite powerful if you know what to use and when to use it. I set out on a journey to explore some of the various design patterns used in iOS development and gain a better understanding of them.

This is the first of a three-part series on design patterns. In this installment, we will be looking at structural patterns. Structural patterns allow us to more easily design the relationships of our application components. Below, we‘ll take a look at six structural patterns, with a code example for each one. Let’s dive in together!

🔌 The Adapter Pattern

This pattern is similar to using adapters in our daily life—for example, if you want to connect a USB-A cable to a USB-C port, you need an adapter to change the connector type of the USB-A cable into one the USB-C port can recognize. Similarly, we can use the adapter pattern to allow incompatible interfaces to communicate with each other. We can also use it when working with third-party libraries that are incompatible with our existing code.

The adapter pattern is beneficial because it abstracts business logic to make our interfaces work together more seamlessly, and allows for the ability to introduce new kinds of adapters without breaking existing code. The drawback, however, is that it increases code complexity by introducing a set of new interfaces and classes.

🖌 The Decorator Pattern

This pattern allows us to add functionality to an object without changing its fundamental components. It‘s like getting dressed—we change our outfits daily, but these changes have no effect on our composition as humans.

The decorator pattern allows us to extend the behavior of objects without making a new subclass. Further, we can divide a large class that implements many behaviors into several smaller ones.

🎂 The Facade Pattern

I think of the facade pattern as a bakery: so many things happen behind the scenes at a bakery, but when a customer comes in, they only see the beautifully designed pastries and cakes.

This pattern is designed to provide a simplified interface to a complex subsystem. It‘s like Paul Hudson says in his book Swift Design Patterns:

A Good Facade: - Makes complex APIs easier to read, understand, and use, because their complexity is wrapped up in simpler methods. - Reduces dependencies on the internals of those APIs, which allows you to change them freely as long as the end result does the same job. - Lets you wrap a bad architecture in something that works better based on experience, or a complex architecture in something simpler that does the job for most people.
Paul Hudson

🎨 Model View Controller

This is the first pattern I learned when I started iOS development. It involves separating app components into models, views, and controllers.

Models are a representation of our underlying data, containing all the properties and methods which define a type of object; views are responsible for displaying information from the controller; and the controller is responsible for mediating views and models. When the user interacts with a view, the controller interprets this information and alerts the model to update accordingly.

While using this pattern, I‘ve run into things in my applications that fall into a grey area, like networking logic—where would that go? Once you start asking yourself questions like that, you should consider reaching for another design pattern.

Below is an example of the MVC pattern in action. We have our model, which represents an IceCream; our controller, containing an array of ice cream flavors; and our view, which takes the information given by the controller and displays it.

🖼 Model-View-ViewModel (MVVM)

One limitation to the MVC pattern is that controllers can get quite large—often jokingly called “Massive View Controller.” This occurs because when we have responsibilities that don‘t fall into our model, view, or controller, they tend to end up in our view controller.

The MVVM pattern has been proposed as an alternative, encapsulating our components into models, views, and view models. Like with MVC, models are our data representations; views can be our UIViewController and our UIView subclasses; and view models are used to transform data from our model into a form that can be used by our views.

👩‍🎨 Model-View-ViewModel-Controller (MVVMC)

We employ the MVVMC pattern heavily at Lickability. Before I started, I was unfamiliar with this pattern, but after using it for a few months I have found it to be quite helpful when structuring my applications. I‘ve noticed three major differences between this pattern and MVC: improved code encapsulation, improved code readability, and smaller controllers as a result of removing some presentation logic.

When I used to use the MVC pattern, I found myself exposing view objects in order to configure them, not yet aware of the dangers of doing so (like outside entities being able to change the content displayed on these objects). With the MVVMC pattern, each view has its own view model encapsulating the data needed to populate the view, and is the single point of configuration of this view. By doing this, our objects no longer need to have an internal level.

🔮 What‘s next

Whew! That was a lot. But this just covers a small selection of all the design patterns out there. In future blog posts, we‘ll take a look at a few other types of design patterns: behavioral patterns, and creational patterns. Stay tuned!

How Our Engineers Collaborate

Michael Liberatore — Tue, 26 Nov 2019 00:00:00 GMT

Collectively, the engineers at Lickability have worked with dozens of iOS development teams, shipping countless features, new products, redesigns, and Swift rewrites. Ten years in, our processes have evolved into a well-oiled machine with collaboration at the core of our day-to-day engineering. Whether we’re augmenting a client’s existing iOS team or acting as the sole developers, and whether we’re building a social network, news reader, or game, our approach to collaborating on code remains largely the same. We find it important to follow a few key guidelines on every product we help ship, and would like to share them with you.

The 30 Minute Rule

Have you ever been stuck trying to fix a bug that seemed extremely straightforward? Have you ever been knee-deep into a new feature, only to find that something just isn’t working correctly and you’re not sure why? Have you ever felt paralyzed while trying to architect a large feature or refactor, spinning your wheels because you’re not sure if you’re making the right decisions? Of course you have! We’ve all been there, and we’ll be there again. In situations like this, we reach for the 30 Minute Rule.

Have you spent 30 minutes trying to solve the problem with no visible progress, and are you able to describe what you’ve tried and what happened? If the answer is yes, then it’s time to ask a teammate for help. If you keep spinning your wheels for hours and hours, you might be wasting your own time. If you haven’t done your 30 minutes of due diligence before reaching out to others, you might be prematurely interrupting and wasting their time. Our magic number is 30, but feel free to experiment and see what works best for your team.

Frequently asking for help might be hard at first, especially if you’re on a team that hasn’t established a pattern of assisting each other in this way. It can be extremely difficult to fight through self-doubt or imposter syndrome and admit that you can’t proceed quickly without aid. I know. I’ve been there. It’s not just you. But asking someone for help doesn’t make you less-than. After all, you’re a team working toward the same goal, not competing against one another.

Be sure to pay it forward when you can, and reach out to others when they appear halted. It might be that one weird UIKit issue that you know exactly how to work around. They might just need to talk through their approach to make sure it’s not too off-the-wall. Or they might find comfort in the fact that there’s not an obvious, simple solution, and it’s not just them. Once your teammates become comfortable asking for help and assisting each other regularly, productivity will soar and you’ll be shipping with confidence.

Talk Before You Code

Sure, sometimes you can just sit down in front of your computer, read a feature or bug description, and hit the ground running. But for larger or more complicated tasks, it can be invaluable to discuss your path forward with another member of your team. Whether or not you prefer to pair program, talking over architecture, or proposing a solution on a whiteboard before you write a line of code can help to shake out any uncertainties, expose previously unconsidered cases, and give your team the opportunity to weigh in and reduce complexity long before opening a pull request.

You might worry that others on your team don’t have enough context to help at this stage. After all, only you have dug deep into this problem. Ignore those thoughts! Like you, the engineers on your team have diverse experience and have likely helped solve similar problems in the past. Just prepare your thoughts, quickly bring them up to speed about the task, and summarize your approach. At Lickability, we do this All. The. Time. And most of us aren’t even working on the same project! Keep things high level at this stage, and your fellow engineers should be able to help you out.

Make Your Work Easy to Review

Code review is an extremely important part of working on a software team. It provides the opportunity for feedback, collaboration, and an early line of defense against issues entering your shipping software. Some find that code review is a chore, but it doesn’t have to be.

Small Pull Requests

Long running branches are a recipe for disaster and conflicts, full-stop. Many teams don’t need to be sold on the benefits of continuous integration, and with modern tools like fastlane and Bitrise, a lot of the boilerplate work can easily be automated. But no software is going to force you to integrate early and often, and no one wants to review your 10,000 line pull request. Have you ever submitted a gigantic pull request and received one comment, “LGTM”? This is not the feedback you want. Have you ever submitted a gigantic pull request and it just sat there, rotting at the bottom of the PR list, surrounded by other large pull requests that were also increasing in the number of conflicts with main? This is surprisingly common, and we try to do everything we can to prevent it.

Now, have you ever fixed a small bug, or introduced a small new feature, and received 16 comments with helpful suggestions? It’s not a coincidence that the size of the pull request produced different results from your peers.

The optimal pull request size will differ for every team, but at Lickability, we encourage engineers to keep them small (500 lines changed or less), and to the point. Sure, sometimes they end up slightly larger, but we try to minimize that by following these guidelines:

Don’t fix 8 bugs in one pull request. Fix 1.
Keep things that generate a lot of noise in code review, like pod updates and adding assets, in their own, separate pull requests that precede the work that requires them.
If you’re working on a large feature, break it up into many small chunks, and submit your work whenever you complete one. Use any form of feature flagging to integrate these chunks while preventing the exposure of incomplete features to users.
Try not to go more than a day or two before putting your work up for review. Just because your changes are small doesn’t mean they weren’t difficult or time consuming to produce. The earlier you receive feedback, the less married to that solution you’ll be. It can be hard to accept criticism on something you’ve poured a ton of time into.

You’ll be surprised how much more meaningful your code reviews will be when your pull requests are small and numerous. Someone can review and fully understand your work in the few minutes before a meeting instead of needing to set aside an afternoon of head scratching.

Explain Your Work

I could go on for hours about the value of documenting your code, but even when code is properly documented, it can be difficult to wrap your head around why a change is being introduced, or how it impacts the user experience. We rely heavily on pull request templates to ensure engineers provide enough information to ensure a speedy and easy review. (You can find ours here.)

Whether or not you use a template, we believe a pull request description should contain:

A link to the issue or task in your issue tracking system so that the reviewer can understand why the change is being proposed.
A short summary of the approach taken to fix the issue or implement the feature.
Detailed steps on how to test the change. This will help the reviewer test the feature themselves if they choose to, but also give them the opportunity to see how you tested the feature, and suggest any gaps or edge cases you might’ve missed.
A screenshot, gif, or video of the change in action, if it has an effect on the user experience.

Here are a few examples from our open-source library PinpointKit.

Teamwork == Dreamwork

If you’ve been writing software for a while, and prefer to work alone, or have been affected by any of the problems discussed here, I encourage you to give some of these guidelines a shot. You don’t have to go all in at once and completely change your workflows. You don’t need the world’s most advanced server-configurable feature flagging system to get started with small PRs. And most of all, you have no reason to feel badly or inadequate if you ask for help. If you’re fortunate enough to work with a team of talented engineers, make the most of it. You and your teammates can do amazing things together.

Our New Blog

Jillian Meehan — Wed, 20 Nov 2019 00:00:00 GMT

Notice anything different? Welcome to the brand new Lickability blog! In the past two months, we took a bit of a break from publishing new posts while we moved all of our content over to our website from Medium. From now on, all of our new blog posts will live here, on Lickability.com.

What we did

I’ll give you the TL;DR version of what we did. We downloaded our archive from Medium and used Brian Donohue‘s script to convert those posts to Jekyll posts that we could use on our website. We spent some time making everything look nice, added blog topics like Engineering and How We Work and What‘s New, and used the jekyll-redirect-from plugin to redirect all of our old blog links to the new ones. Then, we set up Siteleaf—a CMS that was “built for developers”—for editing and publishing new blog posts, like this one.

Why we did it

Medium announced a few years ago that they were deprecating support for custom domains, like ours. Since then, we’ve been thinking about moving our blog so we can have more control over our content.

Medium fit our needs for a long time, but it was time for a change. As we continue to put more energy into our blog and publish more posts, it felt natural to move away from Medium. We want our blog to feel more like us, and making space for it on our own website goes a long way toward achieving that.

If you’ve been reading our blog for a while, thank you! And if you’re new around here, welcome. We have a bunch of blog posts ready for you—we hope you like them. 😊

Conference Condensed: XOXO 2019

Team Lickability — Sun, 29 Sep 2019 00:00:00 GMT

At the beginning of this month, mb and Jillian went to Portland for another year of XOXO, the “experimental festival for independent artists” that we look forward to every year. It was, predictably, fantastic. We could keep this blog post short and tell you to just go, but in case you need some more convincing, we each wrote about some of our favorite parts from this year’s XOXO.

Social

As the Andys reminded us on the first day of the festival, Social started as a happy accident in the first year of the conference and has only grown in importance since then. A day of socializing with other attendees of self-organized meetups all over SE Portland, it’s one of the best parts of the weekend. While Jillian was on her way to the city, I debated between a packed schedule of meetups with thoughtful conscientious nerds. Starting at the #enby meetup at Upper Left Roasters, I met up with a bunch of other well-dressed nonbinary folks who effortlessly used each others pronouns (speaking of which, XOXO’s adorable pronouns pins are now on sale). After that, I headed over to the Glitch Appy Hour where I drank some LaCroix and saw an incredible demo from Christopher Swenson who ported a ’90s multiplayer BBS game to Glitch! At 6 PM I met some more LGBTQ+ tech and art folks at the #queer meetup, held at Crush. The #cocktails nerds came together for a toast at the brand new bar Scotch Lodge. And finally, Jillian found me at the Panic Playdate Party back on the lawn at Revolution Hall where we got to get our hands on the much-anticipated console from our favorite Mac software company.

The meetups I attended as part of XOXO Social just scratched the surface of what the festival has to offer. There were also meetups for fans of #language, #visual-art, #game-making, #zines, and so much more. But, I was so glad I got to meet so many incredible folks and see old friends before jumping into the conference proper. People like Laser Malena-Webber of The Doubleclicks, Isaac Grant (the CEO of Silverorange), my good pal Allen Pike from Steamclock Software, and Neven Mrgan and Cabel Sasser plus more of the team behind Playdate.

An art installation outside the XOXO venue

Arcade

Jillian

As much as I love the conference talks, the live shows, and allllllll the socializing at XOXO, I always find myself gravitating toward the Arcade tent and its live video game demos the most. Maybe because it’s slightly removed from the rest of the action and acts as a nice respite from everything when my energy is a bit low. Maybe because I find it somewhat soothing to be around people who are playing games. Or maybe it’s simply because the games that are showcased are always just really cool and fun. Whatever the reason, Arcade is generally my favorite part of XOXO, and this year was no exception.

A few of the games that especially caught my eye this year were Calico, an extremely cute and cozy cat cafe simulator; The Wild at Heart, a beautiful, magical action-adventure game; and Garden Story, a fruit-themed RPG that I cannot stop thinking about. And, although not technically part of the Arcade showcase, I can’t not mention the Playdate here as well — it’s very good, folks.

Conference

I look forward to the Conference section of XOXO all year long. Its presenters are thoughtfully selected from suggestions made by the community and represent a diverse set of perspectives and mediums. This year’s conference was hosted by podcasters Helen Zaltzman and Hrishikesh Hirway and included talks from incredible creators, writers, artists, musicians, and comedians. Here are a few of my favorites and the themes I saw emerge this year. In their talks, Lindsay Ellis, Emily & Amelia Nagoski, and Jenny Odell touched on themes of burn out, empathy, and how we can disconnect from the parts of the internet that are hurting us and connect with communities that support us through hard times online. As the Nagoski sisters said in the summary of their new book: “the cure for burnout is not self care; it’s all of us caring for each other.”

Other speakers like Nat Puff (aka Left at London), Black Belt Eagle Scout, and Soleil Ho asked us to consider different sides of the questions of representation, marginalization, and what happens when you become the representation you’ve been fighting for. Their talks were great reminders that seeing people like you making things on the internet, makes a huge difference to young and up-coming creative people. And that once we have that representation, we must maintain that power and find a way to remain who we are. As Soleil put it: “we are the grease in each other’s engines.”

Jillian and mb fawning over the Playdate. Photo by Kate Sloan.

Video & Story

Jillian

Every year, XOXO does us the great service of taking some of the best video and podcast creators and putting them on a stage to show us their latest work. Whether that’s a new video they haven’t shared online yet or a live podcast taping, it’s always a blast. Video and Story, to me, really encapsulate what XOXO is all about: engaging with and celebrating the things people make in a friendly, intimate environment — it’s like Twitter, but good.

This year, I particularly enjoyed watching new videos from the Nerdwriter, and Unraveled. The Allusionist did a fantastic live show about gender and the confusion of titles. And Punch Up the Jam stole the show with a hilarious episode about Ghostbusters, Demi’s last episode of the podcast that I’m extremely glad we got to witness.

Conference Condensed: try! Swift 2019

Team Lickability — Mon, 23 Sep 2019 00:00:00 GMT

If you’re in the NYC iOS community and you aren’t following try! Swift, what are you even doing? It’s one of our favorite iOS conferences, especially for folks who are new to Swift. This year, as we did last year, we sponsored a diversity ticket and sent a few volunteers from Lickability to attend. Plus, our very own Marc Aupont gave his first conference talk ever, and it was a hit. Here are a few more of our favorite memories from try! Swift 2019:

😱 SwiftUI in 25 Minutes

Try! Swift was my first conference ever, and I was not disappointed. One of the highlights would have to be Paul Hudson’s “SwiftUI in 25 minutes” talk. I had never seen Paul speak, but I have used his Swift guides extensively. If I could only use one word to describe this talk, it would be thrilling. It was, in my opinion, the greatest sales pitch of all time. He reintroduced us to a product that could make our lives as developers significantly better, and demonstrated how robust the framework is by implementing various features that common applications have, like table views and scroll views. I was sold the moment I saw how easy it is to work with animations. As a plus, he showed us how to make your app cross-platform using SwiftUI — it was as simple as clicking a button. Watching this talk ignited the same fire I felt when SwiftUI was unveiled at WWDC 2019. What an amazing time to be a developer! And as if that wasn’t enough, Paul even gave us a gift: SwiftUI By Example, a 242-page PDF. I can now confidently say my life is complete.

– Ashli Rankin

💸 App Subscriptions — The Good, The Bad, and The Ugly

One of my favorite parts of try! Swift each year is the type of talk that poses an interesting question for me to think about and look into more after the conference is over. Ish Shabazz’s talk about subscriptions was a great example of this. During the talk, he went through the various models developers can use to generate revenue for their apps — payment upfront, ads, free, in-app purchases, subscriptions — and the various pros and cons to each model. He also compared the various revenue models against overall lifetime cost of developing and maintaining your app. Naturally, subscriptions have a lot of pros to them, and generally are the best option for offsetting long term costs of an app. So here’s a summary of the good, the bad, and the ugly parts of subscriptions:

The Good

Recurring revenue
More profit after the first year
Future updates are funded
Offers, promos, and free trials

The Bad

Tricky to implement and test
Schools may not be able to buy them and no family sharing
A lot of users really don’t like them

The Ugly

Can be difficult to cancel
Subscription management is confusing and luckily better in iOS 13
No refunds

What really struck me was how, over time, most revenue models do not help pay for development, and users want free updates for life. It sounds kind of obvious, but Ish’s talk has stuck with me as an interesting challenge we face as developers. How will we adapt to help value the time and effort that goes into software development?

– Michael Amundsen

🌟 Swift Without Screens — Powering Connected Devices

Try! Swift is definitely one of my favorite conferences to attend. The participants are amazingly friendly, and the variety of talks and speakers is great. In 2017, I was fortunate enough to receive a diversity scholarship to attend for the first time. During that time, I met Jazbo, one of that year’s hosts, and we became good friends. I was very much inspired by him, because I had never seen a person of color on stage at a tech conference. I found out that he was a diversity scholarship recipient the year before, and had convinced his company to offer two more diversity scholarships to try! Swift. That very moment, I knew I wanted to follow in his footsteps someday.

Fast forward a couple of years later — I gave my first conference talk at try! Swift this year while working for a company that sponsored a diversity ticket! I was also fortunate enough to host a workshop where we built a small electronic circuit and controlled it via Swift and Raspberry Pi.

– Marc Aupont

📱 Swift UI for Production

I really enjoyed the Swift UI for Production talk by Lea Marolt. I was extremely excited about Swift UI when it was announced at WWDC19, but because of the multitude of breaking changes, I had slightly fallen out of love with it. Lea’s talk demonstrated the successes and challenges faced while building a SwiftUI app for production at RayWenderlich.com. She compared SwiftUI vs UIKit and went through concrete examples of components they built.

– Marc Aupont

This is just a small selection of the many informative, thoughtful talks and workshops featured during the two days of try! Swift. If you didn’t get a chance to attend this year, we hope you’ll consider going next year. And if you see us there, don’t forget to say hi! 👋

What I learned as an iOS Apprentice

Ashli Rankin — Tue, 17 Sep 2019 00:00:00 GMT

There is a saying that goes, “It is not about the destination, but the journey.” This is certainly true — it does the mind good to reflect on the experiences encountered on the way to your chosen destination. My journey into and through the tech world has been a rollercoaster, but I believe that learning from other people’s experiences has anchored me in my desire to work in tech as a young, determined woman forging a name for herself in this field. So here is a gift from me to those of you who are on a similar journey.

My name is Ashli Rankin, and I am an iOS Apprentice here at Lickability. Before this, I was part of a 10-month intensive software development program called Pursuit, which gave me the skills to land my first job in tech.

This apprenticeship has been one of the most challenging yet rewarding experiences of my life. It has been challenging to try to solve problems with the knowledge I have already acquired, and to acquire and hone new skills along the way. It has been rewarding to watch my coding skills improve, to learn how to make more conscious decisions in my work, and to see how truly beneficial working with an awesome team can be. I am now well over halfway through the process, and I want to take time to reflect on the experience and share my reflections with you.

💬 Don’t be afraid to ask questions

Early on in my apprenticeship, I was afraid to ask questions because I didn’t want to look like I had no clue what I was doing. Now, I remind myself that it’s common for new developers to feel that way, and I force myself to ask the question anyway. It is better to have tried and failed than to not try at all. Asking questions also improves your productivity — why let a problem stump you for days when you could save time by asking for help? By asking questions, you also gain valuable insights into how other people solve problems, which is always a good thing. So ask away!

📈 Keep improving

One of my favorite life mantras is, “Keep striving for better.” No matter how many times I fail, I always reassess the situation and try to find a way to do better. There is always room for improvement, but it takes consistency and a desire to be better than the person you were yesterday. That said, owning your accomplishments is important too. I have a hard time recognizing my accomplishments because of my belief that I could always do better — but if I am always chasing the idea of perfection, when will I reach the finish line? Taking small steps to reflect on each pull request and project I have worked on has helped me tremendously to value the work I am doing, thus providing the push I need to do better. At the end of each week, I look through all of the issues I’ve resolved, review the changes I made, and note the reasons behind each change. By doing this, I save valuable time by consciously reminding myself to avoid making the same mistakes over and over, being mindful of best practices, and asking my teammates questions so I can continue to learn.

💡 Have confidence in your abilities

The desire to keep improving can result in increased levels of confidence. With this confidence, it is important to believe in yourself and stand by your choices. Sometimes, when writing code, I’ve been asked about why I made certain decisions. At the beginning of my apprenticeship, I wasn’t always confident enough to answer those questions. That has been a teaching moment for me — I learned to defend my choices, because I made them for a reason. I started using a method that I call “conscious coding.” This entails asking yourself questions: What am I trying to do? Is the code I’m writing affected by other parts of the application? What depends on this code? If I can answer questions like these, I am more equipped to answer questions that may arise on my pull requests, and more confident in my work overall.

🙌 Trust the process

I used to get extremely frustrated when I tried something new and it didn’t work. It took a while for me to accept the rarity of getting something right on the first try — it’s only through practice that I can get better at something. Ultimately, I’ve learned to trust the process. My first time implementing OAuth, I looked for tutorials where people attempted to use the same API I was trying to use. However, no one seemed to be using the APIs from the company that I needed data from. I looked for tutorials explaining the process of OAuth 2.0, which was somewhat helpful — I was one step closer to cracking the puzzle, but I still was not able to authenticate my user. I went home and kept trying. Eventually, at 1:45 am, I had to ask myself some deep questions: What are you doing? What are you trying to do? Do you think stressing yourself out will magically solve this?

And then, I answered myself: You need to pace yourself. Break this problem into smaller executable parts, and you will see how easy it can become. The next day, I went to work with a renewed attitude toward the project, and it only took me another day to complete both the authentication and authorization areas of OAuth2.0. All I needed to do was trust the process and take my time. Remember: everything happens in its own time and for a reason.

🧠 Take care of yourself

If you had the year I’ve had, you would understand why this journey is so important to me. I put my all into a 10-month intensive program with many sleepless nights and very few breaks, coupled with working 11-hour shifts on the weekends. In the midst of it all, I never took the time to check in with myself to make sure I was okay. Despite my packed schedule, I enjoyed working hard, because it gave me a sense of accomplishment. I was surviving on the passion for creating apps and learning as much as I could. At the time, I didn’t feel like I was burned out — but I definitely felt it when I completed the program.

When I began my apprenticeship, there were days when I left work with the intention of working on a new project at night. I would get home, start it, and…bam! One hour in, I was asleep. After a week of this, I realized that my body was trying to send me a message to take better care of myself. I didn’t know where to start, so I asked my teammate Jillian for help, and she gave me the most solid piece of advice I had heard in a while: take things slow, be consistent, and don’t overwhelm yourself. Since then, I’ve taken her advice to heart. I am now slowing down and taking small steps to look after myself. My wellness and wellbeing became a focus of my consciousness. I began taking time during my commute to read and listen to music that makes me feel good — I’ve found that it really helps to calm any feelings of anxiety. What works for someone else might be different, but the important thing is bringing self care into the equation. If you feel good about yourself, world order is restored.

I hope my words will give you some encouragement. While we all struggle with the obstacles life throws at us, the way we deal with those deterrents determines how we progress in life. Once you get over those hurdles, you may realize that the journey wasn’t so bad after all. The key to remaining positive and upbeat in the workplace is to love what you are doing — I love what I do, and I enjoy what I do. If you find that contentment, as I have done, you can conquer the world of tech.

Conference Condensed: AnxietyTech

Team Lickability — Tue, 03 Sep 2019 00:00:00 GMT

A few weeks ago, we had the pleasure of checking out AnxietyTech, an NYC conference that explores mental health and self care in the tech industry. We had a great time and learned a lot, and it’s definitely on our list of favorite tech conferences to attend. Here are a few of our favorite talks from the day:

🧠 How To Hack Our Brains Into Better Health

Dr. Jud. Brewer

The day started out with a fascinating Keynote presentation by Dr. Jud Brewer, the Director of Research and Innovation at the Mindfulness Center at Brown University. Dr. Jud spoke about his research on how to combat the rising tide of clinical anxiety. Having looked into the research on anti-anxiety medication, willpower, and self-control, he realized that there is a better way to treat both anxiety and disordered eating with the help of technology. Using reward and awareness techniques from research on operant conditioning delivered through applications, he’s been able to show a 57% reduction in anxiety and a 50% reduction in feelings of burnout among the folks he’s treated. This presentation really got us thinking about how anxiety is built through negative feedback loops and that those same loops can be re-purposed in order to treat it. If you’re interested in reading more of Dr. Jud’s research you can find it on his blog and find his app-based treatment programs here.

❤️ I’m Not Well and That’s Okay

Julia Nguyen

Julia Nguyen gave a very personal presentation about the technology industry and its impact on her mental health. She astutely pointed out that our industry often centers “impact” to the exclusion of humanity and self-care, and often stigmatizes and silences marginalized groups like those from LGBTQ+ & BIPOC communities. Julia’s contribution to these problems include her successful open-source project, If-Me, which lets people privately discuss their mental health with friends and loved ones. The project also maintains a list of other resources, including Aloe Bud, an app we helped create that focuses on self-care reminders. Julia left us with questions to ask ourselves whenever we take on a new mission-driven project, including: Are they practicing what they preach? How are queer/trans/POC being left out? She also reminded us that even therapists need therapists, and to take care of ourselves so we don’t suffer from the same burnout we’re working against.

💬 UX With Mental Health in Mind

Bradley Gabr-Ryn

Bradley Gabr-Ryn, a product designer at Facebook, explored the ways UX design can impact our mental health in his talk. He pointed out common digital hooks that drive growth and engagement in social platforms — things like retweets and the algorithms we know and love (love to hate, at least) — and how those hooks make it harder to walk away from social media, which leads to overconsumption and reliance. His talk focused on a few ways we can begin to fix this overconsumption: make room to talk and learn about mental health in the workplace, value people’s time, stop calling the people using your product “users,” and be as transparent, comprehensible, and clear with your product’s intentions as possible. The bottom line of this talk? “Don’t be icky” — in other words, treat your customers like people, and do your best to design a product that prioritizes their mental health, rather than engagement at all costs.

💻 Hacking Your Emotional API

John Sawers

John Sawers helped us put emotions in a context developers can better relate to by asking us to imagine our brains are wired to an API that triggers certain feelings. He guided us through four levels of emotional techniques to help us better understand and “refactor” these feelings. These four levels include concepts like controlling your own implementation by deciding where and when to process your feelings, rubber duck debugging to help you solve your problems by explaining them to someone else, doing emotional retros to regularly check in on your feelings, and learning to address your feelings with other people one-on-one or in group settings. More information about this talk, including the slides, can be found on the Emotional API website.

Swift on Raspberry Pi

Marc Aupont — Sun, 25 Aug 2019 00:00:00 GMT

Raspberry Pi is a small, cost-effective, single-board computer with potential only limited by its computing power. It is also well-known by hobbyists and technologists alike. It’s the perfect device for those looking to experiment with an idea or test the validity of a concept. It can fit almost anywhere and be used for a variety of projects — it can be mounted on the back of a monitor and used as a desktop computer, or connected to a breadboard to control an electronic circuit.

The official programming language of Raspberry Pi is Python. While Python is fairly easy to pick up, it lacks features like type safety and has high memory consumption. Swift, on the other hand, has memory management through ARC, and is over 8x faster. Since Raspberry Pi is limited in RAM and CPU power, using a language like Swift is perfect for maximizing the potential of the hardware. Understanding how hardware and software work together is crucial for determining the efficiency of your next project. In this guide, we’ll cover the basics of getting started with Swift on Raspberry Pi.

Hardware vs. software

When it comes to the devices we rely on every day, there are usually two components: the hardware and the software. Hardware is the physical object we interact with, and software is what controls that hardware’s behavior.

Let’s use the iPhone as an example. The hardware includes things like the GPS, Bluetooth, OLED screen, gyroscope, camera, and more. But in order to interact with that hardware, we need software — in this case, iOS. And as a layer on top of that operating system, we have the Swift programming language, which allows developers to create applications that run within the operating system to control the hardware.

On Raspberry Pi, hardware like a camera or GPS is attached separately via chips or electrical components. In order to control these components, we can install libraries that support that hardware. A majority of the available components can be controlled via libraries written in Swift. We’re going to explore how to set up Swift on a Raspberry Pi to control those components.

Installing an OS

Before we can install Swift on Raspberry Pi, we first need to pick an operating system. There are several third-party options to choose from, but the most common choice is Raspbian, the officially supported OS of Raspberry Pi. There are multiple ways to install Raspbian onto an SD card — we’re going to use balenaEtcher. Here are the steps:

Download the latest Raspbian OS here.
Format your SD card to MS-DOS (FAT) using Disk Utility.
Use balenaEtcher to flash the Raspbian OS to your freshly formatted SD card.

Step two: format your SD card to MS-DOS (FAT) using Disk Utility

Step three: Use balenaEtcher to flash the Raspbian OS to your freshly formatted SD card.

Setting up Raspberry Pi

You’re halfway there! 🎉 Now that we have an SD card with the operating system we want to use, we need to make use of it with Raspberry Pi. Here’s where things get a little bit tricky.

There are two ways to set up Raspberry Pi:

Use an attached monitor, keyboard, and mouse.
Headless configuration via SSH or USB Console cable — the term “headless” refers to the lack of an attached monitor (the “head”), wherein the Pi can be controlled by another computer.

If this is your first time tinkering with the Pi, I recommend the first option. Once you’ve inserted your SD card with Raspbian OS into the Pi, plug in your HDMI cable, keyboard, mouse, and power cable.

The Pi should now boot to the Raspbian desktop. Congrats! Now you can take some time to explore the desktop and see what it can do.

The Raspbian desktop

Installing Swift

To install Swift on our Pi, we need to connect it to the internet (either via ethernet or Wi-Fi, depending on the model of your Pi). Once you’re online, you’re ready to start the process of installing Swift.

There are 2 ways to install Swift. You can either build Swift yourself or use pre-compiled binaries. I would highly recommend option 2 because the first option will take several days to do on a Raspberry PI. The precompiled binaries are possible because of the Swift-ARM group. They have put together a repository that allows you to install Swift using the Advanced Package Tool or apt for short.

This command-line tool is kind of like the App Store for applications and packages on linux machines. We use apt by typing apt-get in the terminal, which is usually followed by a series of commands telling the tool what to do. In our case, we want to install Swift 5.0.2. For a list of all of the available Swift packages check here.

So, lets get started! Now that we know we want to install Swift via apt, lets add the swift-arm repo to our list of repositories.

Add/Install the swift-arm repo to our apt command-line tool.

Shell

curl -s <https://packagecloud.io/install/repositories/swift-arm/release/script.deb.sh> | sudo bash

Use apt to install Swift from our freshly added repo from the line above.

Shell

sudo apt-get install swift5=5.0.2-v0.4

Thats it! You now have Swift installed on your Raspberry Pi.

Creating a test project

At the moment, the Swift REPL is not operational — but everything else works. To give it a test run, let’s create a quick Swift package using Swift Package Manager.

Create a new directory called MyFirstProject

Shell

mkdir MyFirstProject

Change your working directory to be your newly created MyFirstProject directory

Shell

cd MyFirstProject

Create a new executable Swift Package

Shell

swift package init --type=executable

Those three lines create an empty Swift package called MyFirstProject. To run this project, type swift run.

Once your project has finished compiling, you should see Hello, world! printed in the terminal.

Now that we’ve built our first program on the PI, lets make some small changes. From the MyFirstProject directory, we will need to make a change in our main.swift file. This is the code that is executed when we run our package via the command swift run.

Change your directory to the Sources/MyFirstProject directory

Shell

cd Sources/MyFirstProject

Edit your main.swift file using the built-in nano editor

Shell

nano main.swift

Once you’re in the nano editor, you’ll be able to edit your program to do as you please. Go ahead and replace the contents of your main.swift file with the following:

main.swift

print("Hello, Marc!")

Feel free to replace the name with your name. To save your changes perform the following:

Press CTRL + X to save the file.
Confirm your changes by pressing the Y key.
Confirm that you want to make to changes to the main.swift file by pressing the Enter key.

We have now completed our changes and its time to re-run our program. Type the following into terminal window:

Shell

swift run

Congratulations! Once your code has compiled, the terminal should now display your recently modified string.

Now that Swift is installed, there’s so much more that you can do. To control hardware — like LEDs, motors, and relays — you can use the help of a library for hardware projects on Linux/ARM boards called SwiftyGPIO. Have fun experimenting with Swift on the Raspberry Pi!

And if you enjoyed this blog post, you might also enjoy my three-part series about using Swift on a Raspberry Pi to create a distance-measuring system for an autonomous car.

Swift Playgrounds is for Everyone

Thomas DeVuono — Thu, 01 Aug 2019 00:00:00 GMT

Ever since joining Lickability as an Account Manager three months ago, my responsibilities have included finding and pursuing leads, working with potential clients through every stage of a project, drafting estimates and contracts, and sending lots and lots of emails. It’s my job to help clients figure out how we can meet their unique needs with the services we can provide.

My final challenge in Learn To Code 2

Although my background is in engineering — I studied mechanical engineering and engineering management — my education and the first four years of my career were outside of tech. Because of that, I’m somewhat of a novice when it comes to software development. For the past three months, I’ve been working on improving that so I can talk to our engineers and clients about app development. I learn best by doing, so I’ve been using Apple’s Swift Playgrounds Learn to Code modules on an iPad here in the office to learn the fundamentals.

The Learn to Code series has three modules, accompanied by additional lessons, developed both by Apple and third parties, in the Swift Playgrounds app. Learn to Code 1 focuses on the fundamentals of coding and Swift, covering topics like commands, functions, bug fixing, loops, conditional code, and operators. Learn to Code 2 starts to get into the meat and potatoes of Swift with topics like variables, types, initialization, parameters, and arrays. I’m just scratching the surface of Learn to Code 3 now, but I can say that this module is really starting to feel like code that could be used in real world app development.

The lessons are presented as a series of puzzles that can be solved with code, with makes them fun to complete and great for any skill level. I sailed through most of the first module pretty easily (although I did run into some trouble with infinitely repeating while loops that I had to ask our engineers for help with 😅) and had a slightly tougher time with the second module. I started AirPlaying my code in our conference room so engineers could stop by and pair with me while I talked through my thought processes.

A screenshot of code in the Swift Playgrounds app

What I’ve learned

Learning to code with Swift Playgrounds has several benefits that make it worth the effort for someone in a sales role at a software company. First, it gives me a better understanding of and appreciation for the work that our engineers do. This context makes it easier for me to evaluate potential clients — we want our engineers to work on interesting and fulfilling projects, and learning about programming has helped me seek out the best clients for us.

Second, I have a better understanding of clients’ needs, which can help me answer their questions and find solutions that best meet those needs without always having to consult with our engineers. Showing clients that I have a baseline knowledge about the services they need helps us establish trust early, and makes the rest of the sales process much smoother.

Finally, learning how to code is a rewarding and enjoyable experience! Solving puzzles and learning new things are some of the reasons I got into engineering in the first place, and diving into Swift has been a great way to continue to experience that. I’ve gotten a lot of personal and professional value out of Swift Playgrounds, not just because I’m learning a new skill, but because I’m learning about the process and best practices involved in coding. Here are some of the most important things I’ve learned from Swift Playgrounds that I use every day:

Pattern recognition: I look for and automate processes that I find myself repeating a lot — this is especially useful when sending lots of emails. I use email templates for common messages I send, Calendly for scheduling client meetings, and document templates for project estimates and contracts.
Pair programming: I’m more proactive about asking for help and working with my teammates on everything from writing up client documents to sending important emails.
Source control & documentation: I make sure all client documents are up to date and filed correctly, document any changes I make to documents and flag them for review, and write down important workflow processes in Notion.
Iteration: I recognize that things are always changing and there are always ways to improve my work, so I actively solicit feedback from teammates and clients to figure out what works and what doesn’t. After evaluating feedback, I develop solutions to address any problem areas in my workflow, and then continuously iterate over those solutions to improve more over time.

Getting started with Swift Playgrounds is as easy as grabbing an iPad, downloading the Swift Playgrounds app, and diving into the Learn To Code 1 module. If you have any questions about it, I’m just a tweet away!

Our Swift Best Practices

Andrew Harrison — Thu, 25 Jul 2019 00:00:00 GMT

Code is written for humans. I’m not the first to say that, and won’t be the last. What you write will eventually be compiled away into something unintelligible, so how you choose to write code isn’t for the computer’s benefit. It’s for yourself, both now and later. It’s for any people working on a team with you. And it’s for anyone that stumbles upon your code after you’re gone.

In order to understand our code better, Lickability employs consistent practices — and to do that, we have a defined structure and style for the way we write code. Today, we’re sharing our best practices guide with you. This guide contains our preferred way of writing code, both in terms of architecture and the way style is enforced (through SwiftLint). It is intended to be a living repository that will be updated as the Swift language and our experience evolves.

If you want to use this, great! If you want to fork it and make changes, go ahead. We won’t be accepting issues or pull requests at this time, but we hope that you’ll find our approach to writing software interesting—and if there are aspects that you’d love to chat about, let us know!

10 Years of Lickability

mb bischoff — Mon, 22 Jul 2019 00:00:00 GMT

Wow! Time flies when you’re having fun and making apps. Our company turned 10 this year, so we figured it’d be good to look back over everything we’ve accomplished together over the last decade. Let’s take a stroll down memory lane, shall we?

2009

Launching in stealth mode.

— Lickability (@lickability) May 25, 2009

In 2009, Brian Capps and I were friends about to graduate high school together in Philadelphia. That year, I had gotten obsessed with the incredible indie apps that were being released on the year-old App Store, and decided I wanted to try my hand at making one. After convincing Brian to work with me, we started Lickability from my parents’ kitchen table in Sicklerville, NJ. We named the company after a Steve Jobs quote that continues to inspire us to this day.

Our summer consisted of late-night iChat AV calls pair programming, watching Evan Doll teach the first section of CS 193P at Stanford, and finishing a 0.9 version of our first app, Broadway. The app never (officially) got released, and if you’re curious why, we wrote the lessons we learned here.

2010

Interested in beta testing a new iPhone app I‘m working on?
http://testflightapp.com/join/2a6c0e8823f64f0f581efce254fca680-NDQ/

— mb Bischoff (@mb) November 25, 2010

Brian and I both went off to college — him to the University of Miami and me to New Jersey Institute of Technology, where I met the mysterious third Lickability Partner: Andrew Harrison, who has become our engineering lead. Andrew and I stayed up late in our sixth-floor dorm room working on an “unfinished idea” that Alex Payne had posted online some years earlier called Quotidian. Once we had something that vaguely worked, we called Brian and showed him a demo. This prototype became one of our most well-known and successful apps of all time, Quotebook.

Quotebook was an app you could use to store, sort, and share the quotes that matter to you. And we worked on it through most of 2010 to make sure it worked as well as it could for 1.0. Afternoons spent on importing and exporting code, building performant search, and following Ray Wenderlich tutorials to create a rating view are the memories that stick with me almost a decade later.

2011

“Real artists ship.” –Steve Jobs

— Quotebook (@quotebookapp) February 25, 2011

We shipped! After tons of beta testing, we released Quotebook on the App Store! And people loved it. Pastors, parents, and book-lovers wrote to us in droves with their feedback and feature requests. Reviews went up on all of our favorite websites, and the app got featured on the front page of the App Store as a Staff Pick. We quickly got to work on point releases and plans for a sequel.

And then: The Gray Lady, baby! I was offered a full-time job on the iOS team at The New York Times and dropped out of college to take it. My mission from the beginning was for us to use what I learned there to make Lickability even better, and that’s exactly what we did.

2012

Quotebook 2.0. http://t.co/wIybzijj.

iPad, iCloud, and so much more.

— Quotebook (@quotebookapp) May 31, 2012

The iPad had been out for a few years and folks were clamoring for Quotebook on iPad. But we knew that in order to do it right, we needed it to be a Universal app, and quotes had to sync seamlessly across devices. Quotebook 2.0 shipped after many weekends spent testing and debugging Apple’s nascent (and, in hindsight, totally broken) iCloud Core Data syncing system. Many radars were filed.

Lickability needed a logo, so we commissioned Aaron Mahnke, now the famous podcaster of the Lore universe, to design one. By this point, all three of us were living together in an apartment in Newark, NJ that we affectionally called Lickability HQ. Brian had moved up from Miami to join me at NYTimes by day and continue building the Lickability empire at night. This was also the year of our first WWDC, where I spent the 5-hour wait for the keynote in line with the hosts of ATP, which wouldn’t launch until the following year.

2013

Velocity is the only speed reading app designed for iOS 7. Read faster, one word at a time.

Download it now. https://t.co/eX93eIcyqA

— Accelerator (@acceleratorapp) September 20, 2013

On the product front, Brian and Andrew took an offhanded comment about an idea for a speed reading app I had and turned it into a functional app prototype. After working on the app for months, with the help of Marcelo Marfil for design and Talos Tsui at Iconfactory for the icon, we launched Velocity (now Acceleator), a speed reading app with support for Instapaper and Pocket. We also brought on Bryarly Bishop part-time to help us with customer support and worked with Grant Butler on a prototype for a Reddit app we never shipped, called Antenna.

This was also the first year we took on clients (now a majority of our business). In 2013, we were lucky to work with the folks at Pocket Bracket and Grouper to apply our Objective-C knowledge and make their apps look, feel, and function better. We also attended and spoke at more conferences, like Çingleton in Montreal, SecondConf, and WWDC for a second time.

2014

Quotebook is featured in Reference on the @AppStore. Thanks . pic.twitter.com/1pAKvDrNCD

— Quotebook (@quotebookapp) September 7, 2014

We released Quotebook 3, a complete redesign and rewrite of the app, and people loved the new look. We continued to write and give interviews about iCloud Core Data in the hopes that Apple would get its act together.

We also did lots of experimentation in 2014. We tried (and failed) to port Velocity to both Android and Windows phone and found out that we’re strongest when we work on platforms we use every day. We also rebranded Velocity to Accelerator after selling the domain to a startup, which allowed us to turn Lickability into more than a side-project. And Accelerator was the most upvoted product of the year on ProductHunt! 😸

2015

I am “Going Indie” today: https://t.co/y4Z83gdpBe

— Brian Capps (@bcapps) April 7, 2015

In 2015, we set aside some money and we took the biggest risk we’ve ever taken: going indie. Brian quit his day job to focus on Lickability full time. And it worked! His first project was a Swift collaboration with Caleb Davenport to rewrite and re-release Bugshot as Pinpoint, after we acquired the app from Marco Arment. That landed us a spot in Daring Fireball’s Linked List.

We also took on Meetup as a client and figured out lawyers, accountants, invoicing, bookkeeping, and all that fun business-y stuff. I attended Layers in San Francisco and then I talked about management at CocoaLove in Philly before also joining Brian as a full-time Lickability employee.

2016

Presenting PinpointKit, our new framework for sending better feedback.https://t.co/qb6FVLcQ0w pic.twitter.com/GhD8dPxEhI

— Lickability (@lickability) June 10, 2016

In 2016, we moved into our first office space and added two new team members: Andrew, and our first purely engineering hire, Michael Liberatore. We also released our first open-source project, PinpointKit, a framework for developers to collect feedback from their beta testers that’s now used in apps around the world. We also made the hard decision to shut down Quotebook. And finally, I spoke at Release Notes in Chicago about how we use writing as a system for solving big and complex problems.

Two major client projects that we’re really proud of shipped in 2016. We helped Meetup redesign and rewrite their entire iOS app from the ground up in Swift. And we helped build a brand new news app for a prestigious publication, The New Yorker Today.

2017

🔱 We were thrilled to work with our friends at @TheAtlantic to build their new, redesigned iOS app, out today!https://t.co/WTg5jMpcoC

— Lickability (@lickability) August 23, 2017

Our biggest launch in 2017 was a redesign and rewrite of an app for one of our favorite publications, The Atlantic. The app was featured on Beautiful Pixels and readers were impressed with the new look and feel and iPad support. We also added clients like Mimeo, Houseparty, and Jet to our roster.

Our team grew by two engineers, Grant Butler (joining us full-time) and Michael Amundsen, our first junior iOS engineer. After WWDC, we thought about what we could build with the new iOS 11 APIs and prototyped an app called Shelf. While we ultimately decided not to ship it, we all learned a lot building the first version.

2018

🏠 We have a new office! Take a look inside the new Lickability HQ in our latest blog post.https://t.co/SLxuQV646O

— Lickability (@lickability) November 2, 2018

It was time. We had outgrown our coworking space and “minimalist” website. So we worked with our friends at Pickaxe to design a snazzy new site and Megan Leet at Perf to help us decorate our brand new office in Chelsea. Also, Jillian Meehan joined to help us get our operations act together and Marc Aupont came aboard as our seventh engineer.

It was also a year of close collaborations with clients. We spent months working with Amber Discko on their Kickstarted self-care app called Aloe Bud. After a successful launch, both Aloe Bud and Houseparty were featured on the App Store as App of the Day.

2019

👋 We + @bcapps will be in San Jose all week for #WWDC19. Say hi if you see us! pic.twitter.com/I8CgeoapRk

— Lickability (@lickability) June 3, 2019

This year is only halfway done, but so far we’ve brought on Ashli Rankin with the launch of our iOS Apprenticeship and Thomas DeVuono, our first Account Manager. Also, we appeared in a five-minute television spot on CBS’s Innovation Nation with Mo Rocca!

We continued to grow our studio, expand our WWDC presence, and got started on a new app. 🤫 I got onstage at NSNorth in Montreal to talk about 10 of the lessons we learned over the last decade. And we’ve got plenty more in store for the next 6 months…

Thank You for Everything 🙏

We wouldn’t be where we are today without the help of so many people. We want to offer a heartfelt thanks to everyone that helped along the way.

Thank you to our team, families, testers, contractors, customers, and clients. And special thanks to Aaron Mahnke, Alex Cox, Alex Hardiman, Alex Payne, Allen Pike, Andrew Carroll, Annie Maguire, Ben Brooks, Ben Scheirman, Brian Murphy, Bryan Irace, Caleb Davenport, Carly Occhifinto, Casey Liss, Chris Eidof, Christina Warren, Christine Chan, Craig Hockenberry, Daniel Pasco, David Barnard, DJ Brinkerhoff, Federico Viticci, Fiona Spruill, Greg Mavronicolas, Guy English, Jason Brennan, Jeff Grossman, Jeremy Swinnen, Jessie Char, Joe Cieplinski, Joe Fiore, John August, John Gruber, John Voorhees, Jon Mitchell, Kate Sloan, Kathy Campbell, Kelly Capps, Ken Ackerson, Maja Henderson, Marco Arment, Mark Kawano, Matt Alexander, Megan Leet, Merlin Mann, Michael Jurewitz, Mohit Pandey, Myke Hurley, Patrick Gibson, Patrick Rhone, Paul Bruneau, Paul Rehkugler, Peter Vidani, Rachel Viniar, Ricky Mondello, Rob Rhyne, Rob Rix, Sam Soffes, Shawn Blanc, Sid O’Neill, Soroush Khanlou, Stephen Hackett, Steve Matthews, Tara Mann, and Zack Sultan.

Conference Condensed: WWDC 2019

Jillian Meehan — Thu, 13 Jun 2019 00:00:00 GMT

Last week, we sent five Lickability team members to San Jose for WWDC, Layers, and AltConf. This week, we’re giving you a rundown of some of our favorite moments — strap in.

WWDC

Although nobody from Lickability had tickets to WWDC this year, we all took time to sit down together and watch the videos online. We’re still making our way through them, but here are some of our favorites so far:

Advances in Collection View Layout

(WWDC 215)

In Advances in Collection View Layout, Apple introduced UICollectionViewCompositionalLayout and NSCollectionViewCompositionalLayout to much fanfare. In 50 minutes, we learned just how easy it is to take our complicated custom collection view layout subclasses and replace them with a few declarations of the section, group, and item components that comprise the new layout types.

Shout out to NSCollectionLayoutSize and NSCollectionLayoutDimension! No longer will we need complicated logic and math to calculate frames for layout attributes. These classes make it possible to specify item layouts relative to their container size by simply describing what you want upfront using fractionalHeight() and fractionalWidth(), and absolute() when your designs call for a specific item size. It’s also amazingly simple to use visually distinct layouts for each section of your collection view, specify paging behaviors, and nest vertically and horizontally scrolling regions in a single collection view.

We can’t wait to delete all of our likely-inefficient UICollectionViewLayout and UICollectionFlowLayout subclasses!

Adopting Swift Packages

(WWDC 408)

We’ve waited a long time, having to rely on open source tools like Cocoapods and Carthage, but that wait is finally over. Apple is finally bringing first class third-party dependency management to Xcode, with Swift Packages. The syntax for defining how a package behaves remains the same from previous years, so any third-party libraries that have already been defined that way will work starting today. With GitHub already signed on to provide support, we can’t wait until existing packages are updated to support the newly integrated Swift Package Manager.

Advances in Foundation

(WWDC 723)

Advances in Foundation is like many of our favorite WWDC sessions in years past: it doesn’t completely change everything we know about app development by introducing a new framework, language, or technology. Rather, we’re introduced to a number of quality-of-life improvements to the things we use on a daily basis that make our jobs less prone to error or repetitive. This session was jam-packed with more than a dozen Foundation improvements that had us clapping along with the audience. To name a few highlights:

addBarrierBlock on OperationQueue 😯
Ordered collection diffing 🎉
ListFormatter 🤩
RelativeDateTimeFormatter 🤯 You’re gonna want to watch this short session at half speed to absorb everything!

Great Developer Habits

(WWDC 239)

This was an excellent talk from Apple going over the habits great developers practice when making applications. It resonated with us because, even though the habits they mentioned focused on best practices in development, they are relatable and easily applicable in any daily workflow. The talk focused on 8 key points:

Organize — organize your work functionally, group related information, keep your work up to date, have a zero tolerance policy for those small errors so they don’t pile up
Track — use source control whenever you can and write detailed comments on your work
Document — your comments should not only explain what something is for but why it was created, document things that are reusable so you don’t waste time redoing work, be descriptive when naming files
Test — have your work checked as part of your regular practice, getting a second set of eyes on something is a great way to catch small mistakes
Analyze — try and think about all the different ways your work will be received, don’t just look at it from your perspective, be efficient
Evaluate — leverage the community’s knowledge if you are stuck or are less experienced, spend the time when reviewing other’s work, don’t just skim, ensure consistency
Decouple — scale your work across everything you do when possible, share what you know with the community
Manage — understand the tools you depend on, have plan for if they are no longer useable

AltConf

Even if you don’t get the golden ticket to attend Apple’s conference, being in the same city as WWDC is such a fun time for anyone in the iOS community. It’s a week filled with goodies, exciting announcements, and friends.

A couple of us used our time in San Jose to attend AltConf this year, which had really awesome talks, interesting workshops, and plenty of chances to mingle with some great folks. And, as a slightly bittersweet bonus, it was held in a hotel right next to the San Jose Convention Center that WWDC was in, which meant we were able to interact with quite a few developers who were trekking back and forth between the two conferences.

The talks and workshops we attended at AltConf were great — especially one workshop where we had a chance to play with the latest CoreML updates that allow you to update your models on device — but we really want to shout out the amazing experience of getting to hang out with friends and meet lots of new people. That’s always, hands down, our favorite part of the week. All in all, AltConf is a great conference, and one of our favorites every year.

Layers

This year, three of us went to Layers, a single-track design and tech conference with amazing snacks. Layers is incredibly well-run, and if you haven’t been, we highly recommend going. Here are a few highlights from this year:

Kelli Anderson

As we walked into the theater to see Kelli Anderson, we were each handed a piece of paper that looked like this. Before she began her talk, Kelli instructed us to start folding the paper along all of the score lines. As we folded, we learned who Kelli is: a designer, a paper engineer, and just a generally very cool person. She made books like This Book Is A Camera, and This Book Is A Planetarium. She made a record player out of paper for her friends’ wedding invitations — yes, really. And she made an “existential calculator” volvelle wheel, a fun and creative way to solve the age-old question: “Should I take that job?”

By the time Kelli finished walking us through the joys of creating art with paper, we were done folding and ready for the next step of the talk: building our paper flexagons. She showed us how to take the flat pieces of paper we had all been given and turn them into something dynamic and fun in just a few minutes — an A+ Layers experience.

Linzi Berry

Linzi Berry, who leads design systems at Lyft, gave an inspiring and useful talk on design systems at the company and how she and the team used them to encode inclusive design for people of all abilities. She covered why accessible design matters, and discussed some of the tools she used at Lyft to ensure contrast and sizing was as readable as possible for all users. Most importantly, Linzi imparted some organizational anecdotes and wisdom about how to talk to others at your company, even a large one like Lyft, to obtain support for unified design systems and accessible design (spoiler: it included selfie sticks!).

The talk left us energized about making design work for everyone and armed with the knowledge to start building more inclusive interfaces!

May-Li Khoe

What is there to say about May-Li Khoe that hasn’t already been said? As a designer, dancer, DJ, and polymath, May-Li has worked on everything from art project protests to multitouch interfaces at Apple.

Her talk at Layers focused on her mission in life and the thread that runs through all her recent projects: joyfully subverting the status quo. May-Li is “from a lot of places” and part of her upbringing all over the world taught her to think of her life as a blank canvas, not a checklist or a linear graph.

With vivid examples from activism (BBQ ‘N While Black and Futbolistias for Life), art (We Are Against the Wall), and technology (Photo Booth and her new app Scribble Together, with Bridger Maxwell), she reminded us that designers are people that visualize what could be, help bring other people along, and help them to see it with us. She taught us that designers have a responsibility to subvert broken politics, systems, and power structures. May Li invited all of us to “make some friends and start some shit.” And that’s exactly what we plan to do.

Yell it into the #void

Jillian Meehan — Thu, 23 May 2019 00:00:00 GMT

We like to try new things in the Lickability Slack from time to time, like inviting friends of the company to join public channels, or using an app called Hey Taco! to give teammates praise in the form of 🌮 emojis. Now, we’ve added a new channel to our Slack — welcome to #void.

What do you do with that post that doesn’t fit into any other Slack channel? #void. What do you do with that thought that probably shouldn’t be a tweet? #void. What do you do with all of the stuff that doesn’t really require a response or acknowledgement from anyone else, the stuff that you just need to get out of your system? #void.

Sometimes you just want to scream into the void — so we made a Slack channel specifically for that. We were introduced to the idea by a similar channel, #bad-attitude, in the XOXO Slack. So while we definitely aren’t pioneers of the #void channel, we are huge advocates of it.

Why #void?

Slack is for work, but when you’re spending an entire day using it, you need to be able to use it to escape from work, too. That’s why we invite friends to our public Slack channels like #tv and #music and #food. That’s also why it’s helpful to have a space where people can get out their frustration, random thoughts, or memes in a way that isn’t distracting or disruptive to other team members.

Yelling (or, in this case, typing) into the #void is therapeutic, and often funny—and once you get those thoughts out, it’s easier to return to your work with a clear head. Of course, that can come with a downside: a channel meant for purging your thoughts can easily become a very negative or judgmental place, which we want to be mindful of (yes, Code of Conduct rules still very much apply).

Your turn!

At the end of the day, our goal is to have a safe space for our team to get it all out. As it turns out, Slack can be that space. And it can be that space for you, too. Here’s how we suggest getting started:

Make a new Slack channel. You don’t have to give it a name that suggests existential dread, but we recommend it.
Set the channel’s topic to make the purpose super clear to everyone. We went with: “Yell about it into the void. (We recommend you mute this channel)” — which brings us to the next step.
We strongly advise that you mute your #void channel. Since the whole point is to allow people to get out their feelings in the least disruptive way possible, you probably don‘t want to be notified every time a teammate needs to do some frustrated keysmashing.
If you’re the kind of person who likes to star Slack channels to keep them at the top of your sidebar, go ahead and star this one! #void is only helpful if you remember it‘s there.

Conference Condensed: NSNorth 2019

mb bischoff — Thu, 09 May 2019 00:00:00 GMT

Two weeks ago, I stepped on stage at the St. James Theatre in Montréal to deliver my talk, Growing Pains, to the audience of NSNorth. Before that, I had the opportunity to spend the weekend learning and socializing with a delightful group of independent iOS app designers and developers in this beautiful, old city.

mb outside the conference. Photo by Kate Sloan.

NSNorth is the spiritual successor to Çingleton, the conference that led us to turn Lickability into a business. And just like Çingleton, it’s run by two lovely Canadians, Dan Byers and Philippe Casgrain. The conference was a blast — here are some of my favorite moments.

Friday: Happy Hour & Ken’s Keynote 🍻

Attendees of NSNorth waiting for the next event

Friday night kicked off with a happy hour to get to know all the new faces and catch up with old friends. We gathered for a keynote by one of my favorite speakers from past WWDCs, Ken Kocienda. Ken, who built the keyboard on the original iPhone, talked in-depth about the “elements” and “molecules” that combined at Apple in the mid-aughts to give birth to the most successful consumer product of all time.

He gave me and the whole crowd lots to think about:

How do you build an engineering environment that allows for rapid feedback but doesn’t encourage interruption?
How can engineers and designers collaborate to solve really thorny problems like building a multitouch keyboard with autocorrect?
How do you decide what to build in the first place?

I’m looking forward to reading Ken’s book Creative Selection to go deeper into his thoughts on how the original iOS team tackled these and other questions.

Saturday: Talks, Tears, & Wheels 🎡

Queuing up to ride La Grande Roue de Montréal

Saturday, a rainy day in Montréal, was spent learning from some of the titans of the iOS software community. James Thomson of PCalc fame kicked off the morning with an impeccable walkthrough of the history of software easter eggs. We heard from Alaina Kafkes about how the Medium iOS team has prioritized and implemented accessibility features for their reading experience. Everyone’s favorite reverse-engineer Gui Rambo gave a great talk about practical advice for approaching privacy and security in iOS apps, reminding us to consider data protection, logging, API security, and user consent and control of data handling.

In the afternoon, I also saw my favorite presentation of the entire conference, Small But Mighty by Huda Idrees. Her energy was infectious as she described the social mission of her company and how small teams can solve big problems. She also reminded the audience that, as engineers and creators, “We need to be looking at falling in love with problems, instead of falling in love with solutions.”

At lunch, we took a break from learning to ride La Grande Roue de Montréal, a large Ferris wheel in the old port, and to get to know our fellow attendees better. Afterward, Daniel Steinberg delivered an emotional talk that had the entire audience in tears. He talk about the deaths of his wife and daughter, and how “the best move on the board” is often figuring out how to spend more time with those you love and finding the balance between work and the life you want to live. I’m getting choked up just writing about it.

We capped off the evening with a delicious banquet dinner. Good wine, new friends, and connections across the table led to an evening of board games that I sadly ducked out of early to rest up for my talk on Sunday.

Sunday: Swift, Subscriptions, and Speech 🎙

mb mentioning Lickability in their talk. Photo by Kate Sloan.

Most of my Sunday was spent pacing around mentally rehearsing my points, but I did catch Chris Eidhof’s virtuosic talk on Type-Driven Development in which he live-coded for an audience of hundreds, flawlessly as usual. Continuing on the theme of accessibility, Leena Mansour explained how she used her phone on VoiceOver exclusively for 7 days and taught us all about how cool and useful the VoiceOver Rotor can be for accessibility power-users. Rene Ritchie walked us through how Mobile Nations has used tools and a remote-first culture to shape their success with iMore and other media brands. And Ish ShaBazz shared his experience with subscriptions in his app Capsicum.

My talk, Growing Pains, covered the things I’ve learned in the last 10 years building Lickability: the things that get harder as you scale and what you can do to stay sane as your team or company grows. I covered topics like how we found our own office space, how we hire engineers, and the mental health challenges of running a small business. I’m glad the talk resonated with many folks, including a few that came up to me after the conference was over, as I was exploring the city’s speakeasies, to tell me how helpful the they found the specifics I shared the tools and processes we have used to scale the business.

Finally, the conference ended with a closing keynote from Kate O’Neill that called us all to think more deeply about the humanity and ethical considerations of the products and algorithms we make. Kate’s also written a book on the topic, Tech Humanist, that she generously gifted to every attendee.

Au Revoir 👋

Notre-Dame Basilica of Montreal. Photo by Kate Sloan.

NSNorth is on an indefinite hiatus, but it definitely went out with a bang. I’m so honored I got to attend and present at its 5th iteration. I hope Dan and Phil enjoy a well-deserved break from the hectic life of conference organizing and that someone starts up another Canadian iOS conference soon. I’ll definitely miss the maple syrup, the bagels, and the brilliant developers and designers that made my weekend in Montréal great. 🇨🇦

How do you collaborate on email?

Jillian Meehan — Thu, 25 Apr 2019 00:00:00 GMT

Let’s just get this out of the way: most of the Lickability team uses (and loves!) Spark for email. For collaboration, especially, it’s great. But that collaboration only works if everyone is using the same app, which isn’t the case in our office. Some people use Apple’s default Mail app, some people use standard Gmail, and some people — you know who you are, mb — have even given apps like Superhuman a try. (Personally, I’m using Polymail right now, and I love it. Don’t @ me.)

So what do you do when your team wants to collaborate on email, but everyone is using a different email app?

Email collaboration with Spark

Why collaborate?

Let’s say you have to send an important email to a client — before you slap your signature on it and hit the “send” button, you probably want to have at least one other pair of eyes on it. Maybe there are typos you missed, maybe a sentence or two could be worded better, or maybe you just need a quick “Looks good to me” before you feel okay sending it.

Clear and quality communication is important to us, which is why almost every email we send is done so collaboratively. Sometimes that means using an app like Spark to comment on and draft emails together, sometimes it means pasting an email draft into Slack and asking if it makes sense, and sometimes it just means saying out loud to each other, “I’m going to send this, is that okay?”

There are pros and cons to this, of course. Collaboration often results in sending cleaner, clearer, and more effective emails, and makes the email process more transparent. Team members feel more in the loop when they help write an email, rather than seeing it for the first time when they’re CC’d. That said, email collaboration can eat up unnecessary time — think about how many minutes are spent asking people to look over emails before you send them when it would be quicker to just type something up and send it yourself. And in our case, just figuring out the best way to collaborate can eat up even more unnecessary time.

At the end of the day, collaboration is essential — as long as you’re doing it right. So what’s the right way to do it?

Sharing emails with Polymail

What we’ve tried

We’ve yet to find the perfect solution for email collaboration. Spark for Teams is great, but only works if everyone on your team is using Spark. Polymail has a similar feature, and also makes it easy to create web links to emails so you can collaborate outside of the app — but, again, this is only useful if your whole team uses Polymail.

In our Switching to Notion blog post from a few months ago, we briefly talked about our “Email Scratchpad”: a Notion page exclusively for drafting emails together. Since then, we’ve stopped using it — it’s just not fast or convenient enough to be worth it. Copying and pasting the body of an email into Slack and editing a quick reply is quick and easy enough, so that’s often what we default to these days. But it doesn’t feel like a perfect solution.

So we’re asking you: how do you collaborate on email with your team? Let us know on Twitter — we want to hear from you!

We Were On TV!

Team Lickability — Thu, 11 Apr 2019 00:00:00 GMT

Back in December, we got an email from CBS about The Henry Ford’s Innovation Nation with Mo Rocca, a weekly Saturday morning show that covers all kinds of innovators and change-makers. They told us they had been researching our company and thought our app Accelerator would be a great fit for a segment. 🥳

A day of filming at Lickability HQ

Weeks later, the CBS crew showed up at our office for a day of filming our spot for Innovation Nation, which just aired last Saturday morning. mb, Brian, and Twig talked to the cohost Alie Ward all about the technology behind Accelerator and how it went from an idea they had back in college to an app that Lickability continues developing today—alongside all of the other work we do.

It’s Epic pic.twitter.com/QYIkfOfsjq

— mb Bischoff (@mb) April 6, 2019

We got up bright and early on Saturday morning to gather in the office with our friends and family and watch the show together — complete with waffles, coffee, and mimosas, of course. We want to say a big thanks to everyone who watched the show (thanks, Mom!) and to the lovely team at Innovation Nation for their support of Accelerator!

If you missed the episode, you can watch it right here.

Podcasts We Can’t Live Without

Team Lickability — Thu, 21 Mar 2019 00:00:00 GMT

It’s probably happened to you: you’re out at a party with a few of your friends, and all of a sudden, you’re comparing podcast subscriptions. (No? Just us? Okay.) We’ve shared and critiqued each other’s podcast-listening choices plenty of times in the office, so we figured it was about time to extend that courtesy to you. Read on to find out what some of our favorite podcasts are and why we love them so much.

Cartridge

Brought to you by our very own Andrew Harrison and Michael Liberatore, Cartridge is the only podcast about video games you’ll ever need (okay, we’re biased).

Why we love it: It’s about video games! And we like video games!

99% Invisible

If you’re someone who loves to notice all the tiny details that go unnoticed, this podcast is for you. Roman Mars’ voice + really in-depth narrative storytelling about design and architecture = magic.

Why we love it: It keeps us looking up and paying attention to the details.

Cortex

Hosted by CGP Grey and Myke Hurley, Cortex is what happens when two nerds who know they should probably get back to work decide instead to spend two hours talking about time-tracking and old business books. And we love it.

Why we love it: Productivity porn. Enough said.

Do By Friday

Do By Friday is a podcast where our pals (and yours) Merlin Mann, Alex Cox, and Max Temkin challenge themselves and their friends every week. Challenges have ranged from “Solve a mystery,” to “Make bacon,” to “Wash your hands.” Hilarity and politics ensue.

Why we love it: It is almost impossible to get through an episode without laughing.

Friendshipping!

Jenn and Trin are here to solve all of the weird, icky friendship problems that we don’t know how to deal with. They give real (but not harsh!) advice for friendship-related questions sent in by listeners — and they do it beautifully.

Why we love it: It manages to make dealing with even the trickiest friendship troubles fun.

Swift Over Coffee

What’s not to like about two guys having a friendly chat about Swift? Paul Hudson and Sean Allen cover all kinds of Swift news on this podcast, as well as topics suggested by the iOS community via open ballot.

Why we love it: It’s about a topic very close to our hearts, and we genuinely appreciate Paul and Sean’s work in the Swift community.

How I Built This with Guy Raz

How I Built This is the ultimate inspiration podcast. Hosted by Guy Raz, this podcast about all kinds of innovators — basically, it’s about people who are doing cool things and how they’re making it happen. If you have an interest in building things, this podcast is the motivation you need to follow through.

Why we love it: We love learning about how others have found success and the journeys that led them to it.

Watch Out for Fireballs!

Watch Out for Fireballs! is a game club (think book club, but for video games) podcast on which Gary Butterfield and Kole Ross discuss a single game at length in each episode.

Why we love it: After covering generalities, mechanics, and impressions, the hosts talk about each and every area or level of the game chronologically, making it a joy to play along while listening.

Bonfireside Chat

In Bonfireside Chat, Gary and Kole of Watch Out for Fireballs! dive even deeper into games like Dark Souls (one of our favorites) with entire seasons devoted to specific games.

Why we love it: It’s everything we love about Watch Out for Fireballs, but way more in-depth. Both shows are evergreen.

Call Your Girlfriend

Everyone has long-distance besties, but not everyone is cool enough to make a podcast with them. Ann Friedman and Aminatou Sow call each other every week to talk about politics, pop culture, and how they do what they do.

Why we love it: This duo is smart, inspiring, and just a delight to listen to.

Honorable mentions

Back to Work ∙ Blacks in Technology ∙ iOS Dev Discussions ∙ The Money Guy Show ∙ Under The Radar ∙ The Suite Podcast ∙ StackTrace ∙ Reconcilable Differences ∙ Rocket ∙ Roderick on the Line ∙ Reply All ∙ Video Games Hot Dog ∙ Function with Anil Dash ∙ The Vergecast ∙ The Cut on Tuesdays ∙ Who? Weekly ∙ Swift by Sundell ∙ Release Notes ∙ Punch Up The Jam

Growing our Small Business

Jillian Meehan — Thu, 14 Feb 2019 00:00:00 GMT

In case you haven’t noticed, we’re hiring. Expanding a small team like ours can be a weird, tricky process, so we thought we’d share a little bit about how we do it.

When we hire

We consider ourselves risk-conscious at Lickability, which means that we tend to be fairly conservative about hiring. We hire new employees based on an existing or immediate upcoming need, rather than trying to anticipate too far into the future. Because of that, we tend not to take on a lot of projects, which means we are far less likely to be caught in a position where we’ve just hired someone and don’t have anything to work on. It’s important to us that new employees feel like they have an important role at the company from the start, and the way we approach hiring helps us accomplish that.

So, how do we decide it’s time to hire someone new? The short answer is that it depends on how much work we have. We look at our current list of clients, our contracts, and any existing leads that we have. If we have more upcoming projects than we have engineers, it’s time to consider bringing on a new team member.

Who we hire

Most of the time, the new employees we hire are Swift engineers. But because Lickability is a small, relatively young company, it’s not uncommon for us to realize we need to hire someone to fill a totally new role.

To decide what positions we need to hire for, we take a look at the responsibilities that we’re either lacking or currently taking on ourselves. Then we try to shape a role around some, or all, of those responsibilities. A big part of writing a job description for a brand new role is looking at companies we admire and compete with that have the same position. Once we’ve read and talked to folks about how theystructured a role, we can come up with something that’s right for us.

Keeping in mind that the person who fits our specific needs has to actually exist, we try to limit requirements (like education and years of experience) to only what’s truly necessary. Having job requirements that aren’t actually requirements tends to systematically discourage women and other underrepresented groups from applying, and that’s the last thing we want. Being honest and clear about what we actually need — and being willing to compromise and change our job description if the applicants we see fit a slightly different profile better — is key when it comes to hiring for positions we’re less familiar with.

How we hire

Our hiring process has three steps: a phone screen, a take-home project, and an interview. The phone screen is a quick conversation to help us get a basic understanding of a person’s skills and personality. After a candidate passes the phone screen, we send them a small project to complete, relevant to the skills we’re looking for, that helps us get an understanding of what they consider to be their best work. Then, finally, the in-person interview is when we ask the candidate questions about the code test, their technical knowledge, and what would make them a good fit for our team.

We adhere fairly strictly to this process, and use the same take-home project and set of interview questions for everyone, which allows us to create a baseline for comparing applicants. We don’t believe in timed coding or algorithmic questions, instead striving to create an environment in our interviews that feels much closer to what it would be like if they were actually working here. For example, applicants can use their laptops to look up documentation and Google answers to questions if they need to, and they’re encouraged to ask questions and generate discussion during the interview.

The nice thing about hiring is that we have the chance to refine the process every time we do it, and if there’s one thing we love at Lickability, it’s figuring out how to do things better. If that sounds like you too, come work with us.

5 Tips for Reporting Bugs & Feedback to Apple

mb bischoff — Thu, 07 Feb 2019 00:00:00 GMT

If you’ve been a developer on Apple platforms like iOS and macOS for a while, you’re undoubtably familiar with an internal tool known as “Radar.” Radar is a bug tracker that Apple builds, maintains, and uses to track nearly every piece of software engineering work that’s necessary to release their operating systems and devices. And sometimes, when you as a third-party developer, encounter a bug in the OS or frameworks you’re using, you might be encouraged (well, shouted at) to FILE A RADAR! Or even “Radar or GTFO.”

While Radar has its critics, and we’re often among them, it has been a useful tool for us to report issues over the years—many of which have been fixed by Apple.

So how do you file a radar? It’s as simple as filling in a single form in Apple’s Bug Reporter, as long as you’ve got a developer account 1 . But what makes Apple more likely to pay attention to your bug when thousands are pouring in? 10 years of radar-filing and nearly a hundred radars later, we have a few tricks up our sleeve.

1. Reproduce the issue 📋

There’s nothing worse than being assigned a bug to fix that you can’t even make happen. So before you file your report with Apple, you’ll want to make sure you can make it happen more than once. Once you know the steps necessary to “repro” the bug, and have confirmed that it’s not an issue with your own app, try to whittle it down to the smallest number of steps or factors necessary to get it to happen.

Find the “smallest reproducible case” and then move on to tip number two.

2. Include a sample project 📎

Apple doesn’t want to hunt through your entire app, and you don’t want to go around uploading your company’s source code on random web forms. That’s a no-no. So instead, try to make a tiny app dedicated to making the bug happen, and include that with your report instead of your hundred-thousand line codebase.

Your sample project can be super barebones and sometimes even fit into a Playground, but feel free to spice up your radars with humor, instructions within the app, and more if you want to. If only we had the time. 🤷‍♂

3. Attach logs 📑

Apple will often also request a [sysdiagnose](https://developer.apple.com/bug-reporting/profiles-and-logs/?name=sysdiagnose) log with your report. Sysdiagnose is a built-in OS-level tool that can collect detailed logs that the engineer on the other side might find very helpful in their debugging of your issue. If you’re having a problem with a particular framework like CloudKit or Photos, you can also find profiles and instructions for enabling additional logging on the developer portal. You’ll save some back-and-forth if you turn those on and include them in your initial report.

4. Publicize your report 📣

Radars are normally private, for good reasons: reports sometimes contain security and privacy-sensitive information that Apple wouldn’t want to inadvertently leak. But every radar has a unique ID number, and if you’re sure that there’s no corporate or personal secrets, you can use that number to file a public version on Open Radar, an open-source community resource. When you link to the radar on Twitter or in Slack, it’s a best practice to include the Open Radar link and the rdar://bugid style link so Apple folks can open it right up inside their native Radar app for macOS and iOS.

Since Open Radar doesn’t host files itself, we recommend uploading your attachments to Dropbox, Google Drive, or GitHub and linking to them from there. Also, once Apple responds to your bug, it’s on you to mirror that on Open Radar so the larger community knows when it’s fixed, or (more commonly) marked as a duplicate of another report.

5. Know people at Apple 🤝

I know, I know…easier said than done. Even though this might not be realistic for every developer, it really does help to build relationships with Apple engineers at WWDC and Tech Talks, on Twitter, and in the Developer Forums. We’ve found that our radars tend to get treated with a little more urgency by having folks to email or DM who work at Apple. There’s also a trend within the company informally called radar-stalking where Apple engineers can set up a filter to be notified whenever an individual reporter or dev team files an issue. So the more folks you get to know, the better your chances that someone might decide to watch your account for fun!

In Closing

The mascot for Radar is an anteater. It eats bugs, get it?

Filing radars is a pain and sometimes it feels like shouting into a black hole. If you need more urgent help or a workaround, don’t be afraid to use a Technical Support Incident (TSI) if your radar isn’t getting traction fast enough. That’s what the Developer Technical Support team is there for.

A Lickability New Year

Team Lickability — Thu, 17 Jan 2019 00:00:00 GMT

We’re already *checks notes* three weeks into 2019, so it’s a little late to dwell on what we accomplished, learned, and loved as a company last year. (If you need a refresher, check out our blog archive.) Right now, we’re ready to focus on our goals for the year ahead — and we’ve got plenty of them.

One of our goals this year is to continue building the Lickability community, both online and offline. And what better way to do that than by throwing a holiday party in our new office? So last week, we invited a bunch of our NYC pals to Lickability HQ to celebrate the new year with us.

We had plenty of good pizza (c/o Williamsburg Pizza 🍕), good drinks (c/o of Cristhian and Eli from The NoMad Bar 🍹), and good snacks (c/o the grocery store around the corner 🥨). Between catching up with our friends, playing board games—including a secret prototype game, shhhh—and taking selfies in the makeshift photo booth, there were lots of great memories to be made.

Now that we’ve started 2019 off on the right foot, we want to thank you. Your continued support and friendship really means a lot to us. Thanks for being part of the Lickability family! ❤️

3 Tools to Stay on Top of Pull Requests

mb bischoff — Thu, 10 Jan 2019 00:00:00 GMT

Here at Lickability, we’re often working on many software projects at once: client products, internal tools, and new apps of our own. That means a lot of issues, pull requests, and discussions about code come up throughout the work week. Naturally, it can get overwhelming if we’re constantly context-switching or checking to see if there’s something new for us to review or chime in on.

We use 3 tools that make the cacophony of code review a lot more manageable. If you’re a pull requests power-user like us, check these out.

Quests

The most recent addition to our tool belt is Quests, from our friends at Steamclock Software. Quests is a macOS menu bar app that can be configured to show you how many pull requests and/or issues you’re the blocker on. A few of us keep an eye on it throughout the day, and when that number starts creeping up, we jump over to GitHub (or GitLab, which it also supports) to help our coworkers get their questions answered.

Get Quests on the Mac App Store for free. Tell ’em Lickability sent you. ⚔️

GitHawk

Sometimes we want to check in on our GitHub notifications when we’re not at our desks. On the way to work, when we’re at a conference, or (rarely) to peek at product progress on vacation. 👀

That’s where GitHawk comes into play. It’s a full-featured iOS app written by fellow New Yorker, Ryan Nystrom. GitHawk lets us process notifications, reply to issues, and merge pull requests all from our phones. With great power comes great responsibility, though — don’t use GitHawk to shirk your responsibility of thoroughly reviewing code. It’s best used if you’ve already done a review and want to merge something on your way home once the tests pass.

GitHawk is free on the App Store and open source on GitHub. 🦅

Danger

Rather than running on your device like the above tools, Danger is a web application that runs as part of your continuous integration system. It’s a helpful little robot that makes the first pass on every pull request so humans don’t have to. Danger can look for things like common anti-patterns, missing PR descriptions, and a lot more. If you’re still making style and formatting comments manually like it’s 2009, level up your workflow with Danger and save the humans on your team a ton of time.

Danger is available in JS, Swift, and Ruby. Pick your poision. 🧪

Pull requests make code review easy, and peer review has been shown to be hugely beneficial to ensuring the correctness of code. But sometimes there’s just too much to stay on top of. We’ve found that these tools make it a lot easier to keep things moving. Try them out and let us know what you think on Twitter at @lickability. Happy reviewing!

The Magic of the Everybody Meeting

Jillian Meehan — Thu, 13 Dec 2018 00:00:00 GMT

Whether you love them or hate them, you have to live with them. Sometimes they’re 10 minutes long, and sometimes they take up an entire hour. Sometimes they’re amazingly productive, and sometimes they would have been better off as a Slack message. You know what I’m talking about — meetings. At Lickability, we have a very special one that we look forward to every week: the Everybody Meeting.

Lickability Fridays

We dedicate the last day of every week to what we call “Lickability Friday.” Four out of five days a week, we spend our time working on client projects — but on Lickability Fridays, the whole company takes a breath to focus on what’s going on in our own office (inspired by our friends at Thoughtbot). We work on our products, we have a team lunch at a nearby restaurant, and we have, of course, the Everybody Meeting.

The Everybody Meeting is exactly what it sounds like: everybody at the company gathers in the conference room, where we go over the details of what happened that week — we review every client project, internal product, and department one by one. This might sound tedious, but it’s also incredibly important. As a small company, we function best when everyone knows what everyone else is working on. The Everybody Meeting creates space for that to happen, and for people to ask questions, hear outside opinions, and learn from each other on a regular basis.

How it works

The structure of our meetings isn’t set in stone, so it’s able to change week to week based on our needs. That said, we like to think we’ve nailed down what works the best for us. We use a Notion template with headers for every topic we want to cover, and bulleted prompts that detail how we want to cover them. A few of the specific things we go over are:

Last week: To refresh everyone’s memory on what was going on a week ago, and to make sure the concerns we had last week have been dealt with.
Good stuff: To celebrate the victories, big and small.
Concerns: To encourage people to bring up issues and find a way to fix them, together.
To do: To make sure the things that need to get done are taken care of. Every Friday morning, we fill out each section in the document and read over what others wrote. Then, when it comes time to gather together in the conference room, we go over the document together and ask questions about what we’re curious or confused about, figure out how to deal with specific concerns, and assign tasks for the week ahead.

Why it works

There’s no one good way to do meetings, because there are lotsof ways to do meetings and every company’s needs are different. What works for us might not work for you! And what works for us this year might not even work for us next year. When it comes to meetings (as with most things), it’s important to recognize that you could probably always be doing the thing you’re doing better.

So far, this structure has been working great for us. It’s thorough, but streamlined, and keeps our meetings both productive and quick — usually, it takes us about 30 minutes to get through everything before heading off to lunch together. We don’t have a lot of meetings at Lickability, so we try to keep the ones we do have as productive, flexible, and helpful as possible. Using a meeting template and sticking to a similar routine every week, while still allowing for change and encouraging discussion, has helped us get the most out of our weekly team meetings

We’ve all been in plenty of bad meetings — meetings with no agenda, meetings that are longer than they should be, and meetings that don’t seem to get anything done at all. If you find yourself stuck in a rut with unproductive, time-wasting meetings, remember: it doesn’t have to be that way. Our advice? Figure out what exactly it is you want to get out of each meeting, put some effort into making it happen, and find a routine that works well for your needs.

And yeah, in some cases, that meeting should totally just be an email.

5 of Our Favorite Blogs

mb bischoff — Thu, 29 Nov 2018 00:00:00 GMT

Writing apps and tweets isn’t all we do here at Lickability. We also love discovering new independent writers and following their blogs in RSS and on Twitter. I recently asked the team for some recommendations to add to my feed reader and shared some of my own. Here are the blogs we can’t get enough of:

NSHipster

Almost every iOS engineer at the company mentioned reading NSHipster. Now that the site’s founder, Mattt Thompson, is back at the helm and publishing regularly, we’re re-energized and excited to learn obscure Cocoa and Swift APIs, answer trivia questions (some of us even won first place at an NSHipster Pub trivia night a few yeas ago), and find ways to apply that new knowledge to our work.

Favorite past topics include NSLinguisticTagger, UIKeyCommand, and Void.

Uses This

One of my personal favorites, Uses This (née The Setup), by Daniel Brogan, is a long-running interview series with curious nerds, creatives, and hackers about the software and hardware they use to get their job done. It’s fascinating to get a window into the obsessive and eccentric workspaces of the people we admire and how they use those tools to do what they do.

Some interviewees and setups we loved: Sara Mauskopf, Karlee Esmailli, and Stephen Hackett.

Swift Talk

Video blogs count as blogs, right? Michael Amundsen, one of our engineers, loves watching Chris Eidhof and Florian Kugler dive into complex architectural challenges and come out on the other side with elegant solutions in Swift. It costs $15 a month to subscribe (half of their videos are available for free), but it’s well worth it if you learn best by watching and want to master the craft.

Laura Hogan

Laura Hogan’s blog about management, inclusion, and um donuts, is a fairly new discovery to me, but I devour every post as it arrives in Reeder. As a coach and consultant, with experience leading teams at Etsy and Kickstarter, Laura writes about technical management in one of the clearest and most empathetic ways I’ve ever seen. It’s a must read if you manage people.

We’re also basing our internal test-device lab on some early work that she and Destiny Montague did during their time at Etsy! Thanks Laura 🙏

Khanlou

Our friend and frequent collaborator, Soroush Khanlou, writes a well-loved blog at his personal domain that focuses more on architecture and design patterns than the kind of specific snippets of code you might find on Stack Overflow. His posts push us to think deeply and often spring to mind as we were solving particularly thorny problems. He’s also inspired us to publish more ourselves.

Posts like Graduation, Refactoring Reveals Truth, and State Negotiations really stuck with us.

That’s all for now! The blogs we come back to over and over again are the ones that challenge us to look critically about our work and our workflows. They lean a bit technical, but their writing is anything but dry.

Switching to Notion

Jillian Meehan — Thu, 15 Nov 2018 00:00:00 GMT

Before Notion, we were using a lot of different apps to do a lot of different things. We used Basecamp to assign tasks to team members and keep track of their progress, we used Google Drive to make documents and spreadsheets, and we used Spark to collaborate on email drafts. None of these are bad tools — in fact, they’re some of our favorites — but we were ready for something new.

Our Notion workspace has everything we need: meeting notes, company policy documents, on boarding checklists, and more.

We started out just wanting a space where we could collaborate on various documents — meeting notes, email drafts, blog posts, and other short, simple things that don’t generally need any sort of special formatting. As an experiment, we gave Notion a try, starting with a “Documents” page for lightweight spreadsheets and company policy docs, and an “Email Scratchpad” to keep track of and collaborate on emails together.

Notion gives us easy access to all of our meeting notes, blog posts, and email drafts. If you’ve gotten an email from us in the past three months, we probably drafted it together in Notion.

No company secrets were harmed in the making of this screenshot—here’s an example of what our To Do page looks like. We keep track of tasks by category (Blog, Finance, Sales, etc.) and by status (Blocked, On Deck, In Progress, and Completed).

Notion is supposed to be an “all-in-one workspace” that can replace seemingly every tool you’re already using at work every day. So, as our experiment went on, we started moving more and more of our work into Notion. We made a “To Do” page to assign and keep track of company tasks, we added an easy-to-use meeting template for our weekly team meetings, and we made a “Home Base” with quick links to all of our new pages.

TGIF: We have a database of all of our weekly meeting notes, a template for starting a new meeting, a space to write our individual self-evaluations every week, and a helpful spreadsheet of our favorite places to get lunch together.

Eventually, the experiment with Notion had to come to a conclusion. Could it replace all of our other tools completely? No. But could it replace some of them and become a really useful workspace? For sure. So far, we’ve said goodbye to Basecamp and started using Notion for all of our task management. We no longer use Spark for email collaboration (though some people in the office still love it!) and use our Email Scratchpad in Notion instead. And aside from legal papers and contracts, a lot of our docs and spreadsheets are now created and stored in Notion rather than Google Drive. (For example, this blog post? Drafted and edited in Notion.)

We didn’t have a good system for keeping track of blog posts before Notion. Now, we have a space where we can brainstorm, assign, draft, and schedule new blog posts.

No tool is perfect, of course. Notion isn’t as powerful as other apps for keeping track of to-dos, formatting with markdown and the built-in slash commands can be tricky if you aren’t used to it, and the iOS app needs some work (@notion, hire us 😉). But so far, Notion has definitely proven itself worthy of being the all-in-one tool we didn’t know we needed. It’s beautiful, it’s flexible, and it’s intuitive. It’s also extremely emoji-friendly, which is always a plus.

As Notion continues to grow and we continue to experiment with different ways of using it, our workspace will likely adapt and change over time. It’s important that we are as flexible as the tools we use. That’s why we encourage you to give Notion a try for yourself — if you need a little help getting started, check out the live demo on their website, and their “Getting started with templates” post. Happy Notion-ing! 🥳

The Many (Watch) Faces of Lickability

Team Lickability — Thu, 08 Nov 2018 00:00:00 GMT

A few posts back, we showed you the Lickability team’s iPhone home screens — and you showed us some of yours. This time around, we’re sharing our Apple Watch Faces. Strap in, folks.

mb Bischoff

I’m a purist (read: elitist). I still love the Utility face that shipped on the Apple Watch Series 0. Four complications keep me aware of everything going on in my day: my next calendar event via Fantastical, temperature and weather conditions from the not-so-friendly A.I. of CARROT Weather, my OmniFocus to-dos, and the date. The second hand and minute markers are set in the signature Hermés orange, because I’m a sucker for exclusives and spent too much money on this watch.

Michael Liberatore

I’m currently using the new Series 4 Infograph Modular watch face on my Apple Watch. While it’s not the prettiest collection or layout of complications, it’s allowed me to have quicker access to more of the things I care about in my daily watch usage.

I care most about Activity, which gets the prime center spot, and Workouts to help fill those activity rings (err… bars in this case, I guess). I love the new weather complication with current, low, and high temperatures, and wouldn’t want a watch face without weather conditions prominently displayed. (Thankfully, there’s enough room for both.) I set timers a lot, frequently via Siri, but I like being able to see the time remaining at a quick glance without having the Timer app full screen.

Oh, and the date and time (duh).

Michael Amundsen

It’s a watch, so time and date are fundamental. I like the weather range complication. Activity, because it’s one of the major reasons I have an Apple Watch. Workouts complication for easy access at the gym. I like to use Breathe to help me fall asleep before bed, and I use timers a lot when cooking.

Jillian Meehan

I fully believe in having multiple watch faces to suit your every mood, but the two I use the most are the Infograph Modular face (for everyday) and the Activity Digital face (for workouts).

My main watch face shows me all of the most important things that I need to be able to see at a glance day to day, like my next calendar event, the weather, and how many tasks are left on my Things to-do list. Having my Activity rings and the Breathe icon there reminds me to check in with my body now and then throughout the day.

I am by no means a serious athlete, but for times when I want to see a more detailed view of my Activity for the day, check my heart rate, or start a workout (in my case, usually yoga) I like to be able to swipe over to my Activity face.

Grant Butler

I’m currently using the Infograph watch face. It’s a bit of a variation of the Utility face I had been using on my Series 0 watch. I’ve got the current temperature, activity information, and today’s date on there. Since the Infograph face has many more complication slots than the Utility face, I also added the current weather conditions, as well as Deliveries’ complication.

…oh, and Brian Capps

Actual quote from Brian: “What’s an Apple Watch?”

Our New Office is Official

Jillian Meehan — Thu, 01 Nov 2018 00:00:00 GMT

A few months ago, all seven of us were sitting side-by-side in a small co-working office. We had enough space for our desks and computers, but that was about it. Not exactly ideal. So, we decided to do something about it and started the search for a new office.

We wanted our new space to feel like an IRL version of our Slack — a corner of the NYC tech community that is uniquely ours, where we can have full control over our own workspace, invite folks over for discussions during lunch, and continue to evolve as a company. Our pal Bryan Irace referred us to Elie Reiss at Skylight Leasing, and with Elie’s help, we found the place for us a month later, after trying (and failing) to picture ourselves in other office spaces all over the neighborhood. At the end of August, we left our old office and excitedly moved into the brand new Lickability HQ in Chelsea at 26th St. and 6th Ave.

Signing the lease on our new place was only the first step. Suddenly, we were in a room several times the size of our old one, and we had almost nothing to fill it with. As eager as we were to leave our co-working space in favor of our own office, there were a lot of advantages to our old place that we never really thought about until we didn’t have them anymore — furniture, food and beverages, cleaning services, conference rooms, etc. were all taken care of for us. When we left, it was up to us to figure it all out ourselves.

We didn’t have any furniture, much less any clue how to decorate an office. So we turned to a friend of the company Megan Leet, at Perf, to help us design the space. She worked with us to find all the furniture, decor, and office supplies we needed to create an office that works for us — complete with adjustable-height desks, a comfy couch (which took us a week to decide on), and plants that we are doing our best to keep alive.

Our new office is great, aside from the lack of desks and chairs. 😅 pic.twitter.com/E794O3g7Eh

— Lickability (@lickability) August 30, 2018

When we first moved into the office, it was almost completely bare. We had a few large boxes full of everything we took with us from our last place, plus a couple of floor pillows to sit on while we waited for furniture to arrive. Over the course of a few weeks, everything trickled in until we were finally able to sit down at our desks to work every day and have meetings around a table in our conference room. Every day, we thought of something else we needed: sponges, dry erase markers, an umbrella holder.

Now, two months later, our office has finally come together. It wasn’t easy — we’ve been buried under piles of empty cardboard boxes, furniture assembly instructions, and shipping confirmation emails for the last couple of months — but we made it out alive on the other side with an office we love. The space, much like our apps, will never feel quite “done” as it continues to grow and change with the company, but that’s the beauty of moving into an office that’s truly our own and allows us to evolve beyond what we are right now.

As nervous as we were to take this leap, leaving that small, seven-person room behind was a big accomplishment for us. We needed room to grow and shape our company’s identity, and this new office gives us that. We’re excited to share the beginning of a new era of Lickability with you.

Working with Clutch

Team Lickability — Thu, 18 Oct 2018 00:00:00 GMT

Big news: Clutch has featured Lickability as one of the best app development studios in the US! 🙌 🎉 ✨

Clutch is a platform for unbiased reviews of B2B businesses (like Yelp for app development companies), which we use to give a way for our clients to provide honest feedback about what it’s like to work with us. We’ve thoroughly enjoyed working with Clutch, and they’ve featured us as one of the top businesses using their service for several years now. This year, they released their first-ever report naming the top mobile app developers in every state — and we’re so proud to be included as one of the top companies in New York, alongside studios like Postlight, Stride, WillowTree, Prolific Interactive, and more.

So, what makes Lickability one of the top app development companies in 2018? We’ll let our client work speak for itself. What we love about Clutch is that they speak to our clients directly to curate quality, helpful reviews that give the most accurate insight possible into what it’s like to work with us. We’ve received truly great feedback this way, and we couldn’t be happier:

Their business is a lifestyle for them, so they’re able to contract really talented people.
COO, Mobile App Company

They delivered on time, offered proactive suggestions for improvement, and took pride in their work.
Executive Director & Product Design Lead, The Atlantic

[Lickability]’s place among iOS developers in the world is really high. They are like the rock stars of the iOS scene.
Product Director, Meetup

Being identified as a leader in our industry is a huge honor, and we’re incredibly thankful to be recognized for our work — but it’s all thanks to our fantastic clients. We owe a huge thank you to everyone who has helped support the Lickability team.

The Value of Values

mb bischoff — Sun, 14 Oct 2018 00:00:00 GMT

When we started Lickability in 2009, we didn’t dream of writing mission statements or defining corporate values. We were a couple of high-schoolers in our parents’ houses, working on apps that we wanted to see on the App Store—and later, working on even more apps from our respective dorm rooms.

Lickability started as a side-project and has grown into a larger, more serious operation. Before we even hired our first employee, we realized that it might be a good idea to define what we actually value. How had we worked together over the last few years, and what did we want new folks joining our little team to carry forward?

Lots of corporate values we’d read were highfalutin and impractical. We wanted a document that we could actually use. Here are the values we came up with three years ago when we turned our passion into our full-time jobs that we still work by today. They’re short. They’re simple. And most importantly, we mean them.

Our Values (a.k.a. The Five Flavors of Lickability™)

◾️ Simplicity

Make everything as simple as possible, but not simpler. Inessential complexity is bad design.

🛠 Craft

Pay attention to every detail. Take extra care even when it goes unnoticed.

🔎 Clarity

Build and explain systems as explicitly as possible. Avoid cleverness.

🙌 Collaboration

Ask for help and offer it. We’re better when we work together.

😄 Delight

Have fun. Make things that will help people be happier.

What do these mean in practice? An office full of whiteboards and pair programming sessions (especially when an engineer breaks their arm). Pitching in when your coworker asks you for help fixing a bug, building a desk, or breaking down cardboard boxes. Aiming for fun and delight in our products (like the sparkly animation when you buy colors in Pinpoint) and in our communication whenever it makes sense. Inviting people outside the team into our spaces for more perspective. Painting the back of the fence. Engineering our internal processes and code to be as simple and painless to work within as possible, and when we find something that can be better, like our 401(k) plan, putting in the effort to fix it.

Since we’ve codified these principles, the company has felt more unified in our direction and it’s a lot easier to break the occasional tie when we’re unsure of what to do next. We aim to stay in business for a long time to continue serving our clients and customers. As such, these values have to remain open to change with their needs and our experiences. Like almost everything we work on, I’m sure there’ll be a v2.0.

Home Sweet Home (Screen)

Team Lickability — Thu, 27 Sep 2018 00:00:00 GMT

Everyone’s home screen is different. Some have lots of apps covering the screen, some have neatly-organized folders, some are color-coordinated, some are nearly empty, and some are downright chaotic. The apps you choose to put on your home screen, and the order you choose to put them in, says a lot about you.

So what do our iPhone home screens at Lickability say about us? Take a look below and decide for yourself.

Jillian Meehan

Let me say this right off the bat: I have an intense need to keep all of my apps on one screen. If I ever have a second page of apps, it’s because I’m trying a few out before I decide to fully commit and give them a coveted home screen spot.

I refuse to cover my entire screen with apps because I hate the way it looks, so aside from my dock and my first three rows of can’t-live-without apps (Instagram, OmniFocus, Bear, Drafts, etc.), I’m a big fan of shoving everything into folders that only make sense to me. The best way I can explain my folder system is that my most-used apps live on the first page of each folder, varying in importance from left to right on the screen.

My ⭐️ folder has some of my most important apps, like Citymapper, ClassPass, Slack, and my Simple banking app — all my money-related apps, like Venmo, Clarity, and Digit, live on the second page of this folder.

The 🌈 folder has a lot of productivity-related apps, like 1Password, Notion, and Streaks. The second page of this folder has some more of my “fun” apps, like Co-Star, Supergreat, and Giphy.

My 👅 folder has all of the apps we use or work on at Lickability, and my 🍎 folder has, naturally, a bunch of Apple’s pre-installed apps.

mb Bischoff

As you can maybe tell, I’m a little obsessive and I like things to be clear and well-organized. My home screen is a reflection of my personality and the apps I use every day to do my work and enjoy my life.

I wouldn’t be able to do my work without Messages, Slack, Fantastical, and Spark to communicate with coworkers and contacts. I take tons of photos (read: selfies), so Camera and Photos can never be too accessible. Bear and Day One are where I take notes and reflect. OmniFocus and Drafts are where I get shit done. And Safari, News, Music, Twitter, Overcast, Kindle, Wikpedia, Instapaper and Reeder are where I relax and learn new things. Finally, I want easy access to all the other apps we make and use at Lickability. 👅

Some honorable mentions: I’m bad at sleeping enough, so Streaks tries to help me with that, and Magic is for those times when I’m dreading doing something but I know it has to get done anyway.

Michael Liberatore

Since Spotlight search is incredibly quick to find the exact app you’re looking for, I’ve been far less precious about the organization of my apps in general. That aside, the apps that comprise my home screen loosely fall into three categories.

The first category, which accounts for most of my home screen (literally the top five rows and the dock) includes the apps I use multiple times a day. Additionally, for Messages, Spark, Slack, Things, and my most used social apps, I want to easily see my notification badges, so I like having them visible every time I unlock my phone instead of tucking them away in the unorganized basement storage closet that is screens 2–5.

The second and third categories change frequently. Currently, holedown fills category two: the games I’m playing right now. Games have a fairly short life span on my phone, and if I don’t see it on screen #1, I’ll quickly forget about it. The third category includes apps I’m checking out at the moment, aspire to use more, or have just downloaded and don’t want to forget to try. At the moment, Shortcuts is the only app in this category. I really aspire to use it more to get hooked on iOS automation.

Grant Butler

The apps on my home screen are usually the ones that I use on a regular basis, with the ones in my dock being the ones I use the most. Apart from those, Slack gets a lot of use for work, and Discord for talking with friends. Trello and Airtable are both used for convention planning and management, so having them on my home screen is nice for easy access to that information, especially when it’s the weekend of the event.

Some of the apps on my home screen are aspirational—apps that I want to start using on a regular basis. I’ve got Clarity Money and RECaf, in hopes that by having them on my home screen, I’ll use them often (it’s not really working so far). And Shortcuts is there to prompt me to experiment with it and try to find ways I can integrate it into my regular usage.

I’ve got a folder for games on a separate screen, but there are two that I keep on my homescreen: Crossword and Spelling Bee, both from The New York Times. While I’m not very good at either, I still enjoy the challenge.

Brian Capps

Here’s what Brian had to say about his home screen setup:

(Let it be known that Jillian has never once “searched” “for” “an” “app.”)

Michael Amundsen

I have a wallpaper e-mail I get each Sunday that I update my wallpaper to. This week was green themed.

Generally, my home page has the apps I’m most actively using. Having said that, these days I just swipe down and search for the app I need, because most of the time, either Siri suggests what I’m looking for, or it’s faster to search

It’s kind of interesting that, if I think about it, my primary way of interacting with my phone or computer is to use Spotlight to search and open what I need.

Andrew Harrison

No comment. 😎

Adding a 401(k) for Our Small Business Wasn’t Scary

Brian Capps — Thu, 20 Sep 2018 00:00:00 GMT

401(k)s are hopelessly complicated. At least, as a small business owner looking to add retirement benefits for our employees, that’s how it seemed earlier this year. The retirement market is flooded with indecipherable jargon, deceptive fees, and atrocious software, and the search can seem overwhelming and pointless. However, after hours upon hours of research, we broke the problem down into understandable categories that could apply to any small business, and we could not be happier with our new provider.

What Even Is a 401(k)?

Before diving into the details of our search, it’s important to have a quick refresher on what a 401(k) even is. Put simply, it’s a tax-advantaged retirement plan offered by employers in the U.S., subject to special restrictions and regulations.

Employees can make contributions pre-tax from their paycheck, paying taxes when withdrawing for retirement, or post-tax, withdrawing tax-free at retirement. The employee contributions are limited to $18,500 per year combined in 2018, and there’s a penalty for early withdrawal before retirement. There’s plenty more nuance, but starting from this baseline, it became a lot easier for us to cut through confusing terminology and rules and begin thinking about what separates a great 401(k) plan from a mediocre one.

The Sound of Settling

It’s a lot easier to articulate what would constitute a desirable retirement plan and provider once you realize that you’ve got a poor one. Wanting to become competitive on employee compensation with our larger competitors, and hoping to make life better for our employees in the process, we added a 401(k) plan at the beginning of 2017. Our payroll provider, Justworks (which we absolutely love), partners with a company called Slavic401k to offer plans fully integrated with payroll, so we took the path of least resistance and signed up for it, excited for our new financial future.

The warning signs came on our first paycheck contribution. I checked the numbers and immediately discovered that half the company had incorrect contributions. After Slavic corrected their error, made more, and then corrected them again, we began to suspect that this wasn’t a fluke. More than that, the website was barely usable, unable to easily show simple calculations like overall rate of return or total employee contributions. Finally, when it took 8 months to fully correct a mistake affecting one of our employees—to the tune of nearly $1000—we knew it was past time to switch.

Breaking It Down

When running a business, there is no shortage of large, daunting tasks that seem insurmountable, and breaking them down into achievable parts is a survival skill that served us particularly well when looking for a new 401(k) provider. We wanted a partner who had our employees’ best interests in mind and who made all participants feel confident that they knew how to achieve their financial retirement goals. Here’s the way we categorized those desires into measurable groups:

Fees: The average 401(k) fees for small plans are between 1.5% and 2% of assets. Our provider had total fees for participants of about 1%, which was considered relatively “low.” However, even a 1% fee can have significant effects in the long run, so we wanted to do better. There are potential expenses from providers, advisors, and the investments themselves, but any plan we chose had to have combined fees much lower than 1% for a company our size. This was the most important priority.

Interface: Saving for retirement is chiefly a psychological endeavor, a pattern of beneficial behaviors that can be reinforced and aided by software. For this reason, software quality was an important factor in our search. We wanted the interface to provide a glanceable overview of how much money is in the account, where it came from, and what returns the investments have earned. Operations like changing contribution amounts or portfolio allocations had to be simple and understandable for those without a degree in finance, in order to encourage greater participation and contributions with a lower barrier to entry.

Fiduciary: It almost goes without saying, but most financial companies are focused solely on enriching their shareholders and do not give one shit about their customers. The only way to try to ensure that one considers your interests is when they have a legal obligation to do so. A law called the ERISA defines several types of opt-in fiduciary responsibilities that require advisors to act in a client’s interest in various ways. The highest standard of care is a 3(38) investment manager fiduciary, who must act in the client’s best interest on many levels, including choosing and monitoring investments and keeping fees reasonable. We wanted to work with a company who was willing to adhere to these stricter standards and liability under the law.

Reviews: This one is pretty self-explanatory. If customers wrote a bunch of negative reviews about the company, that wasn’t a good sign.

Customer Support: I once had a Vanguard customer service employee laugh at me for asking a stupid question over the phone. This stuff can be confusing sometimes, and no one deserves that, so the bar here was “likely won’t laugh at those asking beginner questions.”

The Results

After establishing the rubric for evaluating our options, we got to work comparing the candidates listed as the “top” or “best” for small businesses according to Google searches. The results for these large to medium players in the industry were abjectly abysmal, as you’ll see below.

Yikes. Our investigation showed a complacent 401(k) industry full of inferior products. Luckily, we’d expanded the breadth of our search to include firms with hundreds of millions of dollars under management and fresher approaches, not just the trillions and billions held at the stale companies shown above.

While we didn’t have great results with some of the most established companies, there were three more customer-focused ones that really stood out. Human Interest, an oddly named robo-advisor, had decent fees (about 0.58% for participants) and helpful, knowledgable employees. Betterment for Business, the 401(k) offering of personal investment robo-advisor Betterment, provided plans with reasonable, transparently low fees (about 0.35% for participants), best-in-class software, and solid reviews. And finally there was Guideline, a newer entrant that the founder of TaskRabbit started in 2015, which had absurdly low fees (about 0.06% for participants), useful and pretty software, and nearly limitless payroll integrations. Each one of these companies would take on 3(38) fiduciary responsibility with no added fees and had some great reviews, and I’m confident that any one of them would have worked well at our business — there could, however, be only one winner.

The Winner

The clear choice for us, and hopefully for many others, was Guideline. Their fees of only $8 per employee per month for the business and picks of low-cost investments with average fees of only 0.06% for participants are shockingly reasonable, putting the rest of their competitors to shame (and no, this is not a sponsored post!). They make it easy to choose a portfolio by asking participants about their risk tolerance and recommending a plan, while offering an extensive fund menu for more advanced users who would like to make their own. And, as if that weren’t enough, their software is beautiful and functional, and their representatives are helpful and professional.

Here are the Slavic and Guideline slides from my very professional presentation on switching

Although adding a 401(k) or changing your provider can seem intimidating, it’s simpler than it seems, and can make a real difference in your employees’ lives. If you run a small business, I would highly recommend spending some time to pick the right option and discuss it with your team. Hopefully, our experience switching providers can yield some useful insight into how to best evaluate your choices when you do. It may be scary, but the only thing you truly need to fear is disappointing your employees by not offering any retirement plan at all. And spiders. Spiders are terrifying.

Conferences We Know and Love

Team Lickability — Thu, 13 Sep 2018 00:00:00 GMT

We’re big fans of conferences. Why? Because they give you the opportunity to step away from your desk, expose yourself to new ideas and practices, and meet lots of cool, interesting people in your community.

Conferences are extremely valuable — if you pick the right ones to go to. But maybe you’re not sure where to start. Or maybe you’re curious about a particular conference, but want to hear from someone else about what it’s like before you commit to buying a ticket.

We’ve got you covered. Here’s a look at some of the conferences we love attending. Some of these conferences are no longer around (r.i.p.) but most of them are still going strong. Maybe we’ll see you at one of them next year. 😉

try! Swift

New York, New York

try! Swift is a really good conference for the community in NYC. It’s great for networking, exposure, and talking to people. I find the most value in the community-building part. Oftentimes, the office hours to talk to the speaker after their talk is the most useful thing.

– Michael Amundsen

You might like try! Swift if: you’re a developer at any level (beginners included!) in New York City looking for pals and mentors as you learn more about Swift.

Sponsoring a diversity scholarship at @tryswiftnyc is one of the easiest decisions we make every year. @NatashaTheRobot and co. do an incredible job organizing, and it’s such a clear way to promote a more inclusive iOS community in our city. https://t.co/ov17FHbzUt

— mb Bischoff (@mb) September 4, 2018

Layers

Wherever WWDC is

Having never been to WWDC in my life, I feel that I can confidently say that Layers is the better conference of the two. For the unfamiliar, Layers is a three-day design conference that takes place in the same city and during the same week as Apple’s conference. It is (as you would expect) an incredibly well-designed event, with fantastic speakers, great snacks, and a pretty bomb party at the end of the week. My favorite part is the size—there are plenty of awesome people to meet, but it’s intimate enough that you won’t be too overwhelmed.

– Jillian Meehan

You might like Layers if: you want to be around the WWDC hype, but you don’t actually want to go to WWDC.

The better WWDC

XOXO

Portland, Oregon

I just got back from my first XOXO last week, and all I can say is that it was magical. Aside from the great speakers, the arcade full of soon-to-be-released indie games, and the karaoke bar that was popping every night, the community of people from all corners of the internet that XOXO manages to bring together is fantastic. It’s hard to imagine a conference that’s more well-organized and cares about its attendees more than this one.

– Jillian Meehan

You might like XOXO if: you want to meet your internet friends IRL and start up a new side-hustle with them.

The main stage at this year’s XOXO was 🔥

Release Notes

Chicago, Illinois

Release Notes is a conference about the business of making and releasing software. Coming out of a podcast of the same name, Joe and Charles book incredible speakers year after year (oh, and me once, also). It’s great because we head people sharing real numbers, and stories about how they have or almost failed at making their business sustainable, and even sometimes what actually happened to work. Good pals, good talks, and a dine-around where you get to explore the city at a small dinner with other attendees, I couldn’t ask for a more thoughtfully curated conference.

– mb Bischoff

You might like Release Notes if: you run a software company, are trying to figure out how much to charge for your app, or are scared of marketing.

tbt to mb speaking at Release Notes

CocoaConf Yosemite (r.i.p.)

Yosemite National Park

My favorite conference experience in my years in Apple development was Yosemite by CocoaConf. While the speaker lineup was of incredibly high quality, what set this conference apart from the rest was its location in Yosemite National Park, arguably one of the most beautiful places in the country. Between sessions, there were guided hikes and photo walks around breathtaking mountains and waterfalls. The setting made it easy to leave the stresses and anxieties back home and give full attention to the wonderful talks from the incredibly talented speakers.

– Michael Liberatore

You might like Yosemite if: you enjoy technical talks and networking while fully disconnecting from the worries back home (or you just want an excuse for work to pay for your hiking trip).

The actual conference was cool, too

Úll

Killarney, Ireland

Úll is magical. It takes place in Ireland, and it’s expensive, but everything is taken care of. When I’ve attended, it’s boasted an amazingly diverse set of speakers, experiences, and a much less US-centric crowd. You ride a train across the Irish countryside with your fellow attendees, stay in a hotel with gorgeous views, and learn from folks in all sorts of industries about how they put care and detail into their work. There have been talks, storytelling, science fairs, escape rooms, and so much more. It’s a venue where I was comfortable giving my most vulnerable talk ever, a storytelling slot I used to publicly process the death of Quotebook. If there’s another Úll and you have the money, just go. You’ll see.

– mb Bischoff

You might like Úll if: you’ve never been to Ireland, you “trust the process,” or you feel creatively stuck on what to do next or why your work matters.

How is this a real place?

What else?

We’re always looking to expand our horizons, conference-wise, and there are tons of great events that we’d love to check out but haven’t gotten a chance to. If there are any conferences you love and want to spread the word about, let us know!

A Tale of Two App Store Spotlights

mb bischoff — Thu, 06 Sep 2018 00:00:00 GMT

Some good news for Lickability’s products! A few weeks ago, both of our iOS apps (Pinpoint and Accelerator) were simultaneously featured on the App Store after recent updates we’ve made.

We saw significant spikes in downloads and sales, and because they were featured at the same time, we saw a small but noticeable halo effect from customers who mentioned that they picked up both apps at once.

🎉 The Features

The App Store editorial team featured Pinpoint in a roundup of 5 Apps We Love Right Now on the Today tab, and Accelerator under a similar heading on the Apps tab. It seems like the folks over in editorial have a lot of ❤️ for Lickability these days.

📈 The Results

So, what’d these features do for our apps? Let’s hop on over to AppFigures, the service we use to monitor sales and downloads, and look at some graphs.

Here’s what the features did for Accelerator’s sales:

Accelerator sales graph Aug 9–Aug 22

And for Pinpoint’s downloads:

Pinpoint downloads graph Aug 9–Aug 22

As the graphs show, for both free and paid apps, getting featured on the App Store can have a pretty massive impact. In our case, we saw a 9,000% increase in average daily downloads of our free (with IAP) app and a 900% increase in downloads per day for our paid up-front app.

⏳ More to Come?

Apple also requested artwork to feature both applications a few weeks ago, but hasn’t used it just yet. Here’s a sneak peek of some art you might see soon on an App Store near you…

If you’re looking to get your app featured by Apple, start by making something great (we can help with that part 😉) and getting it in the hands of customers. Once you’ve worked out the kinks and are ready for some more attention, check out Apple’s Marketing Resources and the Release Notes podcast for tips on getting the attention of App Store editors. We hope to share the limelight with you soon!

Slack is for Friends, Too

Jillian Meehan — Thu, 26 Jul 2018 00:00:00 GMT

Because we’re a small company, we like to make an effort to welcome people outside of our 7-person office into the Lickability community. The best way to do that, we’ve found, is to invite friends (and friends of friends) of the company to join the Lickability Slack.

How?

The full-time team at Lickability has 7 people, but the #general channel in our Slack has almost 30 members. That’s because we’ve filled it up with smart, interesting people who we find valuable to have in our virtual office. #general (and other public channels like #food and #music and #games) is our water cooler; it’s a place where we can take a quick break from work and catch up with our friends. Or, in our #ask-anything channel, we can ask and answer questions anyone in the Slack might have — about engineering, designing, running a business, etc. We’ve also invited beta testers into our Slack as single-channel guests to give them a place to discuss the app they’re testing and give us direct feedback.

Our community extends outside Slack, too. We were lucky enough to meet up with some of our Slack members in San Jose at WWDC, and a few of us who are based in New York got together last week for drinks at one of our favorite cocktail spots in the city.

Why?

The bottom line is we love our pals and we’re lucky to have such a great group of people in our community. Opening up our Slack to friends of the company has undeniably made our work life better. We’re not a large company, so it’s nice to bring in more folks to foster discussion, get different opinions on things, and just generally have a good time.

Should I do it too?

It depends. We’ve found a lot of value in having friends in our Slack, but there can be downsides. We have to keep most work discussions locked down in private channels, and (as anything) it can be a bit distracting to have non-work discussions on the clock. This might not be the best Slack strategy for larger companies, but we ultimately recommend it for anyone looking to foster a better community at work. Here’s how to do it:

If you’re not sure who to invite to your own office Slack, look for people who share the same vision and goals as you, people you like working and getting lunch with, and a healthy mix of people both in your city and in others—the point is to get out of your small company bubble and to bring fun discussion and fresh perspectives into the mix.
There’s no need to keep everybody confined to #general. If you don’t already have public channels for people to talk about things happening outside of your office, make some! A few of our favorites are #food, #games, #music, and #politics.
We recommend making a Code of Conduct if you don’t have one already. It’s good to lay down a few ground rules for what’s okay and what’s not if you’re inviting people outside of the company in.
Don’t forget to hang out with your Slack friends IRL sometimes! It’s cool to chat online, but it’s even cooler to make an effort to see people face-to-face when you have the opportunity.

We certainly don’t have all the answers, but this is what works for us. If you decide to try it out, let us know! Or, if you’re a friend of the company and want to join our Slack, get in touch with us on Twitter at @lickability. We’d love to have you.

🐞 Insidious Bugs #2

Grant Butler — Thu, 12 Jul 2018 00:00:00 GMT

The Bug

When setting up a scheme to wait until the app is launched to attach the debugger, performing a “Build & Run” will build the app and prepare it to be launched, but will not deploy a new app bundle. Because of that, you won’t see bug fixes or the effects of other code changes you may have just made.

The innocuous-looking setting

The Solution

To make sure that any changes we make are deployed, we first need to set up the scheme to automatically launch the app, perform a “Build & Run” to deploy our changes, and then switch the scheme back to waiting for the app to launch to attach the debugger.

How We Got There

We came across this issue while expanding on the Today Extension built out in our first Insidious Bugs post. To recap, we had built a Today Extension that is given a set of tweets from its host application, and then displays those tweets in a table view. This has been working well, but we want to give the user a way to see more details about the tweet in the host application. Thus, we went about adding functionality to open a tweet when you tap on it in the Today Extension.

To achieve this, we came up with a URL scheme for our host application to support, along with a URL structure to allow deep linking to a specific tweet. Upon receiving the deep link, the host application would create a view controller to show the tweet and push it onto the navigation stack.

To test this functionality, we switched the “Launch” setting in the scheme to “Wait for executable to be launched,” built and ran the app, opened the widget, and then tapped on a tweet. The app launched, but the details on the tweet we tapped in the widget didn’t show up.

This was certainly not what we expected so we set a breakpoint at the start of our application(\_:open:options:) delegate method, and re-ran the app. Sure enough, our delegate method wasn’t being called. Wait, what?

This definitely didn’t seem right. The first thing to do was double check documentation and confirm that we implemented deep linking correctly. The docs confirmed that we had implemented the correct delegate method, and added the appropriate information to our Info.plist.

After consulting documentation, we tried reverting how the app launched when we did a build and run, switching back to having the app launch automatically. The app launched, we minimized it, went to our widget, and tapped a tweet.

It… worked?

Huzzah! Deep linking was successfully implemented. However, we were still unsure of why it didn’t work when we waited to attach the debugger until the app was launched. This required further investigation.

The first step was to switch back the launch setting. Then, we changed the background color of the tweet detail view controller (a low effort change to make, but one with a big impact that was easy to verify). We built and ran the app and tapped on a tweet in the widget. The app deep linked into the detail view controller and, as we expected, it did not have the new background color.

This seemed to confirm suspicions that if we had the “Wait for executable to be launched” option selected, while Xcode would build the app, it would not actually deploy the newly built app. To confirm our hunch, there was one last thing we could do: we could delete the app from the simulator. If our suspicions were true, then doing a build and run with “Wait for executable to be launched” should not install the app, which means we shouldn’t see its icon anywhere on the home screen.

We deleted the app from the simulator, built and ran, and took a look at the home screen. Lo and behold, the app was nowhere to be found. With this final bit of confirmation, we felt confident that our hypothesis was true.

Radar

We’ve filed a bug report with Apple to get this issue fixed:

Build & Run While Waiting to Attach the Debugger Does Not Redeploy an Application (41436011, closed as a duplicate of 22866783, which is still open)

Our Week in San Jose

Team Lickability — Thu, 14 Jun 2018 00:00:00 GMT

If you spent any time on the internet last week, you may have noticed that a few of us were in San Jose for a little event known as WWDC. Now we’re back, and we can’t wait to tell you all about it!

#WWDC18 🎉

mb, Brian, and Jillian (hi 👋) all flew out to California for a smattering of conferences, live podcast recordings, and pin exchanges. mb was Lickability’s person in the field at WWDC all week, while Brian and Jillian attended Layers for three days of snacks, fun design talks, and more snacks.

You know what it is.

Everyone back at Lickability HQ enjoyed WWDC too. The day of the keynote, we had mb watching at the conference center, Brian and Jillian watching via iPad in a hotel room, and the rest of the team watching on the big screen over pizza back in New York.We’re all still catching up on WWDC videos, but here are some of our favorites from last week:

What’s New in Swift

Michael Liberatore:

I love seeing Apple highlight the open source efforts of the community, and Swift’s constant quality-of-life improvements have me excited for the future. I ❤️ CaseIterable, and that Equatable and Hashable can now be synthesized!

Designing Fluid Interfaces

mb Bischoff:

I liked Designing Fluid Interfaces because they showed a ton of custom rendered videos that explained how and why they made the iPhone X feel so fluid to use.

Getting the Most out of Playgrounds in Xcode

Michael Amundsen:

I don’t use Playgrounds much, but I think they did a good job at explaining some real world use cases of why you should use them even as part of a normal project.

The Life of a Button

mb Bischoff:

It takes something so small (a single button) and walks through the entire design process of how it should work, behave, be titled, etc.

Adding Delight to Your iOS App

mb Bischoff:

It made me think a lot about “Layout Driven UI” which is not something I’d seen written about or described much before.

Michael Liberatore:

I really like these kinds of sessions that are not introducing anything new, API-wise, but provide alternative ways to think about writing code with the same frameworks and tools.

We also ❤️ Layers

None of the talks from Layers are available to watch online (yet), but we want to give a special shout-out to a few of our favorites: Majd Taby gave a very moving talk about his journey toward co-founding Darkroom and creating Displaced; Litha Soyizwapi’s story about developing and designing the GauRider app was inspiring; Ryan McLeod had a magical presentation about sleight of hand in digital design; and Jessica Hische is a fantastic speaker and one of our favorite people. If you get a chance to go to Layers next year, do it.

Here we go! 😅🤞🏻#layersconf pic.twitter.com/0NRB0KESl7

— Ryan McLeod (@warpling) June 6, 2018

See you next year! 👋

A very lickable dinner at The Farmers Union 👅

We were lucky enough to catch up with a bunch of our friends while we were in San Jose, and even luckier to meet so many people we didn’t know before. One of our goals for the week was to hand out Lickability pins and stickers to as many people as possible, and we definitely pulled it off — we don’t have a single Lickability pin left. If you got one, give us a shout-out on Twitter or Instagram so we can see it in its new home! And if you didn’t get one, let us know — we’ll make sure you get one next time.

Inside Lickability HQ

Jillian Meehan — Wed, 16 May 2018 00:00:00 GMT

We’ve been in our current office for almost a year without adding our own Lickability flair to it. Save for the logo on the door and the people inside, it could have been anyone’s office. But in the past few months, we’ve started redecorating the space to make it more our own.

It’s important to us to feel comfortable and motivated at work—that’s why we give every new employee the opportunity to build a workstation setup they love. We thought it was about time to do the same with the rest of our office.

Before this project, our office felt like a generic glass cube. Now it feels like a space where a bunch of creative nerds can come together to make jokes, make apps, and have a cider after work once in a while.
mb Bischoff

Step 1

The first thing we needed was art. We could have gotten any generic art pieces to liven the space up, but we wanted something that felt like us. So we started with fracture art of icons for apps we’ve worked on — some of our own, like Quotebook (r.i.p.) and Pinpoint; and some of our clients, like Aloe Bud and The Atlantic. It’s nice to have a reminder of the work we’ve done hanging on the walls like a motivational poster. Plus, they add lots of great color to the space.

Some of our fractures for Meetup, Quotebook, and New Yorker Today.

Step 2

Next: plants, a staple of any office. But before you can have plants, you need something to put them in. So we reached out to Brooklyn-based ceramicist Marian Bull for custom, Lickability Red planters, and we couldn’t be happier with the result. Marian’s work added much-needed personality to the office. From there, we filled our new planters with (easy to care for, we hope) plants from The Sill. We’re going to try to keep these ones alive for a while.

We ❤️ our new pals

Step 3

And for the bonus round: we got Lickability-branded enamel pins and hoodies for the whole team! Thanks to Pin Game Strong and Corporate Couture, we look just as great as our office does.

Our new pins and hoodies look so good you’ll want to lick them (but maybe don’t).

Profit

In the last few months, we’ve succeeded in adding all of the above to some of the small, already-existing details that make our office fun: our standard new employee welcome kit of chocolate, pens, notebooks, and baby succulents; a reliable supply of Sour Patch Watermelon, our favorite 3 p.m. office snack; and our frequent use of Coffee Runner, a Slack app that we tend to use more for snack runs than for Blue Bottle trips (though we use it plenty for the latter as well).

Our goal wasn’t just to decorate our office, but to decorate our office in a way only we could. We wanted to add life and personality to a space that was essentially just a tiny room full of desks and computers — and we did. We’ve always loved where we work, but now we love it just a little bit more.

Though some of these tweaks are small, they’ve really helped to add personality to our space. Our fractures hang like trophies from the projects we’ve been proud to be a part of, and it’s an exciting motivator to continue filling the walls with even more.
Michael Liberatore

Aloe Bud is Here 🌱

Jillian Meehan — Tue, 01 May 2018 00:00:00 GMT

Self care is important to us at Lickability. But, like everyone else, we sometimes struggle with remembering to take care of ourselves—sitting at a desk for hours at a time, working through lunch, and forgetting to drink water all day is not a good way to live.

That’s why we’re thrilled about the launch of Aloe Bud, the self-care pocket companion we’ve been working on with Serenity Discko. After a successful Kickstarter campaign last summer, nine months of designing and developing the app, and several weeks of beta testing, Aloe Bud is finally available for free on the App Store for all your self-care needs.

What it is

The idea for an app that sends gentle reminders to eat, drink water, and take breaks throughout the day was born out of personal necessity — Serenity wanted an app to help with basic self care and everyday mental health struggles. That app didn’t exist, so when they came to us with their vision, we were happy to turn it into a reality.

Whether you’re having a stressful day at work or you’re trying to relax at home, getting a notification that says “Breathe; it’ll be okay” might be exactly what you need to get through the day (or even just the hour). Aloe Bud makes it easy to set up reminders like this to remind you to do all kinds of activities, like drinking water, reaching out to talk to a friend, taking your medication, and getting up to move around.

How we built it

From the beginning, Aloe Bud was built to be as simple and straightforward as possible, with the ability to expand and customize it in the future. This is why it’s written with the latest version of Swift 4.1 for iOS 11.

Aloe Bud works almost completely offline with local notifications that only users can set up, and all user data is stored on-device only, taking advantage of Core Data for persistence. There’s no need to sign up for an account or connect Aloe Bud to your social accounts—this keeps users in control of driving their own self care experience, allowing us to lower the barrier to entry when it comes to self care. Another added benefit: a user’s data is kept private, only accessible to them.

We are also proud to incorporate open-source work from the iOS community in this app, including extensive use of Static for various parts of the UI and SwiftyStoreKit for in-app purchases. It would have been far more difficult to complete everything along our timeline without the use of these and other thoroughly-reviewed, well-tested libraries.

Now that Aloe Bud has launched, we couldn’t be happier with the reception — the app has been featured in the App Store, TechCrunch, and Bustle, and has received lots of positive feedback online. We’re glad you like it as much as we do! 😊

We were also lucky to work with such a talented team of people. Making the app wouldn’t have been possible without the hard work of all of these fine folks:

🌙 pixel art @galactic_castle
🖌 design @tinkadoic
🎶 sounds @Drainpuppet
📝 copywriting @jersing
📱 dev @serenitydiscko & @lickability
🤓 research @jeansgallo
🙏 sincere thanks to 1,538 Kickstarter backers who brought this simple idea to life! 🌱 https://t.co/ULTIkM5pCk

— Aloe Bud ♡ (@aloebud) April 27, 2018

Aloe Bud is available to download on the App Store. Try it out and let us know what you think by leaving a review or @-ing us on Twitter.

🐞 Insidious Bugs #1: Today Extensions

Michael Liberatore — Mon, 16 Apr 2018 00:00:00 GMT

Today Lickability is relaunching Insidious Bugs on our blog. Insidious Bugs is an occasional series in which we share stories of overcoming obscure issues in iOS development with the goal of saving you the time we lost, should you encounter the issues yourself.

The Bug

In this first entry, we conquer an instance of Xcode’s friendly “This app could not be installed at this time” message. We encountered this when attempting to run our project that includes a Today Extension, or widget, in the iOS Simulator.

Uhhhhhhh… okay?

The Solution

Would you believe that all it took to solve this issue was this seemingly useless file? Well, that and many, many hours of failed attempts.

How We Got Here

“This app could not be installed at this time” doesn’t give us a lot to work with, but let’s explore the somewhat unique setup that got us here.

We recently added Today Extensions to multiple projects, which all share the same layout. We tend to keep things DRY (don’t repeat yourself), so we made our approach generic and reusable across multiple projects via a shared framework. In our framework, the Today Extension displays an arbitrary number of cells that have a thumbnail image and two labels. The framework doesn’t care what type of content is to be displayed, whether it’s social media posts, news, reminders, etc.—it simply formats and displays the data written to the shared container by the host app in the exact same way. Here’s an example:

You’d buy this app, right?

Hooray! This will save us time and tedious boilerplate as we add our Today Extensions to our projects. We simply need to add the framework and associate the view controller in MainInterface.storyboard (part of the Today Extension’s target) with the one found in the framework. At least that’s what we thought. Everything compiled just fine, but we couldn’t debug our app. “This app could not be installed at this time.” 🤔 Since Xcode’s message didn’t point us in any particular direction on how to resolve the bug, we searched log files for anything that was amiss. Every time we’d attempt to build and run, a message similar to the following was printed to mobile\_installation.log.0 within the simulator’s logs folder:

text

<err> (0x700008983000) -[MIExecutableBundle makeExecutableWithError:]: 1162: Failed to chmod /Users/Michael/Library/Developer/CoreSimulator/Devices/51417E58-232D-45D5-9DAB-EB4C6F0AA301/data/Library/Caches/com.apple.containermanagerd/Bundle/Application/0D7DF887-D2D6-45F7-86DB-AACE8F2AE875/LickabilityTweets.app/PlugIns/TodayExtension.appex/TodayExtension : No such file or directory (NSPOSIXErrorDomain:2 (null))

This error was more descriptive, but still didn’t lead us to a solution. “Why wouldn’t the app extension exist on disk after a build succeeded?” we asked, before making dozens of trial and error attempts across several hours to no avail.

Eventually, we found that moving the view controller back to the Today Extension target would resolve the issue, but we weren’t satisfied with duplicating that file across multiple projects. In a stroke of genius (read: luck) we asked each other, “Wait… is it the fact that the view controller needs to be a part of the extension target, or is it just that we linked something to the target that made the difference?” After all, our “Compile Sources” build phase required nothing, since by design, any executable code used by the widget would live in our shared framework.

What a lonely target 😢

So we just added something to our target to see if it made any difference. A single Swift file without any code.

😠😡😭

We thought we had it. But at least we could build and run now. On launch of the Today Extension target, Xcode’s console would display the following:

text

Unknown class \_TtC19SharedExtensionCode19TodayViewController in Interface Builder file.

It seemed as though despite the fact that we were selecting the appropriate view controller class from the appropriate framework within MainInterface.storyboard, our class was still nowhere to be found at run time. After much more trial and error, we added a bit more code to FixEmptyTarget.swift. We wanted to make sure everything was properly linked. We imported our shared framework into the file to see if it built (it did) and wrote some test code to see if we could actually make reference to the view controller class (we could). 🧐 “How come we can reference this view controller from a different framework in code, but not in a storyboard?” we pondered. We tried running this, just to see if anything more helpful would print to the console with our reference to the disappearing view controller in code, and…

Whaaaaaaaaaaaaaaaaaaaaat 🤯

Michael: That… did it?
Andrew: It’s time to relaunch Insidious Bugs.

Simply referencing our view controller in code and adding an otherwise useless file to our target solved this mysterious series of problems, and now we finally have our Today Extension framework. The full, documented version of FixEmptyTarget.swift looks like the following:

Bananas, right? We sincerely hope you don’t encounter an issue like this in your travels. And if you do, we hope this post helped you get back up and running quickly!

Radars

Here are the bugs we’ve filed for Apple about these issues:

Today Extension with no linked files fails to install in the simulator (39237943, closed as intended behavior)
Follow-up: Difficult to understand error message with today extension that has no linked files (39974757)
View controller referenced only from a storyboard not found at runtime (39238390, Closed as duplicate of 4691676)

Tools of the Trade

Jillian Meehan — Thu, 22 Mar 2018 00:00:00 GMT

Running a small software company can be daunting — what are you supposed to do? Where do you start? How do you get help? Our company, Lickability, wouldn’t exist today without a few (okay, more than a few) sharp tools at our disposal to make our lives easier.

Some of our favorites—Google Apps, Xcode, and AppFigures, for example—go all the way back to when Lickability was born in 2009. The more recent additions we can’t live without are Danger, SwiftLint, and 1Password for Teams, which we’ve picked up in the last year. The list only continues to grow.

We’ve dedicated lots of time to researching and testing various applications and services that help us do what we do, and we want to share them with you. Consider this a love letter to all the apps we couldn’t live without.

Code

We are a software company, so (surprise!) a lot of the apps we use are designed to make development go as smoothly as possible — from designing to coding to shipping.

Xcode + Sketch

We literally wouldn’t be able to do what we do without Xcode. It’s got everything you need to make great iOS apps, so it’s really no surprise that it’s first on our list. Xcode has been with us since the very beginning, and it will (hopefully) be around for a long time. It really is the backbone of our work.

Of course, making great apps isn’t just about writing code — apps need design to come to life. Sketch is our go-to tool for making the design documents that later become beautiful apps.

Xcode: For building and maintaining apps like Pinpoint and Accelerator.
GitHub: For collaborative development, version control, and code review.
Tower: For using git, but even easier than the command-line.
SwiftLint: For writing clean code and sticking to our style guide.
Danger: For preventing us from making silly mistakes in pull requests.
Buddybuild**: For easy-to-control build deployment and testing.
Paw: For testing and learning about APIs we interact with.
Dash: For faster and easier lookups in Apple’s documentation.
Charles Proxy: For inspecting the network traffic of our apps.
TextMate: For when all you need is a reliable text editor that works.
Sketch: For drawing pixel-perfect icons and screens for our apps.
Zeplin: For collaborative design and delivering specifications.
xScope: For measuring and perfecting iOS graphics.

Customers

Communicating with customers and clients is a crucial part of any business. These are a few of our favorite ways to keep in touch with you.

Harvest + Xero

Harvest powers all of our work by keeping track of how we spend our time, every hour of every day. It keeps us on task and keeps our clients in the loop about what we’re working on, while also handling all of our estimates and invoices. Harvest also automatically syncs our invoices with Xero, the bookkeeping software that helps us (and our accountant) check in on our finances.

Harvest: For keeping track of time spent working on projects.
Xero: For keeping track of invoices, expenses, and revenue.
AppFigures: For tracking app sales and finding out when we’re featured.
Helpshift: For delivering better customer support.
MailChimp: For sending newsletters to keep you up to date with what we’re working on.
Medium: For writing and publishing this blog. 😎

Communication

And, of course, internal communication is what keeps Lickability running. We like to use tools that make it as easy as possible to keep up to date with everyone at the company and what they’re working on.

Slack + Google Apps

Slack is our hub; it’s the glue that holds us all together. Populated by our entire team, plus a few people we love to chat with during the day, the Lickability Slack is a one-stop shop for asking questions, giving feedback, and making fun of each other’s tweets.

Some of our most-used tools on a daily basis are Google Apps like Gmail, Calendar, Hangouts, and Drive. Having all of our files, schedules, and conversations in one easily accessible place helps keeps us organized like you wouldn’t believe.

Slack: For giving us a space to talk to (and joke with) each other.
Basecamp: For keeping us on top of our to-dos and checkins.
Google Apps (Gmail, Calendar, Hangouts, Drive): For keeping track of everything — important files, dates, and conversations.
Bear: For taking beautiful Markdown notes.
Justworks: For simplifying the payroll and benefits process.
Recruitee: For organizing the hiring process.
1Password for Teams: For locking down and sharing all our team logins.
Giphy/GIFBrewery: For making gifs! Enough said.

Although these are the tools that have worked best for us the past few years, we’re always looking for better ways to serve our clients and customers. So if you’ve got the inside scoop on an app or service you think we’re missing out on, let us know! You can reach out to us on Twitter at @lickability. 💌

How We Smoke Test Pull Requests with Git Revert

Michael Liberatore — Mon, 26 Feb 2018 00:00:00 GMT

You’ve been there: you get assigned to review a pull request for a work-in-progress feature you know little about, and you have trouble seeing how it all fits together with the work that’s yet to come. The code looks good, but you’re hesitant to add your stamp of approval and hit the merge button. Even with thorough UI and unit tests, you want to test the new feature and see it in action yourself, just as the author did during development. Rather than making the reviewer follow a complex set of instructions to add code or print statements to verify that the in-progress feature is working, we’ve landed on this one weird trick. Internally, we call it the “git revert trick.”

An example of the git revert trick in action!

How It Works

When a developer is unable to provide clear “How to Test” steps without requiring additional complicated changes, they can now commit and revert the test code that they used to initially smoke test their feature and provide the git command necessary to re-stage the test code in the reviewer’s working copy. The command is git revert -n <revert-test-code-sha>. This reverts the removal of the test code, with -n (short for --no-commit) preventing the revert from being committed, allowing the user to see the working copy changes and easily discard them when they’ve finished testing.

We now frequently make use of this command in our pull request reviews. It removes room for error in the reviewer’s setup process, provides in-context and diff-able code for exercising the changes, and prevents any throwaway test code for in-progress features from ever getting merged.

See it in action in our open source library PinpointKit and let us know what you think of this technique here or on Twitter at @lickability.

Shelf: A Retrospective

Michael Amundsen — Thu, 01 Feb 2018 00:00:00 GMT

It’s June 5th, 2017. WWDC’s Keynote is in progress, and the Lickability team is spread across the auditorium in San Jose and our office in NYC when Apple unveils the iOS 11 updates coming to iPad. We are instantly excited about drag and drop.

In the aftermath of all the announcements, we quickly gathered to discuss building something new for the release of iOS 11. We were inspired by Federico Viticci’s iOS 11 iPad wishes and concept video and wanted to make the “shelf” concept a reality. During the past summer, Lickability was busy dragging and dropping away to deliver our vision of that concept: Shelf. Though we ultimately chose not to ship the app, we wanted to share with you our journey throughout the process.

Exploring Shelf

Shelf was to be a tool for iPad power users to temporarily (or permanently) store and organize groups of items to drag and drop. It would become a scratchpad full of the stuff you’re working on and frequently need to reference or drop into other apps.

By being able to run in full screen, split view, or slide over, Shelf would always be available to use to quickly access items while working. Drag some items in from apps like Photos, Safari, or Maps, and then drag them back out when needed. This would help to reduce time spent looking for that thing you know you sent a few days ago.

Design and Development Approaches

From a design and development standpoint, we wanted Shelf to display rich previews of the majority of the item types you would drag and drop. We identified these main categories for that:

Images
Text (Plain or Rich)
PDFs
Map Locations
Contacts
Phone Numbers
Email Addresses
Links
Files

Design mockup of file categories

It was also important to us to support the concept of “stacks” of files that would function like folders when in Shelf and drop as multiple items when dragging out. These two primary features were where we wanted to provide a rich user experience.

We hired a designer, Jeremy Swinnen, and got to work, focusing on making the data models as generic as possible while maintaining the desire to keep the highest fidelity data.

We watched all of the drag and drop WWDC video sessions and explored all the sample code to figure out the API’s capabilities, navigating API changes and various bugs throughout the process. We were on the bleeding edge, so if something wasn’t working correctly, it was up to us to figure it out — all while trying to make sure Shelf would be a consistent and reliable experience.

Left: Stack concept. Right: Quick Look mock-up.

Challenges and Takeaways

One of the best parts of working on Shelf was for us as a team to take an idea from brainstorming and try to have an app ready for launch day. We now have a deep understanding of the ins and outs of the drag and drop API, as well as many of its quirks, which has made applying this knowledge to our other projects a breeze.

On the flip side, we should have taken a look at the new APIs as a team and had a prototyping day to validate what we thought was achievable on an accelerated timeline. This would have allowed us to better estimate how much time we needed to dedicate to the project and when we needed to be in alpha and beta.

Reaching beta on the later side of “beta season,” we realized that we may not have identified the most useful features. It became clear from the competition that being able to store data in multiple different representations was important—for example, dragging in a markup document and dragging it out as the original file, an image, a rich text file, or plain text.

We ended up with a way to generically store any data in Shelf, at all representations, but this had significant impacts on our architecture rather late in the development cycle. It also took a lot of time away from making sure we had as many rich preview representations of files as possible.

Working with a beta API is always challenging. We found the rough edges of the API, particularly with trying to handle placeholders and various pieces of making “stacks” of items work. There came a point where we were writing a work-around for a work-around, because a particular private file format was broken mid-beta and didn’t get fixed by release.

Why We Didn’t Ship

With the late beta of Shelf and the release of iOS 11, we quickly discovered we did not have the right combination of features. While Shelf had one of the best user interfaces, we felt we didn’t have enough of some of our competitors’ major features to justify investing more time. The last thing we wanted to do was release an app we wouldn’t want to invest more time in.

There also were some outstanding issues that hadn’t yet been solved in a way we felt was high-quality enough. For example, there was a point where we could reliably crash our app, as well as all of our competitors’ apps, with a use case we felt was core to the Shelf experience.

We believe apps like Shelf will be vital in moving the platform forward as a productivity device, but the current user base and market doesn’t seem to be large enough for these kind of products just yet. It may be a few more years until enough people are using their iPads daily for “power user”-level productivity.

Rather than release an app that we didn’t feel reached our high standards, we decided to shelve Shelf and instead take it as an incredible learning opportunity for the entire team. In the words of Ms. Frizzle, “Take chances, make mistakes, and get messy.”

New Year, New Site

Jillian Meehan — Wed, 10 Jan 2018 00:00:00 GMT

Two years ago, we launched a simple, single-page website to establish our brand as a consulting and product studio. The new site is completely redesigned and revamped. Two years ago, we launched a simple, single-page website to establish our brand as a consulting and product studio. Since then, we have grown as a team from just one to seven full-time people, worked with a number of incredible clients, and continued evolving our own products. Our company has lots to be proud of, and our old site just didn’t reflect that — it was time for something new. Say hello to the revamped lickability.com 👋.

The brand-new Lickability.com

How We Built It

🚨 I’m looking for a great web designer/developer for a new @lickability project.

DM me if you have a recommendation (person or company)! 🚨

— mb Bischoff (@mb) June 16, 2017

In June, we put out a call for web designers and developers who could help with the site. After initial calls and meetings with lots of talented folks, we settled down to start working with the Pickaxe team in September, along with copywriter Annie Maguire and photographer Jorge Quinteros. Together, we built a site that is hosted on GitHub Pages, statically compiled with Jekyll, and can be easily developed locally from within a Docker container. A few months later, we are ready (and excited!) to share the finished product with you.

What’s New

Before and After

Our goal for the new website was to have a home for people to learn about who we are and what we do, see the products we’ve worked on, and easily get in touch with us. We wanted the site to showcase our projects and our team with the same care and close attention to detail that we put into our work.

Lickability.com has new pages to highlight the work we’ve done for our clients as well as our own creations, like Accelerator and PinpointKit. It also has information for people interested in working with us in any capacity, from details about Lickability’s background and services to our Jobs page. Plus, our new Contact page makes it easier than ever to get in touch with us.

What’s Next

We hope the site will give us the platform to expand our offerings as our company continues to grow over the coming months and years. We’ve even got an infrequent newsletter that will keep you updated when we launch some of the new ideas we’re working on.

If you haven’t already, we encourage you to check out the site for yourself and get to know Lickability a little better. If you like what you see or have any feedback for us, we’re only an email or a tweet away.

Huge thanks to the team at Pickaxe, Annie Maguire, and Jorge Quinteros for helping us build the website of our dreams. 🙌

A New Look for The Atlantic App

Brian Capps — Tue, 22 Aug 2017 00:00:00 GMT

Here at Lickability, we obsess over journalism. Having worked for and with some of the most important media organizations, we have nurtured a deep respect for thoughtful reporting and opinion. So when The Atlantic contacted us last year about partnering with them to redesign their iOS app, we were humbled and ecstatic to work with such a vital publication that excels in providing high quality news and analysis.

In April of this year, we visited The Atlantic’s offices in Washington, D.C. to spend some time with their fantastic team and collaborate on ideas for the new version. During this process, we helped refine an app design that we believe is simple to use and understand while reflecting the sensibilities and history of the publication. The design should also feel right at home when iOS 11 launches, adapting the large title styles of the upcoming operating system.

From top to bottom, The Atlantic 5.0 is a universal iOS app that is more modern, easier to use, and faster. The app’s speedier tab bar navigation now clearly organizes the content into top stories, sections, and magazines. Magazines are displayed with their full cover, and archived issues are now accessible all the way back to 2004. It’s also quicker than ever to save stories and full magazine issues for reading offline and manage those items so they don’t take up too much space.

Building the App

We developed this version of The Atlantic using the latest available technologies, exclusively writing it in Swift 3.1 with iOS 10 APIs. The app uses stack views, Auto Layout, adaptivity APIs, and Dynamic Type, allowing readers to set their own size for the app or use the system-wide settings. It is also ready for multitasking, with customized layouts on iPad for each size of the app. Finally, we adhered to programming best practices such as the single responsibility principle and separation of concerns, with small, focused types, and made use of view models for each view in the application. These techniques provide a solid foundation for continuing to iterate on the product to add exciting features and fix troublesome issues.

Our Tools

Nobody builds software in a vacuum. On nearly all of our projects, we have found that Buddybuild streamlines our continuous integration, distribution, and submission processes. This time especially, Buddybuild made configuring and sending test builds a breeze, so that all of our testers were always up-to-date. We are also proud to incorporate open-source work from the iOS community in this app, including extensive use of PINCache for persistence, Kingfisher for image downloading and caching, and Kanna for HTML parsing. It would have been far more difficult to complete everything along our timeline without the use of these thoroughly-reviewed, well-tested libraries, along with many others.

With the small, focused, and determined team at The Atlantic, we were able to assist in bringing this app from conception to release in 4 months. This timeline would not have been possible without the tireless work of the whole team. We believe that today’s release represents a significant step in The Atlantic’s continued success on digital platforms, and hope that it provides an even better mobile venue for some of the most important journalism in the industry.

Download the app today to read this essential publication with its brand new look.

Need some assistance making or updating your app? Send us a note at hello@lickability.com and we’d love to chat about how we can help.

Our View on View Models

Michael Liberatore — Sun, 29 Jan 2017 00:00:00 GMT

Over the past few years, the Model-View-ViewModel (MVVM) design pattern has become popular in iOS application architecture, battling the massive view controller problem that traditional Model-View-Controller (MVC) architecture left us with. Aided by a fourth component, the view model, MVVM offers a means of breaking some presentation logic out of controllers.

View models and their many definitions can leave developers new to the topic scratching their heads. It’s also possible to shift too much responsibility to view models in an effort to make view controllers lighter. We don’t strictly follow MVVM at Lickability, but we do make extensive use of view models, and we think it’s worth sharing exactly how. We’ll explore our approach to using view models, what they are and aren’t in our codebases, and why we find them delightful to work with in iOS and Swift.

View Model: A Simple Definition

We broadly define “view model” as a type that encapsulates the data needed to populate a particular kind of view. More succinctly, a view model is a view’s model. These basic definitions leave something to be desired. Do our view models merely store data and remain void of any operations? No — we allow them to perform operations strictly in the aid of displaying data, so let’s expand this definition to a type that encapsulates the data needed to populate a particular kind of view and the presentation logic needed to transform the data into properties that can be rendered. Okay, but what qualifies as “presentation logic,” and what does “transform” mean in this context? 😵

View Model: A Concrete Example

Let’s start over, and discuss view models in terms of UIKit and iOS application architecture with an example. Ultimately, we’re going to build a cell that can display a comment about a blog post for an interface that looks like this:

The completed interface with comment cells backed by view models

We’ll start with a view. Specifically a UITableViewCell, which is a UIView subclass. A UIView defines a rectangle of content and contains some smarts about user input that we’ll deal with later. But hey, that’s visual! What’s it look like?

An empty view in Interface Builder

Great, we’ve got a view. Our cell is empty and rendered with its default backgroundColor. We haven’t provided it with any data yet, nor have we exposed any means to give it data. Let’s step up our game and fill the view with UI components. To keep our code snippets focused on the topic at hand, we’ll leave the layout to Interface Builder, but you’re free to set up and lay out the view however you’d like. Here’s the final layout of our cell:

A designed UITableViewCell in Interface Builder representing a comment posted on a blog

Awesome, we’ve got some content! Or… placeholders for content. We’ll need to get the data from the model layer of our application into copies of this cell to display on screen. Before our view model will make sense, we need to define that layer of the application.

The Model

Let’s look at a simple model type, which mirrors an object returned from a web service. Assume the application has a use for all of this stuff, despite the cell in our example requiring only a subset.

For good measure, here’s the CommentAuthor type referenced in Comment above.

Look at all that data! In a real application, there may be even more, like the number of “likes,” more author information, and perhaps storage for multimedia included in a comment. But even so, our cell only needs a subset of this data:

The author’s name
The date the comment was posted
The text of the comment
Whether the user has edited the comment’s text since posting it

Although using a value type to model a Comment would save us from our view being able to manipulate any aspect of the application’s model layer, we’re still going to provide the view with only the data it needs. Specifically, our cell subclass will not know about the Comment type. We can accomplish this in a number of different ways including:

Exposing the UI components on our cell subclass to be populated with the data from the model
Keeping the UI components private and exposing individual properties for each piece of data that will populate the UI components when set
Expose a single point of configuration: a view model

Guess which one I’m going to pick.

The first option would greatly increase the surface area of our cell’s API. This could lead to heavy configuration being done at the view controller layer, even spreading or duplicating across multiple view controllers if we chose to use this cell in more than one context. We’d expose the ability to fill the labels with any text, modify any stylistic attributes, and easily manipulate layout. No thanks.

The second option, exposing multiple properties, is better but still not great. We wouldn’t run into any major issues with this approach in our simple example. But, more complex views that expose many configuration properties need to concern themselves with the order in which properties are set and whether some or all have values. This can also lead to multiple layout and drawing passes as each property is configured separately instead of a single pass after configuration.

The way we use view models aims to solve the problems of the first two approaches. The view only needs to know about the data it displays, and the view exposes a single property, the view model, such that layout and drawing can always happen predictably and completely. So what might this look like?

The View and View Model

We usually tie a view model type directly to a view type by nesting it. This covers most of our use cases and makes naming trivial thanks to namespacing. Let’s take a look at a snippet of our CommentCell that backs the view we designed earlier.

We’ve declared two types: CommentCell which is our UITableViewCell subclass, and CommentCell.ViewModel, the view model that backs this cell type. So far, we have one property declared on CommentCell, which is an instance of CommentCell.ViewModel. This will ultimately become the single point of configuration.

Notice that in the view model type, most of the properties can easily be mapped from our model later. We don’t want the view controller layer to take on the responsibility of determining how to format and display an author’s name. We’re also packing the author’s name into the same label as the “Edited” demarcation so that it could wrap naturally. This layout is specific to our cell type, and we want to house that logic in our view model. This is an example of presentation logic, which we alluded to earlier. Similarly, the view controller shouldn’t be responsible for determining how to format the date displayed in our view. Rather, we leave that presentation logic to our view model. We’ll put this presentation logic in an extension on the view model type to separate it from its purely model-like properties.

Burying this presentation logic deep inside of aUIViewController subclass would make it more difficult to test. We tend to leave these computed properties exposed in our view models so that they may be more easily accessed in our test target, without the need to instantiate any UIViewControllers or UIViews.

With the context provided by this example, defining a view model as “a view’s model” begins to make more sense. We store only the properties we need to fill our view with data and we provide operations needed to transform that data into something presentable. Let’s put it to use.

A Single Point of Configuration

So far we’ve only defined a single property on our cell subclass.

Swift

var viewModel: ViewModel?

However, we’re not making use of this just yet. Since we’re using this property as our single point of configuration for all displayable data, we’ll want changes to this property to update our view. We make use of the computed properties that contain our presentation logic as follows.

We define a single means of configuring our view. This makes configuration safer since it becomes impossible to only specify a subset of exposed properties, relying only on prepareForReuse() to reset properties that can be left unset. Rather, we force our controller to set them all at once. Our example cell is relatively simple, but in more complex cases, the order in which UI components are updated may matter more, and by exposing only one property we can ensure the order of updates is consistent and predictable.

Our UITableViewDataSource implementation will be relatively simple with this approach. It’s straightforward for us to translate to the view model type provided our actual model at this layer.

We’ve plucked a few properties from our model object, and that’s pretty much it. Our view models only hold onto the data they need to fill out the UI components. They also specify a means of translating that data into something to present on screen, as we did in our CommentCell.ViewModel extension.

If you’re following closely, you’ll notice that our view model specifies its authorImage as a UIImage?, not a URL, so translation from our actual model layer for that particular property doesn’t come quite as easily. You’ll notice that in the snippet above, we’re simply passing nil for authorImage. 🤔 Also, what happens when you tap that reply button on the cell? Well, nothing yet.

View models are not a silver bullet against massive view controllers!

We’ve housed presentation logic in a location that’s far away from a view controller. However, we’ve kept the responsibilities of our view model simple and well-defined.

Let’s talk about the elephant in the blog post. Where are those comment author images coming from?

Retrieving Data

Our view model has a UIImage? property, not a URL. We do this because we do not want our view model to be responsible for downloading images. A view model is a view’s model (remember?), and you wouldn’t put networking code in your traditional model layer, would you? Would you?

(Okay, maybe you did in that one project early in your career, but it eventually bit you, right? And you really hope no one ever sees that model object that retrieves its data from the network on the main thread, parses it, and persists it, right?)

So why would our view model be responsible for retrieving images from the network? Or from disk? We don’t believe that it should.

In our example, we passed nil for the authorImage parameter of our view model’s initializer with the expectation that something would come along and set the image once its retrieved from the networking or persistence layer. That’s right, we treat networking and persistence as layers separate from our model, view, view controller, and view model layers. We won’t dive too deeply into this concept as it deserves a blog post of its own, but suffice it to say we inject our view controllers with network and persistence-related dependencies that handle this for us. The important takeaway is that these are not the responsibilities of a view or view model — we’ve seen this architectural mistake all too often. There are other ways of moving this type of work out of view controllers!

So instead of setting our authorImage to nil, we could have our UITableViewDataSource ask the persistence layer of our application to retrieve an image for a particular URL. This would change our configuration from above to something like the following.

The method image(for:) in this example would return an optional UIImage since there’s no guarantee that we’d actually have that image yet. We’d defer downloading of the image, prioritizing display of the data that we already have. We could kick off the downloading of images in tableView(\_:willDisplay:forRowAt:) for the cases in which we don’t have them on disk, or perhaps when our local cache has expired and we want to update an existing image already stored on disk. Once we have this image, say, in the completion handler of a network request method, we can simply set it on the cell’s view model as follows.

Swift

cell.viewModel?.authorImage = imageFromNetwork

Now you might notice that we’ve actually left the authorImage property on CommentCell.ViewModel a var as opposed to a let. This is great because it allows us to change the value of a displayable property that we expect to change, but setting it still triggers our viewModel property’s didSet relieving us from any concerns about the order in which UI components are configured. Despite the fact that we’re updating a single property, we still hit our single point of configuration. (Should I create a TextExpander snippet for that phrase?)

To belabor the point, our view models do not touch the networking layer and do not touch the persistence layer of our application.

Delegating Action

Typically, the handling of tapping a cell can be performed by either a storyboard segue or in the UITableViewDelegate method tableView(\_:didSelectRowAt:), commonly implemented by the UIViewController or type that is used by the UIViewController. But notice that in addition to being able to tap the cell, we’ve also got a reply button.

So, does the view model take part in this interaction? No. We like to follow the same pattern as cell selection, in that it can done via a storyboard segue if we’ve specified our layout in prototype cells in a storyboard, or by allowing the UIViewController to handle the interaction. We do not want the view model or view to own any of this responsibility. Let’s walk through the non-storyboard approach.

First, we need to prepare our cell class to be able to intercept the button tap. We’re not going to carry out the button’s action, but rather provide a means for our view controller to do so. We declare a closure to be set externally on our cell and a corresponding action method.

Whether you use an @IBAction or register a target/action using addTarget(\_:action:for:), you’ll simply have to call the closure when the button is tapped.

All we have left to carry out the action of tapping a CommentCell’s reply button is to set the replyButtonTapHandler. We do this in the same location that we configured the viewModel property discussed earlier.

So, the single point of configuration is for all display-related data. We separate actions into their own properties, as it’s not the view model’s responsibility to carry out the handling of user input. These actions could also be handled via delegation, but we prefer closure properties for this type of interaction.

Be a (View) Model Citizen

Looking back at our simplest definition — a view model is a view’s model — the example we’ve illustrated matches this. It also helps to draw very clear barriers about what a view model is not. With this knowledge, we can lighten some of the load on our view controllers while preventing our view models from taking on too much responsibility.

For more on view models, our friends Chris Dzombak and Soroush Khanlou spent episodes 2 and 3 of their podcast Fatal Error on the topic, which include quality coverage of the problems they can solve, the MVVM design pattern as it relates to iOS development, pitfalls, and more. Check out the show notes for these episodes which include links to many more relevant resources. See also Andy Matuschak’s 2015 NSSpain talk Let’s Play: Refactor the Mega-Controller.

What’s Next?

Of course, there’s still more to cover. The approach that we outlined here doesn’t apply to views that are reusable in different scenarios. Our example included a cell for a blog post comment, specifically, but it’s certainly possible that an app would have much simpler cells that could be reused in multiple contexts. In these circumstances, we make use of view model protocols to share common layout behavior for views with varying purposes. We’ll explore this approach in our next post on view models. Stay tuned!

Escape from Times Square

Michael Liberatore — Sun, 13 Nov 2016 00:00:00 GMT

mb: “Can you get the Uber?”

Andrew: “Sure… aghh, never mind…”

mb: “Times Square bug?”

Andrew: “Yep.”

mb: “I can’t believe they haven’t fixed this by now.”

Andrew: “How do I work around it again?”

mb: “Restart your phone.”

For most of 2016, the Lickability team was plagued with an iOS issue causing all of our devices to report their current locations to be in the center of Times Square, New Yorkers’ favorite spot in the city.

Not again…

The only consistent workaround was to restart our phones. After conferring with other iOS developers outside of the company, we believed it to be a widespread problem. Researching online left us wondering how this hadn’t been reported to Apple or heavily discussed on forums.

As time went on, frustration grew. Location sharing in Messages and Find My Friends would suggest we spent most of our days waiting in line for last minute discounts on Broadway tickets at TKTS. Rather than exploring some of the best restaurants in the world, friends assumed we were waiting patiently outside of Olive Garden with restaurant buzzer in hand. Transit and walking directions were misleading, ordering food from Seamless became a hassle, and I frequently found myself shouting “No Foursquare, I’m not back at M&M’s world!” Core Location had gone from helpful to irritating. After months of dealing with this issue, and continuing to reach out to other developers in desperation, we were reminded of a debugging feature of Xcode to simulate location.

Edit Scheme… → Run → Options

This was a great starting point. The only issue was, none of us had used this debugging tool, and it was still happening to us. Which brings us to our next friend:

At some point, one of us had pushed a change to a shared run scheme on a client project to simulate the device or simulator location to “New York, NY”. Those “other iOS developers” who shared in our frustration early on were employees of the client. We had done this to ourselves! Merely running the app using the default scheme in the Xcode project would spread the problem to a device, persisting long after the work day had ended. Finally, Lickability could breathe a collective sigh of relief, share a few laughs, and learn the lesson of not carefully reviewing changes inside of xcshareddata.

Special thanks to Jeff Forbes for pointing us in the right direction to help us escape from Times Square.

The End of Quotebook

Andrew Harrison — Thu, 06 Oct 2016 00:00:00 GMT

In 2011, as three students in a dorm room, we released the first version of Quotebook. Since then, tens of thousands of you have used it to keep track of important quotations in your life.

We’ve recently started receiving an increasing number of complaints from customers that the iCloud syncing features have been working less reliably. We’ve poured thousands of hours into developing, testing, and retesting these features over the years as Apple has released new operating system versions and APIs that have broken our implementation. With the upcoming release of iOS 10, Apple has signaled they will be removing support for iCloud Core Data. This is the foundational technology upon which Quotebook’s storage and syncing is built.

Unfortunately, no matter how much time and energy we’ve spent, we’ve been unable to consistently deliver the quality and reliability that we expect of our products due to fundamental problems with Apple’s APIs. Quotebook has always been a passion project of ours, but its sales simply cannot justify the time we’d need to continue to support it going forward or to migrate to another data storage system.

Today, we are removing the app from the App Store. If you’ve ever purchased Quotebook, you’ll still be able to download it from the App Store’s “Purchased” screen for the foreseeable future. We’re as heartbroken about this removal as we’re sure some of you will be. We’ll be using the additional time and energy to build even better products and focus more on our current and future apps.

If you’ve got data in Quotebook and you’d like to export it for use in another application or system:

Open Quotebook
Tap the settings gear in the top left
Tap Backup & Restore
Tap Export CSV
Choose Email

Your CSV will contain the quotes, authors, sources, tags, dates, and ratings that you’ve collected in the app, and you can import it into a database like Airtable. If you need to export custom author and source descriptions, instead use the “Back Up” button and email the file to yourself. On a Mac, you can open this file in Xcode or PlistEdit Pro, and on Windows in PlistPad to extract the data. If you run into trouble with this process, email us at support@quotebookapp.com.

Thank you so much for being a customer, supporter, and friend of Quotebook. We’re really sorry that we cannot continue to develop the app, and we’ve learned a lot from this experience. If you’re interested in speaking with us about taking over development of the app, email hello@lickability.com.

“The problem with books is that they end.” –Caroline Kepnes

Making Meetup

Brian Capps — Tue, 27 Sep 2016 00:00:00 GMT

In May of 2015, we started working with our friends at Meetup to improve their iOS app. After adding a few features, the team at Meetup began thinking about embarking on a much larger, ambitious redesign of both the app and their entire platform. Today, a little over a year later, we’re excited to share the app we’ve built together.

Meetup 6.0 is a ground-up redesign and rewrite. The new app makes it much easier to find, join, and even start your own Meetups right from your phone. The design takes cues from Meetup’s complete rebranding, Apple’s iOS 10, and the feedback from hundreds of beta testers over the past few months. Check it out and let us know what you think.

Meetup was an ideal client for Lickability, as a New York company whose goal of getting people together in real life matches our enthusiasm for the iOS community. The monthly iOS IRL gathering here in New York is one of our favorite events, and meeting up in-person at our office and conferences has been important for our growth as a company. Meetup brings people together in thousands of cities, and we are thrilled to help further realize that mission.

Our Role

Our team began by researching and proposing a technical foundation for the app, written entirely in Swift, to improve the safety, speed, and expressiveness of the codebase. Even though the rewrite has nearly all of the features of its predecessor — and some new ones — it’s 30,000 lines of code shorter with many more unit and integration tests.

We used frameworks like Realm and Alamofire to create the persistence and networking infrastructure for the app and new platform features like UIStackView, layout anchors, and storyboard references to build a modern, adaptive iOS app that will remain easy to change as new features are added. As well, services like Slack and Buddybuild simplified working with the Meetup team remotely and keeping the tests passing.

The project team focused heavily on keeping the codebase consistent, adhering to best practices like the single responsibility principle, and providing detailed code reviews. Patterns like dependency injection, view models, and composition have made the project a joy to work on, even a year after we started.

Teamwork

As the year progressed, Lickability helped to interview candidates who joined Meetup as iOS engineers and get them up to speed on the project. During our time working together, we saw Meetup’s internal team grow from a single developer to a tight-knit group of four.

While helping to expand Meetup’s engineering team, we worked hand-in-hand with them on the technical decisions in the project, deciding on design, architecture, and technology in concert. We think the product released today reflects that close collaboration.

Thanks!

Meetup 6.0 was a gargantuan effort worked on by countless people at Meetup and here at Lickability. We’re incredibly grateful to have contributed to the project alongside fantastic folks like Farah Assir, Jason Brennan, Paul Bruneau, Amy Chiu, Michael Curtes, Adaam Hukins, Michael Pace, Yvette Pasqua, Laura Ragone, Fiona Spruill, Kathy Tafel, and so many more. We can’t imagine a better team. ❤️

What’s Next?

We’re excited to continue our relationship with Meetup as we bring new features and bugfixes to the redesigned app over the coming months. As always, we’ll also continue to update our existing products, experiment with new ideas, and seek out partners who want to make great software. If you or your team is looking for assistance building, rewriting, or refactoring an app or SDK, don’t hesitate to email us at hello@lickability.com. We’d love to hear from you.

Presenting PinpointKit

mb bischoff — Thu, 09 Jun 2016 00:00:00 GMT

Here at Lickability, when we’re not designing and building apps for our customers and clients, we spend time building internal frameworks. We like to write code that can be shared across all of our apps to make it easier to build great products.

Together with some friends, we spent the last few months extracting the annotation engine from our app Pinpoint into a free, open-source feedback framework for app developers. We’re calling it PinpointKit.

PinpointKit in action

Starting today with our preview release, if you make an iOS app and want to collect annotated feedback from your testers or users, you can include the PinpointKit framework via Cocoapods or Carthage. Whenever the user shakes their device in your app, they’ll be presented with a fully customizable feedback sheet that can send annotated screenshots and feedback via email or straight to your bug tracker. They can add arrows, boxes and text, blur out sensitive information, and even include a full console log.

Everything in PinpointKit is customizable. Flows, fonts, colors, and even behavior can all be controlled and overridden to fit your specific needs and feel at home in your app.

This is our first open-source release, so be sure to reach out on Twitter or GitHub with improvements that we can make before calling PinpointKit a 1.0. And if you’d like to support the continued development of PinpointKit, buy a color or two via in-app purchase in Pinpoint or hire us to build or improve your app.

PinpointKit is inspired by BugshotKit from Marco Arment. Huge thanks to Marco, Caleb, Kenny, Paul, and everyone here at Lickability that worked on PinpointKit.

Try it out in your apps and let us know what you think!

Michael Liberatore Joins Lickability

mb bischoff — Sun, 08 May 2016 00:00:00 GMT

Michael is the first full-time developer to join our team at Lickability. He started today as an iOS Engineer in our brand-new New York office. Just like mb, Brian, and Andrew, he’ll be working with our fantastic clients and improving our existing products for customers.

Welcome Michael, it’s great to have you on the team! Let’s find out a little more about him…

Michael Liberatore on his first day in the office

How’d you get into building apps for iOS?

I’ve been a Mac user since System 7. I began coding much later, but eventually taught myself Objective-C to write my own Mac apps. In college, I remember waiting patiently after requesting to join the developer program when the first iPhone SDK was announced.

I couldn’t wait to run Apple’s OpenGL ES sample projects on my phone. I spent most of my time toying around with 3D graphics and I fell in love with iPhone OS development the first time I used the accelerometer to control the position of a 3D model. It blew my mind how easy it was to set up. I knew right away that I eventually wanted to make a career out of writing software for such an amazing platform.

What did you do before joining Lickability?

After college, I worked for five years primarily as a Mac Developer writing education and interactive participation software for a company in Ohio called Turning Technologies. Turning had a few iOS apps to which I hadn’t contributed much, but my final project was to lead a rewrite of one of them. In 2014, I moved from Ohio to New York to work for the iOS team at The New York Times.

What apps and developers inspire you to make your best work?

Panic was a huge inspiration of mine when I first started Mac development, and continues to be today. For iOS, my most used apps are Tweetbot by Tapbots and Overcast by Marco Arment, which constantly inspire me to match their obsessive detail.

Tell us a little more about what you’re excited to work on here.

Like the companies and apps I mentioned before, Lickability has the reputation for having obsessive attention to detail. I’m excited to match that obsession with any and all projects. I’m also a huge fan of Pinpoint, so I look forward to making contributions there.

Favorite ice cream flavor, and why?

Mike’s favorite, served the proper way

Not exactly a flavor (or really ice cream for that matter), but I have to go with Reese’s Peanut Butter Cup Blizzards from Dairy Queen. My sister Amanda worked at Dairy Queen when I was growing up, so our family had Dairy Queen quite a bit, and I’ve tried them all.

Anything else you’d like to tell the folks at home?

Just to thank my friends and family back home in Ohio for their support. Their encouragement led me to New York, which ultimately led me here.

I’m tremendously excited to join Lickability and start coding!

We’re absolutely thrilled to have Michael joining us. And we can’t wait for you to see what we build together. If you see him on Twitter or in real life, give him a high five for us. 🙏

And as always, if you’re in the market for a group of talented mobile engineers to build your app, train your team, or provide some recommendations, don’t hesitate to reach out.

Helping Build The New Yorker Today

mb bischoff — Sun, 17 Apr 2016 00:00:00 GMT

When The New Yorker first launched its flagship iPad app in 2010 and an iPhone version two years later, it was designed to mimic the magazine’s typographic layout. But as phones have become a bigger part of our lives, many subscribers want to read in a super-fast, native experience that’s not based around individual issues, but rather updates every single day. And now they can with The New Yorker Today.

We worked very closely with Condé Nast’s team of incredibly talented designers, editors, engineers, and project managers to build an app that we’re all really proud of. And just days after it was released, Apple featured it on the front page of the App Store as one of the Best New Apps.

The app was engineered entirely in Swift for iOS 9 and above, with a focus on protocol-oriented design, reusable components, speed, and modern layout systems that will allow the app to easily adapt if it ever comes to other devices or platforms.

Our friend and frequent collaborator, Soroush Khanlou, who writes about development at khanlou.com, spearheaded much of the engineering effort alongside The New Yorker’s very own Justin Savory who built the app’s super fun and seemingly never-ending, swipeable cartoon gallery.

Whether you’re a diehard fan of the magazine or you just like reading the captions on the cartoons, we’d love for you to download the app, try it out, and let us know what you think. For the first month, everything in there is completely free, and after that you can subscribe with a quick in-app purchase.

And if you or your team need help building a new app or updating an existing one, we’d love to hear about it. You can email us at hello@lickability.com.

“The New Yorker” and “Condé Nast” are registered trademarks of Condé Nast. “App Store” is a service mark of Apple Inc.

Going Indie

Brian Capps — Mon, 06 Apr 2015 00:00:00 GMT

On October 13, 2013 a plan was hatched. It wasn’t a diabolical House of Cards political gambit or even anything more concrete than a rough outline. No, on the seven hour drive back from Çingleton in Montreal, we planned to take our small, part-time app development company, Lickability, full time in 2015. And today, right on schedule, I am starting as the first full-time member of Lickability.

In the summer of 2009, right around high school graduation, my friend mb Bischoff called me up one night with their idea for this new thing called an “app.” Armed with nothing but an idea and an abundance of teenage hubris, we built our first iOS app Broadway for theater showtimes, and a partnership was born. We officially created Lickability that year on our laptops at a local Panera, and two new apps and countless hours later, we’re making that company dreamed up by two kids six years ago into a small, world-class software studio.

With a full-time engineer, we will be giving some much-needed love to our existing apps Velocity and Quotebook this year, adding a few nifty iOS 8 features and overdue bug fixes. Additionally, while Lickability has done some selective consulting in the past, we’ll now be taking on more client work, and we’re excited to help others build lickable apps. We’ve got a team of three talented people who have worked for The New York Times and Tumblr and collectively have over 15 years of experience building iOS apps. If you or anyone you know would like to discuss working on an app, feel free to say hello — we love talking to people about their ideas.

One thing that we’ve always done at Lickability is take our time and do things the “right way.” We take our time to ship releases because we want them to be up to our standards and make sure that they’ve got the features and polish that they deserve. We’re taking the same approach with our company. For the past two years we’ve worked on app releases and client projects that have allowed us to save enough money to pay me full time for more than half a year. Without taking any external investment, we’re funding this experiment entirely from the proceeds generated so far by Lickability. While the initial outside funding approach has worked for many, we’re proud to be responsible to no one but ourselves for our future.

Six months. That’s how long we’ve given ourselves to make this work. Like with any business, it’s important to determine how to become profitable over a period of time. So, paying me a full-time salary, we’re going to be profitable in six months or I’m going to start looking for a new gig. As much as we’re idealists who would love to toil away on perfecting products, we understand the realities of starting a small business in a volatile industry. I’m confident that we’re going to meet and exceed our goal, but it’s necessary to have a realistic and well-defined metric for success, and profitability within six months is ours.

Everyone I’ve talked to about this plan has a laundry list of questions: Are you taking funding? Will you have an office? Who’s going full time next? What does success look like? Who’s this phantom third member of Lickability? We’ve made some incredible friends who have successfully started their own businesses — Marco Arment, Allen Pike, Myke Hurley, Matt Alexander, Mark Kawano, to name a few — who we have relied on for advice and answers to those same questions. But not everyone has that same luxury, so I’ll be writing about what it’s like to build an app development company on the Lickability blog whenever possible. Hopefully I can provide a peek behind the curtain and insight into some of the fears, challenges, and triumphs of growing our company.

“We made the buttons on the screen look so good you’ll want to lick them.” – Steve Jobs

When I announced that I was leaving The New York Times a little over a week ago, the outpouring of support before I had even mentioned what was next was beyond imagination. We would not be here without that same support from all of the amazing people who have helped us over the years, and for that we are sincerely grateful. I’m excited for the next chapter, and I know that we will make Lickability into something great. But for now, it’s time for me to get back to work.

Quotebook 3: The Reviews Are In

mb bischoff — Fri, 29 Aug 2014 00:00:00 GMT

Earlier this week, we released the third major version of Quotebook. Here’s what the press had to say:

iMore:

We all have our favorite quotes, and the newly overhauled Quotebook app aims to help us store and organize them all. The app, with the kind of clean design we expect from Lickability, makes it easy to keep all of your favorite quotes in one place, with ratings, sources, tagging, and more.

MacStories:

Quotebook, developed by the folks at Lickability, has long been my favorite app to save and archive quotes and passages on the iPhone and iPad.

Minimal Mac:

Hopefully, this will help you see why I love the app so much and it has been on my home screen since the day it was released. The new version is certainly worth your time checking out.

Beautiful Pixels:

I can’t believe the update is free because of how much has been added, let alone the brand new interface and the fact that it is universal. Quotebook is available on the App Store for $4.99 and is a free update for existing owners.

Tools and Toys:

With today’s update, this universal app is better than ever. You can now add images and descriptions to your authors and sources, import quotes from Tumblr and Facebook, and share your quotes to apps like Tweetbot and Day One.

512 Pixels:

Quotebook 3 by the handsome young men at Likability is not messy or boring. Some of the best apps on iOS are ones that do very specific things. Quotebook is in that class.

Pete Denison:

Developers say many things in press releases, however on this point from Lickability I most certainly concur:

Lickability has been and will always be concerned with all the small details that make apps great.

techēse:

Quotebook is simply a delightful app that I have used for years to collect bits of wisdom from notable people, friends, and even my son. It’s not only perfect for quickly recording a great quote, but it makes returning to those quotes and reflecting on them frictionless.

Quotebook 3: Coming Soon

mb bischoff — Wed, 26 Mar 2014 00:00:00 GMT

If you’ve been paying attention on Twitter, you may know that we’ve been hard at work on a brand new update to Quotebook. Today we’re announcing that the third major version of Quotebook is coming soon to an iPhone or iPad near you.

What’s New

Quotebook 3 is an all new version of Quotebook. Quotebook lets you build a personal library of quotes and organize and share those quotes with your friends on social networks. And now, we’ve rewritten every single line of code, we’ve redesigned every single screen for iOS 7, and we’ve added dozens of the features you’ve been requesting.

It’s the most ambitious update we’ve ever done and it’s almost ready.

Timeline

Quotebook 3 for iPhone is currently in private alpha. After we’re comfortable with our final design on iPhone, we’ll finalize our iPad design and begin a private beta with a few more users.

After that, it’s a month or so of testing until we submit to the App Store. We can’t give you a firm date just yet, but Quotebook 3 is our top priority, and we know you’re eagerly awaiting the update as much as we are.

You can sign up to be notified when Quotebook 3 is released at our website or follow us on Twitter.

Until Then…

Quotebook 3 will be a free update for all existing Quotebook users and it’ll download to your devices automatically if you already have Quotebook installed. All your quotes will still be there, and they’ll look even better.

In the meantime, we’ve pulled Quotebook 2 from the store because it was starting to feel outdated on iOS 7. We didn’t want any new customers downloading it and being disappointed. Quotebook will return to the store as soon as 3.0 is released.

If you need support for Quotebook 2, we’re always happy to help at support@quotebookapp.com.

Thanks for your continued support and patience. Quotebook is a big app and it’s taken us longer than we expected to rewrite, but it’ll be worth the wait. Time to get back to work on finishing the best release of Quotebook yet.

Velocity URL Scheme

mb bischoff — Sun, 06 Oct 2013 00:00:00 GMT

Our new speed reading app, Velocity, has a couple of awesome features for advanced users that we’ll highlight over the coming days. One of them is the app’s URL scheme. A URL scheme is a way to launch and perform actions in an app simply by typing in a URL or clicking a link in a browser. It’s also how apps on your device communicate with one another. If you’re interested in playing with it, you can already use the URL scheme from Launch Center Pro.

If you’re a developer, we’d love it if you added “Read in Velocity” support in your app, and we’d be happy to help make that easier. Email us at hello@velocityapp.com if you have any questions, comments, or complaints. And feel free to let us know if you would like us to add more features to the URL scheme.

Here’s how the URL scheme for Velocity works:

General

velocity://
Opens the app

Reading

These URLs will immediately read the text or the content of the URL provided.

velocity://read?text=Text%20goes%20here
Reads the text: “Text goes here” in Velocity.
velocity://read?url=http://movies.nytimes.com/2013/10/04/movies/gravity-stars-sandra-bullock-and-george-clooney.html
Reads the text at the given URL in Velocity.

Saving

These URLs will save the text or the content of the URL provided for later reading. They will be saved into the user’s local source (e.g. iPhone).

velocity://save?text=Text%20goes%20here
Saves the text: “Text goes here” to the local source in Velocity.
velocity://save?url=http://movies.nytimes.com/2013/10/04/movies/gravity-stars-sandra-bullock-and-george-clooney.html
Saves the text at the given URL to the local source in Velocity.

Editing

These URLs will save the text or the content of the URL provided for later reading and then allow the user to immediately edit the text. They will be saved into the user’s local source (e.g. iPhone).

velocity://edit?text=Text%20goes%20here
Saves the text: “Text goes here” to the local source in Velocity and then displays an editing view.
velocity://edit?url=http://movies.nytimes.com/2013/10/04/movies/gravity-stars-sandra-bullock-and-george-clooney.html
Saves the text at the given URL to the local source in Velocity and then displays an editing view.

If you’re a developer, we look forward to seeing some of the awesome stuff you make with our URL scheme. If not, is there an app you’d like to see Velocity support?

“Why Doesn’t Quotebook Use Dropbox?”

mb bischoff — Sun, 30 Jun 2013 00:00:00 GMT

A few of our most-asked syncing related support questions are:

Why is Quotebook different than other iCloud apps?
What are we doing to fix syncing?
Why not Dropbox?

In today’s blog post, we’d like to shed a little light on these topics. Later we’ll get into the nuts and bolts of how Quotebook syncing works, but for now we’re going to focus on these three queries. Let’s divide them up to keep it simple.

Why is Quotebook different?

The simple answer is that Quotebook uses a different system than other apps. The long answer is that iCloud apps work using one of three technologies:

Key-Value Data
Documents in iCloud
Core Data

We don’t use Key-Value syncing because it’s designed for limited amounts of data that doesn’t need to change very often. It’s great for things like Settings or User Preferences, but it doesn’t work for Quotebook — and it has no conflict resolution.

Documents in iCloud work in a similar way to Dropbox. It also isn’t the right fit for Quotebook because it’s designed for something like Microsoft Word, wherein you open one of multiple documents, work on it, and close it before continuing on with another. Many apps our users use in addition to Quotebook operate using this method, and while it’s a good one, it doesn’t handle databases.

Quotebook uses Core Data. It stores information as a database (which we need) and has automatic conflict resolution. This works perfectly for us because our app uses a ton of information often spread across multiple devices.

For more information on Key-Value Data, read the article here.
For more about Core Data, read here.
For more on Documents in iCloud, read here.

What are we doing to fix syncing?

When we spoke to Apple at the World Wide Developers Conference, they told us that they would have many of our syncing problems fixed in iOS7. That comes out in the fall, and if all goes well it’ll fix a lot of the issues people have been having loading their quotes from iCloud.

A couple of things that will improve the syncing issues some of you have been having are that they’ve given us better debugging tools — Gauges are a good example. Gauges will let us see how much usage is in an iCloud account and what is uploaded/downloaded so that we can see the problems in development rather than guessing at them. It’s proactive instead of reactive debugging, and it should make everything move much more smoothly.

Luckily iOS7 is only a few months away, but while we wait for these new tools all we can ask for is your patience. In the meantime, you can watch the keynote from WWDC here.

Why not Dropbox?

We understand that Dropbox is really useful for a lot of our users, and we think it’s a great piece of technology. Unfortunately, it’s set up in a way that doesn’t work well with Quotebook.

The main issue with Dropbox is that it doesn’t handle databases that need concurrent access — like Quotebook, for example. Concurrent access is essentially multiple devices writing and reading data at the same time, like if you had Quotebook on your iPhone as well as an iPad.

With Dropbox, the most recent update to your database of quotes will overwrite any others. For example, if you had both your iPhone and your iPad offline and added quotes to each, then only the quotes from the latest device you updated will show up when you reconnect both devices. That could mean people losing quotes forever, and that’s not something we want to happen.

By using iCloud and Core Data, we make sure that all of your changes from any devices are logged and marked at the same time. It’s a lot more efficient, and it keeps anyone from losing data. While syncing might currently be taking a while, as mentioned we hope to have that fixed soon.

Thank you for your patience with us, and we hope these explanations help you better understand the inner workings of Quotebook!

If you’ve got any more questions for us, feel free to get in touch:

Twitter: @quotebookapp

Email: support@quotebookapp.com

Quotebook 2.0 API and URL Scheme

mb bischoff — Fri, 12 Oct 2012 00:00:00 GMT

You may already know that in Quotebook 2.0, we added the ability to launch Quotebook from apps like Instapaper, Drafts, and Launch Center Pro. The way that works is through a “custom URL scheme” which just means that we register to handle any links that start with quotebook://.

Here’s the kinds of links we handle and how they work. We’d love it if you added “Add to Quotebook” support in your app, and we’d love to help make that easier. Email us at hello@quotebookapp.com if you have any questions, comments, or complaints.

General Navigation

quotebook:// — Opens the app
quotebook://quotes — Goes to the Quotes Tab
quotebook://authors — Goes to the Authors Tab
quotebook://sources — Goes to the Sources Tab
quotebook://tags — Goes to the Tags tab

Adding Quotes

text

quotebook://add?quote=Stay%20Hungry.%20Stay%20Foolish.&author=Steve%20Jobs&source=Whole%20Earth%20Catalog&rating=5

Adds a quote “Stay Hungry. Stay foolish.” to the user’s Quotebook with the author Steve Jobs, the source Whole Earth Catalog with a rating of 5 stars.
All of these parameters are optional except for quote which is required. Any unused or blank parameter need not be included.
The rating must be between 0 and 5.
The author and source may be names, twitter usernames prefixed by an @, or URLs.