While jailbreaking Apple devices is becoming increasingly difficult with every new iOS release, jailbreak detection seems to be losing none of its popularity. Find out if this really is a necessary safeguard or just an outdated precaution.  

Jailbreak detection in iOS has been a topic of much debate ever since iOS 5. The main reason anyone would want to use a jailbroken device is that iOS is locked, with Apple blocking some software-related features in older OS versions.

Generally speaking, jailbreaking refers to the process of removing Apple’s restrictions imposed on iOS or iPadOS by exploiting kernel or OS security vulnerabilities. With a jailbroken device, the user usually gains root access (admin privileges), which allows them to access parts of the OS that are usually restricted to them or install apps not available on the official App Store.

A couple of years and several iOS’s ago, a jailbroken device would allow the user to take advantage of certain features otherwise unavailable to them, like changing wallpapers, using the camera torch as a flashlight, enabling force touch (long press) or Siri on older devices like the iPhone 4. However, iOS is far more customizable today, and most of these features are available on older devices with a simple software update.

Although the number of jailbroken devices is decreasing year by year, introducing a jailbreak detection mechanism still remains a popular request with clients. Not only that, some consider imposing additional restrictions like limiting app usage upon jailbreak detection.

We found jailbreak detection to be pointless way back in 2019 when we first wrote about it. But what changed over the years? Can the iPhone be jailbroken as easily as before? Is it still important to add jailbreak checks to apps? We’ll answer these questions and provide an overview of the topic from today’s perspective.

If you try searching topics such as “how to jailbreak iPhone,” you’ll mostly be offered sketchy websites filled with even sketchier ads, only to realize that most of them are still stuck in the iOS 15 era when jailbreaking was a thing and almost easy to do.

If you’re persistent in your research, you’ll eventually land on the popular subreddit r/jailbreak, where you can easily spend hours sifting through posts only to get the same advice: “Don’t update your iOS 14 or 15 operating system!”. While there are some tools that claim to jailbreak newer versions like iOS 16, most of them only offer rootless jailbreaks (no root access; only limited access to the device’s file system) or semi-untethered jailbreaks (requiring you to connect your device to a PC and use a jailbreaking tool for each phone reboot).

One post that caught my attention was titled “Why is jb dead?” Most users in the comments agreed that the decline in jailbreaking’s popularity is largely due to Apple incorporating many of the once-desired features directly into iOS. For example, iOS 17 introduced sideloading.

In addition, many of the biggest names in the jailbreaking community have stopped developing new tools and even discontinued their existing ones, as newer OS versions and highly secure A- and M-series chips have made it nearly impossible to find vulnerabilities that could enable jailbreak.

It probably also didn’t hurt that in 2022, Apple introduced its Security Bounty program with whopping rewards of up to $1 million. This likely pushed a number of researchers and developers out of the jailbreaking community and helped Apple patch more security vulnerabilities that could allow jailbreaking.

In summary, compared to the early years of jailbreaking, iOS 15 is hard to jailbreak; the available tools are complex and typically only provide partial access to the system, leaving most of it still secured. Jailbreaking iOS 16 is nearly impossible, and there is currently no reliable method to jailbreak iOS 17. With iOS 18 on the horizon, it is questionable whether jailbreaking will be fully possible or even worth the effort.

A few years ago, we published our first article on the topic, Why Jailbreak Detection in iOS Apps Is Pointless. In it, we described several jailbreak detection methods and how attackers can bypass them by exploiting Objective-C’s dynamic nature, which relies on a messaging mechanism at runtime. Because Objective-C-based apps cannot be easily obfuscated, they are relatively easy to reverse engineer. As explained in the blog post, this makes it possible to inject malicious code during runtime.

A few years later, the most widely used programming language on iOS is Swift. The situation has changed because Swift works differently from Objective-C. By nature, Swift is a static language that doesn’t rely on messaging and can be obfuscated. This means that the method for bypassing jailbreak detection mechanisms described in our previous article is no longer applicable with Swift. However, the main conclusion from that post remains just as relevant:

Now that we understand how broadly available jailbreaking is (or isn’t), the question is: what should we do with our apps, and how are we handling this issue with the apps we are developing?

The first line of defense against jailbreaking is ensuring your app and operating system are up to date. Using the latest SDKs provided by Apple significantly enhances app security, and the key factor in this security is the inability to jailbreak the device. By setting the minimum supported iOS version as high as possible—ideally, the current version plus no more than two previous versions—you reduce the chances that the app will be run on a jailbroken device to nearly zero.

This is why we currently recommend our clients set the minimum supported iOS version to iOS 16. With the upcoming release of iOS 18, “current + max 2” will soon mean iOS 16, 17, and 18. 

