Reveal | News

Cyber Monday Sale

Tony Arnold — Fri, 28 Nov 2025 08:30:00 +1100

Hi, folks!

We’re offering a whopping 75% off the first year of your Reveal subscription for Cyber Monday — you’ve got until the 15th December to take advantage of this offer.

All you have to do is use the discount code CYBERMONDAY25 when purchasing Reveal.

The fine print: We’re not offering this to resellers or enterprise customers. Please be aware that the discounted price applies for the first year. After that, it goes back up to full price.

What’s been happening?

Vibrant, glassy UI as far as the eye can see.

In the past month, we added support for Apple’s 26 SDKs, alongside a thoughtful redesign for Liquid Glass.

Reveal’s accessibility tooling helps you to build helpful, meaningful interfaces for all of your users, faster than ever before. Reveal has been helping developers for Apple’s mobile platforms debug and deliver their apps for over a decade.

Hello, Mantel

Tony Arnold — Fri, 20 Jun 2025 11:00:00 +1100

Hi, folks!

From today onward, you’ll start seeing “Mantel” (or more formally “Mantel Operations Pty Ltd”) on Reveal’s website, and in other communications including invoices from Paddle, our payment provider.

Back in 2022, Itty Bitty Apps (the makers of Reveal) were acquired by Mantel (https://mantelgroup.com.au/) — this acquisition included Reveal.

I want to reassure you that it’s the same team working on Reveal, and aside from the change of name, we don’t expect there will be any other changes that you’ll notice. Mantel continues to invest in and support Reveal, just as Itty Bitty Apps did before it.

Introducing Insights, and new pricing

Tony Arnold — Mon, 16 Oct 2023 14:09:01 +1100

I have two announcements to share with you today:

First up, I’m proud to introduce Insights, a brand new workspace for Reveal. Insights runs a powerful, accessibility-focused audit of your app. Instantly. It will save you time and guide you to build better apps, for everyone.

Second, starting from November 14th, 2023 we’re simplifying our pricing model by unifying the Personal and Team subscription plans and introducing a single price point of $179 USD per year.

Read on for more detail.

Introducing Insights

Reveal’s new Insights workspace.

The Reveal team have spent more than a year building the new Insights workspace, working with industry experts and organisations to encode their expertise into more than 130 rules that pinpoint areas of improvement for your app. These rules are based on a combination of industry and platform-specific guidelines, best practices and over a decade of our own experience developing apps.

Insights runs a powerful, accessibility-focused audit of your app using information extracted from both the visual and accessible user interfaces of your app. This combination of the accessible and visual user interfaces is unique to Reveal, and allows us to provide a level of insight that is more powerful than anything else available for iOS, iPadOS and tvOS.

This new functionality takes Reveal from a passive developer tool, where you need to know what to look for in order to identify issues, to one that proactively surfaces problems along with suggestions on how to fix them. This radically improves developer efficiency and allows you to see and address issues you may never have know existed in your apps.

If Reveal has saved you even a handful of hours of debugging or testing over the years, you’ll love the power of Insights and the productivity it provides.

You can see an early version of Insights in action in Chris & Tony’s talk from /dev/world/2023 earlier this year, Bridging the Accessibility Gap:

New Pricing

Today, we’re announcing that we’re simplifying our pricing model by unifying the Personal and Team subscription plans, and introducing a single price point of $179 USD per year. This new pricing will come in to effect from 14th November, but if you purchase Reveal before then you’ll be able to take advantage of our $119 USD introductory offer on your first year subscription.

Over the past two years Reveal has delivered major new functionality, including our groundbreaking Accessibility tools, and now, the directed checking, guidance and education provided by the new Insights workspace.

Every year Reveal is updated to support new features and properties that Apple introduce in their operating systems, frameworks and hardware. We also track major new features and improvements in Apple’s macOS releases to ensure Reveal is polished to look great and run smoothly on the latest Macs. It’s a big job, and we’re proud to have kept pace with Apple’s releases over the years.

All of these features and updates deliver incredible value, and we believe our new pricing reflects the amazing capabilities that Reveal provides. With your support we plan to continue to build groundbreaking new functionality in to Reveal that help you build better apps more effectively.

Note that we’ll continue to provide a 30% discount to staff and students of qualifying education institutions. For information on educational pricing, please contact sales@revealapp.com.

Introducing the Accessibility Workspace

Chris Kolbu — Wed, 25 May 2022 06:30:00 +1100

Since its release almost ten years ago, Reveal has improved the workflow of thousands of developers, saving what we estimate to be years of developer time. We love being able to provide a tool that is meaningful and useful to you, our peers in the developer community.

The Reveal you know and love today.

We created Reveal because we wanted something like it to exist; because we needed it for our work. That same desire to inspect, modify, and debug with ease — to build better apps, faster — has driven us to develop a brand new, defining feature of Reveal.

Inspect. Experience. Verify.

With this release, we’ve made fundamental changes.

The Reveal you know is now Reveal’s Layout Workspace.

The all-new Accessibility Workspace gives you the tools to inspect, experience and verify that your app is accessible to all your users — by putting the accessible user interfaces of your app front and center.

The all-new Accessibility Workspace, featuring a suite of tools in Reveal to help you inspect, experience and verify your app across a variety of accessibility modes.

Accessibility Workspace Features

Inspecting Soundstagram’s accessible elements in the Accessibility Workspace’s WCAG 2.1 AA color contrast mode.

Instant Insight

The Accessibility Workspace is fast. It loads in fractions of a second and provides at-a-glance, actionable information about every onscreen element.

SwiftUI

The Accessibility Workspace has full support for SwiftUI apps.

Accessibility data is now included in Reveal snapshots. For an even easier way to share, you can export an image of the current canvas.

Detailed Inspectors

Rich information about your accessible elements is at your fingertips, with support for newer APIs like AXCustomContent.

Capable Navigator

Use it to filter elements by description, UIAccessibilityTraits, or both.

Composable Canvas

Reveal’s Canvas shows your primary user interface overlaid with its accessible user interfaces.

Experience your app as your users with common genetic color vision deficiencies would using Reveal’s best-in-class simulations.

Visual VoiceOver

See all of the frames or custom paths for your app’s elements laid out on the canvas.

Use the Navigator to quickly read the spoken descriptions of your elements in the order that VoiceOver will traverse them.

Voice Control

Instantly see how users would interact with your screen using their voice or keyboard.

Use the Navigator to see the Number and Labels of your elements.

WCAG 2.1 Contrast Checks

Verify your app’s use of colour and contrast against the AA and AAA guidelines using Reveal’s sophisticated tools.

Using deep knowledge of your app’s interfaces, Reveal provides useful and detailed information, including partial text contrast.

Use the Navigator to see which elements have contrast issues.

A First Step

We are releasing the Accessibility Workspace as a public beta because we recognize that accessibility testing is complex, and that there is so much more we can — and want to — do.

Talk to us. Tell us how you’re using it, and how you want to use it.

We’re listening.

Redesign, Revealed

Carlos Melegrito — Tue, 26 Oct 2021 00:00:01 +1100

Last year, Apple announced macOS 11 “Big Sur” — featuring an all-new look and feel, with refreshed UI elements and icons. It’s the most significant update to the platform since OS X Yosemite. And once again, Apple continues to bring the Mac’s design language even closer to iOS.

So what’s new? A lot. Everything’s been updated, from the app icons down to the controls. The refreshed look sports more minimal, “unified” toolbars, more vibrancy and blur effects, SF Symbols, plus an overall more friendly and rounded look. System apps like Mail, Messages, Maps (and even Xcode) have also been updated to be in line with the new design patterns.

It’s a big refresh, and makes the Mac feel even more modern and refined. Big Sur — and as of this year, macOS Monterey — sets up a whole new era of design for Mac apps. And consequently, sets up a whole new chapter for Reveal.

Interface-Off

The new UI changes in macOS are many, and they add up. Apps still work the same, and adopting the new look could be as simple as updating icons, buttons and controls. But to make an app appear like it truly belongs requires a lot of re-thinking and re-work.

In order to bring Reveal into this new era of design for the Mac, we decided to completely redesign it.

The Outline

We started with the Outline sidebar. Reveal’s Outline shows a beautiful, legible list of an app’s views. It’s easy to scan, highlights views as you hover over them in the Canvas, and it’s buttery-smooth to scroll through. It has a bespoke and unrivalled design, and is one of Reveal’s most valued and powerful features.

The challenge we faced was trying to reconcile macOS’ newer, yet more sparse (and sometimes, illegible) vibrant sidebar, with our own. Given this was the direction the Mac was headed, we decided to adopt as much of it as we could, while tweaking it to keep our original design intent.

We ended up with a whole new Outline that’s been completely re-engineered, aimed at keeping the utility and performance of the previous design — while making it feel like it fits right in.

Up next was the toolbar. Reveal’s toolbar provides information about the current app, and is the primary way to navigate between connections. Because of the updated, more prominent sidebar, our original design had to be overhauled to take advantage of the new layout. We used this as an opportunity to re-think the way it worked and to come up with a totally new design.

To redesign the toolbar, we took the minimal intent of the new macOS toolbar style and applied it to our own. Connection details now recede into the toolbar itself, allowing a more generous app icon preview. And the main navigation controls have been moved up, to a more convenient and prominent location in the toolbar.

The Canvas

The interactive 3D canvas is the centrepiece of Reveal — it’s gorgeous, powerful and iconic — and something we didn’t want to change too much. Therefore, the only updates we made involved increasing the sizes and legibility of the controls. The scope bar is now centre-aligned, and with the rest of the controls, floats over the canvas using a subtle background blur.

The Icons

Apple’s SF Symbols now permeate the rest of macOS, and give buttons a bolder and more rounded look and feel. And since they all inherit from the same set, toolbar icons across apps have a consistent appearance and visual meaning.

Although the set offered by Apple is extensive, there aren’t enough of them to convey the many kinds of UIViews and elements that Reveal can expose. On top of this, SF Symbols aren’t pixel-hinted and we didn’t want a set of blurry icons in an otherwise sharp interface. As a result, we decided to re-draw all of Reveal’s in-app iconography.

Every detail has been carefully considered, from keeping the original visual meaning of each glyph, down to the alignment of the 1.5pt strokes for @2x screens, and 1pt strokes for @1x screens. Even the alpha values have been set in a way such that similar-looking icons are distinguishable enough even if viewed without colour.

The Connections Dialog

Another updated design pattern in macOS is its new take on modality. App-Modal Dialogs have been established as the Mac’s convention to prompt opening, saving or selecting documents. And now, rather than opening as sheets that unfurl under an app’s toolbar, App-Modal Dialogs are presented as a more elegant window, detached from the app.

Given a lot of the restructuring we’ve made to Reveal’s layout, to keep it aligned with the new conventions in macOS, it made sense for us to do the same with Connections. The Connections “Sheet” and “Welcome Screen” have been combined into one, simpler modal dialog with a refreshed look and feel.

More UI Updates

While there was a lot that we did change to adopt the new look of macOS, the Inspector was the only thing we decided to leave untouched— for now. Reveal’s Inspector still stands the test of time, but we’ve got a lot planned for it in the future.

We’re continuing to shift away from our custom UI towards adopting more system controls and conventions — and it’s been paying off. With this new redesign, we’re leaning in to that even more, to take advantage of everything macOS can offer. This means that we can spend less time fixing and maintaining customised controls and focus on delivering features.

On the whole, Reveal’s UI has been completely redesigned and re-engineered for this next era of design on the Mac. This is one of the biggest changes we’ve made to the interface since version two, and sets up the foundation for Reveal’s future.

Thinking Outside the App Icon Box

A redesigned app isn’t complete without a new icon to go along with it.

As a part of the Big Sur release, Apple announced a new suite of app icons for the Mac. The new set is now more consistent with iOS, and takes on its rounded, “squircle” icon shape. The only distinction they’ve made to — “make it more Mac” — is an added layer of depth and dimension using gorgeous 3D-rendered objects that can extend beyond the edges of the base.

Conforming to this new style posed a hefty challenge for us with Reveal. Our iconic chatterbox had a unique silhouette, and it stood out against other icons on the dock. Shrinking it down to fit within the base wouldn’t have just diluted the impact of our icon, but seemed like an easy way out. And so, much like our revamped interface, we used this opportunity to explore a new design.

Explorations

What is Reveal? How do we distill such an abstract concept into a simple illustration? Should we start from scratch, and throw away a much-beloved and recognised logo? — These were the questions we discussed over and over, deep within many threads across the whole Itty Bitty Apps team.

We explored a few directions and tried to resurrect older ideas — but in the end, decided to go all-in on the chatterbox. This meant that our next challenge was to figure out how to take our existing brand, and make it appear like it belongs next to Apple’s own apps. Eventually, the approach we landed on was to re-draw the chatterbox in 3D.

Modelling in 3D

Many hours were spent modelling an origami chatterbox in Blender. Although tedious upfront, modelling in 3D made it easier to compose the final scene. The chatterbox could be rotated and moved; the lighting could be adjusted; and the virtual camera’s settings could be set up on the fly. All it takes is a bit of set up, the push of a button, then a few minutes of rendering, until we get a couple of potential variations of the chatterbox in 3D.

Once the model was set up, it then came down to the styling. The lighting was set to give the chatterbox its recognisable shadows and sharp lines. Within the scene, the chatterbox was then placed on a platform to bounce the light and provide a subtle reflection under the model. And finally, the textures on the chatterbox were manually hand-painted with a digital, watercolour brush (our goal was to make it look like it came straight out of a Pixar film).

And above is the end result. Our iconic chatterbox, re-modelled and re-textured in 3D — while staying true to the iterations before it.

Reveal’s Next Chapter

It took a lot of re-thinking and re-engineering, but we’re really proud of where we landed with Reveal today. There’s a level of design, care, and attention to detail that people love about Reveal — and we hope to have met that with this new design.

But it doesn’t stop there. Although it’s going to be one of the biggest changes we’ll make to the app in a while, we’ll keep evolving, growing and refining Reveal over time. This major redesign sets up a whole new chapter for Reveal, and we’re very excited to show you what we’ve got lined up next.

Free Tutorial: Debugging UIKit Views with Reveal

Tony Arnold — Wed, 15 Sep 2021 00:00:01 +0000

Over the years, we’ve seen that many developers only scratch the surface of Reveal’s capabilities, so we’ve partnered with Kodeco to create a video course that shows you how to use Reveal, as well as how to find (and fix!) common layout and rendering problems in your UIKit apps.

The tutorials work through a series of practical examples using Joan Disho’s “Papr” app for iOS. These real world examples help to guide you on a detailed walk-through of Reveal’s features. Our hope is that this course will help you to solve problems in your apps that you may not even know that you have!

You can access the course for free on Kodeco’s site.

(Note: this article has been updated to reflect the rebrand of raywenderlich.com to Kodeco.)

Reveal 29: Huge Sur

Tony Arnold — Wed, 02 Jun 2021 00:00:01 +0000

What’s new in Reveal v29?

Once every 5 years or so, Apple completely redesigns the visuals of their operating systems. Last year at their Worldwide Developer’s Conference (WWDC), Apple unveiled a major update to macOS — version 11, or “Big Sur” — that features a brand new look and feel. You can read more about macOS 11 on Apple’s site.

All macOS apps need a bit of tweaking to look right when major operating system updates are released — we’ve taken this opportunity to rework our user interface from the ground up. These changes have not only affected the way Reveal looks when running on macOS 11, but also how it runs. We’ve been able to simplify, optimize, and streamline many of our controls and views to improve responsiveness, and make some workflows dramatically faster.

As with every release, we’ve fixed the most frequent crashes and memory leaks to make Reveal even more reliable.

We hope that you really enjoy using this release, and that it continues to bring fast, accurate visual debugging to your workflow!

You can download Reveal v29 and read the release notes here.

Recent improvements

Version 28 focused on providing full support for Reveal to run natively on Apple’s speedy new M1-based Macs. These new machines are significantly faster for most tasks than previous generations and Reveal has been optimised to take advantage of these performance gains.

Saved document snapshots also load faster in this release. Reveal allows users to save a “snapshot” of their iOS or tvOS app’s UI to disk as a document. This document can then be sent to other Reveal users (such as the team’s designer, or a QA person) to review and comment on.

You can read the Reveal v28 release notes here.

Coming soon

Many developers only scratch the surface of Reveal’s capabilities, so for this release, we’re partnering with Ray Wenderlich to create a series of video tutorials that demonstrate real world applications of Reveal, and how to get the most out of it.

The tutorials will be available shortly.

It’s not a popularity contest, but…

Thousands of iOS developers around the world use Reveal to improve their developer workflow. We were thrilled to see the results of the 2020 iOS Developer Community Survey showing Reveal was voted the most used debugging tool after Apple’s own tooling!

Results of the 2020 iOS Developer Community Survey debugging tools question

What’s next?

Development of the next big release of Reveal is under way, and we’ve got some exciting things in the pipeline that we can’t wait to share with the rest of the iOS developer community later in the year.

Reveal 25 Announcement

Sean Woodhouse — Tue, 12 May 2020 00:00:01 +0000

In light of everything that’s going on in the world at the moment, new software releases can seem a little inconsequential. Our focus over the past few weeks has been the health and safety of our staff, family and friends and we hope that you are keeping well in these unprecedented times.

Since 2013, Reveal has become an important part of the development and debug workflow for thousands of iOS developers around the world. Over the years we have continued to improve the product, adding new features and tracking changes in iOS to allow you to inspect apps accurately and easily.

Today we are announcing the release of Reveal 25. In addition to the usual new features, bug fixes and improvements, Reveal 25 marks an important transition in the way the product is licensed. Going forward, Reveal will be licensed as a 12 month subscription, and you will need an active subscription in order to use the software. Alongside this change we have also created a new account portal which allows self-serve management of licenses and subscription plans.

You can now view and manage all your licenses over at https://account.revealapp.com/

We have also simplified the licensing of Reveal by removing the distinction between Personal and Commercial licenses and adding features to help organisations manage their licenses with our new Team Plan. The Team Plan allows organisations to manage team members and licenses with the convenience of consolidated billing.

Licenses for Reveal 2 to 24 will continue to work under the terms of the license agreement at the time of purchase, and those who bought Reveal within the last year will continue to receive updates to the end of their 12 month support period and will gain access to the account portal to manage their license activations and linked devices.

We look forward to delivering many new features and improvements under this new licensing model and hope the community will continue to support the sustainable development of one of the most widely appreciated iOS development tools on the market. If you have any questions or feedback please reach out from within Reveal (see “Help → Submit Feedback”), or via support.

A Lovely Gesture

Tony Arnold — Wed, 31 Oct 2018 00:00:00 +0000

A new release of Reveal (v19) is available to all users with a current license, and as a 14-day trial.

New Features

Inspect gesture recognizers attached to your view hierarchy - we’ve added full support for viewing and inspecting gestures in the outline view.
Broken layout constraints now provide more information about what is broken, and by how much.
Support for Xcode 10.1 has been added.
Added support for the following new properties:
- UILabel.enablesMarqueeWhenAncestorFocused on tvOS
- UITextInputTraits.passwordRules on iOS/tvOS

Bug Fixes

Performance when saving a Reveal snapshot has been significantly improved.
Performance when resizing the view hierarchy outline view has been significantly improved.
Disabled serialization of Display P3 images for Simulator targets. It turns out that the Simulator does not render P3 images at all - this should speed up loading and reloading, as non-P3 images are smaller in size.
Fixes to visual problems that occurred under Mojave’s dark mode, including light scrollbars being shown in the outline under the light appearance (even though the content is always dark).
Fixed an issue where nil enumeration values did not show appropriate values in the enumeration and mask inspectors.
Fixed an issue that was letting the transformation inspector fields grow too wide when displaying long values.
Bitcode is now properly enabled for RevealServer when targeting devices - it is not included for Simulator builds.

Minimum System Requirements

macOS 10.13.4
iOS 8
tvOS 9
Xcode 8

Support

Please report any problems you experience or give us feedback from within Reveal (see “Help → Submit Feedback”), or via our support forum.

Our Darkest Release Yet!

Tony Arnold — Thu, 20 Sep 2018 00:00:00 +0000

A new release of Reveal (v18) is available to all users with a current license, and as a 14-day trial.

Features

Reveal now supports macOS 10.14 Mojave’s Dark Mode.
Significant performance improvements to rendering and interaction with the canvas. This should be most noticeable with large view hierarchies.
Visual improvements to how filter matches are displayed. Only the elements that have been filtered upon will be highlighted.
Filtering by properties of a view’s backing layer is now possible.

Fixes

Changing the zPosition and transform properties on UIView instances will now properly update the canvas.
Fixed a bug in rendering order calculations that could cause the z-ordering of views to become incorrect when rendered in the canvas.
Modifying layer properties on UIImageView instances will no longer cause the view’s image to disappear in the canvas.
Fixes to filtering of matched ancestors.
The string enumeration inspector will now respond to all selection changes.
The UIScreen property inspectors have been rearranged so that the Layout tab is not empty.

Please note that macOS 10.13.4 or later is now required to run Reveal.

Minimum System Requirements

macOS 10.13.4
iOS 8
tvOS 9
Xcode 8

Support

Please report any problems you experience or give us feedback from within Reveal (see “Help → Submit Feedback”), or via our support forum.

Inspector Updates

Vlas Voloshin — Tue, 07 Aug 2018 00:00:00 +0000

A new release of Reveal (v17) is available to all users with a current license, and as a 14-day trial.

Inspectors

Reveal inspector panel showing new editable properties of CAShapeLayer

Attributes Inspector for Core Animation layers now supports 32 new properties across several classes.
Several layer properties with string enum types (e.g. CAShapeLayer.lineCap) are now displayed correctly in the inspectors and can be modified.
Attributes Inspector for UITextField, UITextView and UISearchBar classes now supports textContentType property.
Attributes Inspector now displays properties of MapKit views when inspecting tvOS apps.

Layout Constraints

Reveal participating constraints inspector showing an annotation for a system constraint and descriptions for autoresizing mask constraints

Reveal can now describe the purpose of many system-managed layout constraints. These annotations are available in:
- Participating Constraints inspector, by clicking the i button that appears when hovering the mouse pointer over a system constraint;
- Layout Report section of a system constraint’s Layout Inspector.
Clicking a warning icon that appears next to broken constraints in the Participating Constraints inspector now displays the description of the warning in a popover, instead of selecting that constraint immediately.
Outline and Participating Constraints inspector now display descriptions for autoresizing mask layout constraints instead of treating them as unknown.

Menus

Navigate menu now includes Select Next Issue and Select Previous Issue commands for quick navigation to the Outline items with detected layout issues (i.e. views with ambiguous layout and broken layout constraints).
Hierarchy navigation commands in the Navigate menu (e.g. Select Parent) have been updated to better support layout constraints, layout guides and layers.
Edit → Copy command now allows copying a debugger expression corresponding to the currently selected item.
Several commands and options in the Canvas and Navigate menus have been renamed to better reflect their current functionality, e.g. layer inspection support.

Miscellaneous Improvements

Outline items for CATextLayer objects now include the text displayed by those layers.
Views from Google Maps SDK (GMSMapView and GMSPanoramaView) are now collapsed in the Outline and Canvas by default, similarly to MKMapView.
Several under-the-hood changes in preparation for Dark Mode support on macOS 10.14 Mojave.

Bugs Fixed

Collapsing some items containing layout guides is now animated correctly in the Canvas.
Canvas now correctly positions items with miniscule intersection, instead of needlessly separating them. This mainly affected inspecting apps displayed on 3× screens.
Inspectors of option set (bitmask) properties no longer include a superfluous checkbox for “None” (zero) option.
View hierarchies that contain objects overriding isEqual: method (e.g. layers from Google Maps SDK) can now be inspected correctly.
Fixed the Layout Report inspector not appearing if a change to a view’s or constraint’s attribute introduced a layout issue.
Launching Soundstagram should now succeed if DEVELOPER_DIR environment variable points to the root of Xcode app bundle instead of the Developer directory inside it.
Launching Soundstagram should no longer fail to create a new Simulator instance if an appropriate one does not exist yet.

Minimum System Requirements

macOS 10.12
iOS 8
tvOS 9
Xcode 8.0

Support

Please report any problems you experience or give us feedback from within Reveal (see “Help → Submit Feedback”), or via our support forum.

Inspecting Xcode Playgrounds Live Views

Vlas Voloshin — Tue, 07 Aug 2018 00:00:00 +0000

Xcode Playgrounds is a great way to rapidly prototype and run an isolated piece of Swift code: an algorithm implementation, type architecture, or even an interactive view hierarchy – with support for live views. The iterative nature of playgrounds enables experimenting with and fixing issues quickly, but sometimes it may not be clear what actually causes an undesired behaviour or an incorrect layout. Traditionally developers rely on debuggers to examine the runtime state of their program at a particular point in time without having to modify and restart it, but aside from timeline previews, this sort of functionality is not currently available in playgrounds. This includes the View Debugger, which means that diagnosing obscure layout issues in custom live views requires resorting to trial and error… unless of course you have Reveal!

Integration

With just a few steps you can integrate the support library into your iOS or tvOS playground and inspect live views using Reveal 2 or newer:

Download this template playground (compatible with Xcode 8 or newer).
If you would like to enable Reveal on an existing playground that you have, copy the code from this template (including, most importantly, RevealServer.swift auxiliary source) into your playground and reopen it. Otherwise, you can simply rename the template and use it as a starting point.
In Reveal, use Help → Show Reveal Library in Finder menu to open the location of RevealServer.framework corresponding to the platform you’re targeting.
Copy this framework to a location accessible by the playground, which is either:
- Playground’s own Resources group in its Project navigator, or
- ~/Documents/Shared Playground Data folder – this option allows you to skip this step for other playgrounds next time.

And that’s it! Run your playground in Xcode, and once the live view becomes visible, it should also appear in Reveal as if it was an app running in Simulator. The comments in the template code provide a bit more information, and can be removed whenever you like.

Reveal main window showing a live view from Xcode playground running alongside it

How does it work?

Xcode Playgrounds with live views indeed run in an automatically managed Simulator instance. Xcode generates and installs a stub application into this Simulator and uses it as a host. What you see as an interactive live view in Xcode is actually a framed “window” into the Simulator screen.

Reveal, on the other hand, communicates with the inspected app via the local network. Dynamically loading Reveal Server framework into the playground’s process enables this communication, and that’s exactly what RevealServer.swift does.

The framework itself, however, needs to be placed in one of the predefined locations due to playgrounds’ sandboxing rules: they’re stricter than for normal Simulators, and don’t even allow reading (let alone executing) from arbitrary locations on your machine, including /Applications, where you’d usually have Reveal installed. Placing the framework in playgrounds’ Resources is a straightforward option, and allows sharing Reveal-instrumented playground more easily, but at a price of increased size. Taking advantage of Shared Playground Data folder, on the other hand, may be more convenient when instrumenting multiple playgrounds, but the framework needs to be placed in that location on every machine where the playground would be inspected. Fortunately, the line of code that attempts loading the framework can be easily changed to fail silently in order to allow the playground to run without Reveal support.

Caveats and limitations

Because the Reveal support library needs to be provided to the playground explicitly, there are limitations on how much of the integration can be automated:

Whenever you update Reveal, you’ll likely need to manually update RevealServer.framework in your playgrounds’ Resources or Shared Playground Data folder. Otherwise, the version mismatch would prevent Reveal from communicating with the playground.
RevealServer.framework versions for iOS and tvOS are different, which means that you’ll need to manually swap it if you inspect playgrounds of both platforms and use Shared Playground Data as the framework location.
And finally, Swift Playgrounds on iPad are unfortunately not supported by this integration method due to even stricter sandboxing (or, more precisely, binary code signing) rules.

We hope that using Reveal in Xcode Playgrounds will make experimenting with live views and layout even faster and easier for you than before. If you have feedback or suggestions about this use case, please let us know on our support forum. Happy playing!

Like parfait, it has layers! 🍰

Vlas Voloshin — Wed, 30 May 2018 00:00:00 +0000

A new release of Reveal (v15) is available to all users with a current license, and as a 14-day trial.

Layer Inspection Support (Beta)

Reveal main window showing a CALayer selected and being inspected

Reveal now supports inspecting custom Core Animation layer hierarchies. Sublayers manually added into views’ backing layers now show up in the Sublayers group in the Outline, and are displayed as selectable items in the Canvas.

Reveal inspector panel showing the new View/Layer scope bar

Layer properties, previously combined into a single Layer Inspector, are now separated into the familiar Identity, Attributes and Layout inspectors. When a view is selected, you can use a scope bar to switch these inspectors between showing properties of that view and its backing layer.

Layer inspection support is currently in beta - there are known issues that we’re working on, and we’re very open to input on this feature, so please get in contact if you have any feedback.

Thanks to Concepts for letting us use their amazing color wheel to debug and demo this feature!

Known issues

Content outside of layer’s bounds is not rendered in the Canvas, even if the layer has masksToBounds disabled. This makes layers with zero bounds size effectively invisible.
Some properties of CALayer and its subclasses (e.g. those defined in CAMediaTiming protocol) are missing from inspectors, while other properties are not editable and/or displayed as a string.
Filtering by name, address or class of a view’s backing layer produces no results.

Layout Constraints Inspection Improvements

Reveal inspector panel showing the revised participating constraints

Optional constraints are now rendered as dashed lines in the Canvas.
Optional constraints now include their priority in labels displayed in the Outline and Participating Constraints inspector.
- This means that you can now also use the Filter to find constraints with a specific priority – or any non-required priority. Simply use the @ character in the filter field: it will match the desciption of optional constraints.
Participating Constraints inspector is now divided in two groups: Participating Constraints Affecting Layout and Other Participating Constraints. As the names suggest, the first group includes constraints that directly affect position or size of the selected view or layout guide, while the remaining constraints connected to that item show up in the second group.
Constraints displayed in the Participating Constraints inspector are now sorted by layout attributes, relation and other properties. As a result, constraints displayed for different views or layout guides follow a consistent order, regardless of the order in which they were originally added into the view hierarchy.
Labels of constraints diplayed in the Participating Constraints are now more context-aware and shorten items such as superview (for views) and owningView (for layout guides).
More kinds of constraints are now classified as “system” and use blue colour for icons and Canvas lines. For example, this includes constraints managed internally by UIStackView.

Bugs Fixed

Inspector for the directionalLayoutMargins property is now displayed correctly.
Added missing inspectors for properties declared in UITextDraggable protocol: textDragActive, textDropActive, textDragOptions.
Participating Constraints inspector now correctly includes descriptions of firstBaseline and margin-related layout attributes.
Changes to the list of windows on the screen are now detected correctly when the view hierarchy is modified using inspectors.
Precise ordering of windows that share the same level is now preserved in the Outline and Canvas.
If a view goes offscreen but is not deallocated while Reveal is collecting snapshot images (e.g. due to an animation completion), it is now captured correctly instead of showing up empty.
Layout guide items in the Outline are now updated correctly when their identifier changes.
Fixed a crash occurring when inspecting applications running in Simulator with views larger than 16384 pixels in size.
New snapshots of applications running on devices and simulators with non-P3 displays will no longer appear “over-exposed” in the Canvas when running High Sierra.
Timeout for launching Soundstagram has been increased to avoid failing due to simulator environment taking a long time to initialise.
Fixed Soundstagram failing to launch in some environments with lots of simulators.

Minimum System Requirements

macOS 10.12
iOS 8
tvOS 9
Xcode 8.0

Support

Please report any problems you experience or give us feedback from within Reveal (see “Help → Submit Feedback”), or via our support forum.

This one goes all the way to eleven

Tony Arnold — Mon, 18 Sep 2017 00:00:00 +0000

A new release of Reveal (v11) is available to all users with a current license, and as a 14-day trial.

We’ve turned the dials to eleven with this release - just in time for Apple’s big round of releases: Reveal now supports tvOS 11, iOS 11 and Xcode 9.

We’ve gone through and added support for over 35 new inspectable properties, including:

CALayer
- maskedCorners
MKMapView
- region
- centerCoordinate
- visibleMapRect
- showsCompass
- showsScale
- showsTraffic
UIAccessibilityContentSizeCategoryImageAdjusting (conformed to by UIButton, UIImageView)
- adjustsImageSizeForAccessibilityContentSizeCategory
UIApplication
- alternateIconName
- supportsAlternateIcons
UIBarPositioning (conformed to by UINavigationBar, UISearchBar, UIToolbar)
- barPosition
UICollectionView
- dragInteractionEnabled
- hasUncommittedUpdates
- reorderingCadence
UIContentSizeCategoryAdjusting (conformed to by UITextField, UITextLabel, UITextView)
- adjustsFontForContentSizeCategory
UIImageView
- masksFocusEffectToContents
UIScreen
- maximumFramesPerSecond
UISegmentedControl
- springLoaded
UIScrollView
- contentInsetAdjustmentBehavior
- adjustedContentInset
- indexDisplayMode
UISpringLoadedInteractionSupporting (conformed to by UIButton, UISegmentedControl, UICollectionView)
- isSpringLoaded
UITableView
- separatorInsetReference
- insetsContentViewsToSafeArea
UITextDraggable (conformed to by UITextField, UITextView)
- textDragActive
- textDropActive
- textDragOptions
UITextInputTraits (conformed to by UISearchBar, UITextField, UITextView)
- smartQuotesType
- smartDashesType
- smartInsertDeleteType
UIView
- accessibilityContainerType
- accessibilityIgnoresInvertColors
- directionalLayoutMargins
- insetsLayoutMarginsFromSafeArea
- safeAreaInsets

We’ve also improved a couple of the property inspectors:

Bit mask options are now presented as checkboxes for types such as UIViewAutoresizing.
An improved representation for CGAffineTransform properties.

I hope you enjoy the improvements we’ve made! If there are any additional properties that you’d like to see us support, please start a discussion about it in our support forum.

Minimum System Requirements

macOS 10.11
iOS 8
tvOS 9
Xcode 7.3

Support

Please report any problems you experience or give us feedback from within Reveal (see “Help → Submit Feedback”), or via our support forum.

Layout Guides and the Touch Bar

Tony Arnold — Wed, 22 Feb 2017 00:00:00 +0000

A new release of Reveal (v7) is available to all users with a current license, and as a 14-day trial.

You thought that after the huge set of new features we released last month we’d slow down and take a breather? No, Sir! We’ve got two great, chunky new features and a light dusting of bug fixes ready to go:

Reveal 7 adds support for inspecting Auto Layout guides, as well supporting dynamic, context-specific keyboard shortcuts on the Touch Bar of Apple’s new MacBook Pro.

Auto Layout Guides

New in this month’s release of Reveal is support for Auto Layout guides.

Being able to inspect layout guides is useful when debugging layout issues in views like UIStackView which use UILayoutGuide to implement their internal layout. For example, if a constraint attached to a layout guide gets broken by Auto Layout, inspecting your app in Reveal will highlight that constraint with a layout error, and now Reveal will also show which layout guide the constraint is related to, and visualize it in the Canvas.

You can read about this feature in-depth in Vlas’ introductory blog post.

Touch Bar Support

If you’re lucky enough to have one of Apple’s new MacBook Pro notebooks, we now support dynamic, context-specific hotkeys in the Touch Bar for:

Connecting to your iOS and tvOS apps
Controlling the canvas and outline view, including:
- Filtering the view hierarchy
- Refreshing the currently focused app
- Toggling auto layout, system windows and hidden view display
- Zooming the canvas
- Controlling the display options of the canvas, including perspective (2D/3D) and the render mode (“Frames”, “Content” or “Frames and Content”)

We’d love your feedback on this feature!

Bug Fixes

Fixed: The position and size of the frontmost document window is remembered across launches.
Fixed: RevealServer.framework’s CFBundleShortVersionString is now the same as the version of Reveal that bundles it.

Minimum System Requirements

macOS 10.11
iOS 8
tvOS 9
Xcode 7.3

Note: The RevealServer.framework has changed. Please remember to update your projects to link to the new framework version.

Support

If you have a question, or would like to give us feedback, you can do so from within Reveal (see “Help → Submit Feedback”), or via our support forum.

Introduction to Auto Layout Guides

Vlas Voloshin — Wed, 22 Feb 2017 00:00:00 +0000

New in this month’s release of Reveal is support for Auto Layout guides. Represented by the UILayoutGuide class, layout guides have been introduced to UIKit as an efficient replacement for “dummy views”, and can be used as spacing between views or to help implement a complex layout. Built-in views like UIStackView use UILayoutGuide internally to implement their layout behavior, while several UIKit classes expose special guides to allow access to specific layout features.

UIKit support

UILayoutGuide defines a rectangular area inside its owning view which interacts with Auto Layout, but does not provide any content. You can create layout guides manually to implement advanced constraint configurations: for example, creating equal or proportional spacing between views. UIStackView provides similar functionality (and it’s implemented using layout guides too), but it’s great to have an efficient tool for implementing such layout manually.

UIKit also provides focus guides (UIFocusGuide). These can be used on tvOS to define an invisible area that redirects focus to some other view. And because they inherit all properties of layout guides, they participate in Auto Layout in the same way.

In addition to supporting custom layout guides, UIKit also provides several “standard” guides:

UIView.layoutMarginsGuide: a portion of the view’s bounds inside its layout margins.
UIView.readableContentGuide: an area of the view which has width optimized for reading text without moving one’s head.
UIViewController.topLayoutGuide and UIViewController.bottomLayoutGuide: define the highest and the lowest visible extents of the view controller’s view. These are not always represented by UILayoutGuide.
UIImageView.focusedFrameGuide (tvOS only): represents the visible frame of an image view when it’s focused.

Reveal support

In Reveal, layout guides appear in the Outline view, the Inspectors, and the Canvas – just like views and constraints.

In the Outline, layout guides owned by a view are inside that view’s “Layout Guides” group. In the Canvas, layout guides are visualized as wireframes with their own unique color. Note that layout guides are rendered “hollow” in the Canvas: this reflects the fact that they don’t render any content themselves. To select a layout guide in the Canvas, click on its wireframe.

Just like views, layout guides in Reveal support features such as:

Participating constraints in the Layout inspector,
Layout ambiguity warnings,
Advanced view hierarchy filtering (by identifier and class name).

And just like constraints, layout guides can be hidden from the Outline view and the Canvas using the “Constraints and Guides” toggle in the bottom-left corner of the Canvas.

Being able to inspect layout guides is useful when debugging issues in views like UIStackView which use UILayoutGuide to implement their internal layout. For example, if a constraint attached to a layout guide gets broken by Auto Layout, inspecting your app in Reveal will highlight that constraint with a layout error, and now, Reveal will also show which layout guide the constraint is related to, and visualize it in the Canvas.

Even if you don’t have any layout issues, having the information about all layout participants gives you an insight into how the layout is implemented in system-provided views. On tvOS, this also has the added benefit of being able to see the invisible focus guides that you or the system have created – and to check that their size and position match your expectations.

You can find an example of using layout guides and focus guides – and see how Reveal visualizes them – on the new “Auto Layout Guides” page of the Revert project.

The curious case of view controllers’ guides

As mentioned above, UIViewController provides two built-in layout guides: topLayoutGuide and bottomLayoutGuide. However, these are not always UILayoutGuide objects.

While UILayoutGuide appeared in iOS 9, top/bottom layout guides API was introduced back in iOS 7. Thus, the underlying implementation of these guides in iOS 7 and 8 always used hidden views with a private class _UILayoutGuide (note the underscore). I wouldn’t be surprised to learn that UILayoutGuide were already in the plans during that time frame, because both these properties are exposed using a special UILayoutSupport protocol instead of having an explicit class. This was a convenient foresight, as it may have allowed UIKit engineers to seamlessly replace the implementation without changing the API.

Even in iOS 9 and 10, the situation is still complicated. When inspecting your apps, you may find that in some cases top and bottom layout guides are now actual layout guides (represented by a private class _UILayoutSpacer), whereas in other situations they are still _UILayoutGuide views. For example, view controllers decoded from a storyboard tend to use view-based implementation, while those instantiated and embedded manually usually have _UILayoutSpacer as their top and bottom layout guides.

In Reveal, _UILayoutGuide objects show up among views, but have the same icon and Canvas color as layout guides. This reflects the duality of these objects: technically, they are views (and are listed as their owners’ subviews), but conceptually, they are used as guides.

Fortunately, as API users we don’t usually have to worry about this difference: UIKit takes care of hiding this abstraction from us. But it is still important to keep in mind, as per The Law of Leaky Abstractions, all non-trivial abstractions, to some degree, are leaky. And when problems (like layout issues) occur, the more you know about the abstraction, the better. So next time you’re wondering how view controllers in your app implement their layout guides, just inspect it in Reveal!

Introducing Layout Errors and Warnings

Tony Arnold — Wed, 18 Jan 2017 00:00:00 +0000

A new release of Reveal (v6) is available to all users with a current license, and as a 14-day trial.

We’re excited about this update! Reveal 6 introduces support for Auto Layout errors & warnings, improved filtering, and a decent helping of smaller features and bug fixes.

Let’s get to it!

Auto Layout Errors & Warnings

Reveal now highlights views that have ambiguous layout, and constraints that have been broken due to an unsatisfiable layout using warning icons in the outline view. Clicking on the warning icon jumps straight to the Layout inspector, where you can find more information about the issue.

Layout ambiguity is an Auto Layout problem where a view that’s laid out using constraints doesn’t have a fully defined position or size (or content size in case of scroll views). As a consequence, such views and their subviews might be laid out in an unexpected manner, and the layout may even change between launches of the app! If you’re using Interface Builder, ambiguity is usually caught early, but at runtime it may be caused by missing constraints, or by inequality constraints that are ambiguous. Reveal will now describe what kind of ambiguity it detects, and what dimensions are ambiguous.

If a constraint configuration cannot be fully satisfied, Auto Layout is forced to break one of the constraints so that your app continues to function (at least partially). Correct layout cannot be guaranteed by the system in such a case, and if this happens while you’re debugging your app the Debug Console log will show the dreaded “Unable to simultaneously satisfy constraints” message. Now, if you inspect your app in Reveal after receiving such message in the log, you’ll be able to see which constraints have been broken – both in the outline view and in the Participating Constraints inspector. Broken constraints are coloured red in the Canvas.

Improved View Hierarchy Filtering

The view hierarchy can now be filtered by specific view properties, such as:

Class or superclass name
Accessibility information such as the identifier, value and label
Constraint identifier
UIView tag
Object memory address

The outline view also shows the matched property along with its value to indicate why a view or constraint matched a particular property.

Clicking on the icon next to the filter field shows the filtering modes that you can select. You can also switch to a filtering mode by typing its keyword right into the filter field! For example, to switch to the “Class Name” mode, type class: and press Return. You can also abbreviate all keywords, so for example i:, id: and ident: are all the same as identifier:. To switch to the default filtering mode, simply press Delete key in an empty filter field.

Here’s a list of all available keywords:

class: for Class Name
accessibility: or ax: for Accessibility
identifier: for Identifier
tag: for View Tag
memory: or address: for Memory Address

Other New Features

We’ve added a “Reset View” button to the canvas in the lower right-hand corner. This will re-orient and reset the zoom level on the canvas so that the presented view hierarchy is centered and visible. It’s really useful when you zoom or scroll too far.
Tooltips have been added to, or improved for many controls.

Bug Fixes

Fixed: Descriptions of participating constraints in the layout inspector had incorrectly formatted labels.
Fixed: Changing selection in the outline view to an item that’s currently collapsed did not expand parent items.
Fixed: RevealServer.framework had simulator platforms listed in its Info.plist.
Fixed: Integration scripts will no longer copy RevealServer.framework inside an already present copy of the framework.
Fixed: Reveal Server no longer requires the CFBundleName, CFBundleVersion and CFBundleShortVersionString to be present your iOS application’s Info.plist.
Fixed: Potential race conditions in the Reveal LLDB script commands.

Minimum System Requirements

macOS 10.11
iOS 8
tvOS 9
Xcode 7.3

Note: The RevealServer.framework has changed. Please remember to update your projects to link to the new framework version.

Support

If you have a question, or would like to give us feedback, you can do so from within Reveal (see “Help → Submit Feedback”), or via our support forum.

Reveal LLDB Commands

Oliver Jones — Wed, 14 Dec 2016 00:00:00 +0000

With the latest release of Reveal (v5), we now provide a set of debugger commands accessible from the LLDB console (including Xcode’s Debug Console). These commands allow you to easily load and control the Reveal Server framework in your current debug session with either the LLDB console command line or breakpoint commands.

Installation

To make the Reveal Server commands available to your debugging sessions, open Reveal’s Help menu and click Install Debugger Commands…

Confirming the installation will add the following lines into your ~/.lldbinit file:

### Reveal LLDB commands support - DO NOT MODIFY
command script import /Applications/Reveal.app/Contents/SharedSupport/Scripts/RevealServerCommands.py
###

The above snippet imports a Python script bundled with Reveal into all your debug sessions. The python script implements functionality required to load, start and stop Reveal Server in the Simulator and on device.

Note that the command directly references your Reveal installation path — if you move Reveal to a different location, Reveal will offer to correct your ~/.lldbinit file on launch.

Removal

To remove the Reveal Server commands from your debugger, open Reveal’s Help menu again and click Remove Debugger Commands… This will remove the snippet previously inserted in your ~/.lldbinit file.

Available commands

The easiest way to take advantage of the Reveal Server debugger commands is to follow the instructions in our breakpoint-based integration guide.

The following commands are exposed to the LLDB console command line, allowing you to control the Reveal Server during debugging:

`reveal load`

Loads the Reveal Server framework in the current debug session. If you’re debugging in the iOS or tvOS Simulator, this command will use the framework bundled with Reveal directly. When debugging on device, the command will look for RevealServer.framework package in your app’s resources. If you’ve followed the instructions in the Debugging on device section of the integration guide, your app will already contain that resource.

To start Reveal Server automatically after loading it, use the --autostart (or -a) flag, e.g. reveal load --autostart.

`reveal start`

Starts Reveal Server. Normally this happens automatically if the Server is loaded during application startup (e.g. in UIApplicationMain breakpoint), and also every time your app becomes active. However, if you would like to load and control Reveal Server manually, you can use this command to start it easily after you load it using reveal load command or by other means.

`reveal stop`

Stops Reveal Server, if it was previously started. You can restart it later using reveal start command.

`reveal status`

Prints the current status of Reveal Server — whether it’s loaded and running, and also its protocol version.

Getting Help

If you have any problems, questions or feedback about using Reveal Server LLDB commands with your app, head over to our support site and let us know.

Improved Debugger Integration and More

Oliver Jones — Wed, 14 Dec 2016 00:00:00 +0000

A new release of Reveal (v5) is available to all users with a current license, and as a 14-day trial.

This release brings improved debugger integration and a smattering of new features, bug fixes and performance improvements.

Improved Debugger Integration

Reveal now has tighter integration with the LLDB debugger. This makes using the breakpoint-based Reveal Server injection method easier and gives developers Reveal-oriented commands to use in LLDB’s debug console. See the associated blog post for more details.

New Features

Using Force Click on a view in the canvas will now focus on that view hierarchy sub-tree.
A new IBARevealServerDisableAutoStart user default that can be specified at iOS application start up to stop the Reveal Server from automatically starting. See RevealServer Configuration Options documentation for more details.

Performance Improvements

A handful of performance improvements were made in this release. In particular Reveal now prefers to use OpenGL over Metal on Intel GPUs on macOS Sierra (due to bugs with Metal on Sierra).

Bugs Fixed

Fixed: Crashes when interacting with the view hierarchy/focus history path during refresh.
Fixed: Issues with the representation and serialisation of very large, very small, or out of bounds numeric values (NaN, Infinity, etc).
Fixed: UIView semanticContentAttribute inspector was showing incorrect values.
Fixed: Restoring a machine image from a Time Machine backup could lead to Reveal showing inaccurate activation dialogs.
Fixed: Reveal now recognises Reveal 1.x RevealLicense files and offers upgrade advice.
Fixed: Colours on Macs with wide gamut (P3) displays were not displayed correctly.

Minimum System Requirements

macOS 10.11
iOS 8
tvOS 9
Xcode 7.3

Note: The RevealServer.framework has changed. Please remember to update your projects to link to the new framework version.

Support

Please report any problems you experience or give us feedback from within Reveal (see “Help → Submit Feedback”), or via our support site.

Taking Revert to tvOS

Brunno Ferreira — Thu, 13 Oct 2016 00:00:00 +0000

To make sure we take support for tvOS on Reveal even further, we recently updated Revert, adding compatibility with this new Apple platform.

As explained on the Reveal.app blog, Revert is an open source project that comprises a series of common and edge case scenarios that help us optimize Reveal and ensure its quality with every update, making sure there are no regressions being introduced.

Coming from the iOS and macOS worlds, here’s what we learned from working with tvOS:

Focus Engine

This is probably the most noticeable change when starting tvOS development. Interface elements aren’t meant to be pointed at with a mouse or touched with your fingers, but are instead focused on a TV across the room according to movements on a touch surface on the Siri Remote.

Focusing a view brings it forward, making it more prominent. Only a single object can be focused at a time. Previously, the only focusable objects were views, but support for this has been extended to non-view items on tvOS 10.

So just like you would use the arrow keys on your computer keyboard to move selection between different files or folders, you now bring a button into focus on your TV and make it the frontmost element. In both cases, you know that that’s the item you will be interacting with when proceeding with the default selection action — be it a key press or a tap on the Siri Remote.

Yes, please do check out the SpriteKit example!

When using most of the controls available on tvOS you get that behavior for free, since they come with sensible defaults that make the focus engine change their appearance automatically. But that is not the same when using standard UICollectionViewCells.

So, let’s say you are a very attentive iOS developer and noticed most of the apps on the TV have UIs that resemble collection views. That seems like a good starting point, right? Thus, you quickly set up a project with a simple collection view and default cells to start playing with the OS and nothing gets focused.

It turns out that is the expected behavior, since collection view cells are composed of ordinary views. You need to use the collection view delegate to update the look of each cell when adding or removing focus. Or, as an easy way around that, design your cells using UIImageViews. By default, they will animate their images in and out of focus when placed as subviews of focusable elements.

If you’d like to get more technical details about the focus engine and what is possible, the Airbnb developers have some great material here.

Sideways, not Downwards/Upwards

Michael Flarup said it best on Designing for the Apple TV: the natural interaction on tvOS is moving the selection around elements — as opposed to smartphone touch screens where entire views get scrolled.

When more content needs to come up or down as a result of a vertical gesture, the whole interface might need to get redrawn, which means the user could potentially get disoriented for a moment while trying to get acquainted with the changes on the screen. Horizontal gestures, on the other hand, usually require redrawing just the related elements that sit side by side.

Based on that approach, we built Revert based on a split view with categories on the master view and test scenarios on the detail view. Scrolling up and down on the list to the left refreshes all the entries to the right — but browsing a single category to the right does not change anything else on the screen. Additionally we need to test tvOS split views with Reveal.

Vertical scrolling on the master view refreshes the whole detail view

Remote Coordinates System

The Siri Remote (as well as game controllers connected to the Apple TV) can handle touches in windowing mode or interpret their absolute values.

To read absolute touch points (where exactly the user touched on the touch surface) we need to use the GCMicroGamepad profile, signaling that the remote will be used as a game controller. Otherwise tvOS defaults to windowing mode, like what happens on the SpriteKit example in Revert.

When using windowing, initial touches on the Siri Remote are always considered the origin (0, 0). So it does not really matter if the gesture starts on the bottom left corner or on the top right corner of the touch surface on the remote. We just start reading finger movement from there.

Unlike on iOS, where the user directly manipulates the interface, on tvOS the user interacts with the Siri Remote — which is one level removed from the interface on screen. This means the user is likely not facing the interaction controls, and thus the concept of the initial touch being “flexible” and gestures starting from there becomes fundamental for building a good user experience.

Missing Controls and Frameworks

Everyone has been making quite a fuss about the absence of UIWebView (or WKWebView) and the Safari View Controller, but there’s more stuff from iOS that didn’t make it to tvOS, like UIToolbars, UIPickerViews, UISliders and UISteppers. MapKit was also absent at launch, but was subsequently included in tvOS 9.2 and is already a part of Revert — check it out to see where all of us here at Itty Bitty Apps come from.

That’s us!

Many frameworks are not included in tvOS, although many of them do not make much sense anyway because the Apple TV lacks the hardware required.

So if you plan on porting an iOS app to tvOS, it is worth checking if all the components you require are either available or can be replicated in some fashion. As an example, Apple implements the language selector in the Settings app (a common use for pickers) as a UIAlertController with many options.

Language selector in tvOS 9.2 inspected on Reveal: UIAlertController with many, many options

Reuse Code, Not Storyboards

If you’re porting an iOS app to tvOS and have got at least a few non-trivial views, this is probably one of the biggest pain points in your endeavor. Storyboards are not interchangeable, and you can’t even copy and paste specific elements between the platforms.

After screaming, crying and flipping a few tables, it is hard not to agree at least in part with that decision though. Since not all the controls from iOS are available on tvOS, it makes sense to have storyboards specific to each platform.

Local Storage

Most people will say there is no local storage for a tvOS app, but that is not really the case. Here’s what Apple says about it:

(…) your app can only access 500 KB of persistent storage that is local to the device (using the NSUserDefaults class).

So there is local storage available, but it is limited to what can be done with the NSUserDefaults class. If your needs go beyond that, then saying there is no local storage is accurate.

And in that case, doing it online is the only way to go. Be it CloudKit or any other cloud service.

Binary Size

There’s also a limit on app binaries. They can’t go over 200 MB, which means using the on-demand resources API introduced on iOS 9 for anything that can’t get bundled in the app.

Since, as mentioned previously, there’s no local storage for anything other than NSUserDefaults, this also means you might need to keep fetching assets every time the app is run. Apple makes this clear:

The maximum size of an Apple TV app is limited to 200 MB. (…) all other data must be purgeable by the operating system when space is low.

Top Shelf

Apps placed on the top row on tvOS can take advantage of the top shelf — a TV Extensions Service that allows exposing contents of the app on the home screen.

Content presented on the top shelf is a combination of a static banner used as the background and dynamic items that can be interacted with by users. You have no control over where your app icon is placed on the user’s home screen, so every app has to be prepared for being placed on the top row:

At a minimum, every app must supply a single, static top shelf image that can be displayed when your app is in the top row of the Home screen and in focus.

Top shelf is an effective way to bring attention to your app.

Overscan

Last, but definitely not least, there’s overscan. This can be a gigantic issue if not considered initially or, even worse, completely neglected.

Surprisingly, there hasn’t been much mention of overscan when people talk about tvOS. But the truth is, there should be. iOS and macOS developers are used to knowing where their apps are going to be run and how that hardware behaves. That simply isn’t the case with tvOS.

Although Apple TVs may work the same and only differ in storage capacity, there is no way of telling what kind of TVs will be displaying your app. Some may have overscan enabled, some may not. Some may allow disabling overscan, some may not. And having overscan enabled means you should not be using the whole screen estate do draw your app. Never place important content too close to the edges.

If you are coming from the game console world, it may be natural to consider the TV Safe Area when thinking about your visual design. But as iOS developers, we don’t expect our layout to be simply clipped at the edges of the display.

Different TVs have different levels of overscan — so testing your app in a few models might not be enough, and there’s currently no way for tvOS to query them for the amount of overscan being used. So the safest route you can go is using industry standards to account for that. Apple recommends placing your layout in a box that sits 90 pixels from side edges and 60 pixels from top and bottom edges.

So if we were only allowed to take one lesson from the whole project, this would probably be it: account for overscan, and do so right at the beginning. It won’t be fun gathering everyone around to show your fresh new app only to find out the aggressive overscan on the TV breaks your layout. It also won’t be fun refactoring a potentially massive storyboard, if you went with that option.

How Revert could look without thinking about overscan, ouch!

As mentioned in the beginning of this post, Revert helps us optimize and improve Reveal in every update. So if you are a Reveal user (thanks! 🎉) and find yourself with an example that doesn’t work quite right, please fork Revert on GitHub and submit us a pull request with your edge case so we can make Reveal even more useful to you in the future!

Reveal 2

Sean Woodhouse — Tue, 13 Sep 2016 00:00:00 +0000

Today we’re thrilled to announce the release of Reveal 2. This release delivers a host of new features and an all-new design that make Reveal even more powerful and easy to use. Here’s a summary of some of the major new features.

USB connection support

Ever need to inspect an app on device in a corporate environment but the networks are locked down and Bonjour doesn’t work? We have, and it’s a pain. Reveal will now discover applications running on devices connected by USB, making inspection easier and more reliable.

Inspect app extensions

Inspect messages extensions, notification extensions, custom keyboard extensions, today extensions and many more. With Reveal you can inspect and debug issues that even Xcode can’t see.

Filtering

Reveal now allows you to filter views and constraints by name and memory address making it even easier to find and fix problems in your view hierarchy.

All-new design

We’ve streamlined the interface, made the inspectors more compact, and polished every nook and cranny of the app. Navigate faster and see more information at a glance with a more refined experience.

Versioning and Licensing

With this release we’re changing the way Reveal is versioned and licensed. We’re switching to a model where we release features as they are ready rather than holding them back for major paid upgrades. We’re also moving to a simpler version strategy. This release is version 2, the next will be version 3, and so on.

Licenses now include a year of updates, after which you can continue to use the last version of Reveal released within those 12 months. To continue to receive updates after the included 12 months, you will need to renew your license.

For more information and an FAQ on these changes to our licensing please visit the Reveal Purchase Page.

Upgrades & Pricing

Instead of offering upgrade pricing for Reveal 2 we have lowered the price for all new and existing users. Personal licenses are now USD$59 (down from $89) and Commercial Seat licenses are USD$119 (down from USD$179).

Customers who bought Reveal on or after 9th June 2016 will receive a free Reveal 2 license. We will be in contact with these customers shortly with more information.

For information on educational discounts, site and enterprise licenses, please contact Reveal Sales.

How to get it

You can download Reveal 2 directly from our web site.

Feedback

If you have any questions or would like to provide feedback, please head over to our support site and leave a comment.

Announcing Revert

Tony Arnold — Thu, 19 Nov 2015 00:00:00 +0000

Revert (REVEal Rendering Test) is an iOS project we’ve built to help test the performance and accuracy of Reveal, our runtime view hierarchy inspection tool. It contains a number of examples which highlight both common and edge case scenarios, and helps us to ensure that we don’t regress or introduce rendering and serialization bugs when updating Reveal.

We’re releasing Revert so that:

The community can compare the features and accuracy of the various view debuggers on the market using a simple, attractive example.
The developers of other view debuggers on the market have access to a standard reference suite of tests to check the accuracy of their own products.

Get it now from GitHub.

Accuracy as a goal

Reveal communicates with a small HTTP server embedded in your iOS application to retrieve information about the view hierarchy at runtime. This information includes the structure of the view hierarchy, bitmaps that represent those views and all properties of the views. Once retrieved, Reveal presents the information hierarchically in an outline view, as well as graphically on a central canvas.

The way in which Reveal interprets this information visually is critically important for users who rely on our app to present an accurate reflection of their application’s state. We go to great lengths to ensure that Reveal renders as accurately as possible, and this focus on accuracy has influenced our approach in a number of areas.

The canvas in Reveal takes one of two divergent rendering paths to ensure that what you see in Reveal reflects what you see in your app:

The 3D canvas mode approximates how the iOS runtime lays out views.
The 2D canvas mode grabs a composited screenshot of the inspected component directly from the iOS runtime, rather than approximating how things might be laid out.

The end result is that what you see on screen in Reveal is much more accurate to what’s actually visible on your device or simulator.

Examples

Using Revert’s test suite as an example, it’s pretty easy to see how much more accurate Reveal is than the Xcode view debugger:

MapKit

MKMapView displays the origin of Itty Bitty Apps employees. All the annotations are linked together by an MKPolygon.

Transformed Views

A selection of transformed views with embedded subviews showing both the transformed and identity (non-transformed) positions:

Translate: A view that has been translated (-20, 20).
Rotate: A view that has been rotated 15°.
Scale: A view that has been scaled by 50%.

The behaviour when mixing constraints and transforms changed between iOS 7 and 8. We published a breakdown of these changes in a previous blog post.

Bounds and Anchor Point Changes

Shows the effects of bounds and anchor point changes.

Reveal’s accuracy is the result of a huge amount of development work. The examples above present a few specific scenarios that highlight the care we take, and the level of detail we pursue when developing Reveal.

Downloading Revert

We’ve made Revert available on GitHub under a BSD 3-Clause License.

We’ve tried to include as many scenarios as possible, but if you’d like to add your own or suggest one that should be supported, please feel free to create a pull request or contact us directly via our online support.

Reveal 1.6.2

Barry Scott — Thu, 05 Nov 2015 00:00:00 +0000

Last week Apple shipped the new Apple TV to the public. Like everyone else we were excited to get our hands on it, because, you guessed it - we love Crossy Road. Seriously though, we’re keen to show off what we actually _have_ been doing with the new Apple TV, and that is using Reveal to inspect tvOS apps. Version 1.6.2 of Reveal which you can download now, will let you pull apart your widescreen view hierarchy on both device and simulator.

Find out all about the great new features in Reveal 1.6 here

What’s new in 1.6.2?

A new tvOS specific framework has been added to allow inspection of tvOS projects both in the simulator and on an Apple TV device.
A new podspec has been created for the tvOS library. Add “Reveal-tvOS-SDK” to your Podfile and run pod update to include it in your project.
The integration guide has been updated to show how to add the tvOS library.

How to get it

You can download Reveal 1.6.2 directly from our web site here. If you already have a previous version of Reveal installed you can update it by selecting ‘Check for Updates…’ from the Reveal menu.

Feedback

If you have any questions or would like to provide feedback, please head over to our support site and leave a comment.

Inspecting watchOS

Vlas Voloshin — Wed, 04 Nov 2015 00:00:00 +0000

Greetings, Apple Watch tinkerers! Today we’ll cover the ways you can use Reveal to take a peek inside apps running on watchOS 2 – made by you or Apple – and see how they tick.

Let’s quickly review the moving parts of a WatchKit app:

WatchKit Extension contains code that developers write and debug.
Watch App is a wrapper that contains the Extension and most of the resources used to construct the UI, like Storyboards and graphical assets. It also contains code that communicates with the Extension and renders the app’s UI as a UIKit view hierarchy.

As of watchOS 2, these two parts run in separate sandboxes right on the watch, but developers still have no control over the Watch App counterpart. This makes it difficult to inspect an application’s user interface, since the extension doesn’t manipulate the objects rendered on screen directly. WatchKit applications don’t “own” their UI in the way iOS apps do, instead they use WKInterfaceObject instances, which provide a “write-only” proxy interface. Due to sandboxing, it’s currently impossible to inspect an app that’s running on device without jailbreaking or performing other modifications. Today we will focus on inspecting apps running in the watchOS simulator.

Injecting the Reveal library

To inspect a view hierarchy with Reveal, we need to inject the Reveal library into the process that owns that hierarchy. In our case, we’re not compiling or running the process in Xcode, so we’re limited to Dynamic Loading: a technique similar to what’s described in the Reveal Integration Guide. We’ll start by demonstrating how to use this technique to inspect apps built into the watchOS 2 Simulator, since it’s actually easier than inspecting your own apps.

First, launch Xcode and open a watchOS project. Then open the watchOS simulator and ensure the watch face is visible.

Apple’s own apps do not follow the WatchKit two-process architecture; instead, each app is run in a single process, similar to iOS apps. In order to attach to one of these apps we need to find out the name of the process. This involves some trial and error, but the watch face and the rest of Apple Watch home screen is rendered by a process called Carousel.

Attach the LLDB debugger to the Carousel process using Debug → Attach to Process by PID or Name… menu in Xcode. Type Carousel in PID or Process Name field of the dialog and click Attach.

In a few moments, Carousel will appear in Debug Area toolbar, indicating that the debugger has been successfully attached. Click the Pause button there to pause execution of the process and give you control over it via the debugger’s console. You’ll notice that the watch’s second hand has stopped.

Now we can inject the Reveal dynamic library into the process. Paste this into the Debugger Console and press Return:

expr (Class)NSClassFromString(@"IBARevealLoader") == nil ? (void *)dlopen("/Applications/Reveal.app/Contents/SharedSupport/iOS-Libraries/libReveal.dylib", 0x2) : ((void*)0); [(NSNotificationCenter*)[NSNotificationCenter defaultCenter] postNotificationName:@"IBARevealRequestStart" object:nil];

This command instructs the process to load Reveal’s dynamic library and start the Reveal server, assuming you have Reveal installed at /Applications/Reveal.app. This approach is documented in the Reveal Integration Guide.

Note: Instead of pasting this long command every time you want to manually inject Reveal into a process, you can use an LLDB macro. Check out this blog post to learn more.

Now, click the Continue button in the debugger’s toolbar to allow the process to continue execution. You’ll notice the watch’s second hand moving again. At this point, you can launch Reveal. If you have enabled automatic connection to Simulator, Reveal will connect to Carousel immediately. Otherwise, you can use File → Connect to → Carousel on Apple Watch Simulator menu in Reveal to select it as you would with any other instrumented app.

Carousel has a fairly complex view hierarchy as it also hosts other apps’ UI, similar to the SpringBoard process on iOS. Feel free to explore and experiment with it!

Inspecting your own apps

As we’ve covered previously, third-party WatchKit apps are executed as two processes running in concert: a WatchKit Extension and a Watch App. When you’re running your own WatchKit app in Xcode, the debugger attaches to the Extension, not the App. In order to inspect the view hierarchy, we’ll need to attach to the App counterpart manually.

Start by opening your WatchKit project and running it in the Watch Simulator.

This time, instead of using Debug → Attach to Process by PID or Name… dialog, we’ll use Debug → Attach to Process → … menu. You’ll see two processes in the Likely Targets section of the list: an App and an Extension. Select the WatchKit App.

This will attach the debugger to the WatchKit App and allow you to perform the same steps as covered previously to inject the Reveal dynamic library into it: click Pause, paste the injection command, click Continue. You’ll then be able to select <YourAppName> WatchKit App on Apple Watch Simulator in Reveal.

It’s actually possible to edit most UIKit properties of your WatchKit app’s view hierarchy as you would expect from an iOS app – and see these changes live in Simulator. Of course, you won’t be able to reproduce some of these changes from your WatchKit Extension, but it can still be useful to try out, for example, different font sizes or colours. Keep in mind that WatchKit apps don’t use Auto Layout, so changing a label’s font size won’t change its bounds automatically.

Conclusions

Using the LLDB debugger, it’s possible to inject the Reveal library into watchOS Simulator apps – both built-in and the ones you develop. It currently requires some manual steps, but it’s a great way to experiment and learn, or just to find out how all these cogs and springs bring the Apple Watch user interface to life.

Some advanced techniques exist which produce similar results on actual Apple Watch hardware (for example, patching the Watch App stub used by Xcode for your apps), but we’ll leave that as an exercise for you, dear reader.

Sample Snapshot Documents

We’ve included a variety of snapshots below for you to play with. You’ll need Reveal 1.6 or greater to view these files.

Reveal常用技巧

Long Sun — Thu, 22 Oct 2015 00:00:00 +0000

以下基于Reveal 1.6。

用于快速上手的内置应用

刚刚下载Reveal，啥都还没配置呢，想先随便玩玩看，怎么办？

我们花了不少时间开发这个复杂程度类似与实际场景的Sample应用──Soundstagram（音频分享版的Instagram， ¯\_(ツ)_/¯），就是为了让大家能最快速地上手Reveal，尝试它的各种强大功能。

在 Help 菜单项中，点击 Inspect Sample App ，稍微等一会，Reveal会将Soundstagram应用拷贝到你的iPhone模拟器中，并自动打开应用，自动连上开始Debug。一键搞定，你马上就会看到活的Reveal了。

集成

关于具体如何将Reveal集成到App中的各种方法，请参考官方的中文文档，当中有非（guo）常（yu）详细的介绍。

这里就啰嗦一句，对于专业的iOS工程师（可是连我们的设计师也毫不留情地采用了这种配置），我个人强烈推荐通过Xcode中加断点的方式集成Reveal。一次配置，终生受益，无论到哪个项目，简直太方便了，有木有。（小缺陷，当你禁用断点时或者不用Xcode而用Appcode开发时，这个方式是不管用的。）

常用的快捷键

这不是一个详细全面的快捷键列表，我只说点特别常用的。

快捷键	作用
（在iPhone模拟器中按）⌘ ⇧ r	切换到Reveal并刷新
⌘ → 和 ⌘ ←	在View的选择历史中，前进后退
⌘ ⌥ 滚动	3D视图时增大/缩小每层视图的间距
⌘ 4 和 ⌘ 5	在2D和3D视图间切换
⌘ r	刷新（强迫症必备）

_重度快捷键用户，请到 Help -> Keyboard Shortcuts 中查看详细列表。

自动布局的调试

自动布局（Auto Layout）已经越来越普遍的深入千家万户了，随着iOS设备分辨率的多(sui)样(pian)化，自动布局已慢慢成为了标准配置。

你可能经常看到控制台输出类似这样的内容，而不知何处下手：

{% highlight objective-c %} Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don’t want. Try this: (1) look at each constraint and try to figure out which you don’t expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you’re seeing NSAutoresizingMaskLayoutConstraints that you don’t understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) ( “<NSLayoutConstraint:0x7fc82d3e18a0 H:[UIView:0x7fc82aba1210(768)]>”, “<NSLayoutConstraint:0x7fc82d6369e0 H:[UIView:0x7fc82aba1210]-(0)-| (Names: ‘|’:UIView:0x7fc82d6b9f80 )>”, “<NSLayoutConstraint:0x7fc82d636a30 H:|-(0)-[UIView:0x7fc82aba1210] (Names: ‘|’:UIView:0x7fc82d6b9f80 )>”, “<NSLayoutConstraint:0x7fc82d3e7fd0 ‘UIView-Encapsulated-Layout-Width’ H:[UIView:0x7fc82d6b9f80(50)]>” )

