WWDC 2018 Focus Article: Performance

WWDC 2018 Focus Article: Performance

WWDC 2018 wrapped up the second week of June, and here in Berlin, we partnered with CocoaHeads (Berlin’s most famous iOS developer meetup) to host a public viewing of the keynote event for iOS developers. This year was surprisingly almost rumor-free, keeping us on our toes and thrilled to learn what would come up this year.

Between the excitement over Siri shortcuts and the heated discussions about UIKit/AppKit, at GYG we really enjoyed the effort put into performance. We always think about how to improve the user experience in our app and Apple has neglected this topic for a while.

Let’s go over the different ways performance was improved:

UI Performance

It was long overdue for Apple to tackle UI performance, which has been slowly decreasing version after version, and it finally happened in iOS 12. They improved in the following ways:

  • They fixed a bug in the prefetching API for table views which was actually causing slow performance in situations when prefetching was happening at the same time as loading another cell on the screen.
  • They improved CPU response times to heavy urgent load requests from apps.  Before iOS 12, by the time the CPU would react, it was often too late and the frame rate had already dropped.
  • They improved automatic backing stores for images which don’t need a super high resolution (grayscale images vs. full HD pictures will now have a very different memory footprint)
  • The autolayout engine was demystified and explained in easy terms in one session. They talked about how they worked on its core in order to speed up performance. This resulted in a linear load scale compared to the exponential load scale that occurred in some cases in iOS11,  such as laying out sibling views with more dependencies.

They also gave tips on how to improve layout speed client-side, but there was nothing new. Basically:

  • Don’t misuse updateConstraints or layoutSubviews, because you will pay for it in terms of speed, especially for devices with Pro-Motion (120 Hz). Just do what is strictly needed.
  • Keep layouts as simple as possible, don’t try to mash different layouts into one. Use setHidden if possible.
  • It is better to change constants on constraints instead of adding/removing constraints if possible.

My favorite surprise of the autolayout talks this year was the introduction of a new AutoLayout instrument that highlights performance issues within the layout engine. Thank you Apple! (Although is not yet available in the beta)

Related talks:

WWDC 2018 - Whats new in cocoa iOS (general overview on what’s new in iOS 12)

WWDC.Autoloayout talk (more specific autolayout talk about how to improve client-side)

Build performance

One of the main pain points as an iOS developer using Swift is building times. This is usually one of the main reasons why we consider switching to React Native (hot reloading for ui tweaking is such a breeze in comparison!)

The good news is they worked hard on this with visible results and also explained in detail how we can improve client-side building times.

There is a new build system (which already existed as a non-default option for a while) that is now the default and is optimized for incremental builds. In Xcode 10 we can set builds to be parallelized on different cores.

In order to help speed up the process, we can then:

  • Split frameworks into smaller independent ones to help parallelizing builds
  • Declare inputs and outputs on script phases
  • Simplify and provide explicit types for complex swift expressions

On a source level, there is also a lot we can do:

  • Avoid using AnyObject altogether because the compiler would need to look in all the frameworks to point to the right method. This is avoidable by using protocols restricting to just the necessary methods.
  • Use the strictest access control possible in order to minimize places where the compiler needs to look to find the right method.
  • Minimize obj-c headers by using internal categories if possible (for mixed projects)

We were able to cut down two minutes on the build times just by setting these new settings on Xcode. I’m looking forward to optimizing the settings and the code itself for even better performance.

The not so good news is there wasn’t a talk on hot reloading and building times are still very far from React Native times. So, for now, the closest option for native iOS developers is to play around with playgrounds to tweak UI in a faster development process.

Related talks:

WWDC 2018 - Building faster in Xcode

Other Performance-Related Improvements

There was a lot more on the topic of performance. Among the different topics, these were my highlights:

  • Performance testing was tackled. The biggest highlight is the ability to launch parallel simulators for parallel testing in Xcode 10 and to avoid a test passing “luckily” because of the old state.  I have to say, the fact that Apple is still optimizing and adding APIs to its own testing frameworks makes me more confident in my decision to use it.
  • LLDB and the swift compilers also went through a great improvement in terms of debugging speed for developers.
  • Metal performance for games was also improved (this has been happening consistently in every new iOS version).
  • The Asset catalog now has a new lossless compression which promises a 15-20% size improvement.
  • There is a new API to measure runtime method performance between any two points in the code.  (Pretty neat!)

Related talks:

WWDC 2018 - What's new in testing

WWDC 2018 - LLDB

WWDC 2018 - Metal game performance optimization

WWDC 2018 - Measuring performance through logging

WWDC 2018 - Optimizing App assets

Conclusion

There is still a long way to go to reach the same developer speed as React Native for tweaking UI, and this was a big miss for Apple. More and more iOS developers are wondering whether to add the new technology to their codebases.

Xcode was also a big miss for me. As of beta 2, in terms of performance, the renaming engine still crashes on our codebase, and in terms of productivity features, it is still very behind compared to other IDEs (i.e. with formatting, refactoring, dependency managers).

I am, however, very pleased with Apple’s effort to speed things up both for app users and app developers. Being able to build faster will definitely speed up our developing cycle, and using new instruments and tools will help us maintain a high bar.  The autolayout instrument could become especially useful for tricky table views.

In summary, I'm happy Apple took a deep dive this year into this topic, and I am looking forward to actually seeing it working in production and in our development cycle when the new operative systems and tools get released in the fall.  

UX Writing

UX Writing

Position Spotlight: Supply Tech Engineer - Connectivity

Position Spotlight: Supply Tech Engineer - Connectivity