DEV Community: Danilo Campos

Designing, building and shipping an iPhone app in five weeks with SwiftUI

Danilo Campos — Thu, 23 Apr 2020 13:04:21 +0000

I was laid off last month.

I’m hardly alone in this. With COVID-19 upending the game boards of every industry under the sun, lots of us have lost jobs.

Of course, this makes finding my next act complicated. Even in the technology business, thousands of highly qualified professionals have been cut loose in recent weeks. It’s just not a great time to look for a job.

So I decided to go back into business for myself.

The first step in that process was building an app as both a source of income and a showcase of my abilities as a product designer and software developer. I’ve spent every day, night and weekend of the last five weeks designing, building and shipping an iPhone app. Part of what made this possible was SwiftUI. Apple’s new declarative UI framework makes building touch interfaces faster than ever. Even with the pitfalls you’d expect from a brand new technology, it is already the best and fastest way to build an app for iOS.

Choosing a product

Once upon a time, I fell in love with product design, code, and shipping software in Second Life. I didn’t think I’d do anything else with those skills—I just had a lot of fun with them, and paid a few bills on the side.

But in 2008, when the App Store debuted, I saw a chance to put those skills to work for a truly global audience. I wanted a career building software.

I knew no one would hire me without experience, so I set about giving myself some. I built a raft of products for the iPhone—a game, a travel organizer, a simple tool for shopping at IKEA. I sold a few of each.

But there was one app that truly stuck. Called Tallymander, it was a flexible tool for counting and math. Early on, to my shock and exhilaration, Apple featured it on the front page of the App Store. I heard from customers across all walks of life—research scientists, drywall installers, collectible card game enthusiasts—who were in love with it and had feature suggestions.

Look at that shiny, glossy UI. Were we ever that innocent?

Eventually, I got my career as a professional product designer and iOS developer. In fact, Tallymander opened the door: the CEO at my first startup gig was an early Tallymander customer. But I didn’t have time to maintain my indie projects, so I took them off the store.

No one really minded. Except my Tallymander customers, who emailed, bereft, for months.

Like an estranged friend, I’ve thought of Tallymander constantly in the years since. I loved that product. I loved that it was useful to people. And I loved my tiny contribution to the Great Conversations of products like VisiCalc, Excel, and Airtable. All of these make data and algorithms something tangible, experimental and fun.

Over the years, I’ve wanted desperately to revisit Tallymander. But the level of effort it takes to build an iOS app is significant. Quality is paramount, for one thing. You have to do things well to thrive in that environment.

But UIKit, Apple’s original UI development framework, can be such a slog. It was hard to maintain the velocity needed to get a project off the ground.

Last month, I was given more time than I asked for. And SwiftUI, Apple’s replacement for UIKit, had gelled enough to build with.

This confluence of events meant one thing: it was time to bring Tallymander back.

SwiftUI: the fast, modern way to build an interface for Apple platforms

UIKit emerged for third-party developers in 2008. It was a very different world. There were only two models of iPhone. Both phones had identical screen sizes. The iPad was still a secret project, known only to a few.

In the years since, iOS evolved to accommodate a vast array of devices. You can use UIKit to target all of the different iPhones and iPads. Using tools like auto layout, you can fiddle your way to a view that looks right on any size screen. Eventually.

But in a lot of ways, UIKit and friends feel pretty creaky. Want a table-based UI? You’ll have to implement dozens of lines of data source and delegate boilerplate just to get started. Want to draw shapes? It’s an exercise in such tedium that an entire app exists to spare you the worst of it.

UIKit also let you create bugs if you weren’t careful. Cocoa Bindings never made the journey from macOS to iOS. With no reactive frameworks built in, a typical approach was to write UI values in one pass, maybe when the view appears, and read back any inputs in another, perhaps when it disappeared. This could work, but the space in between was room for bug city. Frameworks like RxSwift emerged to fill the gaps, but didn’t have the widespread, universal adoption of Apple’s many iOS libraries. You could cobble something together yourself with KVO, but managing subscribers was its own headache. Get it wrong, you get crashes.

Apple’s edge in mobile was multiplied dramatically by the existence of developer tools and frameworks adapted from Mac OS X. Preserving that edge meant investing in new developer-focused technologies, especially Swift, which could be fertile ground for a new generation of APIs.

That strategy is has borne some meaningful fruit in technologies like SwiftUI and Combine.

SwiftUI is declarative. You tell it what you want to see, it figures out the details for you. This is a departure from UIKit, where every point of every frame of every view was a detail the developer could worry about.

