Panic Inc.

Panic Blog

May 17th, 2017

Last week, for about three days, the macOS video transcoding app HandBrake was compromised. One of the two download servers for HandBrake was serving up a special malware-infested version of the app, that, when launched, would essentially give hackers remote control of your computer.

In a case of extraordinarily bad luck, even for a guy that has a lot of bad computer luck, I happened to download HandBrake in that three day window, and my work Mac got pwned.

Long story short, somebody, somewhere, now has quite a bit of source code to several of our apps.

Before I continue, three important points:

  • There’s no indication any customer information was obtained by the attacker.
  • Furthermore, there’s no indication Panic Sync data was accessed.
  • Finally, our web server was not compromised.

(As a reminder, we never store credit card numbers since we process them with Stripe, and all Panic Sync data is encrypted in such a way that even we can’t see it. Read more.)

The other important fact is that I feel like a monumental idiot for having fallen for this.

How did this happen?

Story

HandBrake had been nagging me for some time to install an update. I finally decided, for whatever reason, to do the update. There was a note in HandBrake’s update dialog that the incremental update was not available, and that I’d have to download an entirely fresh copy from their server. I didn’t think too much of this, as we’ve been in a similar situation with a broken Sparkle update channel once before (the worst).

So, I managed to download within the three day window during which the infection was unknown, managed to hit the one download mirror that was compromised, managed to run it and breeze right through an in-retrospect-sketchy authentication dialog, without stopping to wonder why HandBrake would need admin privileges, or why it would suddenly need them when it hadn’t before. I also likely bypassed the Gatekeeper warning without even thinking about it, because I run a handful of apps that are still not signed by their developers. And that was that, my Mac was completely, entirely compromised in 3 seconds or less.

By the time news broke of the HandBrake infection, git credentials had already been stolen from my Mac and used to clone several of our source code repositories, according to our logs.

As soon as I discovered the infection on my Mac, I disabled it, took the Mac out of commission, and we began the incredibly lengthy process of changing all of my passwords, rotating the relevant secret keys throughout our infrastructure, and so on, to re-lock our doors and hopefully prevent anything else from being stolen. The vast majority of these things were changed or rolled simply out of an abundance of caution — again, there’s no indication our web servers were compromised — but in this kind of a situation, you change all the locks.

Then, the forensics: we began combing through our logs to try to determine the extent of what was accessed which, to reiterate, we believe is limited to source code and personal data on my Mac. Thanks to good logging (thank you, James) we got a very complete picture. The method the attacker used prevented them from cloning all of our source code — they were making educated guesses at our repo names, one-by-one, which did not expose everything.

The source code theft was confirmed when we received an email from the attacker (with a few source code files attached as proof of the theft) demanding a large bitcoin ransom to prevent the release of the source code, which would “suffocate” our company, in their words. We’re working on the assumption that there’s no point in paying — the attacker has no reason to keep their end of the bargain.

And that brings us to today.

So…

When the dust settled, we sat down for a company all-hands meeting, and the conclusion was a little different than I originally expected.

Someone has a bunch of our source code. But does it really matter?

There are essentially three “worst case” scenarios we considered with our source being out there in somebody’s hands:

  • They build free, cracked version of our apps.
    Guess what — those already exist. You can already pirate our software if you want to pirate our software — but please don’t — so this doesn’t really change anything in that regard. Also, whatever “free” version of our apps that would come from this person are virtually guaranteed to be infected with malware.
  • They create malware-infected builds of our apps.
    This seems likely. Given the person’s entire MO was to infect a well-used Mac app with malware, it seems inevitable. But we will find them, and working directly with Apple, shut them down. To minimize your risk, never download a copy of one our apps from a source that is not us or the Mac App Store. We are going to be hyper-vigilant about the authenticity of downloads on our servers.
  • A competitor obtains this source to attempt to use it to their advantage in some way.
    The many Mac developers we’ve met over the years are fine, upstanding people. I can’t imagine any of them being this unethical, or even being willing to take the risk of us finding fingerprints of our code in theirs. And let’s not forget that — you guessed it — there’s a good chance any stolen source could have malware slipped into it.

