Some people know Gui Rambo is the creator of the popular WWDC app for macOS, others know him as a writer for the hugely popular 9to5Mac website, but it’s safe to say that he’s best known for his colorful history exploring the innards of Apple’s code as he attempts to find unannounced devices and features.
And he’s successful: he leaked marketing images for Apple Watch Series 4, he found iPhone X glyphs showing the notch, and more.
Wanting to know more about Gui’s not-so-secret life as a spelunker, I got in touch with some questions…
Hacking with Swift: A lot of folks associate you with "spelunking" – digging around Apple's code – but you haven't really been doing it that long. What made you start?
“I’ve always been a tinkerer, the type of person who likes to know how things work under the hood.”
Gui Rambo: That's not entirely true. While I may have been doing things that are more notable recently, I've been doing reverse engineering for a long time, almost as long as I've been using computers. I've always been a tinkerer, the type of person who likes to know how things work under the hood. I think it has something to do with the fact that my father used to have a repair shop where he would fix TVs, VHS players, game consoles and all sorts of electronics (these days he's a voiceover professional), so I grew up surrounded by circuit boards.
I don't remember when exactly it was that I opened up a disassembler for the first time, but I must've been like 13 years old at the time. I clearly remember hacking some sort of car racing game demo that came in one of those CD-ROMs so I could play with any of the cars available (the demo only allowed you to use one of them), at the time it involved looking through hidden config files inside the game and changing some properties. I remember being very happy when I finally figured out the combination of properties I had to change to get the result I wanted.
Many years later, already a Mac user, I was working on a subtitle editor for Mac OS X (a project I later abandoned, as I often do) and I wanted to replicate the “pro app” look that Apple had just shipped with Final Cut Pro X. I disassembled the app and tried to find out how it worked so I could replicate some of its design features in my app. FCPX was being criticized by most of its veteran users for being too limited, one of the main limitations at the time was that it was not possible to import or export Final Cut Pro XML.
During my research into how the app worked, I ended up finding some methods which did just that, they just weren't exposed in the UI. I took some screenshots and wrote to a Brazilian website that covers Apple, they ran a story about it and a few hours later it was all over the internet. I remember feeling a mix of adrenaline (the happy kind of adrenaline) but also fear: what if Apple found out it was me and wanted to punish me in some way? I remember asking the editor of the website to not say I was the person who found it.
HWS: Of course, you don't just dig around in code: you monitor feeds and more, right?
“It requires a certain level of organization and knowledge to be able to parse the firehose of information that’s the entirety of Apple”
GR: Not just code, right. I do monitor some software update feeds, asset feeds used by the OSes, Apple’s sitemap and many other sources of information. It’s important to highlight that all of them are public information that anyone can view if they want to, but it requires a certain level of organization and knowledge to be able to parse the firehose of information that’s the entirety of Apple and filter it down to only the information that’s relevant to the work I do.
When looking into new OS releases, I look at each OS separately, so that includes iOS, tvOS, watchOS, audioOS, bridgeOS and macOS. The first four are usually very similar, but there’s always some stuff that’s only present in one variant but not the others. I don’t limit myself to studying only the code either: many of my discoveries were buried inside asset catalogs and files in obscure formats that I had to figure out how to parse. Recently, I spent an afternoon reverse engineering the compression format Apple uses for app patches in watchOS OTA updates so I could write an extractor and spelunk the new ECG app.
Given how much software Apple has to put out there to support their hardware and services, I suspect it’ll be extremely hard for them to ever really “double down on security”. I’m sure they’ve been doing some work to prevent leaks from inside the factories, but to not leak a single thing from their software is a very difficult thing to do considering the huge surface area they have to deal with. Even a very small mistake can lead to a huge leak, like they did last September when they put up pictures of their unreleased devices on their public website with easily guessable URLs.
HWS: Reverse engineering compression just to explore ECG sounds intense! I know it's hard to quantify, but roughly how much time do you spend digging around just looking for a loose end to investigate?
“I can spend between 3 and 5 hours staring at arm64 assembly.”
GR: It can take a long time. I’m able to focus completely on a single task for a very long time, if it interests me. When I’m trying to figure something out with reverse engineering, I can spend between 3 and 5 hours staring at arm64 assembly, a hex editor or other information on my computer. I know it’s not very healthy, but that’s the way I work, the Apple Watch stand notifications can be very helpful in those situations.
I try to document things as much as possible, because sometimes I’ll find something and have an idea of what it can be, but not have enough material to actually find out for sure and run a story. In those cases, I write down what I found, where I found it and what I think it is and then follow up later when new betas come out or if I find out something from another source. There are little pieces of information I’ve been holding on to for over a year because they’re interesting, I have an idea of what they can mean, but I haven’t been able to get more details.
One of the documents I have is a long (and growing) list of unreleased device models (internal device models, like J320, D33, etc). That’s a list I come back to frequently because if I find those identifiers on some new beta I can check if I have seen it before and if I have any note as to what it can be. That’s in part how I was able to find out so much information about this year’s iPad Pros before they were announced: by searching for their device identifiers on iOS betas.
HWS: What kind responses do you get from people after you leak some news?
GR: They’re all over the place. I’d say the vast majority are positive, many people saying things like “Oh, I’d really like to have that device” or congratulating me for finding something they think is cool. Then there are the skeptics who say things like “Apple would never do something like this”, I saw lots of those in 2017 when I uncovered the glyph for the iPhone X (some people were extremely offended by the notch).
HWS: Any negative reactions?
“Apple's keynotes are basically a two-hour commercial.”
GR: There are some people who feel like the Apple leaks are like spoilers for a movie or a TV show. While I understand the feeling and respect their opinion, I disagree. Apple's keynotes are basically a two-hour commercial, for me it doesn't matter if I know what's going to be announced or not, I watch the keynotes to see the “why”, to see how they're gonna try to sell the devices to us, not to see the “what”.
Also, sometimes people disagree with my findings. The type of work I do involves reading through other people's code, which is not even their code because it's been disassembled, then trying to figure out what it means. It's kind of like being a detective. This means that most times what I find is open to interpretation, sometimes others interpret the findings differently than me and sometimes I’m simply wrong. While I try my best to get things right most of the time (nobody likes to be wrong), I know I will be wrong sometimes and I have no problem with that. We can't edit tweets yet, but when an information I've published on my website or on 9to5mac is wrong, I update the corresponding post as soon as possible.
HWS: Does Apple ever get in touch? Do you think you're unofficially barred from attending WWDC?
GR: That question comes up a lot. I don't know about WWDC because I haven't applied for the lottery yet, I guess I’ll find out later this year because I do plan on going (with or without a ticket). It's kind of ironic that I have to use the phrase “sorry, I can't talk too much about that” when this question comes up, but I do. What I can say is that they do get in touch, not too often, but they do. I’ve also heard from friends that some people who work there actually like the stuff I do (I have no idea why).
HWS: What advice would you give to someone who is keen to follow in your footsteps?
GR: I believe anyone can learn anything they want, if they really want to. I will say though that doing this type of work requires a certain mindset that maybe not everyone will have, but if someone is interested in learning, that’s already a great start. Being a very curious person definitely helps.
As with any sort of learning, it takes time to become proficient. Like I mentioned before, I’ve been doing this for many years and I still feel like a n00b sometimes. One aspect I need to demystify and that probably worries many people who want to get into reverse engineering is that you don't need to know assembly to be able to do it. I mean, I know how to read a little bit of x86-64 assembly and also a little bit of arm64 assembly, but I could never write a working program for either without spending hours looking at a manual.
“I believe anyone can learn anything they want, if they really want to… being a very curious person definitely helps.”
Tools like Hopper (my favorite disassembler) have other modes you can enable which don’t require much knowledge of assembly, like the pseudo-code mode which generates something that looks kinda like Objective-C, so it's easier to follow the flow of a piece of code.
For Apple's systems specifically, I would recommend lots of reading in the beginning, especially into what each part of the root filesystem is responsible for, where are the apps, where are the frameworks, etc. Unfortunately, I don't remember where I learned those basics, but information about that can easily be found with a simple Google search, I also plan on writing more about them on my blog. In fact, if your readers could message me on Twitter telling me what they're struggling with or what they'd like to learn, that would be great.
HWS: Recently you've spoken at some international events, teaching folks the art of spelunking – do you know if anyone has uncovered anything interesting or useful as a result?
GR: It's been a blast speaking at NSSpain and mentoring at The Swift Alps. After speaking at NSSpain, one of the attendees came to talk to me because they wanted to study a very specific subsystem of iOS and they wanted some guidance as to where to find things related to it. I gave them some information and a couple of weeks later they wrote me telling me about how they had learned all about how that particular subsystem worked and were now going to research other things.
Our friend Patrick, one of the organizers of The Swift Alps, was also an attendee to my reverse engineering workshop. The goal of the workshop was for every team to pick a private API and use it to do something cool. At the end of the workshop, Patrick had made an impressive flight tracking app using a private framework.
HWS: You're also well known as the lead developer of the amazing WWDC app for macOS. What was your inspiration for building that, and what plans do you have for the future?**
GR: It’s an interesting story. The unofficial WWDC app for macOS (its full name!) started because I wanted to learn Swift. I believe this was 2015, I had used Swift for some things, but I thought I needed a real-life project to really get used to the language. I often found myself watching WWDC session videos on my Mac as a reference while doing some coding at the same time, but using Safari for it wasn’t that great (their website is a lot better these days than it was back then).
So I decided to write a WWDC app for the Mac. It’s just a list of videos that you can play, right? How hard can it be? The answer is: quite hard. It’s a complicated app, but fortunately these days I have some amazing people working in the app, so much so that the last major update probably consisted mostly of other people’s code than mine.
“It’s interesting that after all these years Apple still hasn't made an official WWDC app for the Mac.”
For this year, we want to improve the app with new features and also improve the ones we already have, adding things like curated playlists and shared bookmarks so it becomes more “social”.
It’s interesting that after all these years Apple still hasn't made an official WWDC app for the Mac. Judging by the popularity of my app, it’s clear that there’s more than enough demand for it. Maybe this year they’ll release a Marzipan version of their iOS app? I wonder how many users who currently use our app would prefer to use the ported one from iOS, it would be interesting to see what happened. What I can say is that if they do come up with an official app for the Mac, Marzipan or not, I’d love for it to be the best app in the world, because then I could shut down mine and not have tons of work to do every May/June!
HWS: The app is written entirely in Swift – how well are you able to keep up with all the Swift language changes?
GR: I don’t remember having major issues migrating Swift versions for my WWDC app, which is definitely not true for my other app, ChibiStudio, which I developed during the migration from 2 to 3, it was pretty rough. For WWDC, the automatic conversion usually gets most things right these days.
We also face changes in AppKit, both in terms of APIs changing to be more swifty and the introduction of new features such as Dark Mode with Mojave. It’s an interesting case because our app has been dark since version 5, so we had to roll our own Dark Mode. Now that we have official Dark Mode in Mojave, we’re leveraging that when the app is running on the new system, but still using our custom appearance when running in High Sierra
HWS: What's your take on why so few developers build apps for macOS?
GR: I believe it’s a combination of many different factors. First of all, there are way more users on iOS, so in general apps have a better chance of succeeding on iOS than on the Mac. The Mac definitely has a better market for more niche or pro apps which can cost more money, but the vast majority of apps don’t fit those categories. So that’s the economical aspect.
“I will take an iPad app running on my Mac over an Electron app any time.”
Then there’s the technical aspect. Even though I like AppKit quite a bit, it’s undeniable that it’s different from UIKit in a way that makes it complicated for iOS developers to easily come to the Mac. I disagree that it’s super hard (or impossible like I’ve seen some people say), but it is definitely a barrier.
I think with Marzipan (iOS apps running on the Mac) we will see a huge influx of new apps to the platform. Will those be amazing Mac apps, when compared to fully native AppKit apps? Probably not. But I will take an iPad app running on my Mac over an Electron app any time. I believe AppKit will continue to exist for the foreseeable future. Maybe it will be more like ProKit, Apple’s private framework they use for their pro apps, and only be used by the niche and pro apps.
HWS: And finally, what feature of Swift 5.0 or beyond are you most looking forward to?
GR: It may sound silly but I’m really excited about Result coming to the standard library. It’s such a simple thing but I find it beautiful and making it a part of the language makes things easier (and also makes it official).
ABI stability is also going to be huge and It wouldn’t hurt if they made compile times even faster, they improved a lot with the new build system in Xcode, but more performance is never too much.
SPONSOR Meet the new Instabug – more than just bug reporting! We help you build better apps and minimize your debugging time. With each bug report, we automatically capture details like network requests, repro steps, and session details. Get real-time crash reports with stack trace details and session data to help you catch and fix issues easily. And with our customizable in-app surveys, you’ll gather insightful user feedback and much more. Instabug is the fastest and easiest way to release with confidence. Start your free trial now! Start your free trial now!
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and Mario Kart world champion. OK, so that last part isn't true. If you're curious you can learn more here.