Tell SwiftUI you want a field here, a slider there, and a toggle switch if the slider exceeds a certain value, and you’ll just get that interface. Maybe it won’t be exactly what you had in mind, so you’ll add a few modifiers. Primp with some padding, polish with some rounded corners.

An entire form with conditional fields specified in under thirty lines. Some of these call out to additional, more complex views, but most of those are reused across this and other forms.

This is already pretty convenient. But SwiftUI debuted alongside Combine, Apple’s framework for “processing values over time.” In practical terms, Combine lets you easily, accurately keep track of everything from network request progress to the state of your user inputs, consistently reflecting that state in both your UI and your data model.

These two frameworks together make it ridiculously fast to build a UI. This operated on two levels:

Easy to experiment/prototype and quickly see results
Less time spent on debugging because things largely just worked

Building Tallymander from scratch, in Swift, I started out with UIKit and thought I might experiment with SwiftUI. It seemed like a good way to build detail views and forms.

By the time I finished, 95% of the app’s view code was SwiftUI. It was just so much better at solving the problems I was tackling, and so much more fun. Before bed, I’d imagine some new feature I wanted. With SwiftUI could often knock it out within an hour or so the next morning.

The almost-instant previewing of SwiftUI interfaces was a big factor here. Rather than building and launching to check sizing, typography or content, you can see in seconds whether your layouts and drawing code are doing what you expect. One thing that surprised me was how deep these previews can go. You can include anything in your application as input to a SwiftUI preview, and that includes Core Data entities. Set up a garbage context that writes to /dev/null and you can build arbitrarily complex object graphs to test your designs.

SwiftUI’s layout system takes some getting used to—I’d be lying if I said I’d come close to mastering its more advanced features. Still, the basics are so easy to learn, and get you quickly to a UI that easily scales to any screen size. It’s a big improvement on the fiddly autolayout experience of yore.

I was helped along the way by Thinking in SwiftUI. To give you an idea how early days we are, I started reading it while it was available chapter-by-chapter on a pre-release basis. It’s done cooking now and worth every penny. It’s a helpful guide to building a new mental model after years with UIKit.

One thing I appreciate about SwiftUI is how easy it is to construct novel UI components. Example: The reset control on a counter expands to cover its neighbor and present a confirmation message.

Could I have built this in UIKit? Of course. But I’m not sure I would have thought to try, because doing it would be so fiddly. SwiftUI’s state management is so tidy, it’s trivial to add a @State variable, attach it to a few views, and see how you like it. Putting things into layout based on state is as trivial as an if statement—so is pulling them out. Tacking on an animation is simple, too. You can go from “what if…?” to working results in a couple of minutes, and then decide from there if you want to keep those results. More experimentation, more fun.

It’s a brand new technology, so there are occasional hiccups. Passing numerical values to TextFields—critical to any math-centric application—is a little buggy, and requires a workaround. But even with these bumps in the road, it’s a much better path to shipping.

Everything in the new Tallymander is drawn with SwiftUI. Aside from the icon assets, there are no pre-rendered images. This is an approach worth taking even in the old world of Quartz and UIKit. With multiple screen densities, and now Dark Mode, if you can afford to do your drawing in code, you’ll save yourself a mess of image variations. SwiftUI makes the economics of this so much more favorable, as you get a realtime preview of your efforts as you go, and the drawing API is significantly less verbose.

But what about iOS 12?

I say don’t even worry about it. My policy has been to target only the latest major OS version for new apps. iOS update adoption is aggressive, especially in the age of emojis. >90% of customers end up on the latest major release within six months, so why bother doubling your test burden? A small and shrinking slice of the market isn’t worth the headache of backwards compatibility in most cases.

This case is even more dramatic now, where it’s a choice between SwiftUI’s velocity and slogging through the mud of UIKit.

Old friends

I said 95% of Tallymander is SwiftUI. So what about the rest?

There was one place where I needed classic, UIKit-style control over the interface down to the quantum level: the actual table that houses your Counters and Calculators.

Right now, SwiftUI doesn’t expose a lot of customization for its analog to UITableView, List. But since this was going to be the core of people’s day-to-day experience of Tallymander, I wanted to be able to tweak everything about layout, cell rendering, edit behavior, you name it.

What’s wild about this, though, is that while the enclosing cells and tableview are UIKit, all of their content is SwiftUI. It’s possible to make them work together that seamlessly. Watch:

The Counter buttons that fade away, along with the bandage symbol, are all views in SwiftUI. They animate alongside the red delete controls on the left, and the reorder controls on the right, which are provided by UIKit.

But to the user, these details are invisible. Thus, where you need an escape hatch to UIKit or SwiftUI in your project, you’ve got one, and there’s no compromise in user experience. That’s powerful stuff.

Other modern niceties

Working with Swift is a joy. The rigid type took some getting used to after years of Objective-C. But the reward for this temporary discomfort is fewer fucking bugs. According to TestFlight, Tallymander has never crashed in the wild. Not once. The only crashes I’ve observed were the immediate consequences of doing weird things with text that SwiftUI didn’t like.

This is a lot of time back in your pocket, once again, because you’re working on features instead of chasing bugs.

I want to take a moment to celebrate a small feature in iOS 13. SF Symbols debuted at the last WWDC and it’s a game changer for teams large and small. By providing a vocabulary of 1500 symbols, developers now have a low friction way to enhance the communication of their UI. This was an enormous headache when I was starting out in 2008. The OS was filled with symbols that meant things—chevrons as “disclosure indicators,” little red gems to indicate delete controls, green dots for creation controls.

SF Symbols: Apple provides a Mac app as a directory of all the glyphs

If you wanted to put your own spin on these, you had to build them from scratch. If you needed your own symbols, you needed to design or procure them as well. An entire cottage industry formed around this—I supported the Glyphish Kickstarter because it promised a few hundred such symbols.

There was also friction with getting such images to the screen. You had to size and convert them, add them to your Xcode project, and with the advent of Retina displays, manage multiple resolutions.

With SF Symbols, it’s a one-liner: Image(systemName: "chevron.right"). It’s trivial to style your symbols with colors appropriate to your app design. If you’re using SwiftUI, composing them with other UI elements is a snap using ZStack and friends.

This makes it so much faster and easier to make a UI that’s clear and easy to understand. Because you’re using a shared vocabulary with the OS and other apps, users will feel at home with your iconography.

Open for business

With SwiftUI, it’s a great time to build iOS apps. The time costs are lower than ever, the APIs are fun and modern, and the results are satisfying. The new technologies have their quirks, but have already gelled to an impressive degree with less than a year in developer hands. I know this was very high-level, but rest assured I have a few practical tips I’ll be sharing soon, especially about how to make UIKit and SwiftUI work well together.

I hope you’ll check out the new Tallymander and share it with anyone you know who’d enjoy a tool like this.

I’ll be continuing to flesh out Tallymander, and plan out my next projects. If you need support for an iOS project on a freelance basis, drop me a line. I can give you the perspective and experience of someone who has not only been with this platform from the beginning, but who is also up to speed on the latest technologies.

Swift: Markdown files from string literals

Danilo Campos — Thu, 05 Mar 2020 16:00:45 +0000

My new iOS fiction project relies heavily on text.

That means I want to make it easy to create that content anywhere, and I want it to be frictionless to drop it into the project as needed.

My solution: Markdown files I can load from the bundle using string literals. Look how easy:

let markdown: MarkdownFile = "markdown.md"

Here’s how to do it.

String literals

In Swift, you use string literals all the time. Usually to initialize strings.

let string: String = "Hello, I am a string."

But Swift includes a protocol called ExpressibleByStringLiteral. Which means if your Swift type adopts it, that type can be initialized with nothing more than a string. While this is immediately convenient, it has real power for assets that need tedious boilerplate. Say, anything that needs to be loaded from a bundle.

Basic example

struct MarkdownFile: ExpressibleByStringLiteral {

    let bundleName: String
    let rawMarkdown: String?

    init(stringLiteral: String) {

        bundleName = stringLiteral

        var loadedMarkdown: String? = nil

        if let filepath = Bundle.main.path(forResource: bundleName, ofType: nil) {
        //By skipping the ofType argument above, we'll match to the first file whose name
        //exactly matches bundleName
            do {
                let loadedString = try String(contentsOfFile: filepath)
                loadedMarkdown = loadedString
            } catch {
                print("Could not load string: \(error)")
            }
        } else {
            print("Could not find file: \(bundleName)")
        }

        rawMarkdown = loadedMarkdown
    }
}

Here’s a basic example of a MarkdownFile struct. It knows two things about itself: the name of the file used to initialize it, and any string it was able to load from a file in the bundle with that name.

