Forem: Sentry

App store rankings hate slow apps - mobile vitals can help you fix them

pry0rity — Tue, 04 Mar 2025 20:27:42 +0000

Mobile devs know the struggle. Small regressions can cause big issues in production, and fixing them isn't as easy as pushing a quick patch. Unlike a web app, shipping fixes for apps means navigating app store approvals, and often hopping on meetings with customers to debug because mobile issues can be so challenging to recreate.

Catching these issues before the 1-star reviews roll in is crucial. Luckily, Sentry just made it easier than ever.

Mobile Vitals - our latest addition to the Insights feature - highlights your slowest app starts, screen loads, and renders, so you can quickly tackle frozen or laggy interactions before users rage-quit. Whether you're building with React Native, Flutter, Android, or iOS, let's dive into what you can do with it.

(P.S. We first wrote about mobile vitals years ago—if you're curious about how this new tool works under the hood, it's a good read.)

What does Mobile Vitals track?

1: App Start Performance

You’re doom-scrolling Instagram recipes and suddenly a great ad for a calorie counting app pops up. You download it out of curiosity, and for some reason, it takes 20 seconds to boot up the first time, and 10 seconds every time after that. What are you gonna do - keep forcing yourself to go through that every time you pop another Oreo, or just go back to the scale?

Sentry tracks App Start performance to help you prevent your users from burning unnecessary calories uninstalling your apps out of frustration. We consider two key metrics here: cold starts & warm starts.

Cold starts: You never get a second chance at a first impression. Sentry tracks cold starts independently so you can make sure your latest patch doesn’t crush your first impressions.
Warm starts: Memory management on iOS & Android is complicated and often suspends some tasks while keeping your application ‘warm’ in the background. Pulling up your application from the recent apps selector should be lightning-fast, too.

It’s not just the top-level metric that matters. For warm starts, Sentry auto-instruments iOS and Android apps with great granular detail. With iOS for instance, you can see pre-runtime, UIKit, frame renders and a bunch of other native tasks independently and work to fix what’s bottlenecking your app load performance.

Clicking into a screen shows you an overview for all your most recent app loads leading up to that screen, which you can then drill into and see what sorts of tasks may be bottlenecking.

2: Screen Load Performance

If it takes 5 seconds every time you want to load the comments page, nobody’s going to leave comments. It’s really that simple.

Sentry helps you cut down on UX bloat by tracking TTID and TTFD for every screen load:

Time to Initial Display (TTID): This tracks the time it takes for a screen to produce its first frame. Often, that’s just a background or a wall of text, but for a user, this is an important metric as it makes the app ‘feel’ fast. Sentry tracks this automatically by default.
Time to Full Display (TTFD): More importantly is the time it takes for a screen to be fully loaded and functional. This is similar to the LCP core web vital on browser loads. TTFD can include content that’s lazy- or async-loaded after getting its first content, making it a more useful metric for a lot of your mobile screens. This isn’t enabled by default, but it’s super easy to set up.

Just like with App Starts, you can drill into Screen Loads by clicking into a screen and drilling into the full trace of the user session, or even dive into a mobile CPU profile.

Check out a 10-second interactive video here.

3: Screen Rendering Performance

Your favorite solitaire clone ships a new patch, and suddenly you find your framerate dropping like a brick. You just got your phone a few years ago… is it time to upgrade? Nah, you’ll just throw out a 1-star review, uninstall, and go right back to Wordle.

We surface 3 key screen rendering performance metrics by default:

Slow frames: any frame that takes longer than a framecycle to render (16.7ms, or 1/60th of a second at 60hz) is considered ‘slow’, causing laggy UI responses and jittery animations. Sentry calculates the % of slow frames for each screen, so you can quickly find the conditions that lead to laggy or dropped frames.
Frozen frames: Even worse is a frame that’s stuck for a longer period of time. . Sentry considered any frame render that takes >700ms ‘frozen’.
Frame delay: This is the total ‘hang’ time accumulated on a screen due to slow & frozen frames.

In our own testing, we found these 3 metrics super useful for debugging the clunkiest-feeling parts of our mobile application. By combining these with mobile session replays, we were able to quickly recreate conditions that led to clunkiness for our users and get down to the brass tax.

Check out a 10-second interactive video here.

Why does this matter?

We’re not narcissistic enough to claim that this is as impactful as Core Web Vitals was for the internet - but it’s a start. For mobile apps, it’s extremely difficult to know what to track, let alone how to track it. So, our mobile SDK team took the step to create an awesome new way to get your mobile application performance on track by monitoring a few vital metrics simply & scalably.

More than just monitoring, Mobile Vitals gives you the why behind slow screens—not just the when. Every insight is backed by a trace, so you can see if the culprit is slow code on your main thread or a deeper issue like sluggish database queries or too complex layouts.

A few of our own, Lazar & Salma, recorded an awesome workshop about how to use Distributed Tracing to debug frontend issues with backend solutions. If you have slow screen loads on your mobile devices but aren’t able to find a root cause on the device itself, this is worth a watch.

In short, Mobile Vitals is a tool to:

Monitor mobile top level performance metrics
Easily identify key areas to improve
Deep dive from a top level metric, to a specific performance issue on a particular screen, to a concrete distributed trace, allowing you to debug and understand an issue across the full-stack
Connect your metrics with session replay and profiling, giving you full insights on what the user was experiencing and which code was running

What numbers do I need to shoot for?

Goodhart’s law - when a metric becomes a target, it ceases to be a good metric - still rings true. That said, Google and Apple both openly state that their app store algorithms prioritize app quality, user engagement, app uninstalls and other key factors that are directly related to app performance. Google in particular recommends cold starts of < 5s, and warm starts of < 2s, but these are just starting points.

Rather than just setting a target, mobile vitals monitoring is useful for objectively assessing the current state of your mobile app, deciding whether you want to try and improve it, and continuously evaluating your vitals metrics to make sure you’re not accidentally shipping a major slowdown.

Credit: xkcd

How do I get started monitoring my mobile vitals?

Most of the Mobile Vitals metrics are instrumented automatically, so as long as you’ve set up the Sentry SDK in your mobile app, you should be good to go! TTFD is the only exception - you’ll need to call the API to let Sentry know when a screen is fully rendered. Here’s the setup for our most popular SDK’s:

If you want to go the extra mile, you can also track custom performance metrics, add custom spans, and attach span attributes that you can use to calculate and monitor span metrics for your most critical user experiences.

If you’re a mobile developer who cares about your user experiences, tracking Mobile Vitals is a great way to gauge how your mobile app releases impact device performance beyond just the top level metrics. Mobile Vitals is available to all paying Sentry customers - just turn it on in your SDK and give it a shot.

Questions? Join our passionate community of mobile devs in the Sentry Discord.

Sentry can’t fix React hydration errors, but it can really help you debug them

Salma Alam-Naylor — Thu, 26 Sep 2024 09:02:11 +0000

Hydration failed because the initial ui does not match what was rendered on the server. Don’t you just ~~love~~ hate it when that happens?

If you’re building server-rendered pages with Next.js or any React-based meta-framework, you know hydration errors suck and are usually difficult to debug. Hydration in React is the process that happens when a React application that was rendered as HTML on the server is made interactive in the browser. Hydration errors happen when the markup rendered by React on the client doesn’t match the initial server-rendered HTML, or when invalid HTML was sent by the server, and React couldn’t fix it. Sometimes this is unavoidable, for example, with dates and localization. You can suppress errors for these unavoidable differences in your React code, but most hydration errors would indicate that you’ve got some bugs in your app.

This article is not about how to fix hydration errors but how to debug them using Sentry. When hydration errors happen in development, your JavaScript framework of choice will usually show you a large error message with some details about the code that triggered the error. However, hydration errors aren’t usually visible or obvious in production, and your average real-world users probably won’t be able to provide useful screenshots with error reports (and probably won’t think to look in the browser console for errors). What’s more, the automatic error issue created by Sentry won’t be very useful, either.

But wait, Session Replay has a superpower

If you’re using Sentry’s Session Replay to get reproductions of user sessions when a user triggers a hydration error:

Sentry will automatically create a specific Hydration Error Issue for you (for free!),
group all the same errors together,
capture both the server-rendered and client-rendered markup that existed when the error happened,
and show you the diffs in both visual and raw HTML modes.

Just make sure you’re using Sentry’s JavaScript SDK, version 7.87.0 or above, and you’ve got Session Replay enabled to get the good stuff.

Here’s what a grouped Hydration Error looks like in Sentry:

It is named “Hydration Error,” so you can find it easily in the issue list view.
Choose which event to view (recommended, latest, oldest) and navigate between events to compare contextual information.
View a sliding diff between the server and the client (open the diff viewer to also view a side by side visual diff and HTML diff).
Click the “Resolving Hydration Errors” link to get more help on solving hydration errors.

Debugging hydration errors

Given that the standard hydration error message states that the server-rendered HTML did not match the client-rendered HTML, the diff viewer is really helpful in finding those differences. The “Before” view is the server-rendered version, and the “After” view is what React rendered on the client.

What you might notice in this example, however, is that the “Before” and “After” versions look the same visually. When inspecting the HTML diff, we see a blank page rendered on the server and HTML rendered on the client. This isn’t correct. HTML is definitely being rendered on the server; I checked in my browser's network tab.

The real issue in the code causing the hydration error is not that the server-rendered and client-rendered HTML don’t match, it’s that my HTML is invalid (a <p> is contained within a <p>) and React threw an error. This is why hydration errors suck: they don’t always make sense.

So why does there appear to be no HTML rendered on the server according to the diff? Given that React threw a nonsensical hydration error for invalid HTML, Sentry can only make a best-effort guess as to what the problem is. Usually, if one event has a diff that doesn’t make sense, another event may be more helpful. The bottom line is that when React throws a hydration error, there’s a problem that needs fixing. And because React doesn’t tell us the details needed to fix the problem in production, Sentry fills in the blanks on the hydration error diff tools as much as possible so you can better debug the problem.

Does creating hydration error issues and diffs increase my Sentry bill?

No. If you’re already using Session Replay, you get automatic grouped hydration error issues for free. Hydration error issues in Sentry are generated from Replays and their associated data, so have no impact on your error quota, either. Additionally, you’ll also get alerted on hydration errors by default.

Bonus tip: level-up your debugging by unmasking non-sensitive data in replays

If you’re using Session Replay, you might have noticed that it masks all text content with * and blocks all media elements on the client by default, before it is sent to Sentry. In this article, the examples shown in the hydration errors images show text rather than asterisks, due to how the Session Replay SDK was configured.

If you're working on a content-based website that's free of personally identifiable information (PII), you can disable the default text masking and image blocking by configuring the maskAllText and blockAllMedia configuration options in the Session Replay initialization.

Sentry.replayIntegration({
  maskAllText: false,
  blockAllMedia: false,
});

This can be really helpful in debugging fake hydration errors (that are actually invalid HTML errors) like the one demonstrated in this article.
Note: Only use this if your site has no sensitive data or if you've already set up other options for masking or blocking actual sensitive data. Read more about Session Replay privacy configuration on the Sentry docs.

Debuggability is key

Hydration errors in production have always been a bit of a mystery, without any practical way to deal with and debug them. With the Sentry Replay SDK, you now get the HTML diffs and as much context as possible with each hydration error, helping you to debug and fix things faster. And whilst this ultimately helps you as a developer, it benefits everyone else as well: stakeholders, clients, and most importantly — your users. Now, go fix those bugs.

