Learn how to boost your app performance using Baseline profiles in Android development. Discover how this technique can significantly improve startup times and eventual performance with no delays after updates. Read our comprehensive guide for Android developers now.

Boost Your App Performance with Baseline Profiles in Android Development | Showmax

At Showmax, we understand that the success of an app heavily depends on its ability to provide a smooth and efficient user experience. While an aesthetically pleasing design is important, it's equally essential to prioritize the app's performance. After all, even the slightest inconvenience such as crashes or frozen frames can drive users away. That's why we were intrigued when we first heard about Baseline Profiles and their bold claim to "make apps blazing fast". Before we dive into how Baseline Profiles can help improve app performance, let's first take a look at the evolution of code execution on Android and the challenges developers face in optimizing their apps for speed.

As we've seen, the evolution of code execution on Android has been a rollercoaster ride, with different optimization techniques being used in different versions of the operating system.

In the first version on Android back in 2008, code execution was entirely interpreted, meaning that no optimization was performed, and the code needed to be translated into bytecode for every instruction which resulted in low app performance. However, this approach didn't require additional disk space, which was a major consideration at the time. 

With the release of Android 2.2 Froyo in 2010, the Just In Time (JIT) compiler was introduced, which optimized the most frequently executed parts of the code to improve app performance. However, the optimizations were lost after the app process was killed, resulting in slower startup times.

The Android 5 Lollipop update in 2014 introduced a full Ahead Of Time (AOT) compiler, which optimized the entire app ahead of time, resulting in faster startup times but longer loading times due to the larger size of the optimized code.

 Once loaded, the app’s performance was fast. However, every time the system or the app was updated, the optimization had to be run again for every single device, which was time-consuming and resource-intensive.

Back to JIT with profile guided optimizations

Android version 7 Nougat from 2016 returned to JIT and added a Profile Guided Optimization (PGO) where the hot paths were stored and then (usually overnight) optimized via a tool called dex2opt. This approach meant that the app would get faster after every use, but only for the parts that were actually used.

The last significant change came in 2018 with the release of Android version 9 Pie which added Cloud profiles. Cloud profiles work by gathering and uploading profiles for a particular app and a device to the Play store, where they are aggregated and distributed during installation to other devices and applied. This approach significantly improves app performance, but it takes days or weeks to gather the profile, and every new version/update means starting from scratch.

At Showmax, we update our Android app every few weeks, meaning that the optimizations are gathered from scratch after every update. While our users may eventually benefit from the optimization profiles distributed through Cloud profiles, as a result, the time it takes for the profiles to become available means that our users may not experience the full benefits of the optimized performance for several days or weeks after each update.

In the next section, we'll explore how Baseline Profiles can help us address these challenges and achieve faster app performance.

Table is inspired by the presentation "Making apps blazing fast with Baseline Profiles" by Rahul Ravikumar and Tomás Mlynaric presented at the Android Dev Summit.

Baseline Profile to the rescue. What does it offer?

Baseline Profiles allow us to generate the profile used for app optimisation beforehand. The generated profile (which is just a list of used methods to be optimized) is then included in the app installer. From there, it is distributed with each install or update via the Play Store to every user. 

The optimizations are then ready immediately.

The benefits of Baseline Profiles are clear: Fast initial and eventual performance, the disk space requirements are still small-ish, and most importantly, it is ready immediately after every install or update. No need to wait for app usage or cloud profiles distribution through the Play store.

Implementation and usage is pretty straightforward and well-documented in the official documentation. 

Adding dependencies for the Macrobenchmark library and setting up the Macrobenchmark module.

Adding a test for generating a Baseline Profile:

@get:Rule val baselineProfileRule = BaselineProfileRule()

@Test
    fun startup() = baselineProfileRule.collectBaselineProfile(
        packageName = "com.example.app",
        profileBlock = {
            startActivityAndWait()
	// Interact with the app if you want
        }
    )


The test run output has a generated file of a Baseline Profile which can then be bundled with the app and together with the added dependency of androidx.profileinstaller it is ready to go!

Ready to go means that it is included in the app build files and should be automatically used for optimizing the app when the app is installed or updated from the Play Store. 

For developers, there is also a way to install an app with the Baseline Profile locally.

Our dataset contains a large number of collected Baseline Profile usage numbers. Below are the values from tests that appear to be the most average and reliable.