On init it goes looking for a bundle resource matching the name it was provided through the string literal. If it finds one, and it can load its contents as a string, those contents are stored to rawMarkdown. If not, rawMarkdown returns nil.

This is already pretty convenient. Again, to initialize, all you need is:

let markdown: MarkdownFile = "markdown.md"

But we can take it further.

Adding convenience

The MarkdownFile struct can be responsible for converting its contents into a display representation, as well. Let’s add a computed property to parse the Markdown into HTML. I’ll be using Ink for this, but you could use any project—or convert it into something else, like NSAttributedString.

var htmlRepresentation: String? {
    if let raw = rawMarkdown {
        return MarkdownParser().html(from: raw)
    } else {
        return nil
    }
}

Putting it all together

With our output property all set up, we have a small, convenient API for handling Markdown files in any way we want. Here’s how we use it:

let markdown: MarkdownFile = "markdown.md"

if let html = markdown.htmlRepresentation {
    webview.loadHTMLString(html, baseURL: nil)
}

self.title = markdown.bundleName

Behind the scenes, lots of stuff is happening to load and parse the file. But when you need Markdown across your project, you need only concern yourself with a filename. If you want to change any part of how this works later on, you have a single struct that’s responsible for all the Markdown behavior in your code.

Full example code here.

ECDSA signatures with node.js and Swift

Danilo Campos — Tue, 19 Nov 2019 21:41:24 +0000

In the process of de-risking some business model questions for Digamo, I went looking for an open source project that would allow us to generate and verify license keys. We’re not sure what our business model will be there, but understanding the technical costs of licensing is important to making decisions.

While this is a problem that has been solved, I didn’t find anything especially modern, well-maintained, or documented—and nothing in Swift or Node, the stuff I’m using for everything else right now.

Some research did suggest that asymmetric cryptography was the way to go, using a private key to sign a registration string, and a public key distributed with the app to verify the signature. This was also the approach used in the older projects that tried to solve this problem for Mac apps.

Still, I found precious little documentation or tutorials to walk me through the implementation. All the signing examples took place within the same context, rather than between client and server. Here’s an approach that appears to be working, using Node and a Swift Mac app.

Try the demo

Generate a signed message file here: https://eccsign-server.glitch.me

Download, build and run the macOS verification app here: https://github.com/daniloc/eccsignaturetest

Once the app is running, you can double-click the signed message files from the Glitch app to automatically load them. File free to tamper with the content of the plaintext field by opening a file in your favorite text editor, then try to verify again. Tampering should cause the verification step to fail.

The public and private keys are included for your inspection and experimentation, as a “known-good” configuration. In your own projects you should use care to ensure your private key is not distributed.

Generate encryption keys

Per the instructions from IBM’s BlueECC project, here’s how you get started:

On macOS you can install OpenSSL using brew:

brew install openssl

Once you have installed OpenSSL, create your private key:

openssl ecparam -name prime256v1 -genkey -noout -out ec256priv.pem

Using the private key, create your public key:

openssl ec -in ec256priv.pem -pubout -out ec256pub.pem

It seems you want to use the prime256v1 curve—other algorithms have some cross-platform issues.

This will leave you with a private and public key. The private key goes on your server to generate signatures. The public key can be distributed with your app to verify those signatures.

Signing with Node.js

The npm module EC-Key will make it easy to load your key:

let ECKey = require("ec-key");

let pem = fs.readFileSync("./privatekey.pem"); let eccPrivateKey = new ECKey(pem, "pem")

Here my implementation gets a little clunky—there may be better ways to do this, but at least it seems pretty flexible. Create a JavaScript object with whatever keys and content you want:

var objectToSign = {} objectToSign.message = message let date = new Date().toJSON() objectToSign.date = date

Convert that into a JSON string:

let outputString = JSON.stringify(objectToSign)

Then, create a signature from that string:

let signature = eccPrivateKey.createSign("SHA256").update(outputString).sign("base64")

And pack the plaintext string and signature into a second object:

let outputObject = {} outputObject.plaintext = outputString outputObject.signatureBase64 = signature

You can then convert the output to JSON and have the user download the file.

See the whole thing in action with this Glitch project.

Verification in Swift

Add the BlueECC package to your project. Install manually, or use the Swift Package Manager. In Xcode, choose File > Swift Packages > Add Package Dependency…

Search for “CryptorECC,” and pick “BlueECC.”

Add your public key file to your project, and import CryptorECC

to the file where you’re working. Then you can grab the public key like this:

let filepath = Bundle.main.path(forResource: "ec256pub", ofType: "pem")!

let keyString = try? String(contentsOfFile: filepath)

let publicKey = try ECPublicKey(key: keyString)

With the public key loaded from your bundle into memory, you can now verify a signature with it:

let signature = try ECSignature(asn1: Data(base64Encoded: signatureBase64)!)

(signatureBase64 is the output from createSign() above)

let verified = signature.verify(plaintext: plaintext, using: publicKey)

The constant verified will tell you if the plaintext and signature match.

Here’s a Mac app you can build and run to see this in action.

Feedback

Is this a good approach? See anywhere it could work better? Drop me a line.

Post Mortem: Digamo Beta

Danilo Campos — Mon, 28 Oct 2019 20:21:45 +0000

I’m excited to share a new project with you. It’s called Digamo and it’s a macOS app built for people who have, or should have, 1:1 meetings at work.

Digamo is a collaboration with my dear friend, podcast co-host, and occasional boss, Nicole Sanchez. It’s something we’ve been thinking about doing for years. Back in April, we decided to go for it.

What the research said

Before diving headlong into development on a project we were both excited to build, though, I asked Nicole to conduct some user research. We had some strong convictions already:

Managers didn’t often get the support or training they needed to do their best work
Healthy, regular communication, especially between bosses and their reports, was essential to inclusion
We could improve both of these situations by creating structure and guidance for common workplace communication through software

We still believe these things. But if we were going to invest the energy and effort needed to produce a whole software product, I wanted more information from the sort of people we wanted to serve.

Nicole gamely conducted interviews with people managers, digging into their processes for communication and how they managed the many meetings and conversations that were essential to their daily work. One theme emerged clearly:

Many managers had an enormous Google Doc they were using to keep track of… everything. The text was monstrous and unstructured. Things often got lost over the longer term.

This was an opportunity we hadn’t considered, but it fit into our goals well: software could also structure the information that emerged from these conversations. This would make it possible to slice, filter, search and summarize that information at a later date. In addition to training managers on good communication, and encouraging that communication, we could also provide value by capturing and summarizing outcomes.

This insight was a North Star that guided our product development, and we share it eagerly with you. People are drowning in information. Help them organize it better, you’ll make a better workplace.

Starting development

At first, we weren’t sure how eager people would be for yet another piece of software at work. We started with the goal of reaching an alpha that would run on an iPhone, sync with your work calendar, and help you prepare for meetings.

The idea here was that we could meet our users in their spare time, relieving their anxiety about upcoming meetings by providing a clear structure for the sorts of things you do before and after sitting down. You might have some decisions that you want to make sure are made by those in attendance. We suggested warmup activities to build rapport between attendees. How will you know the meeting was successful?

We prompted the user to think about, and write down, responses for all of these and more. A neat party trick was that the output was nicely formatted into an agenda you could email.

There was just one problem: the iPhone was a bad fit for these tasks. No one wanted to look at their phone in the middle of a meeting, and prepping for meetings just isn’t the sort of casual task anyone is eager to do with their thumbs.

And we were about to have company.

~Validating the market~

When competitors join the scene, it’s Silicon Valley tradition to smile fixedly and announce how excited you are to see them validate the market. There’s some truth to this posturing, though: it’s encouraging to see others converge on a conclusion you’ve reached on your own. Maybe the timing is right for your idea.

We took the validation to mean we could dispense with the idea of building this as an iPhone toy. We would proceed as though the world was ready for another piece of workplace software.

Still, no amount of business aphorisms would change that we were now approaching a problem alongside teams that were bigger and better-capitalized than we were. Moving to a desktop format would help our project be taken seriously, but we were still outgunned.

For our vision to have a future, we would need to chart an unconventional course. As the sole engineer on the project, it was my job to make things work while keeping things lean. If people were going to use this on the job, it had to be sturdy and reliable. And we had to ship quickly, with competition around the corner. These are interesting constraints to manage when your developer bus factor is one.

What are the decisions only we would make?

As outsiders, Nicole and I had little hope of raising money for this project without showing significant progress, so that ruled out bringing on more engineers. Without a larger crew, I didn’t feel confident in using web technology for something so mission critical. I’d be tied to my keyboard indefinitely, protecting the infrastructure that kept the product alive.

So we tried something different: decentralizing our software entirely. Our approach turned to a native macOS application that would host and maintain all its own data.

Server can’t go down if you don’t have a server.