The best way to debug slow web pages

Salma Alam-Naylor — Mon, 01 Jul 2024 14:31:29 +0000

Tools like Page Speed Insights and Google Lighthouse are great for providing advice for front end performance issues. But what these tools can’t do, is evaluate performance across your entire stack of distributed services and applications.

This is why you need tracing from Sentry.

How We Reduced Replay SDK Bundle Size by 35%

Matt — Thu, 16 Nov 2023 18:02:51 +0000

Bundle Size matters - this is something we SDK engineers at Sentry are acutely aware of. In an ideal world, you'd get all the functionality you want with no additional bundle size - oh, wouldn't that be nice? Sadly, in reality any feature we add to the JavaScript SDK results in additional bundle size for the SDK - there is always a trade off to be made.

With Session Replay, this is especially challenging. Session Replay allows you to capture what's going on in a users' browsers, which can help developers debug errors or other problems the user is experiencing. While this can be incredibly helpful, there is also a considerable amount of JavaScript code required to actually make this possible - thus leading to an increased bundle size.

In version 7.73.0 of the JavaScript SDKs, we updated the underlying rrweb package from v1 to v2. While this brought a host of improvements, it also came with a considerable increase in bundle size. This tipped us over the edge to declare a bundle size emergency, and focus on bringing the additional size Session Replay adds to the SDK down as much as possible.

We're very happy to say that our efforts have been successful, and we managed to reduce the minified & gzipped bundle size compared to the rrweb 2.0 baseline by 23% (~19 KB), and by up to 35% (~29 KB) with maximum tree shaking configuration enabled.

Steps we took to reduce bundle size

In order to achieve these bundle size improvements, we took a couple of steps ranging from removing unused code to build time configuration and improved tree shaking:

Made it possible to remove iframe & shadow DOM support via a build-time flag
Removed canvas recording support by default (users can opt-in via a config option, support is coming)
Removed unused code from our rrweb fork
Removed unused code in Session Replay itself
Made it possible to remove the included compression worker in favor of hosting it yourself
Moved to a different compression library with a smaller footprint

Primer: rrweb

rrweb is the underlying tool we use to make the recordings for Session Replay. While we try to contribute to the main rrweb repository as much as possible, there are some changes that are very specific to our needs at Sentry, which is why we also maintain a forked version of rrweb with some custom changes.

Primer: Tree Shaking

Tree shaking allows a JavaScript bundler to remove unused code from the final bundle. If you're not familiar with how it works and the advantages tree shaking brings, you can learn more about it in our docs.

Made it possible to remove iframe & shadow DOM support via a build-time flag

While rrweb allows you to capture more or less everything that happens on your page, some of the things it can capture may not be necessary for some users. For these cases, we now allow users to manually remove certain parts of the rrweb codebase they may not need at build time, reducing the bundle size.

In getsentry/sentry-javascript#9274 & getsentry/rrweb#114 we implemented the ground work to allow for tree shaking iframe and shadow DOM recordings. This means that if, for example, you don't have any iframes on your page, you can safely opt-in to remove this code from your application.

In getsentry/sentry-javascript-bundler-plugins#428 we implemented an easy way to implement these optimizations in your app. If you are using one of our bundler plugins:

You can just update to its latest version, and add this configuration to the plugin:

sentryPlugin({
  bundleSizeOptimizations: {
    excludeDebugStatements: true,
    excludeReplayIframe: true,
    excludeReplayShadowDom: true,
  },
})

This will save you about 5 KB gzipped of bundle size!

How we implemented build-time tree shaking flags
We already had some build-time flags for tree shaking implemented in the JavaScript SDK itself (__SENTRY_DEBUG__ and __SENTRY_TRACING__). We followed the same structure for rrweb:

// General tree shaking flag example
if (typeof __SENTRY_DEBUG__ === 'undefined' || __SENTRY_DEBUG__) {
  console.log('log a debug message!')
}

By default, this code will result in log a debug message! being logged. However, if you replace the __SENTRY_DEBUG__ constant at build time with false, this will result in the following code:

if (typeof false === 'undefined' || false) {
  console.log('log a debug message!')
}

Which bundlers will optimize to the following:

if (false) {
  console.log('log a debug message!')
}

And in turn, since the code inside of if (false) will definitely never be called, it will be completely tree shaken away.

For rrweb, we used the same approach to allow you to remove certain recording managers:

In order to avoid touching all the parts of the code that may use a manager, we added new dummy managers following the same interface but doing nothing:

interface ShadowDomManagerInterface {
  init(): void
  addShadowRoot(shadowRoot: ShadowRoot, doc: Document): void
  observeAttachShadow(iframeElement: HTMLIFrameElement): void
  reset(): void
}

class ShadowDomManagerNoop implements ShadowDomManagerInterface {
  public init() {}
  public addShadowRoot() {}
  public observeAttachShadow() {}
  public reset() {}
}

Now, in the place where the ShadowDomManager is usually initialized, we can do the following:

const shadowDomManager =
  typeof __RRWEB_EXCLUDE_SHADOW_DOM__ === 'boolean' && __RRWEB_EXCLUDE_SHADOW_DOM__
    ? new ShadowDomManagerNoop()
    : new ShadowDomManager()

This means that by default, the regular ShadowDomManager is used. However, if you replace __RRWEB_EXCLUDE_SHADOW_DOM__ at build time with true, the ShadowDomManagerNoop will be used, and the ShadowDomManager will thus be tree shaken away.

Removed canvas recording support by default

Since we currently do not support replaying captured canvas elements, and because the canvas capturing code makes up a considerable amount of the rrweb codebase, we decided to remove this code by default from our rrweb fork, and instead allow you to opt-in to use this by passing a canvas manager into the rrweb record() function.

We implemented this in getsentry/rrweb#122, where we started to export a new getCanvasManager function, as well as accepting such a function in the record() method. With this, we can successfully tree-shake the unused canvas manager out, leading to smaller bundle size by default, unless users manually import & pass the getCanvasManager function.

Once we fully support capturing & replaying canvas elements in Session Replay (coming soon), we will add a configuration option to new Replay() to opt-in to canvas recording.

Removed unused code from rrweb

Another step we took to reduce bundle size was to remove & streamline some code in our rrweb fork. rrweb can be configured in a lot of different ways and is very flexible. However, due to its flexibility, a lot of the code is not tree shakeable, because it depends on runtime configuration.

For example, consider code like this:

import { large, small } from './my-code'

function doSomething(useLarge) {
  return useLarge ? large : small
}

In this code snippet, even if we know we only ever call this as doSomething(false), it is impossible to tree shake the large code away, because statically we cannot know at build time that useLarge will always be false.

Because of this, we ended up fully removing certain parts of rrweb from our fork:

hooks related code getsentry/rrweb#126
plugins related code getsentry/rrweb#123
Remove some functions on record that we don't need getsentry/rrweb#113
In addition, we also made some general small improvements which we also contributed upstream to the main rrweb repository:
Avoid unnecessary cloning of objects or arrays getsentry/rrweb#125
Avoid cloning events to add timestamp getsentry/rrweb#124

Removed unused code in Session Replay

In addition to rrweb, we also identified & removed some unused code in Session Replay itself:

Clean up some logs and internal checks getsentry/sentry-javascript#9392, getsentry/sentry-javascript#9391
Remove unused function getsentry/sentry-javascript#9393

Updated library used for compression

We used to compress replay payloads with pako, which, while it worked well enough, turned out to be a rather large (bundle-size wise) library for compression. We switched over to use fflate in getsentry/sentry-javascript#9436 instead, which reduced bundle size by a few KB.

Made it possible to host compression worker

We use a web worker to compress Session Replay recording data. This helps to send less data over the network, and reduces the performance overhead for users of the SDK. However, the code for the compression worker makes up about 10 KB gzipped of our bundle size - a considerable amount!

Additionally, since we have to load the worker from an inlined string due to CORS restrictions, the included worker does not work for certain environments, because it requires a more lax CSP setting which some applications cannot comply with.

In order to both satisfy stricter CSP environments, as well as allowing to optimize the bundle size of the SDK, we added a way to tree shake the included compression worker, and instead provide a URL to a self-hosted web worker.

Implemented in getsentry/sentry-javascript#9409, we added an example web worker that users can host on their own server, and then pass in a custom workerUrl to new Replay({}). With this setup, users save 10 KB gzipped of their bundle size, and can serve the worker as a separate asset that can be cached independently.

Performance Monitoring for Every Developer: Web Vitals & Function Regression Issues

Matt — Wed, 15 Nov 2023 20:30:49 +0000

Extracting relevant insights from your performance monitoring tool can be frustrating. You often get back more data than you need, making it difficult to connect that data back to the code you wrote. Sentry’s Performance monitoring product lets you cut through the noise by detecting real problems, then quickly takes you to the exact line of code responsible. The outcome: Less noise, more actionable results.

Today, we’re announcing two new features to help web, mobile, and backend developers discover and solve performance problems in their apps: Web Vitals and Function Regression Issues.

Web Vitals: From performance scores to slow code

Web Vitals unify the measurement of page quality into a handful of useful metrics like loading performance, interactivity, and visual stability. We used these metrics to develop the Sentry Performance Score, which is a normalized score out of 100 calculated using the weighted averages of Web Vital metrics.

The Sentry Performance Score is similar to Google’s Lighthouse performance score, with one key distinction: Sentry collects data from real user experiences, while Lighthouse collects data from a controlled lab environment. We modeled the score to be as close to Lighthouse as possible while excluding components that were only relevant in a lab environment.

Web Vitals identify the biggest opportunities for improvement

To improve your overall performance score, you should start by identifying individual key pages that need performance improvements. To simplify this and help you cut to the chase, we rank pages by Opportunity, which indicates the impact of a single page on the overall performance score.

In this example, the highest opportunity page in Sentry’s own web app is our Issue Details page. Since this is the most commonly accessed page in our product, improving its performance would significantly improve the overall experience of using Sentry.

After identifying a problematic page, the next step is to find example events where users had a subpar experience. Below, you’ll see events that represent real users loading our Issue Details page, with many experiencing poor or mediocre performance:

In the above screenshot, you’ll see a user that experienced a performance score of 9 out of 100 (Poor), primarily driven by a 10+ second Largest Contentful Paint (LCP). Ouch. These worst-case events highlight performance problems not evident during local development or under ideal conditions (e.g. when users have a fast network connection, a high-spec device, etc.).

You’ll notice some of these events have an associated ▶️ Replay. When available, these let you see a video-like reproduction of a user’s real experience with that page. When optimizing your app’s performance, these replays can help you understand where users have a subpar experience–for example, when they struggle with 10-second load times.

Span waterfalls highlight your most expensive operations

To find out what caused the slow LCP, you can click the event’s Transaction button, which provides a detailed breakdown of the operations that occurred during page load. We call these operations spans.

The most relevant spans are the ones that occur before the red LCP marker, as these spans are potentially LCP-blocking. Spans that occur after the LCP marker still impact overall page performance, but do not impact the initial page load.

The first span that looks like a clear performance bottleneck is the app.page.bundle-load span, which measures how long it takes to load the JavaScript bundle. In this case, loading the bundle alone takes almost 6 seconds or about 60% of our total LCP duration.

The JavaScript bundle load time depends primarily on its size; reducing the bundle size would significantly improve page load speed. But, even if we reduced bundle load time by 50%, LCP would only drop from 12 to 7 seconds — which means we need to look for additional optimization opportunities.