The first table shows the median of cold app startup with and without Baseline Profile for our common testing devices. We see a 23% and 33% decrease of app startup time.

Cold app startup in ms, median of 10 iterations

The second table shows data from measuring app performance of scrolling content on our home screen – the main screen where users can browse a large catalog of assets. It consists of a scrolling column with different view types, the most typical one is a row of curated assets (many vertically and horizontally scrollable views). The measured values were frame durations within the 95th percentile. We see an improvement of over 30% on both tested devices.

Home scrolling performance, 95th percentile of frame durations in ms, 10 iterations

So, do the numbers lie or not? The video comparison clearly shows that Baseline Profiles significantly improve app performance. On the right side of the screen, where the Baseline Profile is implemented, the app starts up faster, responds quicker, and the scrolling on the home screen is much smoother.

Incorporating Baseline Profiles into your app is a relatively straightforward process, and the benefits are clear. In our experience at Showmax, we've seen startup time decrease by 20-30%, and the eventual performance improvement by around 35%. The best part is that these optimizations are available immediately after every app install or update, without any delay.

All it takes is to add one test to record a Baseline Profile and the results of that to your project. By implementing this technique, you can ensure that your app provides a seamless user experience, with faster startup times and smoother performance.

In conclusion, code execution on Android has come a long way, and with the introduction of Baseline Profiles, developers have yet another tool to optimize app performance. By incorporating this technique into our app at Showmax, we've seen significant improvements in performance, and we encourage other developers to explore the benefits of Baseline Profiles for their own apps.

Boosting App Performance with Baseline Profiles: A Comprehensive Guide for Android Developers

At Showmax, anything is possible, and we are not talking about the Showmax product only. In the engineering team we believe the sky’s the limit. Together, we build the best product we can. And when you are talented and driven, you can push your ideas all the way to production. Or, you can find a buddy and go an extra mile to level-up in your career, like Alina Sedach did.

Alina, you joined our team back in April 2020 as a QA tester. When did you start this journey and where?
In Minsk, I worked for EPAM Systems that had a great junior program offering a two-month-long internship packed with webinars and practical tasks including detailed feedback. After just two months, I joined an insurance project in Philadelphia where I worked as a tester in a team of four, all communication was in English, and we had daily standups – everything was 100% like real-life development. At that time, I had a mentor who helped me refine my testing process, deal with bugs, write test plans, and improve my communication skills for things like accepting and giving feedback, or dealing with conflicts. Altogether it was a great starting position, a great launch of my career.

When did you realize manual testing was not enough for you?
Later on, I worked for two years at Adastra and I was assigned to a project in China. I was there thirteen times. That was a great life experience, but the project was more about a mix of testing, test management and communication with customers than real full time testing. I realized that I am curious about the technical side of testing and I wanted to learn more about it, gain some more experience mainly with automated testing. Another thing I learnt at that time was that I wanted to focus on mobile app testing and test automation. For that reason, I picked up the opportunity to work at Velvon.

“I am a perfectionist – if I do something, then I do it 100%. I choose well what to focus on, while considering the time I need to spend on it. Time is the most valuable asset we have.”
Alina Sedach

Velvon brought you to Showmax in the end. What was the story behind the transition?
The Showmax Android team leader knew Velvon’s manager and wrote to him offering help for those who would need to find a new job after Velvon was closed. Showmax didn’t have a position in the Android team for me but there was a free spot in the iOS team. So one other colleague and I started at Showmax. I joined the iOS team.

What was the beginning like?
We were two testers in the iOS team at the beginning and cooperated closely. We had daily status meetings to align on what we will test and how. We wrote test plans, test cases, planned regression tests, and we regularly swapped roles in managing the test plans’ creation before releases.

I heard that you were there when the automation revolution took place at Showmax. What was the situation and what enabled the decision?
I think I partially enabled it. Laughter. They promised me at the job interview that I will do automated tests at Showmax. Nobody had done it yet but they would make it happen. So at almost every 1:1 meeting with the team leader, I asked about when it would be possible. In the end the team did the math and we realized that it’s impossible to execute 150 tests on 8 devices before every release. Suddenly, the urge to start with automated tests was there. One of the developers experienced with automated tests wrote the architecture and the few first tests and he handed it over to us.