For example, in one of our ongoing projects, simply by setting the minimum version to iOS 16, we get only 15 out of 4,800 users (0.3%) with jailbroken devices, and those users are well aware of what they’re doing, given how difficult jailbreaking iOS 16 is. Once iOS 18 is released, and if we raise the minimum supported version to iOS 17, the likelihood of any users having jailbroken devices will be virtually nonexistent.

Generally, when we’re dealing with this issue on our projects, besides employing some common jailbreak detection methods, we also try to determine if any debugger or proxy is connected to the device. In such cases, we stop the app’s execution, as this indicates a high-risk scenario where the attacker may have greater control over both the OS and the app. 

Besides, if we keep in mind that jailbreak detection methods are still the same as in the early days (check if the file can be written to a protected directory, whether there’s a forbidden app installed on the device, etc.) and that these checks are not always effective, taking further measures is possible but unnecessary, as they won’t meaningfully increase the app’s security.

To conclude, adding that extra layer of security to an app is okay, but we shouldn’t restrict app usage based solely on detecting a jailbroken device. Not only does this degrade the user experience without offering meaningful security benefits, but it also prevents more advanced users from using their devices as they see fit, which suggests a “lazy” approach to security.

Finally, we must remember that, with enough resources and determination, any protection can be broken, and we should not rely only on jailbreak detection or app integrity checks. Securing an app is a far more complex process that includes security measurements on both the backend and the frontend.

And, as always, if you need any help raising your security posture, you can check out our cybersecurity services.

Rushing to meet deadlines or other outside circumstances can sometimes result in less-than-perfect code quality. Met with a major app redesign, we strategically rewrote and refactored our code, transforming our ugly duckling into a beautiful swan.

Many digital products available today started out as small, innocent MVP projects. Sometimes, getting that app out into the world is the main concern, and getting it there quickly matters more than its internal structure, architecture, or other constituent parts that become important as the product grows into a large, multi-screen complexity. 

The reality is, the best architecture in the world can’t save you if someone beats you to the punch with your app’s core idea.

Developing a piece of software doesn’t happen in a vacuum, and outside factors often dictate the tempo and feature prioritization, as we’ve had it happen on one of our projects. After years of ongoing work and feature development, we started noticing slowdowns in development as well as other issues. Small fixes started to take longer and longer, and we weren’t happy with our efficiency on the project. 

Then a new, large change request came to us, and we knew we had to do something about our legacy code. It was time for a complete overhaul.

The project, a mobile banking app for a major client, was around five years in the making at the time. During that period, we added numerous features to the product, both large and small. 

Taking into consideration the project’s initial scope and timeline, and the fact that Swift was still in its early stages, we decided to go with good ol’ Objective-C. Our architecture of choice was a simplified version of VIPER, basically VIPER without a Router and an Interactor. Since time was of issue, we also couldn’t build every little thing from scratch and had to compromise by using some third-party libraries. 

As you can see, it was the perfect breeding ground for a future escalation. I should note that we did do some refactoring and maintenance along the road, as much as time and budget allowed us. First, we switched to the latest version of VIPER, added some new screens using Swift, and adopted a reactive approach to using RxSwift. We also removed almost 70% of the third-party libraries we added initially and replaced them with our own logic.

We knew we wanted to go with the atomic design pattern, but were painfully aware that more than half of our original code could not support this. 

It was time to decide if we wanted to “hack” our current codebase in some way, which would likely give future us more issues to handle down the line, or invest a little more time and perform a more serious intervention. 

Things were quite clear – we had a large technical debt to resolve ASAP.

Code refactoring and code rewriting are two buzzwords that are frequently thrown around when discussing how to deal with legacy code. However, they are quite different in their nature.

Refactoring is a process of changing smaller chunks of code over a period of time while leaving the original logic mostly intact. It is usually done on a smaller scale to keep the codebase easily readable, decrease the number of bugs and their likelihood to occur, improve app performance, etc. Refactoring usually doesn’t take as much time and resources and can be done periodically whenever software developers do something in the module or add new features.

Code rewrites are usually done only when you have to change more than two-thirds of the code or replace it entirely. In our case, we had to replace Objective-C code with Swift, two programming languages that couldn’t be more different (apart from the fact that they use the same frameworks provided by Apple). 

Clearly, a complete rewrite takes far more time and resources than a simple refactoring. However, as the old code base full of issues, bugs, and technical debt is removed, we give that module a clean slate.

For us, both time and resources were a challenge. Whichever approach we chose, we knew that we couldn’t stop an active project so that we could prepare the app for its redesign.

So, which approach did we choose? Both!

We added a few additional software engineers to the project and had a development team ready to transform this ugly duckling into the beautiful swan it is today. 

As mentioned before, more than 80% of the code was not ready for a major redesign since it was largely written in Objective-C and related to the screens we had at the time.

Several team members were responsible for rewriting and refactoring the existing code and redesigning the app using the latest principles and technologies we now use as a standard on all our modern projects. 