The next clear opportunity is this ui.long-task.app-init span taking almost 1 second. Long task spans represent operations over 50 milliseconds where the browser is executing JavaScript code and blocking the UI thread. Since this is a pure JavaScript operation, let’s go deeper and find out what’s going on.

Browser Profiling takes you to the line of code responsible

Identifying the code causing a long task has traditionally been difficult, as you must reproduce the issue in a development environment with access to a profiler. To solve this, Sentry has launched new support for collecting browser JavaScript profiles in production (on Chromium-based browsers). This lets you debug real user issues and collect a wide range of sample profiles across your user base.

In this example, we can open the profile associated with the page load event and see the code that executed during the ~1-second long task span:

The EChartsReactCore.prototype.componentDidMount function takes 558 ms to execute, which is over half the duration of the long task span. This function is linked to a React component that renders a chart, provided by the open-source ECharts visualization library. This looks exactly like where we should focus our attention if we hope to bring our Issues Details pageload times down.

In summary, we first identified a page with a poor performance score, then determined that reducing the JavaScript bundle size and optimizing a specific React component could significantly improve the performance of our Issue Details page. By finding pages with high opportunity scores, breaking down page load events, and diving deep into JavaScript performance with profiles, you can enhance your product’s overall user experience.

Web Vitals are available to Sentry customers today. Profiling for Browser JavaScript is also now available in beta.

Function Regression Issues: more than just alerts

Recently, we launched the ability to view the slowest and most regressed functions across your application. Now, we can help you debug function-level regressions with a new type of Performance Issue. Function Regression Issues notify you when a function in your application regresses, but they do more than just detect the regression— they use profiling data to give you essential context about what changed so you can solve the problem.

Function Regression Issues can be detected on any platform that supports Sentry Profiling. Below, we’ll walk through a backend example in a Python project.

The screenshot above is a real Function Regression Issue that identified a slowdown in Sentry’s live-running server code. It triggered because the duration of a function that checks customer rate limits stored in Redis regressed by nearly 50%.

The top chart shows how function duration changed over time, while the bottom chart shows the number of invocations (throughput). You’ll notice that throughput also appears to increase during the slowdown period. This suggests that increased load might be one of the causes of this regression.

In the screenshot above, you’ll see that the same issue gives us other essential information like which API endpoints were impacted by the regression and how much they regressed. This data reveals that the rate-limiting function was widely used and called by many of our endpoints, resulting in a significant regression in overall backend performance.

Jump from Regression Issues to Profiles to find the root cause

The Function Regression Issue makes it easy to see the example profiles captured before and after the regression — they’re displayed right under the “Most Affected” endpoints. Comparing these profiles gives the most crucial context, revealing (at a code level) the change in runtime behavior that caused the regression.

Here, we looked at an example profile event that was captured before the regression occurred. We noticed that our regressed function calls into two functions within the third-party redis module: ConnectionPool.get_connection and ConnectionPool.release.

We compared this to a profile collected after the regression and noticed that one of those two functions, ConnectionPool.get_connection, was taking significantly longer than before. Each function frame in a profile offers source context for where the function was defined and the executed line number. In this case, opening this source location in the redis module yielded the following line:

This line attempts to acquire a lock — and the significant wall-time duration increase when executing this line suggests that multiple processes or threads are trying to acquire the lock simultaneously. This lock contention is the code-level reason for the regression.

This lock contention issue also aligns with what we saw earlier in the throughput graph – increased throughput makes contention more likely. Through additional investigation, we discovered that the increased throughput for this function corresponded to an increase in the number of Redis connections starting around the time of the regression; our next step is to isolate the source of the additional connections.

Using this example, we’ve illustrated how Function Regression Issues can help you link performance regressions directly to the code causing the regression with profiling data. While this specific example focused on a backend use case, this capability works on any platform that supports Sentry Profiling.

Function Regression issues are available today to Early Adopters and will become generally available over the next 2 weeks.

Conclusion

A high-performance bar is critical for building differentiated products that people want to use. With Web Vitals and Function Regression Issues, we’ve provided more ways for all developers to solve performance problems by connecting them to code.

Tune in for more exciting product announcements with Sentry Launch Week. To set up Sentry Performance today, check out this guide. You can also drop us a line on Twitter or Discord, or share your Web Vitals feedback with us on GitHub.

And, if you’re new to Sentry, you can try it for free or request a demo to get started.

What’s the difference between API Latency and API Response Time?

Lazar Nikolov — Mon, 13 Nov 2023 15:28:32 +0000

Your app’s networking directly affects the user experience of your app. Imagine having to wait a few seconds for the page to load. Or even worse, imagine waiting for a few seconds every time you perform an action. It would be infuriating! Before you go on a fixing adventure, it’s a good idea to understand what causes that waiting time. So let’s do that!

The difference between Latency vs Response Time

The total client-server communication time is called API Response Time. That’s from the moment the client makes a request, until it receives a response back. A slow request means a very long response time. Anything that contributes to the slowness affects the response time.
The response time consists of the latency and the processing time. The latency is how long it takes to transfer data between the client and the server, or the “processing component”. A few factors contribute to the latency:

the network speed
the server load
the performance of the load balancer
the size of the data we’re sending
and the API design

For example, the client sends a data request to the API and gets a response back in 3 seconds. The total response time is 3 seconds. The latency might be 300ms, which leaves 2500ms, or 2.5 seconds, for processing. Just to have a number in mind, high-performing APIs are considered to have between 0.1 and 1 second average response time. At 2 seconds the delay is noticeable. At 5 seconds the delay is so significant that the users are starting to abandon the application/website.

The response time is one of the most important metrics we need to keep our eyes on. If not, it can significantly hurt the user experience, and even the business itself. Back in 2008, Amazon reported that every 100ms latency costs 1% of their profit. Google also reported that in an experiment that increased the number of search results they noticed that half a second delay caused a 20% drop in traffic. These are significant numbers. Amazon makes $19.4 billion per month. 1% of those sales is $194 million. Add up that number for every 100ms latency and you’ll see the damage. As you can see, learning how to monitor and optimize your API response time is a very good investment.

Just like any other web performance metric, the response time should be measured and monitored in production. Your computer and internet speed might be fast, but your users’ computers and internet are probably not as fast. That results in much less favorable results than what you’ll see if you measured your API’s response time locally. But working with production data also means that you’re working with outliers. The Average Response Time is not always a good metric. Let’s learn how to properly measure the API response time.

Measuring response time

First let’s talk about why ART (Average Response Time) is not a good metric. There are always the edge cases where a small number of your users are reporting the worst response times imaginable. That could be because of a really outdated computer, or they’re trying to access your web app with a bad internet connection (subway, remote locations, etc…), or your API experienced a brief downtime because of a bug or your deployment. You don’t care about those cases because there is usually nothing you can do about them. Calculating an average on that data will take those outliers into account as well, and you don’t want that. You want to exclude those data points from your data. Enter: percentiles.
Percentiles provide you with a different view of your performance data. The data is sorted in a descending order and cut at specific % points. The most commonly used percentiles are p50, p75, p95, p99 and p100.

P50, also called the Median, is the value below which 50% of the data falls. This would be the typical performance of your API.
P75 is the value where 75% of the data falls. This percentile is good for frontend applications because it includes more variable data, which mirrors the variety of the user conditions.
P95 is more valuable for backend applications where the data is more uniform.
P99, also called Peak Response Time, is also more valuable for backend applications, and it marks the upper limit of the performance.
P100 is the maximum observed value. This is the worst measured performance.

If you want to get into more detail about percentiles, read our “Choosing the Right Metric” article.

Another important metric is the Error/Failure Rate of your API. The Error/Failure Rate is a value that indicates the % of requests that resulted with a non-200 status code. Having this data can also help you figure out if things are wrong with your API or documentation. If you’re seeing more “400s” status codes, it might mean that clients don’t use your API properly, or don’t understand it well. If you’re seeing more “500s” status codes then it means you have issues with your code.

Monitoring API response time in production

To monitor your API’s response time (and other metrics as well) in production, you need to implement a mechanism that will continuously take those measurements, save them in a database, and provide you with tools to query and visualize the data. Sentry is an application performance monitoring tool that you can use to monitor all of your frontend, backend, and mobile application projects—not just your API. And don’t worry, Sentry probably has an SDK for whatever framework you’re using.

Getting started is easy. After installing and configuring Sentry’s SDK for your framework of choice, you’ll get automatic instrumentation, which means a bigger part of your backend is already set up with performance monitoring. Depending on the size of your application, this could be enough to get started. If you need more detailed performance data, you can add custom instrumentations in certain places.

When you start getting performance data in your Sentry account, identifying what makes your API slow is quick. Getting to the root cause of the slow performance is even quicker. Sentry’s tracing data makes the performance bottlenecks obvious. Here’s a short arcade that shows you how you can identify performance bottlenecks in your application and figure out what causes them:

Backend Performance Monitoring | Arcade

app.arcade.software

A good resource on improving the performance of your API using Sentry is Lincoln Loop’s “19x faster response time” article.

Conclusion

So, a quick recap. API latency is the time it takes for the data to be transmitted between the client and the backend. The API response time is the latency + the time it takes for the backend to process the request and return the result. Factors like network speed, load balancer, data size, server load, API design, and our code affect the response time.
To properly monitor the performance of your backend, you need to use a tool that will monitor your application while in production. Sentry can help you with that, head to https://sentry.io/signup to get started.

Getting Started with Jetpack Compose

Lazar Nikolov — Fri, 03 Mar 2023 21:04:28 +0000

Recently, we wrote about the demonstrative move to declarative UI. With Jetpack Compose, Android is joining the declarative trends.

Jetpack Compose, a new declarative UI toolkit by Google made for building native Android apps, is rapidly gaining traction. In fact, as announced at the Android Dev Summit last year last year, 160 of the top 1,000 Android apps already use Jetpack Compose. In contrast to the traditional XML Views, Jetpack Compose allows you to build UIs using composable functions that describe how the UI should look and behave.

The main advantage of using Jetpack Compose is that it allows you to write UI code that is more concise and easier to understand. This leads to improved maintainability and reduced development time.

The main disadvantage of using Jetpack Compose is that it’s relatively new, so its ecosystem is limited and the number of available libraries, tools, and resources is lower than the traditional ecosystem.

Despite that, we believe that learning Jetpack Compose is worth the learning curve and challenges. Here are some tips we've found helpful as you are getting started.

How to start using Jetpack Compose

The recommended IDE for working with Jetpack Compose is Android Studio. After downloading and installing Android Studio, you’ll get the option to create a new project. To create a new Jetpack Compose application, you need to select either the Empty Compose Activity (which uses Material v2), or Empty Compose Activity (Material3) (which uses the Material v3 which is in version 1.0 as of last year). You can see both options in the top right of this screenshot:

This is the easiest way to get started with Jetpack Compose. If you’d like to enable Jetpack Compose into an existing Android application, here’s what you need to do:

1. Add the following build configurations in your app’s build.gradle file:

android {
  buildFeatures {
    // this flag enables Jetpack Compose
    compose true
  }

  composeOptions {
    // the compiler version should match
    // your project's Kotlin version
    kotlinCompilerExtensionVersion = "1.3.2"
  }
}

2. Add the Compose BOM (Bill of Materials) and the subset of Compose dependencies to your dependencies:

dependencies {
  def composeBom = platform('androidx.compose:compose-bom:2023.01.00')
  implementation composeBom
  androidTestImplementation composeBom

  // Choose one of the following:
  // Material Design 3
  implementation 'androidx.compose.material3:material3'
  // or Material Design 2
  implementation 'androidx.compose.material:material'
  // or skip Material Design and build directly on top of foundational components
  implementation 'androidx.compose.foundation:foundation'
  // or only import the main APIs for the underlying toolkit systems,
  // such as input and measurement/layout
  implementation 'androidx.compose.ui:ui'       

  // Android Studio Preview support
  implementation 'androidx.compose.ui:ui-tooling-preview'
  debugImplementation 'androidx.compose.ui:ui-tooling'

  // UI Tests
  androidTestImplementation 'androidx.compose.ui:ui-test-junit4'
  debugImplementation 'androidx.compose.ui:ui-test-manifest'

  // Optional - Included automatically by material, only add when you need
  // the icons but not the material library (e.g. when using Material3 or a
  // custom design system based on Foundation)
  implementation 'androidx.compose.material:material-icons-core'
  // Optional - Add full set of material icons
  implementation 'androidx.compose.material:material-icons-extended'
  // Optional - Add window size utils
  implementation 'androidx.compose.material3:material3-window-size-class'

  // Optional - Integration with activities
  implementation 'androidx.activity:activity-compose:1.5.1'
  // Optional - Integration with ViewModels
  implementation 'androidx.lifecycle:lifecycle-viewmodel-compose:2.5.1'
  // Optional - Integration with LiveData
  implementation 'androidx.compose.runtime:runtime-livedata'
  // Optional - Integration with RxJava
  implementation 'androidx.compose.runtime:runtime-rxjava2'
}

How do you build UI in Jetpack Compose?

Jetpack Compose uses Composables to define the view hierarchy, and modifier to apply visual appearance and behavior changes to the composables they’re added to.

Composable functions

Composable functions (or just Composables) are ordinary Kotlin functions that are annotated with @Composable, can be nested within another composable functions, and return a hierarchy of other composables in order to define their UI. Let’s see a simple composable that defines a contact row UI that contains a user photo, and a name and phone number:

@Composable
fun ContactRow(user: User) {
  Row {
    Image (
      painter = painterResource(id = R.drawable.user),
      contentDescription = "A photo of a user"
    )

    Column {
      Text(user.name)
      Text(user.phone)
    }
  }
}

The Row composable is a layout composable that renders its children one next to another. The Image composable is the first child which is going to render the user drawable. Then we have the Column composable which, similar to the Row, is a layout composable, but it renders its children one below another. The children of the Column composable are two Text composables that render the user’s name and phone number.

Modifiers

Modifiers are used to change the visual appearance and behavior of the composables they’re added to. We use modifiers when we want to change UI elements such as the size of the composable (width, height), the padding, background, or alignment.

Modifiers can also be stacked on top of each other, allowing us to modify multiple visual properties. Here’s an example of how we can set the padding and max width of the Contact row from the previous snippet:

@Composable
fun ContactRow(user: User) {
  Row(modifier = Modifier.fillMaxWidth().padding(16.dp)) {
    ...
  }
}

How do you interact with data in Jetpack Compose?

There are multiple ways to keep data within your Jetpack Compose app: MutableState, LiveData, and StateFlow.

MutableState

In Jetpack Compose, state management can be accomplished by using the remember API to store an object in memory, and the mutableStateOf to declare a state variable. We can store both mutable and immutable objects. The mutableStateOf creates an observable MutableState<T>, which is an observable type.

interface MutableState<T> : State<T> {
  override var value: T
}

Any changes to value schedules a recomposition (re-rendering) of any composable functions that read it.
There are three ways to declare a MutableState object:

val mutableState = remember { mutableStateOf(0) }
var value by remember { mutableStateOf(false) }
val (value, setValue) = remember { mutableStateOf("Hello, Compose!") }

LiveData

LiveData is a data holder class that can be observed within a given lifecycle, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This ensures LiveData only updates observers that are in an active lifecycle state, which also ensures no memory leaks happen within your app.

Let’s see an example of working with LiveData:
1. You need to create an instance of the LiveData class to hold a certain type of data, which is usually done within your ViewModel class (use MutableLiveData if you’d like to update the value at some point):

class HomeViewModel : ViewModel() {
  // Create a MutableLiveData instance that keeps a string
  val userName = MutableLiveData<String>()
}

2. Obtain the value in your composable by calling the observeAsState method:

@Composable
fun HomeScreen (viewModel: HomeViewModel = viewModel())   {
  // Create an observer of the state of userName
  val userName = viewModel.userName.observeAsState()

  // Use the value in your UI
  Column {
    Text(userName)
  }
}

3. To update userName's value (also usually done in the view model), create a function that sets the new value to its value property:

fun updateUserName(newName: String) {
  userName.value = newName
}

4. You’d use the new function in your Compose file as viewModel.updateUserName("...").

StateFlow

StateFlow is a newer alternative to LiveData. Both have similarities, and both are observable. Here’s how you can work with StateFlow in Jetpack Compose:
1. Create an instance of StateFlow to hold a certain type of data (use MutableStateFlow if you’d like to update the value at some point)

class HomeViewModel : ViewModel() {
  // Create a MutableStateFlow instance that keeps a string
  val userName = MutableStateFlow<String>()
}

2. Obtain the value in your composable by calling the collectAsState method:

@Composable
fun HomeScreen (viewModel: HomeViewModel = viewModel())   {
  // Create an observer to collect the state of userName
  val userName = viewModel.userName.collectAsState()

  // Use the value in your UI
  Column {
    Text(userName)
  }
}

3. To update userName's value (also usually done in the view model), create a function that sets the new value to its value property:

fun updateUserName(newName: String) {
  userName.value = newName
}

4. You’d use the new function in your Compose file as viewModel.updateUserName("...").

What are the best practices for Jetpack Compose?

Aside from the official best practices documentation, we’ve got a few additional tips that would make your codebase safer and easier to work in.

Code organization

Every developer or organization has their own opinions on how a project should be structured. There is no “right” or “wrong” way to do it. Okay, maybe it’s wrong to put every file in one single directory 😅. Here’s an example structure to help you get started, which you can modify and evolve as your project grows:

.
├─ 📁 **ui** (to keep all your UI related things)
|  ├─ 📁 **screens** (where you define your screens composables and their corresponding view models)
|  |  └─ 📁 **home**
|  |     ├─ 📝 **HomeScreen.kt** (the UI for the Home screen)
|  |     └─ 📝 **HomeViewModel.kt** (the view model for the Home screen)
|  ├─ 📁 **components** (where you define components that are shared across multiple screens)
|  |  └─ 📝 **UserList.kt**
|  └─ 📁 **theme** (where you keep your theme definition and design tokens)
|     ├─ 📝 **Colors.kt**
|     ├─ 📝 **Shapes.kt**
|     ├─ 📝 **Theme.kt**
|     └─ 📝 **Typography.kt**
├─ 📁 **utils** (where you keep your various utility functions, like data converters etc...)
|  └─ 📝 **DateUtils.kt** 
└─ 📝 **MainActivity.kt** (this is your default MainActivity)

Avoid creating “god” files

“God” files are a big no-no. They’re files that contain all code associated with them: UI, domain, business logic, utility functions etc… It might be easier putting everything into one file, but maintaining that would get harder and harder as you add functionalities. The solution to this is using a proper architecture in your Jetpack Compose app.

There are multiple architectures that you can use, all with their own pros and cons. The most common one in Jetpack Compose is MVVM, abbreviated from Model-View-ViewModel, because Jetpack Compose has a first-class ViewModel implementation.

Stay true to the MVVM

As you saw from the previous examples, Jetpack Compose has a first-class ViewModel implementation. The MVVM, or Model-View-ViewModel, is a software design pattern that is structured to separate business logic from the UI. That means, your UI should not handle state updates, but it should let the view model do that by sending it user actions.

Let’s explore that with an example. Remember the MutableStateFlow example from before? That example was oversimplified on purpose, but in a real-world project you would never expose a MutableStateFlow from your ViewModel, but just a StateFlow. In order to make that work, you should define a private MutableStateFlow variable and a public StateFlow variable that returns the mutable flow by invoking the asStateFlow() method.

class HomeViewModel : ViewModel() {
  // Create a private MutableStateFlow instance that keeps a string
  private val _userName = MutableStateFlow<String>()

  // Create a public StateFlow that returns the MutableStateFlow as immutable
  val userName: StateFlow<String> = _userName.asStateFlow()
}

With this simple change, we’re preventing the UI from being able to change the state. But, how do we actually change the state? We’ll expose a function from the view model that does that!

class HomeViewModel : ViewModel() {
  private val _userName = MutableStateFlow<String>()
  val userName: StateFlow<String> = _userName.asStateFlow()

  // Create a public function that updates the private MutableStateFlow value
  fun setUserName(newName: String) {
    _userName.value = newName
  }
}

So now the UI has an immutable StateFlow that it can observe, and a function to update its value. The business logic lives inside of the view model, while the Composable is only responsible to react to state changes and send user actions to the view model.

Don’t create a thousand flows

So you’ve learned how to create state flows. Great! Would you repeat the same for every state variable you need in your UI? Please don’t 😅 To avoid that, you can create a data class that keeps all of the values of your state, and create a single flow that uses it.

Let’s learn this with an example. If we wanted to also keep the user’s phone number, email and address, we can create a data class called HomeScreenState that contains all those values:

data class HomeScreenState(
  val userName: String = ""
  val userPhone: String = ""
  val userEmail: String = ""
  val userAddress: String = ""
)

Then we would refactor our view model to use the new HomeScreenState instead of a String:

class HomeViewModel : ViewModel() {
  private val _uiState = MutableStateFlow<HomeScreenState>()
  val uiState: StateFlow<HomeScreenState> = _uiState.asStateFlow()

  // ...
}

And then we can use all of the values in our composable by viewModel.uiState.userName. If we also wanted to be able to update all those values, we would create functions for each of them in our view model:

class HomeViewModel : ViewModel() {
  private val _uiState = MutableStateFlow<HomeScreenState>()
  val uiState: StateFlow<HomeScreenState> = _uiState.asStateFlow()

  fun updateUserName(newName: String) {
    _uiState.update {
      it.copy(
        userName = newName
      )
    }
  }

  fun updateUserEmail(newEmail: String) {
      _uiState.update {
        it.copy(
          userEmail = newEmail
        )
      }
    }
  }

  // ...

}

Keep a close eye on your errors and performance in production

As you're getting acclimated to Jetpack Compose, an error and performance monitoring tool can be really helpful to reduce your learning curve and ensure that your app is bug-free. Jetpack Compose does a lot of heavy lifting for developers – as a declarative toolkit, developers need to write less code to describe their UI, and Jetpack Compose takes care of the rest. But it does abstract away a lot of code, making it difficult to identify errors.

Sentry offers an out-of-the-box integration that can help you build a better Jetpack Compose app. The integration gives precise context to reduce troubleshooting time with transactions and breadcrumbs. Keep an eye on all the issues and crashes your app is experiencing in production, with a lot of context as to why the issue happened, the exact line of code that triggered it, and all sorts of hardware and software info of the device it ran.

Conclusion

