mb

A photo of mb bischoff in a red lip and leather jacket.

mb bischoff (they/them) makes  apps,  posts, &  podcasts changes

rss subscribe mb

Tagged #tech

WWDC 2024 Wishlist

In line with tradition, I’ve compiled my wishlist for this year’s Worldwide Developers Conference announcements. I’m hoping for thoughtful integration of LLMs across the OSes, performance and reliability updates for core services, and the introduction of a few power-user tweaks and long-missing features.

Some of these ideas have been inspired by others’ wishlists, and where applicable, I’ve included those references. Here’s what I’m hoping to see:

  • Siri that works 🎙️
  • Talk to Siri in Messages 💬
  • Focus status messages 👀
  • Notification category management/blocking 📵
  • Notification summaries 🛎️

Apps

  • Passwords app 🔒
  • Voice Memos transcriptions & summaries 🎤
  • Fix Shortcuts (performance, system shortcuts, reliability) 🦾
  • AirPods button should be able to trigger a Shortcut 🎧
  • Fix Screen Time (reliability) ⏳
  • Files app (performance & reliability) 📂
  • Calendar redesign 🗓️
  • Music redesign 🎵
  • iCloud Shared Photo Library Albums 🖼️

iOS & iPadOS

  • Home screen redesign merging Spotlight and App Library 📱
  • Set default apps (maps, camera, calendar) 📲
  • Lock Screen quick action customization 🔒
  • Smart and AI Playlists 🎶
  • Share Sheet redesign ⬆️
  • Default app support for camera, calendar, & maps 📍
  • iPad Multi-user 👥

macOS

watchOS

  • Custom watch faces ⌚️

visionOS

Developer

  • Xcode for iPad 🛠️
  • Copilot-like assistant in Xcode 🧑‍✈️
  • API for local and cloud LLM access 🤖
  • Clipboard manager API 📋
  • SwiftUI parity with UIKit 🕊️

To be honest, I’ll be elated if I get even half of these things this year. What’re you hoping for from this year’s conference?

If you’ll be in Cupertino for the event next week, don’t hesitate to reach out and say hi! I’ll be there with my Lickability business partner, Brian Capps, from June 10  –  13.

#apple #tech #wwdc

Clockwise #430: Misinformation Tracing 

Clockwise #430: Misinformation Tracing

I was thrilled to guest on episode #430 the Clockwise podcast today where we talked about the last apps we purchased, how we’d handle third-party payment options on our Apple devices, our experience with Exposure Notifications, and how we track our resolutions, themes, and habits for the new year.

Give it a listen and let me know on Twitter what your answer would have been to my question: What apps or systems do you use to track your progress toward your resolutions/themes/habits you’re trying to work on in 2022?

#me #podcast #tech

Reasons You Aren't Updating Your Personal Site 

This was the first year in many that I managed to regularly update and publish content on my personal site. In past years I started strong (usually around New Years) with fresh writing, energy, and enthusiasm. But somewhere around February or March, things died off and I could never find that momentum again.

Why was this year different? In this post I've tried to tease apart factors that made writing and editing easier this time around – hopefully there's something in here that may be useful for your own personal website.

Brian Lovin

Like Brian writes here, for me 2020 was the year that my personal website saw some regular updates. Looking forward to 2021, I plan to keep up the momentum and increase the number of long-form posts here.

Lovin makes some great points in this piece about ways to make that easier on yourself by maintaining an ongoing list of ideas, turning conversations you’re having on social media into articles, and making the process of publishing as seamless as possible.

#release notes #tech

Being Generous with Your Time 

There is no gate keeping, no screening, just a calendar form. I just show up to whatever appointments folks booked on my calendar with hopefully a little context of what they’d like to discuss. I don’t think I’m some industry pundit, but I do recognize that anyone who has been doing roughly the same thing for 10 years might be able to provide advice for someone earlier on in their career. Also, it just feels like the right thing to do to try to give back to folks in this very small way.

My pal and former Tumblr coworker Brian Michel is opening up his office hours to the public and wrote a great post about why experienced technologists should be open to new connections and offering support, as well as some instructions on how to set it up.

