Author Archive

End of the Road for Google Drive in Transmit

Tuesday, October 8th, 2024

We never like removing functionality from our apps. We especially don’t like doing it when it’s due to circumstances beyond our control. But, sometimes — rarely? — it can happen, and so, please take note:

At some unknown point in the future, Google will revoke Transmit’s access to Google Drive. Sometime after that, we’ll be releasing updates to Transmit and Nova that remove the ability to create Google Drive connections.

Transmit itself is of course still in active development, and no other connection types are affected.

(Note that existing connections should continue to work for as long as they remain authenticated!)

Why Though

Well, Google has a new set of policies that require apps that connect to Google Drive to go through expensive, time-consuming annual reviews, and this has made it extremely difficult for us to reasonably maintain Google Drive access. You may have seen iA Writer’s announcement that they are stopping development of their Android version for similar reasons. Our experience was different, but our circumstances are similar. While Google Drive may not be the most popular connection option in Transmit, we know many users rely on it, and we often use it here at Panic to send and receive files from the game developers we work with. 

This is not a decision we took lightly, and was the result of much debate and anguish in the office. But rest assured we looked at every angle. Hopefully that explains everything.

Actually, I Want to Know More

Okay, okay, here’s a more background for the deeply curious. In 2019, Google announced they were adding additional security checks to apps with full access to users’ files on Drive. Shortly after, they prevented Transmit from authorizing new Drive users. We submitted Transmit to Google for review. And waited for months without hearing anything back.

Eventually, by reaching out through friends of friends of friends to find someone inside Google who could help, we got in contact with a Google employee who was very helpful in getting the process started. We went through review, and our access was restored in early 2020. Unfortunately, we were never able to get Google to approve Nova.

For the next couple years, the annual re-review was pretty straightforward. However, in December 2023, Google again disabled Transmit and emailed us, explaining that we would need to complete a “Cloud Application Security Assessment (CASA)” security review. The review found no security issues with Transmit, but it was an incredibly lengthy process. It involved registering with a security lab, running a vulnerability scanner on Transmit’s source code, and filling out a long form. Between each step, we had to wait for days before we’d hear back from the lab, causing the process to take nearly a month.

In March, Transmit was re-approved for Google Drive access — but we were told we would now need to pass this check annually. At this point, we began to question whether this yearly process was worth it.

Between the weeks of waiting, submitting the required documentation and the process of scanning the code, it took a significant amount of time from our engineers. For example, Google provided a Docker image for running the scanner, but it didn’t work. We had to spend more than a week debugging and fixing it. And because the scanner found no problems, it didn’t result in any improvements to Transmit. No one benefitted from this process. Not Google, not Panic, and not our users.

As a small, independent developer, losing this time for no benefit is a huge cost. That week could have been better spent improving our products. But even so, at the time, we resigned ourselves to the yearly checks. We didn’t want to let our users down, and hopefully, now that we had experience with it, the scanner would be easier to run next year.

But then… a couple of months later, Google completely removed the option for us to scan our own code. Instead, to keep access to Google Drive, we would now have to pay one of Google’s business partners to conduct the review. They promised a discounted minimum price, but no maximum price. We realized that either we’d most likely be paying someone else a chunk of cash to run the same scanner we were running, or our bill would end up much higher.

These ever-shifting requirements and expenses are finally catching up to third parties. Other products have discontinued Google Drive support or come up with interesting workarounds with various limitations that don’t work for all users. Ultimately, we think any workaround strategy is too risky and may result in banned accounts, and we definitely don’t want to be responsible for anyone getting banned.

We’re Very Sorry!

In short, with all these factors in play, we have decided we will not attempt to renew Google Drive access for Transmit once it expires. We’ll miss it too. We will instead focus our efforts on other features and products. We know that this situation, to put it in simplified terms, kinda sucks. If Google ever revises their security policies to be more in reach for a small software company like Panic, we will definitely take a second look.

Thanks for using Transmit and thanks for supporting Panic for all of these years. Onward.

The Future of Code Editor

Monday, May 10th, 2021

If you’re pressed for time, here’s the short version:

  • We’ll stop selling our Code Editor app for iOS soon
  • The app should continue to function for a long time, but won’t receive further updates
  • If you bought Code Editor in the last 60 days, contact us if you need help with a refund
  • We’re working on a new version of Prompt, though!