Also, one important thought gave us some comfort:

With every day that passes, that stolen source code is more and more out-of-date.

This hack hasn’t slowed us down. That source is already missing a ton of fixes and improvements we committed over the last week alone, and six months from now it will be missing major critical new features. In short: it’s old and getting older.

At this point in our discussion, we even half-seriously considered releasing the source code ourselves — and when that idea was floated, and we realized there wouldn’t be any fallout (other than a lot of code questions!), that’s when we truly felt free.

Assistance

Within 24 hours of the hack, we were on the phone with two important teams: Apple and the FBI.

Apple rallied the right security people quickly to learn all they could about our situation. (They had, of course, already blocked the HandBrake-attached malware for the broader Mac population once it was discovered widely.) They walked us through the best way to roll our Developer ID and invalidate the old one, which we don’t think was leaked, but we’re being overly cautious. And more importantly, the right people at Apple are now standing by to quickly shut down any stolen/malware-infested versions of our apps that we may discover.

The FBI is actively investigating, so I can’t say anything more about that.

Together

We’ll be working overtime for the foreseeable future to keep an eye on this situation.

But we could also use your help.

If you see any cracked or otherwise unofficial versions of our apps in the wild, it’s safest to assume they are infected, and we ask that you please let us know. If you see our source show up somewhere, also let us know. And if you have information that could help with the investigation into this incident, definitely let us know.

The more we know, the more we can use every method available to us — legal, technical, you name it — to fix it.

Feel free to e-mail us or DM us on Twitter anytime — even if you just have questions. We’re here.

And as a reminder, never download one of our apps from a source that is not our website or the Mac App Store.

This has been a hard post to write. I hate that this happened. I kick myself every day for not paying attention to what I was doing; the tells were obvious in hindsight. It’s a good reminder though — no matter how experienced you might be with computers, you’re human, and mistakes are easily made. And even though this doesn’t affect our customers directly, we want to apologize that we’re even having to have this discussion with you.

We’ve been doing this 20 years because you keep us going every day — by buying our software, by giving us your good ideas, by telling your friends about us. You are the good in the world. So we’re going to do everything we can to rise above this and keep going even further — together.

Posted at 10:50 am 82 Comments
April 4th, 2017

Welcome to 2017… Panic’s 20th anniversary!!

No, your eyes do not deceive you. Some of you may not know that we founded our company in 1997, but it’s true. We’re older than Facebook, older than Twitter, older than Google, and somehow still kickin’.

Every year is a little different, and last year was for sure — a little bit quieter on the software front (at least publicly), and a whole lot louder on the launch-of-a-major-multi-platform-video-game front.

Yes, it’s time: here’s a look back at 2016, and look forward to 2017.

Releases

FirewatchFirewatch

2016 was clearly the Year of Firewatch for us. Thanks to Campo Santo’s heroic efforts, Firewatch shipped right on time on Mac, PC, and PlayStation 4. We later added an Xbox One port. I wrote a lot about the launch of Firewatch previously, and it’s still moderately interesting reading.

We’ve had a year to digest the whole (almost out-of-body) experience. I think the most rewarding part was something we don’t often get from apps: the e-mails, blog posts, YouTube videos, and forum discussions people had about Firewatch. How it reminded them of past loves, how it reinvigorated their fondness for the outdoors, how it spoke to life decisions past and present, how the ending was disappointing and/or absolutely perfect… it all made us feel like we created something a little bit more substantial than a lot of video games.

We got to support good friends in making something cool, we got to establish our name a little bit in a new industry, we got to push our marketing skills, and we learned a ton about what it takes to make and ship a game. Firewatch was also a financial success for us — a very solid return on our investment — which has created a nice cushion that I think will allow Panic to develop more software, take more risks, and try more crazy things in the future. That means Firewatch’s success is everyone’s gain. (Even you, the person who might be waiting for a new Coda!)