If you’re in tech and wanna talk to one of the kindest, smartest folks I know, you can sign up for his office hours here. I just did.

#calendly #management #office hours #tech

Lickability Blog: Tooling at Home 

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.

I wrote a new blog post over on the Lickability blog about the new tools we’re using to work from home better and some tips about how we’re using them. 🛋

#apps #coronavirus #lickability #software #tech #tools #work

An App Can be a Home-cooked Meal 

The exhortation “learn to code!” has its foundations in market value. “Learn to code” is suggested as a way up, a way out. “Learn to code” offers economic leverage, a squirt of power. “Learn to code” goes on your resume.

But let’s substitute a different phrase: “learn to cook.” People don’t only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way. Or because they want to carry on a tradition. Sometimes they learn just because they’re bored! Or even because—get this—they love spending time with the person who’s teaching them.

Robin Sloan

A very smart essay from Robin about an app he made for his family, but also about how truly personal software and its creation is powerful.

He reminds us that not all code has to scale or produce market value. Sometimes code can be a way to express yourself, have fun, and make life a little better for the people closest to you. Sometimes coding can be like cooking a meal for someone you love.

#apps #code #essay #family #iOS #media #software #tech

App Builders CH 2020 

I’m super excited that I’ll be speaking this May at the App Builders CH conference in Lugano, Switzerland. App Builders is one of the biggest European conferences about mobile technologies, and I’ll be presenting alongside a bunch of incredibly smart folks. It’s sure to be a great time, and I hope to see you there! 🇨🇭

#conferences #ios #me #talks #tech

Write Your Way Out

mb speaking at Release Notes 2016
Photo courtesy of Ben McCarthy

In September 2016, I was honored to be invited to speak at Joe and Charles’s incredible Release Notes conference in Indianapolis. Release Notes, an outgrowth of their podcast of the same name, approaches the software business as a business first and foremost. Their guiding principle is to discuss “everything but the code”.

Here’s the audio and slides from my talk. It’s called Write Your Way Out (yes, it’s a Hamilton reference). I spoke about writing and the importance of writing well as a software engineer, a product manager, and especially the owner of a software company. Watch it below and let me know what you think on Twitter.


The dates for Release 2019 in sunny Playa Mujeres, Mexico have just been announced (Oct 3—5). If you’re in the software business, I can’t recommend it more strongly. Get on the mailing list so you don’t miss tickets!

#release notes #talks #tech #writing

Culture Rot

This weekend, I spoke to the audience of the Difficult to Name reading series at Study Hall in Brooklyn. My talk was about the internet, my fears about building and sustaining culture there, and what we might be able to do about it. Watch the talk or read my prepared remarks below. And let me know what you think on Twitter. I’m @mb there.


I want to tell you about a number that scares me: 404. That infamous code you see when that internet thing you meant to visit is gone or it moved and no one bothered to add a redirect or maybe it never existed at all.

I’m curious though: how many of you have ever made something you’re proud of on the Web?

So many of us have written, recorded, photographed, or created important works in our personal and professional worlds that live online. Maybe they’re your bylines at that fancy publication about tiny houses, or your YouTube seltzer reviews, or your graduate thesis about the history of pizza ovens. It’s not really important what they are, just that they exist and they’re online.

Well, until…they don’t. 404: Page Not found. 410: Gone. 500: Internal Server Error. These numbers, or status codes, tell us what went wrong but not really why. This problem, the problem of the disappearing internet, of “link rot”, is no joke. Researchers have found that over 50% of URLs cited in Supreme Court opinions no longer point to the intended content. Roughly 70% of links in academic legal journals are broken, and 20% of all science, technology and medicine articles suffer from link rot. The average life of a webpage hovers right around 100 days.

People often patly state that “the internet never forgets,” that once something is online, it will be forever. In a certain light that’s true. It’s nearly impossible to permanently remove something from the internet, on purpose. But, by the same token, the web also disappears at an alarming rate. 5% of the entire internet is lost every year, and we barely notice.