Was it that simple? Have you learnt how to continue?
Tomáš, the colleague who wrote the tests, of course prepared a few presentations or courses for me and my co-tester. But it was tough, obviously. It almost took me one whole day to write the first test and I am not exaggerating! I was determined to learn and improve. Our first tests were written in Ruby, so I took courses in Ruby on Udemy. And I wanted to continue.

Did you get a chance to improve and learn more?
In fact, I got the chance very quickly. The automated tests used specific IDs to refer to a particular element and the IDs were added to the code by developers. More IDs meant easier work for testers but more work for developers. So I offered to help with that. “I could learn how to do it and do it for you,” I said. And they took my offer seriously and told me: “Why not but you need to learn Swift.” It was my turn again and I of course said: “Yes absolutely, teach me!” Laughter.

Who was the teacher?
None other than the iOS team leader himself! He prepared courses for me and the other tester and we started to learn the very basics together with the necessary context. We learnt about data types, collections, and the rules of working with memory. He told us how the functions are written through letting us write the functions on our own. Michal, the team leader, is a great teacher indeed!

And here we are, you are learning automated tests, then Swift as well. When did the team see your full potential and decide to make you a junior developer?
I would say a year ago. It was a year after I had joined the Showmax team. I developed pretty fast. The team set conditions on which I would be ready for the role, they had it defined precisely, and I moved slowly forward. They were giving me junior tasks so that I could practice. And I learnt from Udemy courses in Swift, and read books. Frankly speaking, it consumed a lot if not all of my free time because I was still a tester learning all this on top of my regular daily work.

It must be a great satisfaction and even greater relief to finally be a junior developer! What do you plan to do next?
I must say I enjoy the fact that I finally have a bit more time to myself. For me, it’s all about programming and sports, and you need to have time for sports! I play beach volleyball with the Prague Beach Team and a few weeks back we played at the Czech Republic tournament championship among clubs. I still read a book or take an iPad with me when commuting to training, but I am under less time pressure. I really enjoy that! I don’t really have a next step in mind, I still need to learn a lot in programming. The team still gives me harder and harder tasks to guide me and I am discovering how to write elegant code. So the elegant code could be the next milestone for me. Tomáš, the author of the automated tests architecture, is a great buddy to me and I am devoted to continuing learning. I will keep up with sports and programming apps for at least a few next years! Promise :)

From iOS Tester to Junior iOS Developer in 2 Years

Since its launch in 2019, we had been looking forward to using SwiftUI in a production environment. Unfortunately, the situation on iOS is not favorable as, to this day, we still need to support iOS 12. However, we also have a tvOS application and the situation is very different there. The latest tvOS version is supported by all the devices we develop for, so all of our users can update to the newest version. We usually have around 85% of users on the latest version within 4 months of its launch. That means we can afford to raise our deployment target quickly. We also have quite a lot of freedom on tvOS - because it is (unfortunately) amongst the least used Showmax platforms. That allows us to experiment more and use the platform as a sort of a playground.

Therefore, we decided to try out SwiftUI for all the new features. We also tried to rewrite some screens using SwiftUI. And as of now we have around 10 screens written entirely in SwiftUI and used in production.

Unfortunately, using SwiftUI on tvOS has quite a lot of unforeseen caveats and it hasn’t always been easy. To be completely honest, we probably haven’t gained any advantage nor even saved much time by using it. That said, it has definitely been worth the experience. It has been fun to work with it, and it has certainly made our developers happier. Let me share some of our experiences, highlight the things that have surprised us the most, and give you some tips for working with it yourself.

The first thing we noticed was the lack of resources for SwiftUI on Apple TV. That is understandable though, because tvOS is not a major platform and there was always a problem with finding resources. Unfortunately, it also seems that even Apple does not give a lot of attention to it. There are only 2 relevant videos for SwiftUI on tvOS from the last two editions of WWDC. So the main source of information for the development are these videos and documentation.

To quickly summarize the main APIs that SwiftUI offers for tvOS:

CardButtonStyle - special button style for tvOS buttons that applies effects, e.g. motion effect

SwiftUI offers the following for working with the focus engine:

prefersDefaultFocus(_:in:) - modifier that indicates that the view should receive focus by default for a given namespace

focusScope(_:) - modifier that limits your focus preferences to a specific view

resetFocus - action that resets the focus back to its default in the current scope

isFocused - environment variable that returns true if the nearest focusable ancestor of your view is focused

focusable(_:onFocusChange:) - modifier that specifies if the view is focusable and, if so, adds an action to perform when the view comes into focus. Deprecated in tvOS 15 in favor of the new FocusState API