Will attempt to recover by breaking constraint <NSLayoutConstraint:0x7fc82d3e18a0 H:[UIView:0x7fc82aba1210(768)]>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful. {% endhighlight %}
除了我们在编码时自己绑定到View上的约束条件(Constraints)之外，其实许多UIKit控件还会被隐式地地设置上一些约束，而这些可能会带来一些意外的布局结果。

也许曾经你需要使用LLDB来一点点调试Auto Layouts：

(lldb) po 0x7731880
$0 = 124983424 <UIView: 0x7731880; frame = (90 -50; 80 100);
layer = <CALayer: 0x7731450>>
(lldb) po [0x7731880 superview]
$2 = 0x07730fe0 <UIView: 0x7730fe0; frame = (32 128; 259 604);
layer = <CALayer: 0x7731150>>
(lldb) po [[0x7731880 superview] recursiveDescription]
$3 = 0x07117ac0 <UIView: 0x7730fe0; frame = (32 128; 259 604); layer = <CALayer: 0x7731150>>
| <UIView: 0x7731880; frame = (90 -50; 80 100); layer = <CALayer: 0x7731450>>
| <UIView: 0x7731aa0; frame = (90 101; 80 100); layer = <CALayer: 0x7731c60>>

有了Reveal，这就方便多了。Reveal对视图上的约束条件提供了相当丰富的检视与实时修改功能，具体看下面这张图，再自己摸索一下就好了。