I’d totally understand if you’re feeling overwhelmed by now, but let’s do a quick recap! We’ve learned how to create a new Jetpack Compose project, and that Jetpack Compose uses Composables and Modifiers to define the view hierarchy and apply visual changes. Data in Jetpack Compose can be handled either with a MutableState, LiveData, or StateFlow, which make the composables that observe it re-render when the value changes, making our UI dynamic. We also learned how to keep our projects tidy, and how to write maintainable composables and view models.

Even though it’s a relatively new technology, Jetpack Compose’s ecosystem is steadily growing, so we can expect to see a lot of libraries pop up that make it easier to create Jetpack Compose apps. With companies like Lyft, Twitter, Airbnb, Square, Reddit, and Firefox putting their trust into it, more and more developers will follow along and create apps, libraries and resources for Jetpack Compose.

Mobile: The Future is Declarative

Lazar Nikolov — Fri, 30 Dec 2022 10:55:05 +0000

The mobile development ecosystem has always been very diverse, arguably more diverse than the web development ecosystem. While it seems like every day there are more frameworks and tools for web developers, a lot of them are built on top of JavaScript and implement similar patterns to each other. The mobile ecosystem, on the other hand, has a core set of languages that make the differences between mobile tools and frameworks much easier to identify.

Two of the leading native mobile platforms are native Android and iOS, both of which have had interesting innovations recently. With the introductions of Jetpack Compose and SwiftUI, developing native apps looks very similar to developing React Native or Flutter apps. Both React Native and Flutter have a declarative approach from the start, but with Android and iOS now joining the declarative bandwagon, we can see that the future of mobile development is declarative.

A little history

While React Native and Flutter have always taken a declarative approach, Android and iOS started completely different.

Android utilized (and still does) Views. Views are XML files where we define our user interfaces using widgets like Button, TextView, LinearLayout and where we assign IDs to those widgets. Those IDs are then used to reference widgets in our Java files where we develop the functionality and behavior. Here’s an example View file:

<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_width="match_parent"
  android:layout_height="match_parent">
  <TextView
    android:id="@+id/text_view_id"
    android:layout_height="wrap_content"
    android:layout_width="wrap_content"
    android:text="@string/hello" />
</LinearLayout>

And we would create a reference to the widget like this:

public class MainActivity extends Activity {
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    // Create a reference to the TextView using its ID
    final TextView helloTextView = (TextView) findViewById(R.id.text_view_id);

    // Change the TextView's text
    helloTextView.setText(R.string.user_greeting);
  }
}

iOS did have some declarative features, like Auto Layout, UIAppearance, the Objective-C @property declarations, KVC collection operators, and Combine, but it still required writing some level of imperative code.

For example, iOS had (and still has) Storyboards. Storyboards is a graphical tool we use to build our UIs. It is actually an XML file under the hood, but the developers almost never touch the XML code itself. Here’s how we added UI elements in our Storyboards, and created references and actions:

Becoming declarative

To refresh our memory, the imperative approach is when you provide step-by-step instructions until you achieve the desired UI. The declarative approach is when you describe how the final state of the desired UI should look.

Android’s new Jetpack Compose is written in Kotlin, which is a programming language as opposed to XML, which is a markup language. The previous XML View example would look something like this in Jetpack Compose:

class MainActivity: ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    // Start defining the UI
    setContent {
      BasicsCodelabTheme {
        // Add a Row (alternative to LinearLayout)
        Row(modifier = Modifier.fillMaxSize()) {
          // Add a Text (alternative to TextView)
          Text("Hello, Sentry!")
        }
      }
    }
  }
}

As you can see, building UIs with this approach requires a lot less code. And, since we stay in a programming language context, we can directly use variables and callbacks instead of creating references to widgets and attaching logic to those widgets. Any change in the values will trigger a recomposition (rerender), so our UI is always up to date.

iOS’s SwiftUI is pretty much the same, just built with Swift instead. The previous Storyboard example would look something like this in SwiftUI:

struct ContentView: View {
  var body: some View {
    Button {
      // handle onClick
    } label: {
      Text("Button")
    }
  }
}

Again, much less code. And we’re in a programming language, so we can directly define the Button’s label and provide an onClick callback without creating a reference.

One issue we stumbled upon when working with the imperative UIKit is activating constraints of a view before adding it to the view hierarchy:

let subview = UIView(frame: .zero)
subview.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true
// ^^^ it's going to crash on this line with the error:
//
// Unable to activate constraint with anchors *** because they have
// no common ancestor. Does the constraint or its anchors reference
// items in different view hierarchies?  That's illegal.

view.addSubview(subview)

Swapping the subview.leadingAnchor.constraint(...) line with the view.addSubview(view) line will work without an error. Admittedly, it took me a while to understand what was going on when I first encountered this error, and I triggered this error a few more times until it became a muscle memory for me. But with the new declarative approach we’re not going to encounter this issue. (Muscle memory in coding is good, but it’s better to improve the developer experience).

This shift towards declarative in Android and iOS is a huge step towards better developer experience and faster development. Defining your UI in a declarative way using a programming language solves a lot of the pain points that Android and iOS developers have.

Here are some of the benefits of the declarative approach:

Theming becomes easier and more dynamic.
State Management feels natural and actually plays a crucial role in the new declarative approach.
The composition approach allows us to compose our UI by nesting components, which is inferred from the nesting of the code’s block scope.
Dynamic layouts and conditional rendering are now straightforward because we’re building our UIs with programming languages that have control structures and branching logic.
It’s easier to grep through Swift/Kotlin code than through XML.
We can more uniformly refactor our code using the same tools that apply to the rest of the programming language.
The code diffs in PRs are easier to understand.
Since our UI elements are built with actual data structures (i.e. functions, classes, structs) as opposed to markup language, we have the possibility of doing unit tests on our Views as well (not available for Jetpack Compose at the time of writing this blog post).

Of course, there are always some drawbacks to be aware of. It’s worth mentioning that both SwiftUI and Jetpack Compose are only 2-3 years old. A short research on their drawbacks will reveal the lack of documentation, smaller community, some performance issues (for example Android’s lazy columns), not all components from the previous frameworks are supported, and there are limitations when it comes to building more complex UIs. Though they are still evolving and improving, be mindful of the pain points if you decide to start working with them today.

Example UI

Let’s look at how the same example UI is built in the declarative approach for both iOS and Android:

iOS (SwiftUI):

//: An example Modal UI built with SwiftUI

import SwiftUI
import PlaygroundSupport

struct ContentView: View {
    @State private var emailAddress = ""
    var body: some View {
        VStack(spacing: 16) {
            Image(systemName: "envelope.fill")
                .font(.largeTitle).foregroundColor(.blue)
            Text("Sign up to our newsletter!").font(.title).fontWeight(.bold)
            Text("Since you love our content so much, why not get them every day in your inbox?")
                .multilineTextAlignment(.center)
                .foregroundColor(.secondary)
                .frame(width: 400)
            HStack(spacing: 0) {
                TextField("john@doe.xyz", text: $emailAddress)
                    .frame(height: 40)
                    .padding(.leading, 12)
                    .border(.gray)
                Button(action: {
                    // Handle onClick logic
                }) {
                    Text("Subscribe")
                        .foregroundColor(.white)
                }
                .padding(.horizontal, 16)
                .padding(.vertical, 10)
                .background(.black)
            }
            .frame(width: 400)
        }
        .padding(40)
    }
}
// Present the view controller in the Live View window
PlaygroundPage.current.setLiveView(ContentView())

(View iOS gist here)

Android (Jetpack Compose):

@Composable
fun Modal() {
    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        modifier = Modifier.padding(40.dp),
    ) {
        Icon(
            Icons.Filled.Email,
            "icon",
            tint = Color(52, 120, 246), // similar to the iOS one
            modifier = Modifier.size(48.dp)
        )
        Text(
            "Sign up to our newsletter!",
            fontWeight = FontWeight.Black, fontSize = 24.sp,
            modifier = Modifier.padding(top = 16.dp)
        )
        Text(
            "Since you love our content so much, why not get them every day in your inbox?",
            textAlign = TextAlign.Center,
            color = Color.Gray,
            fontSize = 14.sp,
            modifier = Modifier.padding(top = 16.dp)
        )
        Row(
            verticalAlignment = Alignment.CenterVertically,
            modifier = Modifier
                .padding(top = 16.dp)
                .height(56.dp)
        ) {
            TextField(
                "",
                onValueChange = {},
                placeholder = { Text("john@doe.xyz") },
                colors = TextFieldDefaults.textFieldColors(
                    backgroundColor = Color.White,
                ),
                modifier = Modifier
                    .border(BorderStroke(1.dp, Color.Black))
                    .weight(1f)
                    .background(Color.White)
                    .fillMaxHeight()
            )
            Button(
                onClick = { /* handle onClick logic */ },
                colors = ButtonDefaults.buttonColors(
                    backgroundColor = Color.Black,
                    contentColor = Color.White,
                ),
                contentPadding = PaddingValues(horizontal = 16.dp, vertical = 10.dp),
                shape = RoundedCornerShape(0.dp),
                modifier = Modifier.fillMaxHeight()
            ) {
                Text("Subscribe")
            }
        }
    }
}

(View Android gist here)

Conclusion

The declarative approach of building UIs brings us a ton of benefits and eliminates a lot of the “pain points” we had in the imperative approach, but it also introduces new ones. Building UIs requires a lot less time with the declarative approach, and a lot less code. It’s also easier to achieve dynamic layouts and conditional rendering.

Since the native platforms are taking this approach, it also sets up the whole ecosystem for creating new frameworks on top of the native ones that will bring a lot more features and possibilities. It might be a bit early to call them “the industry standard” yet, but the mobile development world is about to get even more productive.

Measuring application performance in Swift using transactions

Lazar Nikolov — Tue, 22 Nov 2022 21:43:00 +0000

So you're building a mobile app that’s performing big data requests; or crunching big data. But now you're asking yourself:

How will my app perform in production?
How will it perform on a lower-tier phone?
Is there a scenario where the function's execution time is unbearably long?

With Sentry’s Custom Instrumentation you can keep an eye on those big data-handling functions. Let’s see how you can implement them in your Storyboard and SwiftUI projects.

Requirements

First, you need to setup performance monitoring. With performance monitoring, Sentry tracks application performance, measures metrics like throughput and latency, and displays the impact of errors across multiple services.

To get your app setup with performance monitoring, you need to configure the traces sample rate in your Swift.UI.App file's init() method:

import Sentry

// This should be in your SwiftUI.App file's init() method
SentrySDK.start { options in
  options.dsn = "[YOUR_DSN_HERE]"

  // Example uniform sample rate: capture 100% of transactions
  // In Production you will probably want a smaller number such as 0.5 for 50%
  options.tracesSampleRate = 1.0

  // OR if you prefer, determine traces sample rate based on the
  // sampling context
  options.tracesSampler = { context in
    // Don't miss any transactions for VIP users 
    if context?["vip"] as? Bool == true { 
      return 1.0 
    } else { 
      return 0.25 // 25% for everything else
    }
  }
}

Implementing custom transactions

Now that you’ve got performance monitoring enabled, you can start setting up custom transactions in the functions you’d like to measure. The measurement starts when you start a new transaction:

// don't forget to import Sentry's SDK at the top
import Sentry

// ...

func syncPersonDatabase() {
  let transaction = SentrySDK.startTransaction(
    // Give the transaction a descriptive name
    name: "transaction-name",

    // Give the operation a descriptive name
    operation: "transaction-operation"
  )

  // ...
  // perform the operation
  // ...
}