Code Editor — originally called “Diet Coda” then later “Coda for iOS” — was our powerful and full-featured iOS editor for developers. Introduced in 2012, it was packed with innovation, like our “Super Loupe” designed to make iOS cursor placement more precise — even fun, and an “iPad Preview” that let you use your iPad as a dedicated website preview screen long before Sidecar. The goal was to make a great code editor for iOS that anyone could use on-the-go.

Unfortunately, like Transmit iOS and Status Board before it, we’re discontinuing Code Editor as it doesn’t generate enough revenue to cover its continued development.

But that’s not the only reason. Read on.

Why?

First, we must apologize to those of you disappointed by this news. But here’s the backstory:

The process of web development changed dramatically in the years after our release of Coda in 2007, and our products needed to change with it. This ultimately led to our release of Nova for Mac, which supports more modern workflows and replaced Coda 2. (Not to be confused with the other document editor named Coda, not developed by us.) Those same changes to web development workflows also affected Code Editor.

A significant number of web developers now use tools like TypeScript and JSX, which often require a build or compilation process before they can be previewed. The only way to make this work in Code Editor was to separately run the compilers on a remote computer in a different app; a cumbersome proposition for a mobile device like an iPhone or iPad.

So, as the time went on, fewer and fewer web developers found Code Editor useful, and sales declined.

What about making a version of Nova for iOS?

As of right now, we don’t have any plans to bring Nova to iOS because, well, it’s hard to imagine how it would work.

Launching Nova reaffirmed to us how technologically diverse web development has become. During its development, we got requests to support libraries and technologies we thought long dead, as well as requests for brand new frameworks we’d never heard of. The churn of new web tools and tech is rapid and constant. This is why having a flexible extension system is essential for a modern web-focused IDE. But that’s where the trouble lies.

The biggest technical hurdle is the inability to run external processes on iOS and iPadOS. There’s just no way around it: this is required for modern web development. For example, the TypeScript extension is one of the most popular Nova extensions right now, and it launches and runs the TypeScript compiler. While we could attempt to build the TypeScript compiler into Nova, we can’t possibly anticipate and include every such tool that might be needed by a developer. We’d need to bundle compilers, interpreters, and language servers for just about every programming language in existence, not to mention tools like linters, JavaScript transpilers, and bundlers. The scope would quickly become unmanageable, and we’d always be lagging behind the latest versions of these tools.

Even if it were viable, we’d likely run afoul of App Store policy as well. Apps on iOS and iPadOS must use Apple’s Javascript interpreter, JavaScriptCore. Although JavaScriptCore is excellent, many developer tools rely on features or behaviors only present in Google’s V8 JavaScript interpreter. Similarly, WebKit is the only allowed web rendering engine on iOS.

And still, even if we could find some clever technical way around all of these limitations, we wouldn’t know if our approaches would be allowed on the App Store until we’d fully built and submitted them for review. So, we’d be facing a huge investment of time with the possibility that it would all ultimately get rejected.

Faced with this situation, we considered a more modest design: what if we combined Apple’s new File Provider technology with a streamlined text editor? Then we could at least create a version of Code Editor with robust local file support. In the end, we concluded that this hypothetical app didn’t fully address the needs of modern web developers, plus we’d be facing stiff competition from other high-quality apps that are laser focused on this space. We just weren’t confident that the additional work required could sustain itself.

That’s a long way of saying: we gave it our best shot.

But, you know us — we love to make things, and we never say never. None of this means we’re permanently, irrevocably turning away from professional iOS tools. We’ll keep a close eye on the market and see where it goes. If the stars align and the platform shifts, who knows? There may be a way forward for a better product in the future.

What next?

Soon, we’ll remove Code Editor from sale.

The good news for Code Editor users is that it should continue to work fine on your devices for the foreseeable future. (For comparison, even Transmit iOS, discontinued in 2018, continues to work fine today for those who purchased it.) We can’t promise these discontinued apps will work indefinitely, but barring any dramatic iOS changes, they should keep going for a good long while.

Any customers who purchased Code Editor in the last 60 days or so and want a refund, please contact Apple. Apple doesn’t provide us with the ability to issue refunds for App Store purchases directly, but if they deny your request, please contact us.

And what was that bit about a new Prompt?

Well, here’s some good news, at least!