Making something on the web is not a one-time investment. Someone has to spend money every year on the domain, hosting, and maintenance. But what happens when the financial incentives to do that change? Right now the massive data centers that house all this information use 3% of all the electricity in the United States. What happens when that power gets too expensive? Or when we’ve been online for centuries and we start deleting dead people’s pages? Unlike a film, or a play, or a book, the costs of keeping art and science on the web are never-ending. We’re building one of our most important shared cultural resources on land that we rent rather than own, on borrowed time from a parking meter that’s all but guaranteed to run out.

We even saw a large-scale example of this recently when a capricious billionaire hastily took down years of content from Gothamist and DNAInfo, leaving reporters to scramble for saved and aggregated clippings of their work just to build a portfolio to get an new job.

Before you say, “Wait Matt, there’s this One Weird Trick. What about the Wayback Machine, what about the Internet Archive, what about Google’s cache?” Let me quote the web developer Maciej Cegłowski in his talk Web Design - The First 100 Years:

We have heroic efforts like the Internet Archive to preserve stuff, but that's like burning down houses and then cheering on the fire department when it comes to save what's left inside. It's no way to run a culture. We take better care of scrap paper than we do of the early internet, because at least we look at scrap paper before we throw it away.

He’s right. It is no way to run a culture. We’re experiencing quantitative losses of data on par with the burning of Alexandria every year, and we’re barely blinking an eye as the stuff we’re making vanishes in a puff of smoke.

The truth is: there is no easy fix. But as writers and makers and inhabitants of the internet, we need to demand better of the platforms and services and publications we entrust with our work. It might seem safer to trust the big guys (Facebook, Twitter, Medium) with this content because they have the funding and incentives to maintain it. That’s true today, but large platforms like them have failed before, taking terabytes of data with them. Remember Friendster, TwitPic, Geocities?

There are academic efforts like Perma.cc out of the Harvard Library Innovation Lab that will solve this problem for the most important legal and scholarly works. But we can and must to do better than that.

Starting in 2014, a small group of programmers became obsessed with building what is called “content addressable” version of the internet called IPFS. IPFS stands for “InterPlanetary File System”. And “content addressable” means that files are stored and located by their content instead of an arbitrary and therefore brittle address. As I’m sure some of you have guessed by now, it’s built on top the blockchain. Insert eye roll emoji 🙄. But before you write them off, I think these nerds might be on to something. Their system, which is entirely peer to peer, and inherently resistant to the rot I’m talking about is already being used to build a mirrored version of Wikipedia that will be accessible from countries with oppressive regimes, and was used by those in Catalan seeking independence when the government blocked their pages from being accessible on the web. The IPFS team is building a system by which the websites and apps of tomorrow might be able to defend against this failing foundation, but who knows if it’ll get adopted.

The next time you make something and put it online: think about where it’s going to live, how long it’ll be around, and what you can do to preserve it, even if that means making an extra local backup, or printing it out on a dead tree. The culture we’re building together is increasingly digital, hyperlinked, and accessible from anywhere. But it’s not accessible from any when. We’re losing more and more of it every day. If we’re going to continue making things online, we need to deal with this problem systematically and soon. How? I’m not sure. Maybe IPFS, or something like it that hasn’t been invented yet. Until then, I’ll keep my printer.

#404 #internet #talks #tech

Code is Prose

I first saw the phrase “Code is poetry” pop up on websites and in conversations about the craft of software development in the early 2000s. Popularized by the Wordpress project, the idea that programming and poetry are similar forms has been the subject of Quora questions, as well as pieces in WIRED, Torque, and Smashing Magazine.

On its face, it is an appealing idea for a few reasons. We programmers would prefer to think of ourselves as lone artists creating clever works of art than a tribe of code monkeys or monastic scribes writing line after line of boilerplate to make a button do something. Sure, some methods might look so concise and beautiful that they remind you of a piece of modern poetry or so archaic that they sound like Old English. And yes, sometimes the variable names and symbols used in a script look sort of like E. E. Cummings if you squint.

But this idea is an example of elitist thinking in our discipline, and it misleads new programmers and the general public into believing that being a software developer requires natural talent, a spark of divine inspiration, or that the code they write should be inscrutable upon first glance. Nothing could be further from the truth.