实时修改View属性

Reveal不仅仅只是查看各种属性的工具，也支持实时的修改一些属性。如下图中的大部份属性，你都可以实时的在模拟器中看到修改后的效果。这省去了过去总是要修改代码，重新编译运行这个漫长的反馈流程。在和设计师一起尝试各种显示效果时，这个功能特别高效。

Snapshot

Reveal还具有保存现场的功能（快捷键，⌘ s），它将保存应用的截图，所有View的层级结构和具体属性信息。换句话说，下次你打开这个Snapshot文件时，不需要启动iOS应用，也可以看到所有的视图信息。

一些可能的使用场景：你可以在描述布局问题时，给其他团队成员分享Snapshot；还可以对不同大小的模拟器分别保存Snapshot，然后再做详细地比较，找出问题所在。

Reveal 1.6

Sean Woodhouse — Thu, 15 Oct 2015 00:00:00 +0000

The team at Itty Bitty Apps is excited to announce the release of Reveal 1.6. This release delivers a bunch of new features and adds support for OS X 10.11, iOS 9 and tvOS. Here’s the rundown…

Multi-window support

You can now inspect more than one app at the same time. Using multiple windows you can compare snapshots of your application side by side to see how the structure of the view hierarchy has changed over time or across device types.

Snapshots can be saved and loaded, allowing you to use them as a point-in-time reference during development or to share for educational and problem solving purposes.