We’re still actively working on Prompt, our iOS terminal/SSH app. Having the ability to tackle quick or urgent administrative tasks from your pocket is a great fit for an iOS app. So, we’ll be rolling out Prompt 3 in the future, and we’ll keep you posted on our progress. We don’t want to tip our hand just yet, but we’re hopeful we’ve come up with some great features to keep Prompt rolling well into the future.

And of course, our Mac apps continue to be as healthy as ever.

Thank you!

It’s always extremely hard to say goodbye to one of our apps. We spent months agonizing over this decision, exploring every approach we could think of that might keep the app viable. This is always our absolute last resort. We know we have customers who love and rely on our apps, and every time we discontinue one, we’re letting them down. Thank you for being a Panic customer and fan. We appreciate your support, always. We’ll keep working hard to develop apps and products you love.

PS: Nova for Mac is doing great! We hope you’ve had a chance to check it out. It’s kind of beautiful that a big part of Code Editor’s core — the parsing engine, grammars, indexing engine, document architecture and more — became the foundation of Nova. Code Editor lives on inside Nova!

Facing Forward

Wednesday, January 6th, 2021


With 2020 now squarely behind us, it’s safe to say that the year didn’t go as anyone planned, but at Panic we somehow managed to release Nova as wildfires were approaching our homes, announce Nour: Play With Your Food for PS5, and update our apps for Big Sur, Apple M1, and iOS 14.

We have even more exciting projects in the works for this year, but to start, we’d like to present you with one very small gift.

Once upon a time, we made one of the earliest MP3 players for the Mac, Audion. We’ve come to appreciate that Audion captured a special moment in time, and we’ve been trying to preserve its history. Back in March, we revealed that we were working on converting Audion faces to a more modern format so they could be preserved.

Since then, we’ve succeeded in converting 867 faces, and are currently working on a further 15 faces, representing every Audion face we know of.

Today, we’d like to give you the chance to experience these faces yourself on any Mac running 10.12 or later. We’re releasing a stripped-down version of Audion for modern macOS to view these faces.

Download Audion.app

Now, this isn’t a full-fledged return of Audion. It can play music files and streams, but it doesn’t have playlists, and we’re not offering support for it. Its primary purpose is to view faces in the converted format. In addition, we’re releasing the source code to document how these faces work and an archive of converted faces.

Some Faces

Inside the face archive, you’ll find hundreds of great Audion faces. Some are more traditional music player interfaces; many mimicked the then-brand-new OS X, replete with pinstripes and brushed metal; and others were boldly glossy and skeuomorphic, a trend which, for a short time, seemed like it might be the future of GUI design. The TokyoBay face by Paul Johnson exemplifies this last aesthetic. Like many faces, it displayed track info on a glossy LCD with scanlines.

Of course, not all faces fell into these categories. The Face PP by Rudluph looks like it would fit right in at the Y2K Aesthetic Institute:

As with any themeable software, Audion got its fair share of holiday-themed faces. Bescherung, by Andy Pratioto, cleverly replaced the time display with animating Christmas lights, causing the lights to animate as the track plays:

In fact, many Audion faces really came alive when animating. Audion supported streaming music from the Internet, but it could take a long time to connect and buffer audio streams, during which time the UI would be static. To assure users that Audion had not frozen, it would play animations while connecting and streaming. Lots of face artists created delightful streaming animations, but I was surprised to find that Slap Happy by Chris Fayette contained a ten-second clip from Charlie Chaplin’s The Cure:

But it didn’t take animation to make a great skin. StickyAudion by Dr. Joseph A. Gardner disguised itself as a classic Mac OS sticky note, with the controls hidden in the text of the note:

This kind of interface is fun, but if you’re seeing it for the first time, it can take a minute to figure how how it works. Interface design over the last couple decades has focused on making GUIs as intuitive and easy to use as possible, and that’s one major reason why themeable software fell out of style. Some Audion faces took this to an extreme, hiding buttons in the design so you would have to click around the face to find where they were. But themeable software also allowed for unconventional GUI designs that remained usable while allowing artists to explore new directions for UI design. Contragravity by Margaret Trauth has always stood out to me as a fun face that is easy to use:

It’s also one of the very few faces that still has a working URL in its info field. Most of the faces contain links to expired domains or abandoned email addresses. Given that they were created around twenty years ago, this shouldn’t be surprising. Face artists put a lot of time and effort into their faces, and while it may be sad to think that all their work has largely vanished from the Internet, people change, discovering new interests and reinventing their Internet identities in the process.