For example, let’s say you want to measure how long it takes to sync a database of all people within a company; the “person database”. The name and operation could be "Sync person database" and "data.update" respectfully.

When you’re done with the operation you want to measure, you can call the finish() method of the transaction. Finishing the transaction will stop the measurement and send it to your Sentry project.

The final structure of your function should look like this:

// don't forget to import Sentry's SDK at the top
import Sentry

// ...

func syncPersonDatabase() {
  let transaction = SentrySDK.startTransaction(
    name: "Sync person database", // give it a name
    operation: "data.update" // and a name for the operation
  )

  // ...
  // perform the operation
  // ...

  transaction.finish() // stop the measurement and report it to Sentry
}

Monitoring the performance

So far you’ve set up the performance measuring mechanism of your syncPersonDatabase function. Now you run your app...

You run it again...

Maybe you run it one more time for good measure...

Okay, that should have kicked off a transaction. You visit your Sentry dashboard and open the Performance tab and see the new custom transaction appear at the bottom:

Clicking on the transaction and then into the “Suspect Span” found in the second table, you will see a detailed representation of the span operation:

Let's break this view down a bit.

The first thing that you’ll see is the Self Time Breakdown chart.

This chart visualises the p50, p75, p95 and p99 metrics, which are called “latency percentiles”. p50 means that 50% of the function executions are faster than the p50 value (let’s say 0.47ms). To learn more about the latency percentiles, check out the Latency section in the Metrics documentation.

In the top right corner you can see the Self Time Percentiles widgets.

If you don’t want to look at the chart, these values will give you an insight on the average “p” values.

Below the chart is the events table.

Here if you notice an event that took longer than you anticipated, you can click on it to get more details about it, like:

The device that the user was using when the transaction occurred
The device’s memory at the time of the transaction
How long the user had been using the app prior to the transaction
The version of the app
The breadcrumbs (bits of events and interactions that led up to that transaction)

This gives you enough information on the context and environment to be able to discover potential ways to refactor the function to improve its performance. And, you can get even more granular if your function has multiple steps of execution. You can measure each steps individually and still keep them under the umbrella of the main function transaction.

Enter: child spans

More granular measurement with child spans

Child spans are like mini transactions that are attached to the main transaction. And child spans can have their own child spans as well. This feature allows you to measure your function’s performance in a greater detail, by starting a child span for every step of the function.

Let’s say your function performs the following steps:

1. Gather changed person properties
2. Pass each of them through a validation mechanism
3. Perform the updates to the database
4. Save the current timestamp as the "lastUpdated"

You can measure each step individually using child spans like this:

// don't forget to import Sentry's SDK at the top
import Sentry

// ...

func syncPersonDatabase() {
  let transaction = SentrySDK.startTransaction(
    name: "Sync person database", // give it a name
    operation: "data.update" // and a name for the operation
  )

  // span the first child
  let gatherSpan = transaction.startChild(operation: "gather-changed")
  // perform the gather operation
  gatherSpan.finish()

  // span the second child
  let validationSpan = transaction.startChild(operation: "validate-changed")
  // perform the validation
  validationSpan.finish()

  // span the third child
  let updateSpan = transaction.startChild(operation: "update-database")
  // perform the update
  updateSpan.finish()

  // span the last child
  let timestampSpan = transaction.startChild(operation: "update-timestamp")
  // perform the timestamp update
  timestampSpan.finish()

  transaction.finish()
}

Remember: Only finished spans will be sent along with the transaction. So you need to make sure that you’re finishing each child span before finishing the main transaction.

Monitoring the performance of child spans

Alright, you have set up child spans and you're ready to run your app again with the latest changes...

You run it again...

Maybe you run it one more time for good measure...

Done! You head back to your Sentry dashboard and notice that the Suspect Spans table provides more information now. You can see the child spans, and how long they took to execute.

Clicking on the “View All Spans” button you can see and sort all of them.

But you realize that your function has conditional steps that don’t always execute. Or maybe you have dynamically generated child spans whose name contains a unique id. To see the actual order of the child spans, you have to pick a specific event from the Events Table above and a new page will open with more details around that specific event.

You can see from the Gantt chart the order of execution of the child spans.

Here you can see that:

The data.update encapsulates all child spans
The gather-changed started executing first and took 16.02ms
Then the validate-changed ran for 5.64ms
Then the update-database took its 121.02ms to run
And finally the update-timestamp flashed for 5.63ms.

You can identify which step contributes the most to the performance of your function with this. You can now turn our whole focus to improving the performance of your update-database function.

Using a transaction in multiple functions

Now that you have a hang of measuring straightforward functions, you're ready to tackle something a bit more complex. You realize that you want to measure performance on multiple nested functions. You do not need to pass the transaction as an argument. Instead, you can bind the transaction to the current scope:

let transaction = SentrySDK.startTransaction(
  name: "Sync person database", // give it a name
  operation: "data.update", // and a name for the operation
  bindToScope: true // bind the transaction to the curent scope
)

Now you can access this transaction without having to pass it as an argument while you're in the current scope. You could have a function gatherChangedProperties, that calls another function filterProperties. And to gain access to the transaction within the filterProperties, you can directly reference SentrySDK.span, and if no transaction exists yet, you can create it. Your structure should look something like this:

let transaction = SentrySDK.startTransaction(
  name: "Sync person database", // give it a name
  operation: "data.update", // and a name for the operation
  bindToScope: true // bind the transaction to the curent scope
)

let properties = gatherChangedProperties()

// ...

transaction.finish()

func gatherChangedProperties() {
  // ...
  let filteredProperties = filterProperties();
  // ...
}

func filterProperties() {
  // obtain the transaction
  var span = SentrySDK.span

  // if non existing, recreate it
  if span == nil {
    span = SentrySDK.startTransaction(...)
  }

  // use it like a normal transaction
  let filterSpan = span.startChild(operation: "filter-properties")

  //...
}

Recap

You can now create custom transactions to measure long running functions in your app with SentrySDK.startTransaction(...).
You can measure more granularly by starting child spans to our transaction for each logical step in our function with transaction.startChild(...) to zero in on the slowest part of the function and improve it.
If you’re measuring a more complex function with multiple branches, you can bind the transaction to the current scope by setting the bindToScope property to true.

Time to measure all the things! 🙌

Performance Monitoring and more updates to Sentry for Electron

Rahul Chhabria — Fri, 25 Mar 2022 22:18:22 +0000

For those who aren’t that familiar with it, Electron is an open-source framework that allows developers to build cross-platform desktop applications in JavaScript. Some of the most popular desktop applications like VS Code, Slack, Discord, and Atom, are all built in Electron.

While Electron makes it easy to build cross-platform applications, maintaining them is a whole other thing. You need to be aware of OS-specific challenges, the machines your applications are running on, and their configurations. Version 3.0 of our Electron SDK helps you get a handle on all these unknowns with more context on every error, insight into when a release starts to degrade, and enable distributed tracing to easily see where the most time in a transaction is spent.

Get started

Install

# Using yarn
yarn add @sentry/electron

# Using npm
npm install @sentry/electron

Configure

import * as Sentry from "@sentry/electron";
Sentry.init({ dsn: "https://examplePublicKey@o0.ingest.sentry.io/0" });

You need to call init in the main process and every renderer process you spawn.

With V3.0 of Sentry for Electron, you can automatically monitor application performance without any additional configuration. As well as, track crash-free sessions by release, and unlock more information for every issue like CPU details, display data, memory status, language details, and more. Check out the release notes here.

Electron Performance Monitoring

Errors are only half the story. Electron developers also need to know if their app responds quickly to user input on any machine or operating system. This type of visibility helps you see if objects load quickly when called—and, if not, then provide you with tools to solve what’s urgent, faster.

Sentry’s performance monitoring for Electron surfaces conditions that cause bottlenecks or latency issues for Electron renderer processes, along with a breakdown of operations within each transaction. So you can easily see which span is taking the longest and save yourself the frustration of clicking into every trace and span by getting operation details and insights on a silver platter.

Electron Release Health

Version 3.0 automatically captures session data to help you better understand how each app release is performing. Sentry calculates crash-free sessions, crash-free users, and version adoption by release. If a release inexplicably tanks your crash-free users, you can see the moment a release starts to degrade and get a list of new issues and failed transactions. Plus, we also provide a list of commit authors so you can skip git blame and just Slack your teammates who are best suited to fix the problem (that they created).

But hey, don’t know why there was a dramatic dip in crash-free sessions? This is fine. Click “Open in Discover” from any release details page; then, Sentry will automatically build and run a query for events by release to help you get to the root of any problem.

Explore whether multiple conditions contribute to an issue: does this only happen on a specific machine or operating system? Or does it affect all Linux machines? Or all Windows 11 users? Answer it quickly in Discover.

Discover also includes pre-built searches that help answer common questions about all your events, unique errors, and clients. And if you don’t like these thoughtful, hand-crafted, pre-built searches, you can modify them and save them to a custom dashboard.

Electron Error Monitoring

Understanding issues across various devices with access to different metadata, latencies, network issues, and upgrade cadences is hard and getting exponentially harder. Sentry for Electron 3.0 helps developers see what actually matters, solve issues faster with richer context, and learn continuously about their applications.

Not only will you see the user impact of each issue, but you’ll also get all the information you need to know about the machines the error happened on, like:

CPU (processor count, machine architecture)
Screen (density, resolution, height/width)
Memory
Language Details (locale details)

To wrap it up

Developers need visibility into when a user writes to disk, fetches media, loads an object in a given viewport—or, simply when a user tries to launch the app. Without this data, untreated performance problems and serious errors inevitably result in a poor user experience.

Update your Electron SDK to immediately know everything about the hardware, OS, screen orientation, network conditions, and device language settings for every issue caught and reported by Sentry. Solve issues with context and confidence and save time by not looking for obscure machines to recreate the problem. With the latest Electron SDK and Sentry, you can easily uncover the who, what, when, where, and why behind every issue.

Get started with Sentry for Electron and drop us a line on GitHub, Twitter, or our Discord. And if you’re new to Sentry, you can try it for free today or write to sales@sentry.io to get started.

Deprecation From U2F API to WebAuthn

Rahul Chhabria — Wed, 19 Jan 2022 01:48:03 +0000

By: Richard Ma

If you’re using the U2F API for registration and authentication of your U2F devices, you will notice a dire situation is coming soon: Google Chrome will no longer support U2F API after February 2022:

For anyone using U2F API in their web apps, like us at Sentry, their users who had 2FA enabled with U2F devices would not be able to sign in. To remedy this, there’s a shiny new specification written by the World Wide Web Consortium (W3C) and the Fast IDentity Online Alliance (FIDO) that will solve all our problems.

In this blog post, we will go into the weeds on migrating from U2F API to WebAuthn.

WebAuthn

WebAuthn is an API that allows web services to seamlessly integrate strong authentication into applications. With WebAuthn, web services can offer the user a choice of authenticators, such as security keys (Yubikeys, Titan Keys, for example) or built-in platform authenticators (biometric readers). In addition, it is supported by all the leading browsers — including Safari, which U2F API was not — and web platforms, which standardizes the integration of strong authentication. You can read more on WebAuthn’s website.

Migrating to WebAuthn From U2F API

Now, here’s the part you’re all here for, the migration to WebAuthn. Let’s break this down into two main parts:

Part 1: Authenticating existing U2F and new WebAuthn devices with WebAuthn