Great code reads like great prose. It is succinct, expressive, and clear the first time you read it. It tries to be as linear as possible, guiding the reader through tough transitions with the knowledge that one wrong move could lose them entirely. Good code uses language and vocabulary with an understanding of its audience, and it aims for functions with a single main idea, like the paragraphs of a persuasive essay. Instances are narratives—they have a beginning (initialization), a middle (operation), and an end (deallocation).

Well-structured codebases feel more like newspapers or encyclopedias than poetry collections. Individual files operate in a shared universe and are often edited by multiple authors and revised as the facts change. Frequently used objects act like recurring characters: the more you see them, the more you begin to understand how they work.

Even language designers know this. Smalltalk, Swift, and other languages that don’t start with the letter “S” have made English prose the basis of their syntax design. Individual lines of code are called statements, the same word we use in English for the most common type of sentence.

Unlike poetry, computer code does not try to express emotion or evoke meaning through rhythm and rhyme. It aims to tell a story to two audiences: the machines that run it and the people who maintain it. It both narrates and defines how the product it powers works. As Eric Suh points out in Writing code and prose:

Those that I see write the cleanest, most maintainable code are those who write prose well, whether in documentation, in emails, or in their everyday lives.

Many aphorisms about writing style translate fairly well to coding.

So, the next time you write a piece of code and revel in its austere beauty or multi-layered meaning, think about whether it might be better suited as straightforward prose. And while you’re at it, write some actual prose in the form of documentation. Save the poetics for poetry.

#code #tech #writing

Activist Engineering

You’ve been there. You’re sitting in a meeting and your boss, a product manager, or an executive is talking about Q2 goals. They’re laying out a roadmap of the features that are going to be “coming down the pike”. All of a sudden you see it. An innocuous bullet that makes your blood boil: “Auto-invite friends”, “Re-engagement notifications”, or “Disable ATS”.

The particular feature isn’t important. What matters is that you’re the engineer that’s noticed this capital-B Bad Idea. You know why it’s a problem. This time it’s not just the technical debt or the time it’d take to implement. This idea is bad because it trades a worse product for a better “business”: revenue, eyeballs, impressions, you know the drill.

You have a choice in this moment. You can stay quiet and hope it goes away or point it out, question it, and even argue against it. But so often, engineers fold. They ignore their conscience and their gut in the interest of a steady paycheck and an easier work day. Avoid conflict at all costs, especially when that cost could be their job. “Just keep your head down and do what you’re told”, they think, while they twiddle their thumbs as bad product decisions whoosh by. Sure, they complain about it over drinks with coworkers and in one-on-ones, but they don’t say anything when it counts.

We’re better than this. As software engineers and designers, we’re in the room when decisions are shaped, and the only ones who have the power to actually execute them. It’s our responsibility not to forsake the people who trust the apps we make with our silence. To stand up and refuse to implement unethical systems and dark patterns. And even more, to educate stakeholders on the real human costs of their business decisions: the time, attention, money, and trust of their customers.

It’s harder, yes, and riskier. But they can’t build it without us. We get a say. Even if it’s not in that meeting, we can think about the goals they’re trying to accomplish and propose alternatives. We don’t have to hide in our sit-stand nap pods and eye-roll while we engineer a worse world. We can do more than write code. We can research and present better alternatives. We can write memos and make slide decks to convince them of our position. We can be activist engineers.

Even though these bad ideas may buttress the metric-of-the-week, they’re at the direct expense of consumer trust and customer satisfaction. They’re a tax on our company’s reputation. We have to push the people making the decisions to measure more than just the number they’re trying to increase. Look at reviews, net promoter score, social media mentions, and team morale. All of these trends matter to the long-term health of the company, and should be treated as such.

This requires long-term thinking and the kind of organization that’s receptive to it. In many companies, quantifiable short term gains are valued more than long-term, qualitative investment. The best companies resist this temptation to make a quick buck and build upon a lasting mission and principles. But even in companies with lofty vision statements, things can go awry. A bad quarter can send the company’s hard-won principles out the window to make room for the growth hackers.


In other disciplines, engineers wear an iron ring to remind them of their commitment to their profession. Though we may not be part of the Order of the Engineer, we can learn a lot from their obligation:

As an engineer, I shall participate in none but honest enterprises. When needed, my skill and knowledge shall be given without reservation for the public good. In the performance of duty, and in fidelity to my profession, I shall give the utmost.

Of course, not every idea you dislike is a bad one, so spend your reputation thoughtfully but forcefully. Make your dissent count, but don’t be a jerk.

Our job as software engineers is to build things that make the world (or a corner of it) better, things that solve problems. But that’s not our only job. It’s also to be gatekeepers: to prevent ideas that we know are harmful from being realized. What’s the worst that could happen: we get a reputation for giving a damn?

#activism #code #politics #programming #tech #work

Lowering the Gates

The New York Times Building at night
Photo courtesy of Jason Kuffer

A year ago, I sat in a glass-walled conference room at The New York Times in a routine meeting. I listened as a business-schooled product manager spoke about yet another monetization strategy when he broke character and whispered, “now is the time to lower the gates”. He was referring to The Times’s crackdown on website users who read articles for free by googling headlines, installing NYT Clean, and clearing their cookies. Now, that defensive mindset is creeping into The Times’s mobile products.


Late last month, The New York Times quietly slashed the number of free articles in its mobile applications from 3 per day to 10 per month. It’s not hard math, each reader can access 80 fewer articles this month than they could have last month, a decrease of 89%.

While great free apps like Circa, Yahoo News Digest.1, and now Paper from Facebook, fight to take over mobile news, The Times scrambles to persuade mobile users to pay top dollar for its coverage by limiting what they get for free.

Since the NYTimes iOS application was released in 2008, the number of articles that users can read for free has changed multiple times. The app has gone from everything being free, to the dozen rotating “Top News” stories, to three articles daily, to only ten per month. The last change occurred just months after the previous. If it had to be adjusted this quickly and drastically, the meter strategy on mobile just isn’t working.

Since The Times’s mobile products are partially supported by advertising, it’s counterintuitive to drive down the number of ad impressions by cutting off enthusiastic users just as they’re getting excited about the content. Ten articles per month just aren’t enough to justify keeping the apps installed; it’s almost insulting. The proof is in the plummeting App Store ratings as well as in the company’s usage statistics, which I suspect show readers returning less frequently since the change.

From the outside, it looks as if the company is desperate to drive up subscription numbers on its confusing digital subscription packages, which are still more expensive than having the newspaper dropped on your doorstep every weekend. But I think there may be something deeper going on.

The Times plans to roll out even more digital packages this year, and people I’ve spoken to at the company are starting to worry that few will want them. Why not make its current offerings less appealing in the short term, so that they can save the day with their newer, better apps in a few months? If this is what NYT is doing, it’s downright irresponsible and counter to The Times’s commitment to integrity. There’s no integrity in misleading readers.

I asked Times spokesperson Linda Zebian about the changes and she defended the move, writing, “We continue to believe that our strategy of balancing free and accessible content with revenue from paid usages is the right one.” When asked whether the company was attempting to make the mobile applications behave identically to the website she added, “The intention is to align the meter experience on mobile apps with the website and our mobile website…”. I got no real answers to the questions of whether this change is expected to decrease advertising revenue or intended to bolster the planned new digital products.

When I raised this issue on Twitter, Jordan Kay asked me what I would do differently if I were in charge of The Times’s digital subscription strategy. If The Times wants to be the place that most Americans read their news, then it must adopt a freemium model that’s much freer than this in order to compete.

But I don’t think that’s what The Times is or should be. It’s a premium news source, and it would be much better to make that clear from the start. Everyone knows how good the journalism is. Charge for it up front with an optional free trial. As it stands, the meter devalues both the product and the brand, and any new products the Times plans to add later this year run the same risk — creating confusion and muddling the message.

The Times’s new mobile strategy forces casual readers to look for other options, and there are many out there. I hope The Grey Lady will realize her mistake and change course quickly, but knowing how things work inside an organization founded over a century ago, I’m not holding my breath. By dropping the pay gates on mobile users, the Times is ensuring its irrelevance in an increasingly mobile world.


1. Disclosure: Yahoo owns Tumblr, where I work.

#nytimes #paywall #strategy #tech