Because we weren’t starting with non-negotiable hyper growth as a requirement, this old-fashioned approach would be viable for us. The more we explored it, the better it fit our values. By designing our project without a centralized server infrastructure, we could guarantee that no one else surveilled your usage of it. This was important because we wanted our users to be real about the thorny communication issues they encountered at work. We wanted them to trust our product the way they would their own physical notebook.

I’ve seen complex, misconfigured workplace software that leaks sensitive details like a sieve. It’s a privacy nightmare. Our approach sidestepped all of that.

We also got some practical benefits: the application could run locally without needing to package an entire web browser under the hood, so the binary size is just 20 MB. The native code is also efficient. Even with a large data set, it doesn’t seem to need more than 50-100 MB of system RAM. So, as a bonus, we got a minimal resource footprint and the ability to run without an internet connection thanks to building a native desktop app.

For object graph maintenance and persistence, the app uses Apple’s Core Data framework. Ten years after my first Core Data projects, I’m impressed with how much easier it is to work with these days. The framework still has a meaningful learning curve and I’d be bullshitting you if I said I grasped all its complexities. Nonetheless, I found it a straightforward way to maintain all of Digamo’s relationships and generate the user-specified queries needed for summarizing data.

As a long time iOS developer, I have to take a moment to gush about Cocoa Bindings. They make UI development so fast and easy. With the advent of SwiftUI, they may be destined for sunset. I’m glad I finally got a chance to use them, after years of envy from afar.

We still ended up with a lightweight server to provide automatic updates, delivered by the excellent Sparkle Project. This is just good practice if you’re distributing outside the App Store, but it’s also essential for a beta. Our users will always have access to the latest features if they opt-in to these updates. Still, the server could go down for a weekend and no one’s work would be interrupted.

Reaching the home stretch

Meanwhile, Nicole’s work in the field was yielding some interesting feedback.

In her capacity as an expert in organizational design and workplace culture, Nicole spends a lot of time training leaders in the basics of good management. She had this slide:

People were grasping at it more than anything else in her trainings. Just a simple spreadsheet, but it offered so much clarity about how to consistently do 1:1 meetings. Weeks after their first introduction, people were still using spreadsheet as part of their ongoing work.

We had our product.

From there, we dumped the complexity of calendar syncing and meeting prep. Our laser focus was one thing: supporting 1:1 meetings. Setting expectations for the topics people should cover, helping them keep track of how often they discuss things like feedback, professional goals, time off, major wins, and more—not to mention helping our users dig up those discussion notes later on.

Nicole’s spreadsheet also asked people to keep track of sentiment, and we worked together to find a structure for this fuzzy data so that we could surface it in the UI.

Each teammate gets their own emoji timeline, showing the progression of their sentiments over time. We can also give you a bird’s-eye view of sentiment across your team at any given moment, as the teammate selector list view displays a summary of the most recent entry. That view also flags any teammates who have been neglected in your 1:1 meetings, always showing people with meetings furthest in the past at the top of the list.

Emojis are subjective, so it’s possible to set your own preferences for them, too.

With all this data structured, it’s easy to retrieve later on. Just choose a teammate, a time frame, and the notes you care about, and Digamo will generate a summary. We can also do the same with your whole team. We know how much work performance review season can be. We’re excited to see how this feature helps streamline those processes, reminding you of the full picture of your team’s challenges and accomplishments.

So that’s Digamo. It’s your private, digital notebook for recording 1:1 meetings. Thanks to the Vaya Consulting team, and especially our friend Dr. Nick Bedo, for the support in getting this out the door.

Hidden in the product are a handful of deliberate bias mitigation strategies:

Summaries help mitigate recency bias, surfacing details you might have forgotten in the day-to-day maelstrom of surviving work.
The teammate list really wants you to see anyone whose 1:1’s you’ve been dodging.
By collecting your sentiments, in addition to those of your 1:1 counterparts, Digamo can help you compare how you’re engaging with one teammate versus another.

What’s next?

There’s so much more we want to do with Digamo, but it’s time to get it out into the world. High on the list are things like automated backups, sync with other devices, and a return of calendar sync. We’ll get there. Meanwhile, we’ve got the start of something a lot of folks have been asking us for. We hope the structure and conveniences provided by this initial beta will be helpful in your daily work.

While a lot of the people we know use a Mac, we know a macOS app doesn’t cover the full spectrum of people who need this product. We’ll be thinking about how to deliver this more broadly in the future.

Meanwhile, Digamo is free to download and use while we develop it further. Download it here.