Loading a snapshot does not require the iOS application to be running in the simulator or device. Snapshots can be opened by any other Reveal 1.6 user.

We even added Quick Look support so you can easily find the snapshot you’re looking for.

Auto-connect

Reveal can automatically connect to instrumented apps running in the simulator. One less click we knew you’d appreciate.

Bitcode

The Reveal 1.6 library includes a bitcode slice which fixes linking problems under Xcode 7.

Platform support

Reveal now supports inspecting iOS 9 applications and includes custom editors for a number of new properties. You can also inspect tvOS applications seamlessly.

We’ll be publishing a blog post shortly which will detail how to inspect Apple Watch applications. The process is a little convoluted, but we know many of you will be interested to see how things work under the covers.

The Reveal desktop application now requires OS X 10.10 “Yosemite” to run and we’ve also bumped the minimum iOS version it’ll inspect to iOS 7.

If you need to inspect iOS 6 applications you can download Reveal 1.5.1 here.

Bug fixes

Reveal 1.6 fixes a number of visual artefacts when running on OS X 10.11 “El Capitan” and includes many bug fixes and stability improvements.

How to get it

You can download Reveal 1.6 directly from our web site here. If you already have a previous version of Reveal installed you can update it by selecting ‘Check for Updates…’ from the Reveal menu.