Since the game’s release:

  • Firewatch landed in a lot of year-end Top 10s, including Salon and Vulture and Polygon and The Independent (#2, right behind Uncharted 4!?). PC Gamer even said it had the best writing of any game in 2016.
  • It officially sold over one million copies.
  • We shipped on the Mac App Store (for people who don’t use Steam), which got featured by Apple.
  • We won some nice awards, including Best Debut and Best Narrative at the 2017 Game Developer Choice Awards.
  • And we lost a lot of awards, but one cool thing was consistent: our very first video game was right there nominated next to major franchises from massive studios. Amazing.
  • We’re now working to bring Firewatch to Japan, with localized subtitles. Here’s hoping we can pull it off.
  • And who could forget the story of the uncle that works for Nintendo?

We’ll always look back fondly at this particular time of our lives — from the initial crazy idea, to watching the team at Campo Santo actually make something of substance, on time, and for a ridiculous budget (well, as far as games go). I enjoyed updating the folks at Panic every week with what was going on, and watching our team pitch in in every way that they could, be it QA or marketing or what have you. It really felt like a team effort.

Thanks, Campo Santo, for taking us with you on this ride.

The team at GDC winning an award

FirewatchFirewatch Photos

We also launched and ran our fictitious photo printing company, Fotodome, to deliver people’s Firewatch memories on paper. All told, we — well, June, to be specific — shipped 1,500+ beautiful sets of video game photo prints around the world. And we’re now hosting over 45,000 separate “rolls” of photos on our servers — that’s over 534,000 photos taken in the Shoshone National Forest.

Fotodome was the goofy kind of thing Panic likes to do for fun, not for profit. It made Firewatch feel a little bit more special for the people who connected with it, and it still feels awesome every time a new order comes in — and there’s usually one or two every day even now!

Coda iOSCoda with Touch Bar

At the very tail end of 2016, Apple added the Touch Bar to the MacBook Pro, and we were fortunate enough to get in on the ground floor — we immediately thought it might be an interesting thing to support in Coda, an app where it’s really in your best interest to keep your hands on the keyboard as much as possible. Coda 2.6 with Touch Bar landed just a few weeks after MacBook Pro. It felt good to semi-quickly add a major new hardware feature to our app.

Updates

Other than working on new things, our team is constantly updating our apps. And I do mean constantly. Here’s a chart of all the bits we got out the door in 2016:

2.5.14 2.1.3 2.5 2.0.9 4.4.12 1.3.2
2.5.15 2.2 2.5.1 2.0.10 1.3.3
2.5.16 2.2.1 2.5.2 2.0.11 1.3.4
2.5.17 2.2.2 2.5.3 2.0.12 1.3.5
2.5.18 2.2.3 2.5.4 2.0.13
2.5.19 2.5.5 ☠️😩
2.6 2.5.6
2.5.7
2.5.8
2.5.9

We shipped 34 software releases over the course of 52 weeks in 2016, and three of them were significant new-feature updates. Each one of them was fully tested and qualified by our expanded and improved QA team. This might be a new record for us!

It’s our goal to make sure that our software works well, constantly — that the app you paid for continues to deliver, every day.

Successes

A few things that are notable from 2016:

  • Our software quality is the best it’s ever been. In 2016, we moved Aaron over to join Ashur in QA, meaning we now have two, yes two!, people invested in full-time testing and release qualification of our apps. It has been a huge change from the early years of making a few educated spot-checks before pressing “deploy” and hoping for the best. I have great confidence that the software leaving our door is stable and polished. (As a case in point, the Transmit 5 beta may be our shortest ever, because we fixed so many bugs during development.)
  • We’ve upped our group skills. This is going to sound painfully obvious so please don’t laugh, but between conducting more regular status meetings and lengthy-but-helpful bug triage meetings, we’re doing a better job all working together to define our immediate goals clearly and make them happen.
  • Supporting an external project, like Firewatch, felt very worthwhile. We’d like to do more of it in the future. Does that mean we might want to support more games? If a good fit came our way, quite possibly.
  • We took the hiring process seriously. Driven mostly by Ashur and Heather, we approached hiring with new, more refined, structured process. We created a new recruitment page, and tried a lot of new things: blind resumes (James manually redacted all personally identifying information on each and every resume we got), outreach to underrepresented groups (not just me posting on Twitter), a fixed application window, focused deadlines for responses to keep applicants informed at all times, and more. It was a huge change for us, and it took a lot of work, but the results were worth it. Speaking of…
  • Our team is extremely good. I’m serious. 2016 welcomed both Jesus and Helen into our Support group, and I’m so glad they’re here. But truly every single person here at Panic continues to impress me every day with their skill, initiative, and unstoppable urge to make the best and coolest things possible. There’s a lot I can’t talk about yet, but it’s amazing to watch everyone find what they love and do their best at it. This is a world-class team, full stop.

Challenges

But not everything was super smooth:

  • iOS continues to haunt us. If you remember, 2016 was the year we killed Status Board, our very nice data visualization app. Now, a lot of it was our fault. But it was another blow to our heavy investment in pro-level iOS apps a couple years ago, a decision we’re still feeling the ramifications of today as we revert back to a deep focus on macOS. Trying to do macOS quality work on iOS cost us a lot of time for sadly not much payoff. We love iOS, we love our iPhones, and we love our iPads. But we remain convinced that it’s not — yet? — possible to make a living selling pro software on those platforms. Which is a real bummer!
  • Game development is tricky. We didn’t bear the brunt of this (thank you for everything always Ben!). But it turns out we’re a little bit spoiled in the Mac / iOS development world, what with our usually consistent tools like Xcode and mostly reliable platforms from Apple. Heck, even the App Store is blissful by comparison. Minor updates to Unity can break your game, hundreds of PC configurations make a smooth experience for all users a literal moving target, console submission processes are extremely complex, etc. This was often tough: we got so close to a Metal-powered Firewatch Mac, but Unity complexities got in the way. We’ll get it next game!
  • Defining roles is important. What happens when you’re truly a “flat” organization and you have a bunch of incredibly smart people that can all offer valuable input on almost every task happening at any one time? Things can actually slow down a little at times. You want the right people on the right tasks, and you want someone who can make tough decisions and process the possibilities. It’s possible we’ve outgrown complete flatness. We’ll be experimenting with this more into the future, although it’s so tricky — you don’t want people feeling excluded, and you don’t want to extinguish the passion of creating!

What’s Next

This is the part you probably care about. Here’s what we’re busy working on right now:

Transmit 5

Yeah, it’s 100% real. It’s been seven years (yes, really) since we last charged for a Transmit update. Currently in private beta testing, we’re getting tantalizingly close to the launch of Transmit 5! We don’t want to give it all away yet, but we think it’s a super solid update to this venerable and trustworthy file transfer app for macOS.

Coda

If you’re wondering what the long-term plans are for Coda, I can’t blame you! It’s been a while since Coda had a massive new release, as nice as adding that Touch Bar support was. So, what’s up with that?

The good news: we’ve been brainstorming a great deal about what it would mean to reboot Coda — tear it down to the studs, equip it for modern web development in 2017, and figure out what we can bring to that table that’s distinct and helpful. Can we make Coda leaner, faster, with more modern workflows for developing, building, and deploying web work, without completely alienating existing users who love the way it already works for them today? Can we do constant iteration instead of giant monolithic releases, and can we cook up a revenue model to support that? Can we carve out a unique identity in a universe of good (and often free!) competitors? These are the big questions. But we have a general plan, and the work is well underway.

The tougher news: this won’t happen overnight. This is a long road. This will take a while. You get the idea. I will post updates on Twitter or here on the blog when I have more to report.

To everyone who uses Coda, thank you so much for your support and your patience — this work is overdue, but we think it’ll set us up nicely for a future where Coda won’t get “stuck” for long periods of time again. (Also, feel free to e-mail us any time, and tell us where you’d like to see Coda go. We love your constructive feedback and always take the time to read and consider it.)

Misc.

It wouldn’t be Panic if we didn’t also have some crazy things in the works that may or may not see the light of day. Hopefully in 2017, our 20th year, we’ll be able to crank out something new.

Thanks

Sometimes it feels wildly improbable that we’re still here, but we’re still here.

Our good fortune is boundless. We’re fortunate to have been able to do this amazing job for 20 years straight. We’re fortunate to have found this solid group of people to work with. We’re fortunate to have the independence, opportunities, and means to try different things. We’re fortunate to have you as a customer and/or fan.

It’s been a beautiful 20 years. Let’s see where our fortune takes us next!

Posted at 3:45 pm 70 Comments
December 7th, 2016
touchbar

We’re happy to announce the release of Coda to 2.6, which fixes a few bugs…

…and adds support for the swanky Touch Bar in the new MacBook Pro!

Coda’s Touch Bar support focused on the Editor/Preview, Files, and Sites views. Here are a few things you can do super easily on the Touch Bar, without having to take your fingers off the keyboard or move a pointer:

  • Instantly switch between Editor and Preview
  • Indent/outdent/comment lines
  • Jump to a line
  • Insert hex colors using a color picker (on the bar!)
  • Create sites
  • Switch between file browser views
  • Create new files and folders
  • Open the Web Inspector
  • More!

We hope that you enjoy this nice new thing.

You can download Coda 2.6 here. (If you already have it, just auto-update.)

And if you haven’t bought it yet, buy it right here — try using Apple Pay!

Once you’ve given it a try, please let us know what features you’d like us to add to the Touch Bar in Coda!

Posted at 4:56 pm 49 Comments
November 28th, 2016
dropping-chart

Short story: we’re discontinuing development of Status Board.

Status Board was something we’d always wanted. Originally a very nice web page designed to brighten up our office and act as our virtual water-cooler for company stats — as seen in this famous blog post — it evolved into a feature-packed, beautiful iOS app. We made it very easy to make beautiful boards, it worked great with video-out on a large screen (even despite the AV Adapter surprise), it offered lots of cool customizable modules, and it had a first-launch experience I still think is delightful to this day.

Unfortunately, while Status Board became a beloved friend to offices around the world, sales weren’t enough to sustain further development.

Why?

I think Status Board’s lack of success can be boiled down to a few things.

First, we had hoped to find a sweet spot between consumer and pro users, but the market for Status Board turned out to be almost entirely pro, which limits potential sales on iOS — as we’ve learned the hard way over the past couple of years, there’s not a lot of overlap right now between “pro” and “iOS”. Second, pro users are more likely to want a larger number of integrations with new services and data sources, something that’s hard to provide with limited revenue, which left the app “close but not quite” for many users. Finally, in the pro/corporate universe, we were simply on the wrong end of the overall “want a status board” budget: companies would buy a $3,000 display for our $10 app. Hmm, maybe we should’ve gone into production on LCD displays instead…

What Next?

Soon, we will remove Status Board from sale.

But! The good news for everyone that already has Status Board installed is that it will continue to work fine on your devices in the foreseeable future. There are a few things on the horizon to be aware of: due to API changes our Dropbox support will stop working in June of 2017, and we’ll continue to pay for our weather service as long as we can but sometime in late 2017 it will likely stop working also.

We’ve also just posted a final update, 2.0.13, that adds full iOS 10 support and fixes some bugs. If you use Status Board, make sure to grab that final update before the app is removed from sale in a couple of weeks! Update now!

And any customers who purchased Status Board in the last 30 days or so should contact us — Apple doesn’t provide us with the ability to process refunds directly, but we’ll do everything we can to help.

Thank You

For everyone who helped support Status Board during its tenure, it was a pleasure to work on this app, and we deeply appreciate your support, as always.

Posted at 3:26 pm 87 Comments
May 10th, 2016

The Panic Sign

By Cabel

sign-header2
Image courtesy app: the human story.

After many many years of writing apps and doing things, Panic finally feels like a real company. Why now? Well, we put our name on a building. That’s right, we’re hittin’ the small big leagues, baby! But this isn’t just for show or ego — it’s a little bit cooler than that. Read on.

The Idea

As a kid growing up in Portland, I was always fascinated by a strange, bright, sometimes-flashing colored light on the top of the Standard Plaza building. You could see it crossing the bridge on the way to school — sometimes it’d be red, sometimes green, sometimes white. Weird.

Unknown-3

One day my dad told me the secret: it was a weather beacon. If the temperature was going to rise more than 5 degrees, it was red. Drop more than five degrees, white. Stay within five degrees, green. And if it’s flashing? Rain.

(Needless to say, the beacon almost exclusively flashes green.)

Something about this blew my mind and stuck with me forever. This little tidbit of knowledge felt like a secret between me and the building. This seemingly-decorative light did more than just just decorate, and I was pretty certain nobody else in my school (or later, my whole city) knew.

With the Panic Sign, I wanted to do something similar — not just feel cool about seeing our name on a thing but also build in a little magic for the city, something special for the observant, curious, and knowledgable. And I thought we could take it one step further: we’d put the magic in your hand.

The Build

We hired Security Signs to fabricate and install the sign, for two reasons. First, they’ve been around since 1925 and have created some of my favorite signs in the city, from the ’50s swoops of Burlingame Fred Meyer to the unforgettable rotating loaf on top of Franz Bakery. And second, they were OK with our probably-unusual request: “can you build a sign but let us provide all of the internals, power supplies, and controllers?” (Their only stipulation: everything had to be UL approved!)

They got to work:

IMG_0178

IMG_0468

We put a test segment together with our controller and… it lit up ok!

IMG_0467

The Install

Sadly, I can provide no pictures of me dangling precariously from a cherry picker, because this is one of those phases where you leave it to the professionals. It was amazing to watch — these folks know how to install a sign.

IMG_0738

IMG_0745

IMG_0756

The Test

After a good day’s worth of installation, with everything in place, we hooked up a lot of stuff…

Nervously flipped the switch, and…

sign-changing2

…success! Our Panic Sign lit up — and it could change colors!

Now, we just had to take it one step further…

The Magic

The idea was simple: wouldn’t it be cool if, at the touch of a button, you could change our sign?

Well, you can.

IMG_0739
IMG_0740

With a simple, clean web app, we’ve enabled anyone in the city to change the colors of our sign.

There’s something surprisingly special about standing on a street corner, tapping on your phone, and watching some colors you chose appear on a big brick building. I mean, don’t get me wrong, it’s not going to change the world, but it’ll change our colors.

(And just like my Standard Plaza weather beacon, I wonder — does it feel like magic because maybe nobody else around you knows how you did it?)

The Tech

Here’s the fun part (at least for nerdy dummies like me).

The first thing we had to do was take the Panic Palette — a set of colors we developed for website/apps/whatever — and try to convent them into similar colors for the RGB LEDs. This was basically just me sitting at my desk tweaking RGB values and eyeballing it on some lights. Once we had the colors set, it was time to build the controller rig.

Here are the pieces of the puzzle:

IMG_1923-compressed

RGB LEDs: places in the sign itself, we used JE-006M-04 from JS LED Corporation. (They’ve since been replaced by the JE-006M-06.) These modules were UL approved and super affordable — a real solid part.

DMX Controllers. Something’s gotta make them lights change. Two HM-12RGB8A3-DMX512 controllers also from JS LED, one for each half of the sign. Each controller sits on a different DMX channel and waits for color changing instructions, then they drive the lights directly via separate RGB wires for each light strip. (The power supply powers the controller which in turn powers the lights. Also it’s so weird to me that DMX uses MIDI XLR cables.)

• Power Supplies. After running some cool math, we finally arrived at a 60 watt driver also from JS LED. Our first math was bad and we bought two 40 watt drivers — when we set the sign to “white” (full RGB active), everything overloaded and shut down. Oops. Turns out each “bag” of RGB lights = 42 watts at full RGB.

(I should note here there may be better/cheaper/other parts from other companies, but we just kind of rolled with JS LED since they were responsive and helpful!)

• Ethernet to DMX Bridge. To control the sign from a server, we needed to be able to send DMX commands. The Enttec OpenDMX Ethernet did the trick. You have to give it a static IP — no DHCP allowed — but it sits on your network listening for any “Art-Net” protocol packets to be sent over UDP. It converts them into DMX and sends them to the controllers.

• Airport Express. Because this whole rig is mounted in the ceiling with no ethernet jack nearby, we thought we’d use an Airport Express as a dumb ethernet bridge. But after months of insane debugging of sign sluggishness and eventual unresponsiveness, we eventually ran an ethernet line there and all of our problems immediately vanished and the signs responsiveness became instantaneous. Take heed! Use ethernet!

• Test LightsWe added a few tiny strips of test lights above the controller boxes, because debugging the sign previously involved phoning someone standing out on the street. Now we can, at a glance, make sure the lights are doing what we want. Plus it looks cool.

IMG_1931-compressed

On the server end, I’ll let Steve explain:

Well, it's pretty simple! When the user taps the submit button on the web page, it sends an HTTP request to the "sign server", which is a tiny Node.js app running on its own port. The two sets of RGB color values chosen by the user are embedded in the request's URL.

The server breaks out those RGB values, does some sanity checking of them (each value must be an integer in the range 0-255), and performs some rate-limiting and other things to deter general abuse.

If the request looks good, the server uses the artnet Node module to craft a special UDP packet that gets sent to the Ethernet-to-DMX bridge to actually change the color on the LED modules. (In fact, it will send several of these packets to quickly and smoothly crossfade between the previous and new color selections.)

And that's it!

Now go out there and make your own cool sign! At the very least, one-up us by using using pixel-addressable RGB modules (think of the effects!) — that was my original plan but I couldn’t find any that were UL approved! Maybe they exist now…

The Intern

tFz62JoEFor fun, we asked Carmen — one of our two amazing summer interns last year, Hi Carmen! We miss you! — to take our existing API and create a native iOS sign-changing app that we could all throw on our phones. She even went a couple of steps further: she wrote it in Swift, and she also wrote a watch app.

Carmen the student intern here.

I'm now a junior at Scripps College where I am majoring in computer science.  Somehow I was able to convince Cabel to take me as an intern, so I've spent my summer here Portland with the Panic team.

This Panic Sign project is what I spent a majority of my time on.  Using the app, or the watch extension, you can remotely select and change the color of the real life sign outside our building.

Before this project I had virtually no experience in iOS coding—let alone Xcode or swift.  But with heavy help from Heather, I was able to make this nifty project.  Although Xcode's auto layout sometimes made me want to cry, I enjoyed getting to do some front-end design work.  It was incredible to work with Panic not only because everyone here is ridiculously resourceful and smart, but also because everyone is outrageously nice and helpful.

Hope you enjoy changing the sign's colors as much as I enjoyed my summer with Panic.

Both her native app and the watch app turned out great:

iPhone app

watch

(Of course, we thought about submitting this “Panic Sign” app to the App Store but became worried Apple would reject it for not being “very useful”. While that would be a pretty valuable real-world intern lesson, instead we’ll try to find some other sneaky place to put this code!)

Now, It’s Yours

If you’re in Portland — maybe you’ve lived here forever, you just moved here from San Francisco, you’re visiting for a few weeks just for fun hopefully in the summertime, or something else — please come down to the corner of 11th and Burnside at night, that’s right by Powell’s books, stand across the street on the corner, and change our sign.

Impress your friends. Blow your child’s mind. Make a weird? cool? impression on a first date.

Just visit sign.panic.com, and enjoy.

Our sign is in your hands. Thanks for being a part of Panic.

Posted at 4:59 pm 54 Comments