Step 1: Generating the challenge and state
Step 2: Creating PublicKeyCredential data
Step 3: Verifying the device

Part 2: Registering new devices with WebAuthn

Step 1: Generating the PublicKeyCredentialRpEntity and state
Step 2: Creating PublicKeyCredential data
Step 3: Registering the device

Part 1: Authentication

Let’s start with authentication so existing users can continue to log in. This is also important because newly registered WebAuthn devices can’t log in without a working WebAuthn login.

To understand the authentication flow, we can look at the following diagrams:

[Source left][12] [Source right][13]

We’ll be using Python for the backend APIs. The U2F API sequence (left) is very similar to the WebAuthn sequence (on the right). We simply have to replace three API calls: u2f.start_authentication() and u2f.finish_authentication() in the backend, and u2f.sign() in the frontend.

Let’s start with u2f.start_authentication(), which takes in the browser’s application ID and the currently registered devices.

The U2F API authentication process starts with the backend generating a challenge, an example of which is shown below:

{
  "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
  "challenge": "VwmGI-4…",
  "registeredKeys": [
      {
          "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
          "keyHandle": "cxSl4oQ…",
          "publicKey": "BP4Q8MR…",
          "transports": [
                "usb"
          ],
          "version": "U2F_V2"
      }
  ]
}

This challenge is sent to the browser where u2f.sign() takes the challenge as an input and returns a promise that is the result of:

verifying the application identity of the caller
creating a client data object and using the client data
the application ID
the key handle

This creates a raw authentication request message and sends it to the U2F device. The result of the promise should look like this:

{
    "keyHandle": "cxSl4oQ…",
    "clientData": "eyJ0eXA…",
    "signatureData": "AQAAAQ4…"
}

Once the result of the promise is sent to the server, we call U2f.complete_authentication() with the following two parameters: the original challenge data and the newly generated client data object passed in. This method will verify the device with the parameters and return the device info if it succeeded. From there, the server can allow the user to pass through the 2FA process.

Step 1: Generating the challenge and state

To start the migration process, let’s first replace u2f.start_authentication() with its counterpart. The data types that the WebAuthn API takes are not quite the same ones used in U2F API. In fact, one of the main pain points was converting the necessary fields into the correct data type.

We want to authenticate users on legacy U2F API and WebAuthn, so we will create an authentication server first. The following will create an authentication server using WebAuthn that is backwards compatible with U2F API:

webauthn_authentication_server = U2FFido2Server(
    app_id=u2f_app_id, 
    rp={
        "id": “sentry-webauthn.io”, 
        "name": "Sentry with WebAuthn"}
)

Your app_id will be the same value as before. The rp, or Relying Party, is an object that contains an ID, which is the hostname of the URL, and the name of your Relying Party.

Next, we need to generate a list of credentials, which is the same as the list of devices for U2F API. Keep in mind that the list of credentials will contain both WebAuthn and U2F API registered devices and that list needs to be manipulated.

credentials = []

for device in self.get_u2f_devices():
    if type(device) == AuthenticatorData:
        credentials.append(device.credential_data)
    else:
        credentials.append(create_credential_object(device))

The devices that are registered with WebAuthn have the type AuthenticatorData. For devices registered with U2F API, we need to create an AttestedCredentialData object for them to be compatible with WebAuthn. The following is the function we wrote that decodes the necessary parameters and creates the credential data:

def create_credential_object(registeredKey):
    return base.AttestedCredentialData.from_ctap1(
        websafe_decode(registeredKey["keyHandle"]),
        websafe_decode(registeredKey["publicKey"]),
    )

[Source of function][16]

With that, we can begin the registration process by calling register_begin() on the WebAuthn server that we created earlier, with credentials as its parameter. This will return a challenge and state.

The challenge is needed for the browser to perform authentication, but we will only use the PublicKey object within the challenge. In addition, you should store the state in your sessions, as it will be needed later.

challenge, state = self.webauthn_authentication_server.authenticate_begin(
    credentials=credentials
)
request.session["webauthn_authentication_state"] = state
return ActivationChallengeResult(
    challenge=cbor.encode(challenge["publicKey"])
)

We also encoded the challenge using the [FIDO2 CBOR][18] library, as we will be sending it to the frontend using JSON, which does not handle binary representation well on its own. On the frontend, we convert the JSON string back into a byte array and decode it to return the challenge to its original form.

Step 2: Creating PublicKeyCredential for authentication

To replace u2f.sign(), we can call its WebAuthn equivalent navigator.credentials.get() with the challenge data. This library is now native to modern browsers, so don’t worry about importing any libraries.

const challengeArray = base64urlToBuffer(
    challengeData.webAuthnAuthenticationData
);
const challenge = cbor.decodeFirst(challengeArray);

challenge.then(data => {
    webAuthnSignIn(data);
}).catch(err => {
    const failure = 'DEVICE_ERROR';
    Sentry.captureException(err);
    this.setState({
        deviceFailure: failure,
        hasBeenTapped: false,
    });
});

function webAuthnSignIn(publicKeyCredentialRequestOptions) {
    return navigator.credentials.get({
        publicKey: publicKeyCredentialRequestOptions,
    }).then(data => {
        // Send to backend
    })
}

When the promise is resolved after calling navigator.credentials.get(), we need to send the appropriate data to the backend to finish authentication. To convert the PublicKeyCredential that was obtained from navigator.credentials.get(), we can run it through the following function:

getU2FResponse(data) {
    if (data.response) {
        const authenticatorData = {
          keyHandle: data.id,
          clientData: bufferToBase64url(data.response.clientDataJSON),
          signatureData: bufferToBase64url(data.response.signature),
          authenticatorData: bufferToBase64url(data.response.authenticatorData),
        };
        return JSON.stringify(authenticatorData);
    }

    return JSON.stringify(data);
}

Step 3: Verifying the device

For the final step, we can pass the original challenge and this new response to the backend. We need to create a list of credentials to validate the device, then call authenticate_complete on the authentication server that was made earlier with the following parameters:

state: the value which we stored in session from start_authentication
credentials: list which we just generated
A websafe_decode for the following:
- credential_id: a “keyHandle” of the response object
- client_data: a “clientData” of the response object passed through fido2.client.ClientData
- auth_data: an “authenticatorData” of the response object passed through fido2.ctap2.authenticatorData
- signature: a “signatureData” of the response object

self.webauthn_authentication_server.authenticate_complete(
    state=request.session["webauthn_authentication_state"],
    credentials=credentials,
    credential_id=websafe_decode(response["keyHandle"]),
    client_data=ClientData(websafe_decode(response["clientData"])),
    auth_data=AuthenticatorData(websafe_decode(response["authenticatorData"])),
    signature=websafe_decode(response["signatureData"]),
)

If this function returns true, you are now fully authenticated and good to go!

For our deployment, this feature was behind a flag to manage the rollout and for error monitoring. (We recommend using Sentry 😉.) We deployed this feature independently from registration because the area of effect is limited in the event of an incident.

Congrats! The authentication part of the migration is finished.

Part 2: Registration

Similar to authentication, first, let’s take a look at the flow:

[Source left][12] [Source right][20]

The flow of registration is almost identical to that of the authentication process. The three components we need to deprecate in order to migrate to WebAuthn are u2f.begin_registration() and u2f.complete_registration() in the backend, and u2f.register() in the frontend.

Once again, we will start with u2f.begin_registration(). This API call takes in the u2f application ID and list of registered devices. This results in the following data being sent to the browser to begin the registration process:

{
    "appId": "https://your-webauthn-app/2fa/u2fappid.jso",
    "registerRequests": [
        {
            "challenge": "uexgFSl…",
            "version": "U2F_V2"
        }
    ],
    "registeredKeys": []
}

Similar to u2f.sign(), u2f.register() will take the previously generated results and return a promise that will look like the following if the device is registrable:

{
    "registrationData": "BQQ1xlC…",
    "version": "U2F_V2",
    "challenge": "Jkh_Tfo…",
    "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
    "clientData": "eyJ0eXA…"
}

Along with the previously generated challenge, this result is sent to the backend where u2f.complete_registration() takes in both parameters and generates the following data object:

{
    "appId": "https://your-webauthn-app.io/2fa/u2fappid.json",
    "keyHandle": "SnllNGC…",
    "publicKey": "BIs-gsW…",
    "transports": [
        "usb"
    ],
    "version": "U2F_V2"
}

You can save this dictionary and name of the device. They will be used for authentication.

Just like before, let’s replace u2f.begin_registration() with its counterpart. We need to create a FIDO2Server and import it from fido2.server. We don’t need to make it backward compatible, as all new devices will be registered with WebAuthn.

Step 1: Generating the PublicKeyCredentialRpEntity and state

We start with importing the fido2.webauthn library to create a PublicKeyCredentialRpEntity. To create the entity, we need to pass in the Relying Party’s ID and name. With the entity, we pass it into Fido2Server to set things up.

from fido2.server import Fido2Server
from fido2.webauthn import PublicKeyCredentialRpEntity

rp = PublicKeyCredentialRpEntity(rp_id, "Sentry")
webauthn_registration_server = Fido2Server(rp)

When the server is created, we can optionally pass in a list of registered devices to avoid duplicate registrations.

Next, we call register_begin() with:

user: dictionary with the user’s id, name, and display name
credentials: the list we just generated
user_verification: normally defaulted to discouraged