At the same time, other team members continued working on new features and bug fixes. Both teams used the same approaches and technologies we agreed on – (Rx)Swift, and the latest version of VIPER.

The rewrite (redesign) part was done on a separate branch, while refactoring was done on the main branch. We split the rewrite into two major releases. The first release covered around 70% of the app. The second release followed the first one by a few months and covered the remaining 30% of the app.

As for the new features, the only difference for those two teams was the user interface. While the “rewrite” team used newly created components for the app’s (atomic) redesign, the “maintenance” team worked with the old screens, performing maintenance and adding new features to the “main” branch. As a feature was completed, it was merged on the redesigned branch. That way, the business logic didn’t have to be written more than once, as the “rewrite” team only needed to change the UI.

This approach sometimes led to double UI interface creation (two different Views in the project), but that was the price we were willing to pay to speed up the whole process.

A few months later, we basically had a new project – our beautiful swan. The app became beautiful on the outside, and more importantly, on the inside as well.

Finally, this is what we managed to accomplish:

At the end of the process, we sent the app to a pentest and got a positive grade. The very nature of Swift (and Apple’s code obfuscation) doesn’t allow a memory dump, which would allow someone to read out class and method names, which was an issue with Objective-C. That code dump can often be used for attacking the app with some sort of a code injection, so this is a large motivation for us to keep rewriting the code until everything is written in Swift.

We all try to maintain our projects regularly, but as this example shows, without occasional rewrites or at least refactors, an application can fall back in stability and performance. Fixing bugs becomes slower, adding new features more challenging, and scaling the product nearly impossible. Not to mention the accrual of technical debt. 

If you’re starting to detect code smells and your legacy code is giving you trouble, don’t give up. With a little planning and finding the best approach for your project, it’s not too late to make it shiny and new. 

Maintain your code regularly, and as frequently as possible. You never know when the time will come to turn your ugly duckling into a beautiful swan. 

Pre-made scripts are cool, but writing your own Xcode shell scrips opens up a world of possibilities for making developers’ lives easier. We demonstrate this on one potential use case – checking the SSL pinning certificate.

If you’re an iOS developer, chances are you use some sort of a bash command on our Xcode projects on a daily basis, even if you’re unaware of it. If you are using Cocoapods, just check the Build Phases of your project. You will find the Run Script Phase named Check Pods Manifest.lock. 

If you are using Universal Frameworks in your project, you will also have some sort of a Strip unused architecture script. These pre-made scripts are cool, but Xcode shell scripts can make our lives easier in many different ways. So let’s dive in and see how we can utilize them.

Writing our own Xcode shell scripts opens up many possibilities. We’ll illustrate this on a use case we’ve chosen as our example: checking the SSL pinning certificate validity date.

We often want to make our apps more secure, especially those that involve sensitive user data (i.e., mobile banking applications). One of the most common ways of doing that is by using SSL pinning. As it says in the blog post,

For the sake of this example, let’s say we are using a certificate check rather than a public key. Considering that certificates usually have an expiration time of two years, you’ll have to track the validity date so your app doesn’t suddenly stop working. 

The expiration date is easy to miss. It’s a common scenario that everyone goes crazy a couple of days before the expiration because a new certificate is issued, and the app has to include it. 

In this case, there is little time to create an app update and review the testing required for the certificate update. What’s more, that kind of test could result in a couple of hours of downtime for the users as their app is still not ready for the new certificate. This is bad UX and can bring about negative comments from the community. So, let’s see how a custom script can help us out here.

To check the certificate’s validity, we will use two main components in our script:

In your project, go to the Build Phases and add the New Run Script Phase named Check Certificates Validity.

As iOS 13 has become available on more than 70% of the iOS devices, dark mode has been getting great support from iOS developers every day.

However, sometimes you want to go beyond the monochromatic color scheme and brighten up your app with a lively shade.

Before we delve into implementing dynamic color schemes we recommend you check out our Bullet-Proof Color-Naming System for iOS Development. The system offers a structured approach to color-naming, and also makes it easier to add dark mode support.

Imagine you have to create a new app with the functionality to rent your branded car. Currently, there are only three models available for rent: X, Y, and Z. The app should be able to show basic information about each car, availability, and the possibility to rent it.

That UI could look something like this.

It would be quite easy to modify the UI to support dark mode, but now the designer has sent us a proposal for another cool feature – every car should have its own color.

The implementation should support as many themes as the designer wants, as well as any number of screens and components that might be themable as a result of that design proposal.

There are a few possible approaches to adding color functionality, some better than others.

This approach comes naturally to everyone faced with such a problem. Basically, inside viewWillAppear it’s possible to assign a color, font, image, etc. to the UI elements by checking which theme was last selected. Theme selection can be stored in UserDefaults.