In tvOS 15 Apple introduced a new focus state API that makes working with focus across different platforms easier. Of course, it also made working with the focus engine on tvOS dramatically better:

FocusState - new property wrapper that controls the placement of the app focus. It should be used together with focused(_:equals:) and focus​​ed(_:) modifiers

focused(_:) and focused(_:equals:) - modifiers that bind the view focus state to the given state value

focusSection() - tvOS specific modifier, that tells SwiftUi that this view is capable of accepting focus if it contains any focusable subviews

You can learn more by watching these two WWDC videos: Build SwiftUI apps for tvOS and Direct and reflect focus in SwiftUI.

All the code shown in the following sections is compatible with tvOS 15.

One of the first things we did was that we tried to rewrite some of our screens in SwiftUI. Previously, we were using the advantage of the TVUIKit framework that contains common user interface components for the Apple TV app. We were mainly using TVPosterView - ffor example, for posters on the homepage.

Using this component is very easy with TVUIKit:

var poster: TVPosterView {
    let poster = TVPosterView(image: UIImage(named: "image"))
    poster.title = "Title"

    poster.translatesAutoresizingMaskIntoConstraints = false
    poster.widthAnchor.constraint(equalToConstant: 400).isActive = true
    poster.heightAnchor.constraint(equalToConstant: 300).isActive = true

    return poster
}


Our initial assumption was that it should be fairly easy to rewrite this component in SwiftUI - it is basically a native component after all. We quickly realized that this assumption was not correct.

When it comes to any tvOS specific components that we might use, SwiftUI basically offers only CardButtonStyle - which is the recommended button style for tvOS, because it handles focus and motion effects out of the box.

So we tried to use the component in the following way:

var poster: some View {
    Button(
        action: { },
        label: {
            VStack {
                Image("image")
                    .resizable()
                    .scaledToFill()
                    .frame(width: 400, height: 225)
                    .clipped()

                Text("Title")
                    .padding(.bottom)
            }
        }
    )
    .buttonStyle(.card)
}


As you can see, it doesn’t look exactly the same. And there are a couple of other issues with it as well. It reacts well to the focus changes and it also handles the motion effect well, but it has no parallax effect.

Another option we tried was using completely custom view in the following way:

struct PosterView: View {
    @FocusState var isFocused

    var body: some View {
        Button(
            action: { },
            label: {
                VStack(spacing: 4) {
                    Image("image")
                        .resizable()
                        .scaledToFill()
                        .frame(width: 400, height: 225)
                        .clipped()
                        .shadow(radius: 18, x: 0, y: isFocused ? 50 : 0)

                    Text("Title")
                        .foregroundColor(isFocused ? .white : .black)

                }
            }
        )
        .focused($isFocused)
        .buttonStyle(PressHandlingStyle())
        .scaleEffect(isFocused ? 1.2 : 1)
        .animation(.easeOut(duration: isFocused ? 0.12 : 0.35), value: isFocused)
    }
}

// We use this button style to handle `isPressed` state of the component.
struct PressHandlingStyle: ButtonStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.label
            .scaleEffect(configuration.isPressed ? (1 / 1.15) : 1)
    }
}


This looks much better and pretty similar to standard TVPosterView. It has a couple of problems though. It does not behave completely natively, because it does not handle motion effect and it also has no parallax effect.

Also, when we compare it to TVPosterView, there are a couple of disadvantages. The implementation is of course more difficult, as we need to handle focus changes ourselves, but an obvious advantage is that our own implementation is easily extensible. That is not the case with TVPosterView.

The last solution we tried was wrapping TVPosterView into a UIViewRepresentable view. Sizing can be an issue, but it works quite well when you specify the width and height inside TVPosterView as well. Something like this:

class Poster: TVPosterView {
    init(width: CGFloat, height: CGFloat) {
        super.init(frame: .zero)
        image = UIImage(named: "image")
        title = "Title"
        translatesAutoresizingMaskIntoConstraints = false

        // We need to set the width and height here as well otherwise it does not work correctly.
        widthAnchor.constraint(equalToConstant: width).isActive = true
        heightAnchor.constraint(equalToConstant: height).isActive = true
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

public struct UIKitView<T: UIView>: UIViewRepresentable {
    let viewBuilder: () -> T

    public func makeUIView(context: Context) -> T {
        return viewBuilder()
    }

    public func updateUIView(_ uiView: T, context: Context) {}
}


var poster: some View {
    let width: CGFloat = 400
    let height: CGFloat = 300
    return UIKitView {
        Poster(width: width, height: height))
            .frame(width: width, height: height)
    }
}


Which produces great results. That is, until you try to mix the usage of such a component with some other custom SwiftUI component that handles focus in a similar manner to the previous poster. In that situation, there is an issue because the focus stays on multiple views:

It works fine, though, if you mix it with non-custom components (like a button with card style). Or perhaps there is just some issue in our custom implementation. But if so, we did not find the issue.

So, as you can see, there is basically no ideal solution in SwiftUI for this use case. We could obviously try to go further and add all of the missing things to our custom solution, but it would get super complicated. We would also probably have to implement it using the introspect technique to access the underlying UIKit components (check out the introspect technique e.g. in this library).

What probably disappointed us the most is the lack of the parallax and motion effects. It’s a shame that SwiftUI views don’t have these, because UIKit views have all of this out of the box and it would make SwiftUI on tvOS more native. There are a couple of other features that UIKit offers for free. For example, UILabel has an enablesMarqueeWhenAncestorFocused property that determines whether the label scrolls its text while one of its containing views has focus. That is completely missing in SwiftUI as well.

Another thing that we use extensively in our tvOS app are customized buttons. Customizing buttons was not simple in UIKit as well so let’s have a look at what the situation is in SwiftUI world.

var button: some View {
    Button(
        action: { },
        label: {
            Text("Button")
        }
    )
}


This gives us a standard native tvOS button:

Problems arise when we try to, for example, implement a round button. Naively, we could simply add the clipShape(Circle()) modifier to our button like this:

var button: some View {
    Button(
        action: { },
        label: {
            Image(systemName: "play")
        }
    )
    .clipShape(Circle())
}


This looks good at first glance, but as you can see, it does not work very well with focus:

To fix this, we have to create a custom button once again:

struct RoundButton: View {
    @FocusState var isFocused

    var body: some View {
        Button(
            action: { },
            label: {
                Image(systemName: "play")
                    .font(.headline)
                    .padding(25)
                    .background(isFocused ? Color.white : Color.gray)
                    .clipShape(Circle())
                    .shadow(radius: isFocused ? 20 : 0, x: 0, y: isFocused ? 20 : 0)
            }
        )
        .focused($isFocused)
        .buttonStyle(PressHandlingStyle())
        .scaleEffect(isFocused ? 1.2 : 1)
        .animation(.easeOut(duration: isFocused ? 0.12 : 0.35), value: isFocused)
    }
}

// We use this button style to handle the `isPressed` state of the component.
struct PressHandlingStyle: ButtonStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.label
            .scaleEffect(configuration.isPressed ? (1 / 1.15) : 1)
    }
}


However, you still need to handle the focus changes and the system does not help you much. It is probably still simpler than in UIKit, though, where you also need to handle focus changes yourself if you want to make customized buttons. Ultimately, SwiftUI wins over UIKit in this field.

Another issue we’ve stumbled upon regarding button customization was missing the Accessibility Focused state. We did not find any way to use a custom button style while maintaining its ability to work correctly with the Accessibility Focus API so that the button’s hasFocus property would work in UI tests. We even have an open Stack Overflow question for this topic.

One of our biggest struggles with SwiftUI on the tvOS platform was working with the focus engine. According to Apple, SwiftUI manages focus on your behalf for the most part. That is true. And when you need to create something simple, it really does a great job. But when you need something more complicated, it becomes more difficult.

Since tvOS 15 when Apple introduced the new Focus State API (see above) things got a lot easier. In particular, focusSection() made working with the focus engine a lot easier. However, one of the things we are still missing is an alternative to UIFocusGuide that was introduced in tvOS 9 and made working with the focus engine significantly simpler. On one of our more complex screen, we came up with an alternative to UIFocusGuide to make things easier. Let me show you how.

We decided to use it on our episodes selection screen because we were struggling with being able to switch focus from the episodes grid to the seasons list on the left. It wasn’t working in the situation when the focused episode didn’t have any corresponding season view next to the episode:

In this situation, the user wasn’t able to focus the “Season 1” when swiping left even when we used the focusSection() modifier. Our idea was to add something like UIFocusGuide between those two sections. It would be responsible for switching the focus correctly. Something like this:

We implemented it in SwiftUI through an invisible focusable View that switches the focus according to the previously focused section:

enum EpisodesFocusedSection {
    case seasons
    case episodes
}

struct EpisodesFocusGuide: View {
    @FocusState private var isFocused
    @Binding var focusedSection: EpisodesFocusedSection

    var body: some View {
        Color(.clear)
            .frame(width: 1, height: nil)
            .focused($isFocused)
            .onChange(of: isFocused) { isFocused in
                if isFocused {
                    switch focusedSection {
                    case .seasons:
                        focusedSection = .episodes
                    case .episodes:
                        focusedSection = .seasons
                    }
                }
            }
    }
}


Then, for example, in the EpisodesView, we listen for the changes in focusedSection and set the isFocused state accordingly:

@Binding var focusedSection: EpisodesFocusedSection
@FocusState var isFocused: Bool
...
.onChange(of: focusedSection) { section in
    if section == .episodes {
        isFocused = true
    }
}


As you can see, the good news is that we were able to handle the focus engine even in quite complex situations with the new tvOS 15 API. The API works in a very different way than focus handling in UIKit and it takes some time to get used to.

Working with SwiftUI on tvOS has been fun and it has been an interesting experience. Most of our issues arose because we tried to completely replicate previous behavior. If we had adjusted our UI for SwiftUI components right away, we would have avoided most of the issues. So if you are willing to accommodate your UI for SwiftUI components (and give up some native features like parallax effect) and you do not need to do any complex work with the focus engine, then SwiftUI is clearly the better choice. In such cases, it makes the development significantly easier and faster. On the other hand, if you have a complex UI and you want it to look as native as possible, then UIKit is probably a better choice. It gives you more control over your UI and you can also take advantage of frameworks like TVUIKit. Overall, SwiftUI still feels a bit like a non-native framework, mainly due to the lack of APIs for motion and parallax effect handling. We can just hope that Apple fills the gap in the future and SwiftUI on tvOS will be the number one choice for development.

At first sight, I absolutely loved how simple it was to announce changes to SwiftUI views. You just set a value in @Published variables and the view gets reloaded with the fresh value. But soon I realized that there was something I’d missed: the context. In fact, it is described in Apple docs. But it’s quite easy to overlook all of the consequences when reading. You understand it better in practice. Let’s have a look at a few examples.

Consider a model that implements ObservableObject with several @Published variables. ObservableObject will automatically synthesize the objectWillChange property. Each SwiftUI view that uses your ObservableObject will subscribe to the objectWillChange changes. Now, if your model changes one of the @Published variables, then SwiftUI will redraw all of the views that use your ObservableObject.

#swift#
class SeriesModel: ObservableObject {
    @Published var title: String = "Tali's Wedding"
    @Published var isMyFavourite: Bool = false
    @Published var episodes: [Episode] = [...]
}


This object is shared in several SwiftUI views where each view reads some @Published variable (either directly or indirectly via Binding).

#swift#
struct ContentView: View {
    @StateObject var model = SeriesModel()
    var body: some View {
        VStack(spacing: 16) {
            TitleView(title: model.title)
            MyFavouriteView(model: model)
            EpisodesView(model: model)
        }
    }
}


Here’s a full code example.
Now, if you tap on the heart button, what views will be redrawn?

To see that, use the hint from Peter Steinberger: add .background(Color.debug) into each view’s body. You can also add Self._printChanges().

#swift#
public extension ShapeStyle where Self == Color {
    static var debug: Color {
    #if DEBUG
        return Color(
            red: .random(in: 0...1),
            green: .random(in: 0...1),
            blue: .random(in: 0...1)
        )
    #else
        return Color(.clear)
    #endif
    }
}


Now set this debug color as the background for each of your views.

#swift#
TitleView(model: model).background(.debug)

The problem is that all of the views (even “episodes”) got redrawn, despite the fact that we only update the “Add series to favorites” button.

Your gut feeling would tell you, it is …bad. Too many redraws. Fix it.

But first, let’s explore the pros and cons of the current approach.
➕ Pros
simpler code; having all relevant @Published variables inside a single ObservableObject which is very easy to understand
➖ Cons
too many extra redraws could lead to a lagging UI, extra CPU usage, and battery drain.