Feedback

If you have any questions or would like to provide feedback, please head over to our support site and leave a comment.

Exploring accessibility

Giovanni Lodi — Tue, 06 Oct 2015 00:00:00 +0000

Making your app accessible for the visually impaired is not only a good service to humanity, but also brings the quality and attention to detail of your product to the next level.

UIKit provides great support for implementing accessibility and Reveal makes it easy to debug by allowing you to inspect this information at runtime.

The Identity Inspector

The Identity Inspector displays a host of information related to the selected view including the restoration identifier, class, memory address, and the associated View Controller.

It also displays a number of properties from the UIAccessibility protocol that you might find useful when making your application accessible or when writing automated tests.

Pro Tip: Although some of the properties are editable, changes made through the Identity Inspector may not persist if the view has implemented the UIAccessibility protocol methods to return hard-coded values.

Let’s have a look at the accessibility information displayed in the Identity Inspector

Enabled

Indicates whether the view has accessibility enabled and responds to user interaction. If the view doesn’t have accessibility enabled then VoiceOver won’t read it to the user, nor allow interaction with it by double-tapping.

According to the Apple documentation, the only use case to not set this to true is: “[…] a view that merely serves as a container for other items that should be accessible. Such a view should implement the UIAccessibilityContainer protocol and set this property to NO.”