Panic has also changed a lot over the same time period. We still develop some of the best Mac shareware around, but we’re also working on exciting things like Playdate, our handheld game system. This is only possible because, as a company, we’re always facing forward, looking for the next challenge. But Audion remains an important part of our past, and that’s why we’re so excited to bring these faces to life again.

Extras

But that’s not the end of the Audion preservation story!

After our March blog post, we got in touch with a few face authors who had some fun tidbits to share.

In 2001, Joel Day developed a third-party Mac app to create and edit Audion faces named FaceEdit. This app only runs on Classic Mac OS, but Joel has generously made a registered copy available for free — and notes that anyone who wants to pay for a registration code can send him a few dollars on GitHub sponsors. Make some faces!

In addition, an amazing long-lost piece of history: Paul Johnson, Author of the TokyoBay face featured earlier, did some work for Panic conceptualizing the default face for the cancelled Audion 4 and sent me this never-seen-before mock-up of it:

Thanks

Well, we hope you enjoyed this final look at Audion and its many faces on our blog. When we finish converting the remaining faces, we’ll post an update on our Twitter.

And here’s to 2021, which we can only hope will be bright and meaningful for all of you. Forward!

Saving Face

Monday, March 9th, 2020
 

Episode 4 of the Panic Podcast, Audion & On, hit the podcast feeds last week, but if you play the episode directly from our podcast page using the “Play Now” button, you’ll find a nice surprise waiting for you.

A screenshot of the podcast page, displaying audio controlled by an Audion face.

We wanted to give our listeners an opportunity to experience some of Audion’s amazing faces for themselves. No matter how well we described them on the podcast, we couldn’t do them justice. The faces aren’t just visual: they’re interactive.

They’re also an important part of Panic’s history that has been inaccessible to modern computing devices for well over a decade. Although they were cutting-edge technology when Audion launched 21 years ago, porting them to modern Web browsers was an involved process. In this post I’d like to give you a peek at how these faces work, and touch on what it took to bring them to the Web.

Painting a Picture

At their core, Audion faces consist of a base image, with smaller images drawn over it. The base image contains not only the background of the face, but all the buttons and UI indicators.

The base image for Smoothface Original.

Buttons in Audion can have different appearances when they’re pressed, when they’re disabled, and when the mouse pointer is hovering over them. Each of these appearances has its own image.

The disabled buttons for Smoothface Original.

For each frame of animation, the base face is drawn first and any special appearances for the buttons are drawn over that.

SmoothFace original with the stop button disabled.

The other UI elements—the UI indicators, the play time, the track number, and the various animation frames—are then drawn over the face. Faces can display animations when connecting to a stream, when playing a stream, and when the stream is lagging. Face designers can use as many frames as they’d like for these animations, and they control the speed of the animations. Because of this flexibility, each animation frame is stored as its own image.

Animation frames for Smoothface Original.

Drawing images this way is not difficult to do in modern Web browsers. However, the faces themselves used Classic Mac OS file formats which are not well-supported today.

In the Old Days

Audion started as a Classic Mac OS application, and, like most Mac OS applications at the time, it used resource forks to store its assets. Resource forks are a Macintosh-only technology designed to store metadata associated with a file. Every file in Classic Mac OS has a data fork and a resource fork. For Applications, the data fork contains the machine code that was run, and the resource fork contains the icons, graphics, sound, and text strings used by the application. This allowed Mac applications to be distributed as a single file, while Windows applications are typically comprised of multiple files.

A year after Audion launched, Apple released the first public beta of Mac OS X. Although it still supported resource forks, Apple began to discourage their use. In their place, Apple promoted the use of packages. Packages are special folders that appear to be a single file on macOS, but look like normal folders on other systems. They serve many of the same purposes as resource forks, and many users wouldn’t notice any difference between the two technologies. More savvy users, however, began to see resource forks as an artifact of old, outdated software, putting pressure on developers to move to Apple’s newer technologies.

In 2003, Panic alumnus Les Pozdena worked on an app to convert Audion faces from resource forks to a package-based format. Audion was discontinued soon after, so these package-based faces were never used, but the face converter code remained in Panic’s source code archive. When Christa first mentioned that she was doing a podcast about Audion, the idea of adding Audion faces to the podcast page immediately popped into my mind. At the time, I had no idea how the faces worked, and Les’s code provided an invaluable starting point.