To correctly assess whether the extra redraws are a problem or not, ask yourself two additional questions: Do you code for older devices?, and Do you see any issues when profiling the app with Instruments? In our case, the answer to both questions is “no”, so it’s not worth it. Just accept some possible extra redraws and have simpler code.

We would especially recommend verifying view redraws if:

you use onReceive to create (Rx/Combine) a subscription that leads to an API call. This could cause extra API calls due to SwiftUI making some extra calls of onReceive. This is nicely described here

If view redraws hurt the UX or cause other problems, what then?

We have tried several of the options below. They are sorted by their complexity. If you have problems with your current setup, go ahead and try the next, more complex approach.

Accept a few extra redraws and have a simpler codebase. Especially if your view + model are standalone.

I want to stress that it is perfectly ok to do nothing with redraws. You can always optimize quite easily when it is a real issue.

#2 Divide into separate observable objects

Split the big problem into two smaller ones.

That way, SwiftUI will observe two separate objectWillChange properties and won’t redraw unrelated views.

We used this on the Showmax detail screen.
– The detail header had one ObservableObject.
– The episode list had another ObservableObject.

This is suitable for cases when you have a list of items and each of them can change independently.

You decouple the component from the original changes. Now the component only works with a subset of the data it actually needs. And, if necessary, you can report changes back to the parent observable object.

We used this for the rows in the episodes list on the Showmax detail screen.
– Each row was represented by a separate EpisodeModel: ObservableObject.
– The parent EpisodesModel had the property @Published var episodes: [EpisodeModel] so when it was set, all episodes were redrawn.
– But, for example, if one of the episodes started to download and we showed download progress, then only this one row was redrawn. Without a separate ObservableObject, all of the rows would have been be redrawn.

This is difficult to read due to the boilerplate code, but it effectively controls what changes in the view.

The main point is to prevent SwiftUI from being notified by objectWillChange for redrawing.

You can do it by replacing the @Published variable with CurrentValueSubject

You will need to notify SwiftUI manually. In the view, you will create an @State var myState property that will hold the data to show in the view. Then use onReceive(model.mySubject) { myState = $0 } to listen for changes and forward data to view.

We tried this approach for pagination of episodes on Showmax detail screen.

At first, extra view updates look dangerous. It’s definitely paying off to keep an eye on them. If they don’t happen that much, just let them go and prefer simpler, more readable code. You can always optimize when really needed.

Join us and build a streaming platform used by millions. 

We’re excited to witness the recently announced partnership between Showmax, Sky and NBCU coming to life here in Prague. Following the recent announcement of our partnership; that will bring some of the world’s best content and technology to streaming customers across sub-Saharan Africa, Sky are hiring developers to make it happen.

You might know Sky for TV. But we’re more than that. We’re a tech business. We’re broadband and broadcasting, streaming and sports, mobile and magic. And we’re proud to be part of the Comcast NBCUniversal family, creating incredible technology and entertainment that connect millions of people to the moments and experiences that matter most. 

We’ve already rolled out NBCUniversal’s streaming platform Peacock to our European audiences. Now you have the opportunity to work on an exciting new venture powered by Peacock’s leading, globally scaled technology. 

You will be part of a dynamic team developing client applications and making sure our technology delivers the best experience for our customers.

Craft high-quality software utilizing agile methodologies

Design clean, efficient, and reliable code

Deliver highly scalable and extremely reliable products (our customers demand 99.999% availability)

Collaborate with fellow developers, exchanging knowledge and insights - prepare to learn a lot!

Passionately introduce top-notch technology and software development practices into the team

Participate in the entire development cycle, from analysis and implementation to testing and operation

Embrace operational excellence and support as integral aspects of the development team's responsibilities

Proficiency in native iOS languages, specifically Swift

Familiarity with Design Patterns and Object-Oriented Design principles

Comprehensive knowledge of key iOS architectural components, including Model-View-Controller (MVC), Model-View-ViewModel (MVVM), and Coordinator patterns

Practical knowledge of network protocols, along with an understanding of latency and reliability challenges

Demonstrated experience with multithreading, request queuing, and caching in code

Familiarity with Continuous Integration/Deployment tools and processes

Excellent teamwork, self-motivation, and eagerness to learn

Creative thinking, strong analytical skills, and attention to detail

 Working in an international environment on an impactful globally scaled technology in cross-functional team with an agile approach 

Open and healthy working culture where we care about people as much as about stability of the code  

Work equipment as per your specifications 

Hybrid work, combining working from our office to be closer to the team and working from home 