Corresponds to isAccessibilityElement. Pro Tip: when you hover over an inspector field name a tooltip will display the corresponding UIKit property name.

Should Group Children

By default VoiceOver, Apple’s gesture based screen reader, will scan and read the UI left to right, top to bottom, regardless of the subviews hierarchy. This default mode might not be the best way to present certain kinds of content. Information could be organised in columns, for example, and the best way to read it would be column after column. In such cases setting the value of shouldGroupAccessibilityChildren to true will make VoiceOver group together the elements in the receiver, and read all of them before moving to the next element in the normal order.

In the example above the container views are not set to group their children, and VoiceOver will read “1, 3, 2, 4”.

With shouldGroupAccessibilityChildren set to true VoiceOver will read “1, 2, 3, 4” as intended.

Note that if we had implemented the layout above using two instances of UICollectionView we would have had the desired VoiceOver behaviour out of the box.

Traits

Corresponds to the accessibilityTraits property and contains a mask that best characterizes the accessibility element, giving VoiceOver the context needed to read it properly.

Activation Point

The activation point of a view is the point, expressed in screen coordinates, to which VoiceOver will send a touch event when the view is double-tapped.

Corresponds to the accessibilityActivationPoint property.

Frame

The frame of the accessibility element, in screen coordinates, as set in the accessibilityFrame property.

