1. Some people have mentioned it already but turning human-readable code to machine code is like turning a precise cake recipe into a cake. A decent baker can do it. Any developer can compile existing code. Going from a baked cake to a precise recipe requires a chemistry lab and a team of highly-trained scientists. Same thing for code. You’ll need a highly-experienced and specialized programmer to turn a program into legible code. Its almost always easier to just rebuild from scratch.

However companies do other things as well.

2. Companies sometimes purposefully compress and obfuscate their code to make it hard to unpack. This happens a lot on the web where a website might have code sent to your machine in a format which could have been legible. But before they send it to you, they run the code through a program which adds extra steps, renames things, and reorders things and removes extra spaces… all to make it hard to read.

3. Some companies will encrypt their code or programs to varying degrees. Some will do it at the storage level, such as DRM or modern disk-based videogames. The data in these games is “locked” behind passwords and keys which can only work if the program “calls home” to Steam or Xbox or whatever and those providers let the game be opened. It’s more complicated than this but that’s the basics.

4. A lot of companies have moved their code “into the cloud”. That means, instead of giving you a full piece of software, you only get the front-end, or the pictures and words you see on screen. The actual program lives on the company’s servers which you don’ have access to. You only get to send those servers inputs, and they return outputs back to your screen.

5. Companies can make their code secret from internal developers by breaking programs up into smaller pieces. Say you’re a developer at Apple. You might be assigned on the specific part of the system which opens apps from the home screen and may only get access to that part of the system so if your development machine gets hacked, the hackers don’t know ALL the inner workings of iOS.

I’m sure there are more ways but this is a start.

The source code isn’t raw on the device in its normal human editable format. It’s compiled from easy to read code into binary machine code, it generally can’t be easily decompiled.

While everything else everyone said is true, to some extent there has been code leaked or decompiled of internal iOS libraries. That code is sometimes used in things like jailbreaking iPhones or making jailbroken-only apps.

If by “adversary” you mean a hacker, secure software should remain secure even if your adversary has your full source code.

Turning code usable by machines into anything remotely readable is really hard. Hard enough that the people doing it are either doing it as a hobby, meaning the output quality isn’t a concern, or there has to be massive amounts of potential profit. For something like iOS the second isn’t ever going to be the case because competitors outright can’t really use the source code if they did get it, that’s protected by copyright or something. On the hobby side however, code decompilation is a thing that happens from time to time.

TLDR: the difficulty is in making the source code readable, not in getting the source code.

For most of the code, I don’t think anything special is used.

Compiling the code already obfuscates it enough. Most function, type and variable names are removed, the compiler does some optimizations and what you end up with is already pretty indecipherable code soup.

There are obfuscators that make the resulting binaries even harder to read/decompile, but further obfuscation also makes your code run slower.

People here talking about decompiling code. Maybe you meant to ask how they’re certain it’s not stolen from home base?

All our goods are hidden behind a VPN or MFA (multi-factor authentication). Unless someone does something stupid, you’re not getting in our BitBucket or AWS account.

A lot of iOS is open source.

But to actually answer your question, most companies of a big enough size will issue the devices their workers use to them, that way they own the machine the source code will be on, rather than the employee. They will also have some sort of enterprise management software on it that gives them remote administrator access to delete everything in case the device is stolen.

As for disk encryption, they use the same disk encryption methods consumers use.

But sometimes source code does leak. Either accidentally or maliciously. Often times, that source code isn’t really useful to anyone else. Like when Facebook’s source code leaked, it wasn’t really that big of a deal, because Facebook is the only company that has the tech stack in place to run it. And it’s not like Google is gonna blatantly steal Facebook’s code.

The biggest risk to leaked code like that is that someone will discover a vulnerability in it and use that to compromise the company’s service.

Often times the employee (or ex employee) who leaked the code can be found and sued or prosecuted. It’s an incredibly stupid thing to leak that kind of code, because it really doesn’t gain you much if anything, and puts you in huge legal jeopardy.

Source: I’ve worked as a software engineer for Facebook, Google, and Microsoft.

Or, sometimes it’s outright stolen:

https://www.theguardian.com/business/2024/mar/31/bank-of-england-investigating-claim-metro-bank-put-customers-data-at-risk

TL;DR: They can‘t. Apps are not encrypted and could be read by anyone that has access to the application files

But it is not as easy as it sounds:

There is a saying „Everything is open source if you can read assembly.“ And this is true (for most cases)

They cant encrypt their code because you phone has to be able to read it, and therefore you could.

But the applications are compiled, meaning a application called the compiler turns the readable code in form of text to binary, which can be read and executed by a computer. Reading binary is (almost) impossible for a human, but there are applications called decompilers which turn binary back to code, but most of the time to assembly which is hard (but not impossible) to read. You could post this online, but very few people would be able to understand this. Turning it back into normal code would require way too much effort.

But there are other problems with reading source code (specifically for ios):

1. You have to get acces to the compiled application which will require you to jailbreak you phone. Only then you can access system files.
2. Code for different chip types are compiled differently, and im not sure if there is a decompiler for the type used by ios chips.
3. Since the binary is different, the assembly code is different, which means you habe to learn to read ios-decompiled-assembly specifically.

Autocode generators which take 5 lines and turn them to 5000 and a compiler which throws out a binary of those 5000 lines customized to the particular processor.

They use a lock on the door to where it’s stored.

This mechanism blocks people from discovering their source code.

Also the source is split into subsystems - very few at apple will have access to the full iOS code base at any time