Work life balance thanks to flexible working hours

Generous free day scheme providing 25 days of holidays + 5 days of on-demand leave (sick days)

Ergonomic office and kitchen full of tasty snacks 

Contribution to Multisport Card or Benefit Card 

Learning opportunities with access to Udemy, O’Reilly, and our internal library of physical books, as well as a budget for attending conferences, including strong support if you want to present at a conference yourself 

Events, meetups, hackathons in the office or elsewhere

 We’re excited to witness the recently announced partnership between Showmax, Sky and NBCU coming to life here in Prague. Following the recent announcement of our partnership; that will bring some of the world’s best content and technology to streaming customers across sub-Saharan Africa, Sky are hiring developers to make it happen.

We’ve already rolled out NBCUniversal’s streaming platform Peacock to our European audiences. Now you have the opportunity to work on an exciting new venture powered by Peacock’s leading, globally scaled technology.  

Our team develops and supports market-leading video streaming services, underpinned by state-of-the-art engineering principles. We do this at huge scale: for millions of customers globally. No matter the device, the time or the place, we make sure that our diverse audiences can easily find and enjoy whatever they want to watch, choosing from the world’s best entertainment, news and sport.

You will join the Online Video Platform team (OVP) within Global Video Engineering & Apps where you will be positioned within business-critical propositions that support all our global streaming initiatives such as NOW, Sky Go, Peacock and SkyShowtime. 

You will be responsible for automating and streamlining tooling for cloud-based services using a range of scripting languages, automation tools, and cloud-native services. You will work with a variety of development / DevOps teams and business partners to ensure that cloud automation activities are secure, reliable, and efficient. We are on the lookout for motivated and outstanding individuals who want to be involved in ground breaking technology that truly pushes the boundaries and growth of streaming! 

Exploring and implementing new ways to automate systems, across a domain that powers business-critical streaming propositions globally.

Design and implement automation strategies, solutions and policies across a range of web API, network and cloud-based technologies.

Automate aspects of deployment and management of cloud-native applications.

Track and fix automation issues and develop solutions

Develop and maintain scripts to automate tasks and processes.

Collaborating with other scrum teams to help support their technical roadmaps by offloading deployment activities into our team workflow and achieving cross-team and department goals through automation.

Provide technical support and training to other team members.

Create and maintain detailed technical documentation.

What skills do you need to play your role well?  

Experience working with REST APIs and multi-distributed systems e.g. Cassandra

Familiarity with configuration and build tools including Jenkins, Gradle, Maven

An understanding of message driven systems e.g. Kafka, Amazon Kinesis, ActiveMQ

Applied knowledge of agile methodologies and software engineering concepts e.g. XP, Scrum, Pair Programming, TDD, BDD

Ability to communicate well with other teams and consult with developers of all levels of experience

 

Working in an international environment on an impactful globally scaled technology in cross-functional team with an agile approach 

We’re one of Europe’s leading entertainment and communication business. We’re always looking to improve by developing pioneering products and services which give every one of our customers experiences they’ll love. 

Join us as an QA Automation Tester and you'll be part of a dynamic team that makes sure our technology delivers the best experience for our customers.

Help to define and manage our testing processes

Participate in the team's agile planning & delivery process

Responsible for ensuring features meet specified requirements

Definition of test plans, test scripts, test data requirements, etc.

Planning test environments and automation strategies.

Preparation of automation frameworks and test runs for API back ends

Preparation of automation frameworks and test runs for frontend clients

What skills do you need to play your role well? 

Strong at programming in at least one of the following languages: Ruby, Python, Java, C# or JavaScript

Experience with CI process and tools (Jenkins, etc.)

Knowledge of networking and HTTP Protocol

Ability to track down the root cause of a defect using debugging tools

About the team

How we work

Join the team

iOS Developer

QA Automation Tester

Android Developer

Frontend Developer

Read our blog posts #apps

Boosting App Performance with Baseline Profiles: A Comprehensive Guide for Android Developers

From iOS Tester to Junior iOS Developer in 2 Years

Our experience with SwiftUI on tvOS

Unexpected redrawing in SwiftUI

Boosting App Performance with Baseline Profiles: A Comprehensive Guide for Android Developers

From iOS Tester to Junior iOS Developer in 2 Years

Our experience with SwiftUI on tvOS

Unexpected redrawing in SwiftUI

Check out our other teams