All UIView subclasses have this value set for them automatically but the value can be altered by overriding accessibilityFrame in a subclass.

Pro Tip: don’t confuse this property with the frame of the view. It is set in screen coordinates and may not necessarily map to the position of the view’s frame.

Label

The accessibilityLabel property is a short, localized label that succinctly identifies the element.

Value

The default value for this property is nil unless the receiver is a UIControl subclass. In this case it represents the value of the control as a localized string if it differs from the label.

Hint

For interactive elements the accessibility hint provides a way to briefly describe the expected result of the user interacting with the element.

It corresponds to the accessibilityHint property.

Identifier

Unlike the rest of the accessibility information in the Identity Inspector, the identifier is not part of the UIAccessibility protocol. It corresponds to the accessibilityIdentifier property of the UIAccessibilityIdentification protocol.

This value is meant to be used to uniquely identify views in the context of UI tests, and is never read by VoiceOver.

Language

The language in which to speak the accessibility element’s label, value, and hint. Most of the time this field will be empty since nil is the default value and correspond to the user’s current language settings.

This value, corresponding to accessibilityViewIsModal, represents whether VoiceOver should ignore the elements within views that are siblings of the receiver.

This can be useful when displaying custom views that are presented modally.

Elements Hidden

This value, corresponding to accessibilityElementsHidden, represents whether the accessibility elements contained within the view should be ignored by VoiceOver.

Apple’s documentation states “you might also use this property to hide a transient view that VoiceOver users don’t need to notice. For example, VoiceOver doesn’t need to describe the translucent view that appears when users adjust the volume on their devices, because the aural feedback of this action is sufficient.”

Pro Tip: Turn on the Accessibility Inspector

Sometimes you might not see all the expected accessibility information appear in the Identity Inspector. This can happen because the information is only vended by the iOS application once the classes that implement accessibility have been dynamically loaded at runtime. You can see proof of this by looking at the Xcode 7 UI test execution output. Before any interaction starts the test runner says Waiting for accessibility to load.

To enable accessibility in the simulator you need to turn on the Accessibility Inspector.

Go to the Settings app. You can background a running app by pressing Cmd + H, which simulates pressing on the Home button.
Select the General options.
Select Accessibility.
Turn the Accessibility Inspector switch on.
You should now see the Accessibility Inspector window and the accessibility information for applications you inspect with Reveal should now be visible in the Identity Inspector.

While we have shown how Reveal can help inspect the accessibility properties of your views, we’d love to hear how you’re using these features when it comes to implementing accessibility and writing automated tests. You can tweet us @reveal_app or email us your feedback.

Revealed: Soundproof

Sean Woodhouse — Fri, 29 May 2015 00:00:00 +0000

At NSConference 7 I was fortunate to meet Marc Palmer, an avid Reveal user and developer of Soundproof, a practice app for musicians. As I poured over the UI and we discussed the implementation, it became clear that this would be a great app to feature on Revealed.

Marc, can you tell me a little bit about yourself and Soundproof?

Marc: I’ve been a programmer since I was 11, so that’s around 31 years ago now. I left school at 16 because I hated it, and persuaded my dad to employee me at his small software company in the music industry. At that time I was in the UK Atari ST demo scene coding graphics in 68000 assembly. It was much more interesting than working on DOS and early Windows 3.1 apps, although I loved Turbo/Object Pascal. After some Borland C++ pain I moved to Java web apps, Java 2 ME embedded apps, Java mobile phone games and then fell back to web apps for big brands and a lot of Grails open source development.

When the iPhone SDK came out I started playing with it and studying this “alien" Objective-C stuff but didn’t make the switch to iOS commercially until 2013. That year I had been working on our first app with Adam in my spare time, which is still unreleased, but then had to have emergency spinal surgery to avoid becoming paralysed. This was one of those times that really focuses the mind, and I became resolved to convert to full time commercial iOS/Mac work as soon as possible. Two days after surgery I was hacking iOS at home in bed; the miracle of modern medicine.

Soundproof was the first in-house app we built. To fill a need we had as musicians, it is all about effortlessly looping the music you practice. There is no “repeat off” mode. Swiping between tracks is infinite, the set list just cycles around. The controls are deliberately oversized and easy to hit at arm’s length. We wanted everyone to find it easier to practice using the app, not more fiddly, where you try to hit a little button while holding a plectrum, cello bow, or drumsticks. We also have a cool count-in and text-to-speech track announcements you can toggle without interrupting your flow.

Plus, we also needed to get an app in the store to prove ourselves commercially in the iOS contracting market. With one big unreleased app still in development we needed to get something in the App Store quickly and I foolishly thought Soundproof would be a quick 2-3 week project. It turned out that we are incapable of releasing something half-baked, so we iterated… and iterated…

Who is the app aimed at - what’s the target audience?

Marc: Soundproof is for anybody who needs to learn by playing, singing, or listening along with audio. Many of us practice by just playing along with tracks. This is who we want to reach. People who want to improve their skills and maybe need help to practice more by removing the friction. I play guitar but have been learning drums for some time. When I practice I put the phone in my pocket with a loop region set, headphones on and just jam along until I can’t any more. At the end, it tells me how much time I spent doing that practice, and how much I’ve done that week.

My daughters use it too. My 12 year old puts the phone on her music stand and plays along with pieces and recordings of scales, and my 9 year old props it on the music stand of a piano keyboard and taps out tunes while it loops a little tune she’s trying to learn.

How long have you been working on it, and how big is your team?

Marc: There are two of us at Montana Floss Co., Adam Hinks and myself. We spent about three months getting Soundproof to 1.0. The hardest part of building it was the time it took us to get a track selector, set list, and player UI structure that we were happy with. When you look at the built-in Music app for example, it is pretty much upside down for what you want when you practice. When you open the app, you always want to be in the player where you left off. We built, threw away and rebuilt that whole UI several times. Sometimes things can look great in wireframes but when you actually try to use it…

Did you work with a designer?

Marc: Oh yes. I wouldn’t work without a designer, and I was lucky enough to meet Adam, a great local brand and visual designer, a couple of years ago. We get on because we both like Metal music, are very fussy, and hanker for simplicity. I am pretty good at iterating on UX problems but I can’t even draw a square with a pencil. Plus I can display shockingly bad taste at times.

So Adam and I work together on all the UX and product design. It works really well, especially as we now run a small co-working space together here in the UK and get to help each other all the time.

Did you have any inspiration for the app?

Marc: Not so much direct inspiration from other music apps. I am a big fan of classic iOS apps like Tweetbot, Day One, and Writer.Pro — in terms of general polish and simplicity. I was a user of Capo on Mac long ago, and also used it a little on iOS for working out riffs.

We are so lucky to have great apps like Capo and AnyTune Pro for high quality slow-down and other fancy features, but Soundproof is all about the player mechanic and the specifics of repeat practicing rather than working out the minutiae of solos. It is a great complement to tools like that.

If anything the inspiration for Soundproof came more from the old 4-track recorders you could get when we were kids; with buttons to set and reset in/out loop points. We think of our iOS apps as tactile, almost mechanical devices. We want everything to make some kind of kinetic sense. We also don’t want an audio waveform display. We want people who are learning to use their ears more and get a feel for the structure of tracks. It is opinionated software.

The UI is very clean. It’s custom, but works well with the platform. Do you think iOS 7 & 8 have made it easier for developers to design for the platform?

Marc: Perhaps, but not for me. My design skills are so lacking — and I’m also very lazy about it. Get someone who knows what they are doing rather than labouring over it yourself. It has, on the other hand, made it easier (but not easy) to find good designers, as they don’t also have to have photo-realistic texturing skills. Adam is certainly very keen on the flat design, as he loves print. The iOS 7 & 8 styling is much closer to what he likes.

What was the most complicated UI element in the app to build?

Marc: There were a couple of tricky things actually. The zooming time display and the time position slider were pretty hard to make. As an example, the slider morphs to expand the loop region full width when you enter loop mode. As ever with good iOS apps, there’s a lot of detail that isn’t immediately noticeable, and this is the stuff that takes time.

When did you find Reveal useful and how did you use it?