Updating the Converter

Les’s converter was mostly complete. It could already open resource files, extract images and their coordinates, and convert images from the PICT image format to PNG, an image format in wide use today. However, the code needed to be updated to run on modern versions of macOS. It used a few functions which have been removed from macOS since the converter was written. The converter also didn’t support UI indicators. Many newer faces, like Smoothface 2, don’t have these indicators. Thankfully, the face files themselves provided a description of their format, making it easy to fill in the missing details.

The template description for a face resource.

After a few hours of work, I set the converter loose on the files in our Audion face archive. After I finished, I noticed that some of the faces were using the wrong text color for the artist and album text fields. As it turned out, these fields could optionally be styled by a separate text style resource. This resource contained the text’s color, its styles, (e.g. bold, italic) and its transfer modes. None of the faces on the podcast page use special transfer modes, but if you’re interested in learning about them, they are documented in Inside Macintosh: Imaging With QuickDraw.

Converting the faces for the Web required making a few changes to how they worked. When drawing to HTML’s <canvas> element, you can get better performance by redrawing as little as possible. Audion redrew the face every frame starting from the base image because it needed to in order to get transparency right, but that’s not required on modern computers. The converter therefore cut the button and indicators out of the base image. This allows the base and the buttons to be drawn separately.

The base image for Smoothface Original with its buttons and indicators cut out.

The most challenging part of displaying the faces on the Web is text rendering. There are two reasons for this. The first is that many Classic Mac OS fonts contain a set of bitmap glyphs that were used when drawing the font on screen and a separate set of outline glyphs used when printing. The bitmap glyphs were designed to look good on low-resolution screens and were faster to draw than the outline glyphs. Modern operating systems exclusively use the outline glyphs, which makes the text look quite different. This was noticeable back in 2001. Audion’s text looked different in Mac OS X than it did in Classic Mac OS. However, HTML’s <canvas> element offers very little control over text rendering, and each Web browser draws the text differently. If you used Audion back in the day, the text on the page will not look exactly like you remember.

Text rendering on Classic Mac OS.Text rendering on the podcasts page.

The second problem is that many Audion faces used custom fonts, and some of these fonts have been difficult to convert for the Web. Mac Postscript fonts also stored their font data in resource forks, and although there are many tools to convert these fonts to other formats, these tools fail to convert some of these fonts correctly. It is likely that we will need to write a bespoke tool to convert these fonts. The faces in our archive use a total of 95 unique fonts, and converting them all will take some time.

Hidden Details

Not every image in the face is used in the Web player. For example, we couldn’t find a good use for the inactive face image, which is used when Audion was in the background. The drag region, a bitmask image which Audion 1 used to draw face outlines while dragging, was the most interesting of these images.

Some face designers used this image to sign their work.

A drag region image with the artist's signature.

Others used the drag region to hide messages or drawings.

A drag region image with the message, "expose what lies beneath."

When SoundJam first added support for Audion faces, they incorrectly used the drag mask for transparency, causing these messages to be cut out from the face. Because of this, some face designers would hide advertisements for Audion in the drag region.

Preserving Audion for the Future

It’s wonderful to be able to show off these faces on our podcast page, but it’s also important to preserve them for the future. A few of the faces in our archive are offensive, especially in a modern context, but they may be useful to future historians.

However, as time goes by, it will become harder to preserve these faces. The face converter already does not currently work on macOS Catalina because Catalina removed support for working with resource forks and PICT images. There are third-party libraries which can read these formats, but much more work would need to be done to the converter to get it running in current and future versions of macOS.

That makes now the ideal time to convert and archive Audion faces. If you have any faces that aren’t in our archive, please get in touch so we can convert as many faces as possible.

For Fun

The most rewarding part of this process has been revisiting the many great Audion faces in our archive. There are good reasons we don’t design customizable software interfaces anymore, but they’ll always hold a special place in my heart. They weren’t just fun, they made personal computing personal.

If you’ve read this far, there’s a good chance that you also have a fondness for Audion. I hope you enjoyed this look into how the faces worked. I plan to post a followup in a few months detailing my progress converting the rest of the faces and showing off some cool finds.

Please look forward to it!