You should get a result similar to this:

  "publicKey": {
    "authenticatorSelection": {
      "userVerification": <UserVerificationRequirement.DISCOURAGED: "discouraged">},
      "challenge": b"\xe9)#\x86\xfa.\xa9\x82r\x86\xf7\x15e\xb5m\xdc"
                   b"\x1dR\xc4\x1b\xdb\xab\x94\x88\xb8\x94\xf43"
                   b"b\x03\xab\n",
      "excludeCredentials": [],
      "pubKeyCredParams": [
        {"alg": -7,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">},
        {"alg": -8,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">},
        {"alg": -37,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">},
        {"alg": -257,
         "type": <PublicKeyCredentialType.PUBLIC_KEY: "public-key">}],
      "rp": {"id": "<$YOUR_APP>",
      "name": "Sentry"},
      "user": {"displayName": "<$YOUR_NAME>",
      "id": b"\x00",
      "name": "<$YOUR_APP>"
    }
  }
}

The registration data as seen above will be returned. Encode the registration data with the cbor.encode() method and base64 encode that to a string.

publicKeyCredentialCreate = cbor.encode(registration_data)
return b64encode(publicKeyCredentialCreate)

Set the state for later use in the session.
Interestingly, the data from WebAuthn is exactly the same from U2F API, despite looking different on first glance. WebAuthn sets the challenge in a byte array and the clientData in a COSE key object (which is a CBOR map), while U2F API uses an encoded string.

Step 2: Creating PublicKeyCredential for registration

Once the registration data is received by the browser, we convert the string into a buffer and decode it with this library. This gives us the data that will be used as the input parameter of navigator.credentials.create():

challenge, state = self.webauthn_authentication_server.authenticate_begin(
    credentials=credentials
)
request.session["webauthn_authentication_state"] = state

return ActivationChallengeResult(challenge=cbor.encode(challenge["publicKey"]))

webAuthnRegister(publicKey) {
    const promise = navigator.credentials.create({publicKey});
    this.submitU2fResponse(promise);
}

Step 3: Registering the device

We have reached the final step where we need to extract some data from the response from navigator.credentials.create(). The following are needed for register_complete():

state: from user sessions, set earlier after begin_registration()
client_data: from decoding the data’s cliendDataJSON and creating a ClientData Object with it
AttestationObject: from decoding the data’s attestationObject and creating an AttestationObject Object with it

data = json.loads(response_data)
client_data = ClientData(
    websafe_decode(data["response"]["clientDataJSON"])
)
att_obj = base.AttestationObject(
    websafe_decode(data["response"]["attestationObject"])
)

binding = webauthn_registration_server.register_complete(
    state, client_data, att_obj
)

ClientData should look like this:

{
    "type": "webauthn.create",
    "challenge": "_Uas89Y…",
    "origin": "https://<$YOUR_APP>",
    "crossOrigin": false
}

AttestationObject should look like this:

AttestationObject(
    fmt: 'none', 
    auth_data: AuthenticatorData(
        rp_id_hash: h'74cb1ce…5',
        flags: 0x41, 
        counter: 281, 
        credential_data: AttestedCredentialData(
            aaguid: h'0000000…', 
            credential_id: h'63af2c9…', 
            public_key: {...}
        ), 
        att_statement: {}, 
        ep_attr: None, 
        large_blob_key: None
    )
)

Registered device data:

AuthenticatorData(
    rp_id_hash: h'74cb1ce…',
    flags: 0x41, 
    counter: 281, 
    credential_data: AttestedCredentialData(
        aaguid: h'0000000…', 
        credential_id: h'63af2c9…', 
        public_key: {...}
    )
)

With that, you can save the registered device data. The registration process is complete.
Just like authentication, the deployment of this feature was behind a feature flag to manage the rollout. There were no database migrations needed as WebAuthn is backward compatible with U2F API.

That’s a wrap

With that, WebAuthn should be set up and you can purge U2F API from your codebase. If you have made it this far, we hope that this guide was useful to you. With some planning, you will make it in time before Chrome locks out users from your application. All the best!

—

Everything we do at Sentry is built in the open. Find us on GitHub.

Bytecode Transformations: The Android Gradle Plugin

Rahul Chhabria — Tue, 14 Dec 2021 23:05:18 +0000

By: Roman Zavarnitsyn

This is the first part of a blog post series about bytecode transformations on Android. In this part we’ll cover different approaches to bytecode manipulation in Java as well as how to make it work with Android and the Android Gradle plugin. In the next two parts we’ll dive into the actual bytecode, bytecode instructions and how we can modify the bytecode and inject our own instructions, using Room as an example. In the last part we’ll see how we can test our transformations and how it can influence Gradle build speed.

Detecting the slow spots in your app without having to write a single line of code is an intriguing idea, but is also not that easy to implement. At Sentry we wanted to provide the capability for Android users to automatically measure the execution time of database queries because oftentimes they can become a hidden bottleneck for app performance. Room is a widely-adopted ORM solution built by Google and is a go-to library for persistence for the majority of the Android developers, so it was an obvious choice for us to start with.

If we want database operations to show up in Sentry, we need to wrap them into special objects called Spans. In short, Spans are application events that have a start and end time and some metadata like operation name, description, etc. For example, this is how the performance breakdown looks for a popular open-source app tivi:

On the screenshot above, there’s a parent span ui.screen.interaction that contains multiple child spans, for instance, the network request span with a http.client operation, duration 225ms and a request url as a description. If you want to learn more about performance @ Sentry, check this post out.

Back to the topic, this all means we need to find a way to inject our code before and after Room executes its queries to measure their execution time. There’s a QueryCallback available in the Room API, but it’s invoked only before a query gets executed, so we couldn’t really utilize it.

Options

Since there’s no way to know when a SQL query starts and finishes at runtime, we started looking into compile-time solutions. There are a few well-known options in the JVM world available for bytecode weaving:

AspectJ: an AOP framework, which allows extending methods and plugging into their execution from outside of the target codebase.
ASM: a bytecode manipulation framework, which allows dealing with bytecode directly. For example, it’s used by R8 and D8 on Android for optimizing and dexing the bytecode.
Other higher-level abstractions like Javassist: are all based on ASM, but have a nicer and easier-to-understand APIs to deal with.

While it would be logical to pick something higher-level, considering we had no expertise in any of those, we’ve decided to look into how we could marry those with the Android Gradle plugin (AGP), as we are aiming to transform Android apps and need to support things like differe build types, flavours and so on. A quick search revealed that we could go with:

Gradle’s TransformAction: a plain Gradle API for transforming outputs. This is used, for example, for dexing, jetifying, and many other things that the Android Gradle plugin does.
AGP’s Transform: an old API from AGP that gives a list of inputs to be transformed, depending on the options provided. It also handles full/incremental builds automatically. Now deprecated in favor of the new API.
AGP’s transformClassesWith: the new API from AGP that allows registering an ASM ClassVisitor for visiting bytecode instructions and instrumenting .class files. It utilizes the aforementioned TransformAction to transform dependencies and provides a Gradle task that handles full/incremental builds automatically. Available from AGP version 4.2.0 and above.

The first option would require us to manually hook into the AGP process and deal with its artifacts, so we decided to look into options 2 and 3 and compare them, as they come directly from the vendor.

Previously, in the old AGP versions (pre-4.2.0), if one would like to instrument compiled classes, they would need to register their own Transform, traverse the input files and perform instrumentation for each of those files using ClassWriter from ASM. For each such Transform AGP would register a new Gradle task, so if you happen to have 10 transforms instrumenting your application, you would end up with 10 additional Gradle tasks doing almost the same thing - iterating over the changed files, reading the bytecode, applying their own transformations and writing the bytecode back.

This is horrible for the build speed and most of that can be commonized up until the point of actually instrumenting the bytecode.

The new transformClassesWith API tackles exactly that by providing a single API for registering ClassVisitors and abstracting away file iteration and reading/writing the bytecode. It collects all visitors in a single list and then, for each file, runs all of them in order of registering, meaning there’s just a single Gradle task running for all transformations.

We’ve decided to go with ASM + transformClassesWith pack, deliberately supporting only the new versions of AGP.

Note, that if you want to support bytecode transformations in lower AGP versions (below 4.2.0) you still need to use the old Transform API. However, you can perform an AGP version check at runtime and choose either a new or an old API depending on it. An example can be seen in the Hilt Gradle plugin.

Using new transform APIs

Registering AsmClassVisitorFactory

As this post is not about how to create Gradle plugins, I will skip the setup part, but in a nutshell, we have to implement the Plugin interface from Gradle and override a single method called apply, which is called when the Gradle plugin is applied to a project:

class SentryPlugin : Plugin<Project> {

    override fun apply(project: Project) {
        ...
    }
}

After that we have to listen when the Android Gradle plugin is applied to the project and retrieve the new AndroidComponentsExtension like this:

project.pluginManager.withPlugin("com.android.application") {
    val androidComponentsExtension =
    project.extensions.getByType(AndroidComponentsExtension::class.java)
    ...
}

The extension has a special onVariants method that configures the build variants:

androidComponentsExtension.onVariants { variant ->
    ...
}

Finally we can register our custom AsmClassVisitorFactory for the variant through transformClassesWith:

variant.transformClassesWith(
  SpanAddingClassVisitorFactory::class.java,
  InstrumentationScope.ALL
) { params ->
  if (extension.tracingInstrumentation.forceInstrumentDependencies.get()) {
    params.invalidate.setDisallowChanges(System.currentTimeMillis())
  }
  params.debug.setDisallowChanges(
    extension.tracingInstrumentation.debug.get()
  )
  params.tmpDir.set(tmpDir)
}

transformClassesWith accepts 3 parameters:

ClassVisitorFactory: a factory, which provides a ClassVisitor implementation and defines whether this visitor is interested in instrumenting a given class
InstrumentationScope: either ALL or PROJECT. Defines whether the instrumentation applies only for project files or for project files and their dependencies (e.g. jars). In our case, we were interested in instrumenting all Room queries, regardless of their origin, so we set it to ALL

If you’re using InsrumentationScope.ALL, beware that Gradle will cache the transformed artifacts across builds as long as the InstrumentationParameters do not change. This may come as a surprise while developing, as some of the classes coming from the dependencies might not show up for instrumentation. We found it useful to have a boolean parameter, which would invalidate the transform caches by simply setting System.currentTimeMillis and allow us to always receive all classes for instrumentation.

Configuration function to be applied before passing the necessary parameters for the ClassVisitorFactory

The InstrumentationParameters are the way to pass information from the plugin to the ClassVisitorFactory. They are being used as Gradle inputs, this means they contribute to the up-to-date checks of the task and should be properly annotated. For example, here we are setting a debug boolean as well as a tmpDir to use this information later and stream debug output of instrumentation into a file under the tmpDir.

Implementing AsmClassVisitorFactory

For the ClassVisitorFactory it’s necessary to implement 2 methods:

createClassVisitor which provides a custom ClassVisitor from ASM that does the actual visiting of bytecode instructions and transformation
isInstrumentable which defines whether a given class is applicable for instrumentation or not

It is also necessary to specify an implementation of InstrumentationParameters as a type for AsmVisitorFactory or use InstrumentationParameters.None in case there are no params.

abstract class SpanAddingClassVisitorFactory :
    AsmClassVisitorFactory<SpanAddingClassVisitorFactory.SpanAddingParameters> {

    interface SpanAddingParameters : InstrumentationParameters {

        @get:Input
        @get:Optional
        val invalidate: Property<Long>

        @get:Input
        val debug: Property<Boolean>

        @get:Internal
        val tmpDir: Property<File>
    }

    override fun createClassVisitor(
        classContext: ClassContext,
        nextClassVisitor: ClassVisitor
    ): ClassVisitor =
        TODO("If we return true from the isInstrumentable below, we should return a ClassVisitor that will inject our code for measuring the execution time")

    override fun isInstrumentable(classData: ClassData): Boolean =
        TODO("Determine if we are interested in instrumenting the given ClassData. For us it would mean a class annotated with @Dao")
}

Inside the isInstrumentable method, we determine whether we are interested in instrumenting the given ClassData and later return our custom ClassVisitor from the createClassVisitor method in case we are. Note, however, that it’s always a good practice to fall back to nextClassVisitor in case there’s no ClassVisitor for the given class, otherwise the Gradle build will fail.

Last, let’s look at the ClassData structure:

interface ClassData {
    /**
     * Fully qualified name of the class.
     */
    val className: String

    /**
     * List of the annotations the class has.
     */
    val classAnnotations: List<String>

    /**
     * List of all the interfaces that this class or a superclass of this class implements.
     */
    val interfaces: List<String>

    /**
     * List of all the super classes that this class or a super class of this class extends.
     */
    val superClasses: List<String>
}

It may seem to have everything to help us determine whether a class is suitable for instrumentation or not, but there’s a setback which we’ll cover in the next post.

Using the new AGP transform APIs with ASM looks like an obvious choice for bytecode manipulation for Android as it affects the build speed almost unnoticeable (we’ll cover that later), handles full/incremental builds on its own, and offers a great API surface via ASM at the same time.

In the next part, we’ll talk about Room internals, how we collected the methods for instrumentation, and what tools are available out there for dealing with ASM.

The code is available in the sentry-android-grade-plugin repo, specifically:

By the way, if you are already using the Sentry Android Gradle plugin, give this new Room instrumentation a try in version 3.0.0-beta.1 , we would appreciate your feedback via GitHub issues. If not, it’s time to start using Sentry — request a demo and try it out for free.