Marc: I started using Reveal back in 2013 when I was working on that first app we still haven’t released yet. In Soundproof I used it to solve the classic “where the hell is my view” problem, as well as the tricky controls like the time slider which involve multi-layered sub-controls that cross fade and change bounds to create the transition effect. Also the volume control and its handling of the AirPlay button appearing and disappearing when external outputs become available — frankly all of it. The drop-down stats bar in the app was also fiddly, as you’ll know if you’ve done something similar, so being able to see its positioning and verify its bounds for clipping was invaluable.

Oh, and our infinitely swipeable track selector is a UICollectionView with some trickery to add false items at each end of the scroll range. Viewing what items were offscreen in that case in Reveal was great. We’re 100% Auto Layout and oh how we wish we’d had that in Reveal when we did the app!

We also used it a lot to tweak colours, sizes and positions, and to debug retina stroke pixel alignment issues in realtime. Modifying properties on the fly and seeing the results immediately on the device was so useful. We tweaked until it was right and then I wrote the values down and carried them over to the source. Things like getting the pixel alignment of custom background images on a UISlider were very challenging because of some weird undocumented iOS behaviours and insets. Without Reveal it would have been almost impossible to identify these.

I like how when you tap the scrubber the time zooms up and the rest of the UI fades away. Can you describe how you achieved that?

Marc: I’m glad you like it. I’ll try to explain it the best I can. It took so much tuning, you wouldn’t believe. The user experience we wanted here was based on the fact that while you are scrubbing the track at arm’s length with an instrument in your other hand, no other controls matter. There are a few things going on at once with it. The time display label has to move up the screen from its position on the time slider to where the Play button is, getting much larger as it does so. At the same time we fade in a full screen dark blurred image view that sits on top of everything but the time label and the slider in the Z-order, so the slider and time appear to “push through” the blur. It’s a nice bit of sleight-of-hand. This was developed pre-UIVisualEffectView.

The tricky part is that if you use a scale transform to zoom a UILabel you’ll get pixellated text, which obviously won’t do. So when you start dragging the slider we instantly swap the font on the UILabel for the much bigger font we use in the final top position, and we counteract the change in size by applying an appropriate scale transform to the label, to shrink it to the same size as the original small font. There’s a slight pixel discrepancy here in the text rendering but you don’t notice it, its so fast.

Anyway, with the pixellation solved, we can zoom from the shrunken large version of the font up to an identity scale transform in the final position where the Play button normally is (yes, we are animating constraints). When you release the slider, we reverse most of this — we keep the big font until it drops down to the lower position in the slider, and then swap the font and scale transform back out to the originals. If you look closely you can sometimes see this change happen at the end — we should put a crossfade on that! Of course we are applying some spring velocity to the movement of the label too but only the tiniest amount. Adam and I fiddle for ages with that stuff as we never want it to be obvious, but you do want it to be at least noticeable in terms of feel.

Funnily enough after we launched Soundproof we noticed that the Soundcloud app added a similar time animation when scrubbing, but without zooming the text or fading out the rest of the UI. We didn’t copy it — and of course like ours more. It has the Jony Ive-ish “fiddle factor” which we intentionally build into everything we do.

What’s next for Soundproof?

Marc: We have a 1.1 already in the pipeline with some nice feature additions, including more ways to get audio into the app, i.e. not just from the Music Library. We’ve also got more slow down options, which has been a frequent request from users. We’re not a slow-downer like Capo or AnyTune and never will be, but we can add more Soundproof-style options. Also, Watch support is coming…

We have big plans beyond this of course, but… “Montana Floss Co. does not discuss future products” :)

Constraints & Transformations

Vlas Voloshin — Fri, 08 May 2015 00:00:00 +0000

Building frameworks is hard, we all know that. It’s even harder when you’re building and maintaining a behemoth like UIKit and you have to make sure client code doesn’t break when a new version of your framework is released. Backward compatibility allows existing apps to keep functioning on newer versions of iOS, even if they are built for an older version. However, sometimes implementing new features with backward compatibility means introducing inconsistent behaviour between different versions of the framework.

The Problem

Prior to the release of iOS 8, mixing Auto Layout with view affine transformations was a shady business: some configurations just didn’t work as expected, so it was mostly avoided or worked around (this Stack Overflow question on the topic has been quite popular). But soon after iOS 8 was released it became apparent that one of the many changes Apple introduced was how Auto Layout and transformations interact. To illustrate, here are two screenshots of the same app running on iOS 7 and iOS 8:

Notice that on iOS 7, views in the left column are misplaced, while on iOS 8 they are positioned as expected.

This app has three rows of transformed views: one for translation, one for rotation and one for scaling. Transformed views in the left column are laid out using Auto Layout, while transformed views in the right column are positioned manually by setting the center property. The transforms themselves are the same across columns. There are also untransformed grey views that serve as “anchors” for the transformed views. Views in the left column are connected via Top and Leading constraints to their “anchor” views (though using Bottom, Trailing, Left or Right attributes would have similar results). Notice that on iOS 7, views in the left column are misplaced (red), while on iOS 8 they are positioned as expected (green). The sample app is available on GitHub.

The behaviour of misplaced views is present when running iOS 7 or older, or when linking against iOS 7 SDK. Clearly, this looks like a fix introduced in iOS 8 with backward compatibility for older apps. What exactly is happening, and why?

Investigation

For the purposes of debugging this behaviour, we’ll focus on translation, since it’s the simplest example of the three. First, let’s launch Reveal to take a quick look at the view hierarchy and attributes. Here’s how it looks on iOS 7:

Notice that the red view is visually offset by (-10, 10) from its grey “anchor” view, while the green view is correctly offset by (-20, 20), which corresponds to its transform matrix. With the red view selected (a), you can also see that its alignment rect is misplaced (b), while for the green view (c) it correctly matches its “anchor” view (d).

Let’s take a look at the same app running on iOS 8:

The views are now aligned, and all alignment rectangles match their “anchor” views. Clearly Auto Layout behaviour has changed: center values of constraint-positioned views are not the same between iOS 7 and iOS 8.

Diving Deeper

As a starting point in debugging this behaviour we’ll determine what alters the position of a view when using Auto Layout, as this appears to have changed between iOS 7 and iOS 8.

We can do this by using the same sample app and overriding the setFrame: and setCenter: instance methods in the GradientView class. By placing breakpoints in these methods we can see that the overridden setFrame: method is not called by UIKit at all during layout on iOS 7 or iOS 8. Only the setCenter: method is called to update the view’s position. This makes sense when dealing with transformed views, since the frame property cannot be used reliably on views with a non-identity transformation applied:

If the transform property is not the identity transform, the value of this property is undefined and therefore should be ignored. – UIView Class Reference

The frame property of a view is actually calculated by the underlying CALayer as a derivative of the layer’s bounds, anchorPoint, position and transform properties in the parent layer’s coordinate space.

The stack trace leading to the setCenter: call during a layout pass reveals internal UIKit methods used to apply the layout:

With the help of Hopper and using the _applyISEngineLayoutValues method as a starting point, it is possible to disassemble UIKit and analyse its implementation of Auto Layout. It appears to have changed quite significantly in iOS 8, with a private function __UILayoutEngineSolutionIsInRationalEdges now determining the “layout engine solution style” used throughout UIKit. “Layout engine” here refers to NSISLayoutEngine: a private class in Foundation framework that implements the iterative linear arithmetic constraint solver, the heart of Auto Layout. The function itself returns YES if the app is linked against iOS 8 SDK, and NO otherwise, thus enabling backward compatibility with apps that haven’t been updated for iOS 8.

Some of the methods that provide legacy behaviour depending on the layout solution style include:

-[UIView setTransform:]
-[UIView setBounds:]
-[UIScrollView setContentInset:]
-[UIScrollView _nsis_contentSize]
-[UIWindow _initializeLayoutEngine]
-[UIView _updateLayoutEngineHostConstraints]
-[UIView _preferredLayoutEngineToUserScalingCoefficients]
… and more.

Critically, the layout solution style also determines which method is used to convert the solution from the solver into the resulting view geometry:

_nsis_origin:bounds:inEngine: method is used with “legacy” solution style. Its implementation performs geometry calculations that take view’s transform property into account, which corresponds to the behaviour we can see on iOS 7.
_nsis_center:bounds:inEngine: method is used with “modern” solution style. Its implementation doesn’t use view’s transform matrix, so the results of its calculations are unaffected by the applied transformations.

Conclusions

As it turns out, the observed differences in the behaviour of Auto Layout between iOS 7 and iOS 8 are caused by a deliberate change in UIKit. View transformations no longer seem to factor into Auto Layout’s calculations.

So what does this mean in practice?

If your app:

Links against the iOS 8.0 SDK or later, and
Supports iOS 7, and
Uses Auto Layout on views with non-identity transforms

You may have to resort to one of the following workarounds:

If you’re only using rotation and/or scaling transformations, try using Centre X/Centre Y constraints instead of Top/Bottom/Left/Right/Trailing/Leading constraints: if the transformed view is laid out by its centre, results tend to be correct.
Place any transformed views inside a container view, and:
- Constrain the container view rather than the transformed view.
- The transformed view could be laid out in the container either manually, or using Centre X and Centre Y constraints. Using Equal Width/Height constraints between the transformed view and container view, however, will not give expected results in this case.
Do not use explicit constraints for these views: use autoresizing masks. Fall back to the behaviour provided by UIKit for views with translatesAutoresizingMaskIntoConstraints property being YES. You will probably need to configure the autoresizingMask property of your views in code.

If your app doesn’t need to support iOS 7, you’re in luck! Auto Layout’s behaviour in iOS 8 and higher is more obvious and correct.

I do wish that Apple had been more transparent when introducing these changes: this would have allowed developers to make more informed decisions without going through trial, error and disassembly. It also would have made it easier to update apps to support the latest versions of the system frameworks.

A new home

Sean Woodhouse — Thu, 07 May 2015 00:00:00 +0000

For the past year and a half we’ve been posting Itty Bitty Apps and Reveal related content to our Itty Bitty Labs blog. After releasing Reveal 1.5 we felt it was high time Reveal had a dedicated blog, so here it is!

We’ll deep dive in to Reveal best practices, highlight new features, investigate interesting aspects of iOS and keep you up to date with our plans. We’ll also be publishing a new series of articles called Revealed, where we interview developers and find out their tricks of the trade for creating amazing, immersive user experiences on iOS.

In the mean time, Vlas kicks off with an investigation in to the behaviour of Auto Layout constraints and transformations across iOS 7 & 8.

Enjoy!

Reveal | News

Cyber Monday Sale

What’s been happening?

Hello, Mantel

Introducing Insights, and new pricing

Introducing Insights

New Pricing

Introducing the Accessibility Workspace

Inspect. Experience. Verify.

Accessibility Workspace Features

Instant Insight

SwiftUI

Effortless Sharing

Detailed Inspectors

Capable Navigator

Composable Canvas

Visual VoiceOver

Voice Control

WCAG 2.1 Contrast Checks

A First Step

Redesign, Revealed

Interface-Off

The Outline

The Toolbar

The Canvas

The Icons

The Connections Dialog

More UI Updates

Thinking Outside the App Icon Box

Explorations

Modelling in 3D

Reveal’s Next Chapter

Free Tutorial: Debugging UIKit Views with Reveal

Reveal 29: Huge Sur

What’s new in Reveal v29?

Recent improvements

Coming soon

It’s not a popularity contest, but…

What’s next?

Reveal 25 Announcement

A Lovely Gesture

New Features

Bug Fixes

Minimum System Requirements

Support

Our Darkest Release Yet!

Features

Fixes

Minimum System Requirements

Support

Inspector Updates

Inspectors

Layout Constraints

Menus

Miscellaneous Improvements

Bugs Fixed

Minimum System Requirements

Support

Inspecting Xcode Playgrounds Live Views

Integration

How does it work?

Caveats and limitations

Like parfait, it has layers! 🍰

Layer Inspection Support (Beta)

Known issues

Layout Constraints Inspection Improvements

Bugs Fixed

Minimum System Requirements

Support

This one goes all the way to eleven

Minimum System Requirements

Support

Layout Guides and the Touch Bar

Auto Layout Guides

Touch Bar Support

Bug Fixes

Minimum System Requirements

Support

Introduction to Auto Layout Guides

UIKit support

`reveal load`

`reveal start`

`reveal stop`

`reveal status`