What are the flaws to that approach? Well, the problem occurs the first time when adding a new element, i.e. next time when adding a new view controller. There is no way to keep track of every element that is added to viewWillAppear so that the correct color or font is set.

Also, sometimes it’s not even desirable to connect our UI with our code (e.g. static labels that don’t have to be localized or changed in runtime). When adding a new view controller, also account for the extra time necessary to implement the logic for color change (duplicated code).

However, the biggest problem with this approach is theme reloading, which will introduce multiple bugs. For example, when changing the theme on the currently active screen, it will not be changed without somehow reloading the entire screen, which will either look ugly, or cause a screen flicker.

The second approach can fix some things from the first one.

If you ignore the problem of connecting every UI component to our code and code duplications for a moment, you would be able to reload the entire app, i.e. change the navigation stack so that the user is on the first screen in the app every time the theme is changed.

Even if this fixes the initial problem with the UI reloading, there will now be a new problem — the app state.

This could be fixed by trying to store the last known app state, but as the app becomes bigger and bigger, this will increase the complexity linearly for such a small feature. So, this is a no-go as well.

Getting warmer but not quite there yet.

You could create a subscription to NotificationCenter in every view controller and post a notification that will trigger UI reloading whenever theme change occurs. The problem of reloading and app state is solved in this approach.

We have a winner!

The two key components here are UIAppearance and Protocols . Let’s see how these two small but powerful things can help us implement any color.

UIAppearance

As official documentation says, UIAppearance is a collection of methods that grants access to the appearance proxy for a class. It is a protocol which returns a proxy that forwards any configuration to instances of a particular class.

Once config is received, it is applied when a class is added to the window hierarchy and can be applied to all instances of a class, or classes contained within a certain hierarchy structure.

There is the problem of every UILabel contained in our hierarchy having red text color. To solve this, use whenContainedInInstancesOf :

It’s possible to use appearance proxy on most of the element properties, but what if you wanted to do something like this:

The problem you will encounter is that UIButton does not have a property named cornerRadius that conforms to UIAppearance protocol. Let’s fix that as well!

In order to add that support, create @objc dynamic computed property:

That’s it! With this powerful OS feature, you will be one step closer to a colorful app.

Before continuing to the Protocol part, there is one small thing to consider regarding UIAppearance. As you can see, there isn’t a created extension on UIButton but a custom subclass AppButton instead.

The reason for doing that is so you can use UIButton later as the component with default appearance, as well as easily see which component is themeable in code and be sure that your coloring will not interfere with other system components used by the iOS.

Protocol, enum and manager

The second part of this feature contains a simple enum, two protocols, and one manager to glue everything together.

Enum has two responsibilities – to list all of the available themes and to provide the configuration for the selected theme.

In general, only one protocol is enough in order for this to work, but let’s separate the responsibility in two protocols. Main ThemeProtocol and Themeable as a helper protocol.

ThemeProtocol is used as the main protocol responsible for defining the behaviour of main assets and extension:

This protocol is used later in the last component — manager. But inside of it we can see another Themeable protocol responsible for describing how the item should look.

If there is a theme which conforms to Themeable and you would like to extend functionality only for that one theme, use extension block in order to extend features only for that one theme.

E.g. description of the one item could look something like this:

The last component here is ThemeManager that binds everything together. All the logic needed to apply the selected theme can be written in just a few lines of code:

Let’s go through those four lines of code one by one, in order to make everything clear. In // 1 first line, you are just retrieving items descriptions for the selected theme.

The second line // 2 is responsible for applying that theme using UIAppearance protocol described in the first part. This will only set the new value for our label, but it will not change it yet. Implementation of updateLabel is simple as well:

In the next line // 3 apply some additional changes specific for the theme that implements the extension.

Let’s say the Blue theme is doing something extra that red and green are not doing (here is shown the implementation of only a blue theme, but the same principle is applied on other themes as well):

Last // 4 step is to force UI to apply these values to all components and the easiest way is to just reload everything in a window hierarchy:

When tested, this approach did not have any big impact on CPU/GPU and it worked nicely with auto layout (all constraints were intact).

To change the theme, call one line of code and the entire magic will happen.

The red theme will be applied on all screens in the app, without the need to add any kind of code for theme handling inside any view controllers or connect your UI with the code.

Now, if you set your label as AppLabel, even added from the Storyboard, a new color will always be properly applied.

These were four different ways to implement app customization and make apps dynamically colorful. To make your life easier, avoid using the first two and make apps colorful with the other two methods.

Use the power of Apple’s UIAppearance for setting the new appearance of an element in combination with Protocols for describing that appearance and applying it. This way, you can create customizable items only once.

By using them anywhere in the app, you have support for changing themes without the need to add any additional logic for changing its appearance when the theme is changed.

Now that you’ve got this in black and white, your app can finally show its true colors.