8 posts tagged with "Swift"

Charts play a key role when it comes to turning raw data into something people can actually understand. Whether you're tracking user activity, visualizing growth, or summarizing analytics, charts help communicate complex information quickly and clearly.

SwiftUI already gives you a powerful way to build clean, modern interfaces. And with Apple's Charts library, bringing interactive and visually rich charts into your iOS apps feels like a natural extension of the SwiftUI workflow - not an extra chore.

In this guide, we'll walk through how to integrate charts into SwiftUI applications, build different chart types like bar charts, line charts, and pie-style charts, and tweak their appearance so they fit seamlessly into your app's design. The goal is simple: help you move from data to insight with minimal effort and maximum clarity.

Let's start building.

Importing the Charts Library​

Apple introduced the Charts framework starting from iOS 16. It's built specifically for SwiftUI, so it fits naturally into the declarative UI flow you're already using.

First, make sure your project meets these requirements:

• iOS 16 or later
• SwiftUI-based app
• Xcode 14+

Then, simply import Charts wherever you plan to use it:

import Charts

That's it. No external dependencies, no package managers, no setup headaches.

Creating a Simple Bar Chart​

Let's start with something simple and practical - a bar chart. Bar charts are usually the first choice when you want to compare values across categories, like monthly sales, usage stats, or feature adoption.

Suppose you want to show how sales performed over the first few months of the year. With SwiftUI and the Charts library, you can set this up with very little code:

struct BarChartView: View {
    var body: some View {
        Chart {
            BarMark(
                x: .value("X", 1),
                y: .value("Y", 10)
            )
            
            BarMark(
                x: .value("X", 2),
                y: .value("Y", 20)
            )
            
            BarMark(
                x: .value("X", 3),
                y: .value("Y", 30)
            )
            
            BarMark(
                x: .value("X", 4),
                y: .value("Y", 40)
            )
            
            BarMark(
                x: .value("X", 5),
                y: .value("Y", 50)
            )
            
            BarMark(
                x: .value("X", 6),
                y: .value("Y", 60)
            )
        }
        .frame(height: 300)
        .padding()
    }
}

Here's what's happening under the hood:

• Chart acts as the container that holds and renders your chart.
• BarMark tells SwiftUI that you want to display the data as vertical bars.
• Each tuple in the data array represents a single bar:
  • The first value maps to the x-axis (for example, months).
  • The second value maps to the y-axis (such as sales numbers).

SwiftUI automatically handles layout, scaling, and axis rendering for you. You don't need to manually calculate positions or sizes - the chart adapts based on the data you provide. This makes bar charts a great starting point when you want quick, readable visualizations without a lot of setup.

Once you're comfortable with this pattern, you can easily extend it to real-world data coming from APIs, databases, or user input.

Creating Other Types of Charts​

Once you understand one chart type, the rest feel familiar. You mostly change the mark.

Line Chart (Great for Trends)​

Perfect for showing progress over time.

var body: some View {
    Chart(data) { item in
        LineMark(
            x: .value("Day", item.day),
            y: .value("Value", item.value)
        )
        .foregroundStyle(.blue)
        .lineStyle(StrokeStyle(lineWidth: 3))
        
        PointMark(   // optional: show dots on points
            x: .value("Day", item.day),
            y: .value("Value", item.value)
        )
        .foregroundStyle(.blue)
    }
    .frame(height: 300)
    .padding()
}

Line charts are ideal for things like:

• Growth metrics
• Performance tracking
• Time-based analytics

Pie Chart (Proportions and Distribution)​

let data: [Country] = [
    Country(name: "India", population: 1428),
    Country(name: "China", population: 1412),
    Country(name: "USA", population: 339),
    Country(name: "Indonesia", population: 277),
    Country(name: "Pakistan", population: 240),
    Country(name: "Brazil", population: 216)
]
var body: some View {
    Chart(data) { item in
        SectorMark(
            angle: .value("Population", item.population)
        )
        .foregroundStyle(by: .value("Country", item.name))
    }
    .frame(height: 350)
    .padding()
}

Use pie charts sparingly. They're best when comparing parts of a whole, not precise values.

Scatter Plot (Finding Patterns)​

Scatter plots are useful when comparing two continuous variables.

var body: some View {
    Chart(sampleData) { dataPoint in
        PointMark(
            x: .value("Hours Used", dataPoint.dailyHours),
            y: .value("Social Battery %", dataPoint.socialBattery)
        )
    }
    .frame(height: 300) // Set a frame height for better display
    .padding()
}

These are great for:

• Identifying outliers
• Spotting correlations
• Visualizing raw data points

You can choose the chart type that best suits your data visualization needs.

Customizing the Look and Feel of Your Charts​

Once your chart is working, the next question is always the same: "How do I make this match my app's design?"

That's where customization comes in.

SwiftUI's Charts library gives you a lot of control over how your charts look - colors, text styles, and overall presentation - without turning your code into a mess.

Here's a simple example of customizing a bar chart:

var body: some View {
    Chart(data, id: \.x) { item in
        BarMark(
            x: .value("X Value", item.x),
            y: .value("Y Value", item.y)
        )
        .foregroundStyle(Color.red)          // Fill color
        .clipShape(RoundedRectangle(cornerRadius: 4))
        .annotation(position: .overlay) {    // Stroke workaround
            Rectangle()
                .stroke(Color.black, lineWidth: 1)
        }
    }
    .chartXAxis {
        AxisMarks { _ in
            AxisValueLabel()
                .font(.system(size: 12))      // Axis label font
        }
    }
    .chartYAxis {
        AxisMarks { _ in
            AxisValueLabel()
                .font(.system(size: 12))
        }
    }
    .frame(height: 300)
    .padding()
}

What this customization does:

• Bar color: Each bar is styled with a red fill using foregroundStyle(Color.red). This helps the data stand out instantly and keeps the chart visually focused on the values.

• Rounded bar edges: The clipShape(RoundedRectangle(cornerRadius: 4)) adds subtle rounded corners to the bars. It's a small touch, but it makes the chart look cleaner and more modern.

• Bar outlines for clarity: Since Charts doesn't provide a direct stroke modifier for bars, an overlay annotation is used to draw a black border around each bar. This improves visual separation, especially when bars are close in value.

• X-axis labels: The X-axis is customized using chartXAxis with AxisMarks. The label font is set to a smaller system font, keeping it readable without overwhelming the chart.

• Y-axis labels: The Y-axis follows the same approach as the X-axis, maintaining visual consistency and ensuring values are easy to scan at a glance.

• Layout and spacing: The chart is given a fixed height of 300 points and padded on all sides. This prevents crowding and ensures the chart fits comfortably within the UI.

These small tweaks go a long way. They help your charts feel like a natural part of your app instead of something that looks bolted on. Whether you're matching a brand color palette or improving readability, SwiftUI makes it easy to fine-tune charts without overcomplicating your layout.

Once you're comfortable with these basics, you can layer in more advanced styling to create charts that are both functional and visually polished.

Conclusion​

We've walked through how charts fit into SwiftUI apps using the Charts library—from setting things up to building bar charts, line charts, pie charts, and scatter plots, and finally shaping them to match your app's design. Each chart type serves a purpose, and when used thoughtfully, they turn raw numbers into something users can actually understand.

The best approach is to start small. Add a simple bar chart. Make sure it's clear and readable. Then, as your app grows, experiment with lines, points, and sectors where they make sense. Charts should guide users, not overwhelm them—clarity always matters more than visual flair.

When done right, charts don't just display data. They help users see patterns, understand trends, and make confident decisions. And that's where good design and good data meet.

Happy coding.

You've probably felt it before.

You tap a button. Nothing happens.

You scroll a list. It stutters.

You wonder if the app is frozen - or just thinking too hard.

Most of the time, this isn't because the app is doing too much. It's because it's doing the right work in the wrong place.

Modern iOS apps are expected to stay smooth no matter how much work is happening behind the scenes. Network calls, image processing, database operations - all of this needs to run without blocking the UI.

That's where concurrency and parallelism come in. When used correctly, they let your app work hard in the background while the UI stays smooth and responsive. When used poorly, they lead to hangs, race conditions, and subtle performance issues that users feel long before you see a crash report.

Let's break this down - clearly and practically.

Concurrency vs Parallelism - Clear and Simple​

Before jumping into code, let's clear up the big question:

Concurrency means handling multiple tasks at the same time conceptually - tasks start, run, and complete in overlapping time periods.

Parallelism means executing multiple tasks literally at the same time, usually on multiple CPU cores.

Think of concurrency as juggling multiple balls, while parallelism is having multiple people toss those balls simultaneously.

In Swift, both concepts help make apps feel fast and responsive, but they solve slightly different problems.

Achieving Concurrency in Swift​

Concurrency is about managing multiple tasks at once, even if they aren't running at the same exact moment. Swift gives us multiple tools to achieve this, each suited for different scenarios.

1. Grand Central Dispatch (GCD)​

GCD is the foundation of swift multithreading. It allows you to move work off the main thread so your UI doesn't block.

let queue = DispatchQueue(label: "com.example.myqueue")
queue.async {
    // perform task asynchronously
}

GCD works well when:

• You need quick background execution
• You want control over priority (QoS)
• You're performing independent tasks like parsing, disk I/O, or network calls

However, GCD relies heavily on callbacks. As projects grow, nested closures can become difficult to read and maintain.

2. Async / Await (Swift Concurrency)​

Swift's modern concurrency model changed how developers think about async code.

Instead of managing queues and callbacks, you write code that reads almost like synchronous logic:

func fetchData() async throws -> Data {
    let url = URL(string: "https://example.com/data.json")!
    let (data, _) = try await URLSession.shared.data(from: url)
    return data
}

do {
    let data = try await fetchData()
    // handle data
} catch {
    // handle error
}

This makes concurrent flows easier to reason about and significantly reduces mistakes.

Async/await is ideal when:

• Performing network requests
• Coordinating dependent async tasks
• Writing readable, structured concurrency code

Swift Concurrency doesn't replace GCD entirely - but for most app-level use cases, it's now the preferred approach.

3. Operation and OperationQueue​

Operation and OperationQueue sit at a higher abstraction level than GCD.

They shine when:

• Tasks depend on each other
• You need cancellation support
• You want fine-grained control over execution order

class MyOperation: Operation {
    override func main() {
        // perform task
    }
}

let queue = OperationQueue()
let op1 = MyOperation()
let op2 = MyOperation()
let op3 = MyOperation()
op2.addDependency(op1)
op3.addDependency(op2)
queue.addOperations([op1, op2, op3], waitUntilFinished: false)

Operations can be paused, cancelled, prioritized, and chained - making them perfect for complex workflows like file uploads, background syncing, or batch processing.

If GCD is a power tool, OperationQueue is a workflow manager.

Achieving Parallelism in Swift​

Parallelism is about doing multiple things at the same time, usually across different CPU cores. This is where performance gains can be dramatic - but also risky if misused.

1. Threading​

At the lowest level, Swift supports manual thread management.

let thread = Thread {
    // perform task in separate thread
}
thread.start()

Direct threading is rarely recommended today. It's easy to misuse and hard to scale safely. Most modern Swift apps rely on higher-level abstractions like GCD or Swift Concurrency instead.

Still, understanding threads helps you understand why parallelism behaves the way it does.

2. DispatchQueue.concurrentPerform​

When you need true parallel execution, DispatchQueue.concurrentPerform is one of the most powerful tools available.

let count = 1000000
var results = [Int](repeating: 0, count: count)
DispatchQueue.concurrentPerform(iterations: count) { index in
    results[index] = index * 2
}

This method:

• Splits work across available CPU cores
• Executes iterations in parallel
• Blocks until all tasks complete

It's ideal for CPU-intensive tasks like:

• Image processing
• Data transformation
• Batch calculations

Important: Never run concurrentPerform on the main thread. Doing so will block the UI and negate all benefits of parallelism.

Used correctly, concurrentPerform is one of the most efficient ways to handle parallel workloads in multithreading Swift apps.

Choosing the Right Tool (This Matters)​

Not every concurrency problem needs the same solution.

• Use Swift Concurrency for async workflows and networking
• Use GCD for low-level control and background tasks
• Use concurrentPerform for parallel CPU-bound work

Real-world apps often mix all three. That's normal. The goal isn't purity - it's performance without surprises.

Why Multithreading Swift Apps Still Goes Wrong​

Most performance issues don't come from doing too much work.

They come from doing the right work in the wrong place.

Common mistakes include:

• Blocking the main thread
• Running parallel work where concurrency would suffice
• Overusing background threads without coordination

This is where monitoring becomes just as important as implementation.

Final Thoughts​

Concurrency isn't about making your app complicated.

It's about making it feel effortless.

When multithreading Swift is done right, users never notice it.

They just notice that your app feels fast, smooth, and reliable.

Understanding data structures and algorithms in Swift is important - but understanding multithreading Swift, concurrency models, and parallel execution is what keeps your app fast, responsive, and trustworthy.

Because great apps aren't just built - they're engineered to stay responsive under pressure.

When you build SDKs or apps long enough, you start noticing patterns.

One of them is this: developers love adding motion to their apps - until motion starts fighting back.

GIFs are a perfect example.

On paper, they're simple. Drop in a file, play it, done.

In reality? Native iOS support is… let's say minimal. You end up decoding frames manually, managing timing, watching memory spike, and wondering why something so small turned into a whole sprint.

I've seen teams delay releases just because a loading GIF caused stutters on older devices. And I've also seen apps feel instantly more polished once GIFs were handled properly.

That's where SwiftyGif quietly does its job - and does it well.

Let's talk about why it exists, how it fits into real products, and how to use it without turning your codebase into a science experiment.

Why GIF Handling Is Hard in iOS​

iOS technically supports animated images, but real-world apps expose the cracks quickly. Large GIFs consume memory fast. Multiple GIFs on a screen can slow down scrolling. Older devices struggle even more.

Most teams don't notice these issues during development. They show up later - as UI lag, dropped frames, or subtle performance regressions.

SwiftyGif exists to take care of these problems so you don't have to reinvent GIF playback logic yourself.

Integrating SwiftyGif​

Getting started with SwiftyGif is straightforward. You can add it to your project using whichever dependency manager you already use - CocoaPods, Carthage, or Swift Package Manager.

CocoaPods:

pod 'SwiftyGif'

Carthage:

github "SwiftyGif/SwiftyGif"

Swift Package Manager: Add the package with the URL https://github.com/alexiscreuzot/SwiftyGif for compatibility with Swift Package Manager.

There's no special setup, no configuration files, and no extra steps after installation. Once the dependency is added, you're ready to start displaying GIFs.

This simplicity is intentional. SwiftyGif is designed to fit into existing projects without friction.

Displaying a GIF in Your App​

SwiftyGif introduces a custom image view called SwiftyGifView. Think of it as a smarter UIImageView - built specifically for GIF playback.

let gifImageView = SwiftyGifView()
gifImageView.setGifImage(gif)

Advantages of Using SwiftyGif​

Controlling GIF Playback​

Once a GIF is loaded, SwiftyGif gives you control when you need it.

You can pause and resume animations, adjust playback speed, control looping behavior, and even respond to user interactions like taps. This is useful when GIFs are part of user flows, not just decorative elements.

The following code snippet illustrates this control:

let gifManager = SwiftyGifManager(memoryLimit: 20)
let gifImageView = SwiftyGifView()
gifImageView.setGifImage(gif, manager: gifManager) 
gifImageView.speed = 2.0 

For example, slowing down a GIF during onboarding or stopping animations when a screen goes off-screen helps keep the experience intentional and efficient.

Keeping Animations Smooth​

One of SwiftyGif's biggest strengths is performance. The library is optimized to keep animations smooth without overloading the CPU.

Even with larger GIFs, playback stays stable. Scrolling doesn't stutter. UI responsiveness remains intact.

This matters more than it sounds. Animations that feel "almost smooth" are often worse than no animation at all. SwiftyGif focuses on avoiding that middle ground.

Managing Memory with SwiftyGifManager​

GIFs can consume a lot of memory, especially when multiple animations are active at the same time. SwiftyGif addresses this with SwiftyGifManager.

The manager lets you define memory limits for GIF playback. Once those limits are reached, SwiftyGif handles things gracefully instead of letting memory usage spiral out of control.

This is especially helpful in apps with feeds, dashboards, or onboarding flows that use more than one GIF at a time.

let gifManager = SwiftyGifManager(memoryLimit: 20)
let gifImageView = SwiftyGifView()
gifImageView.setGifImage(gif, manager: gifManager)

Loading GIFs from a URL​

SwiftyGif also supports loading GIFs directly from remote URLs. This is useful for apps that display dynamic or server-driven content.

You point the GIF view to a URL, and SwiftyGif takes care of loading and playback. No custom decoding logic needed.

As always, remote content should be handled thoughtfully—but SwiftyGif makes the technical side simple.

let remoteGifURL = URL(string: "https://example.com/your_gif.gif") 
let gifImageView = SwiftyGifView() 
gifImageView.setGifFromURL(remoteGifURL)

Common Pitfalls to Avoid​

Even with the right library, a few mistakes can still sneak in:

• Overusing large GIFs where lightweight animations would work
• Forgetting to manage memory when multiple GIFs are active
• Treating decorative animations as free from performance cost

SwiftyGif helps, but thoughtful usage matters just as much.

Final Thoughts​

SwiftyGif doesn't try to be flashy. It doesn't promise magic.

It does something better: it solves a very specific problem - GIF handling on iOS - and does it reliably, efficiently, and with respect for your codebase.

If your app uses GIFs in any meaningful way, SwiftyGif gives you control without complexity. And when paired with proper performance visibility, it helps ensure those animations stay delightful instead of becoming liabilities.

Sometimes, the best libraries are the ones you don't think about after integration. SwiftyGif fits that description perfectly.

Every Swift developer eventually runs into the same moment.

The app works fine… until it doesn't.

Scrolling becomes sluggish. Memory usage slowly creeps up. A feature that worked perfectly in testing starts behaving strangely in production. And when you dig deep enough, the issue often traces back to one thing: how data is stored and managed.

That's where swift data structures come in.

This blog is a practical walkthrough of data structures in Swift, not from a textbook point of view, but from how they actually show up in real iOS apps. If you've ever wondered how DSA in Swift connects to everyday development, this guide is for you.

If you've ever integrated a third-party iOS framework, you already know this truth: great code means nothing if the documentation is confusing.

An iOS framework exists to make another developer's life easier. But without clear documentation, even the most powerful framework feels hard to adopt, risky to use, and easy to abandon. Documentation isn't an afterthought - it's the bridge between your framework and its users.

Think of your documentation as a guided walkthrough. When done right, it answers questions before they're asked and removes friction at every step. Let's walk through how to build documentation that developers trust, understand, and keep coming back to.

Imagine this: You've spent months building your iOS app. You've tested it, fine-tuned every detail, and you're finally ready to show it to the world. You hit "Submit to App Store"... and then the anxiety kicks in. Did you miss anything? Will it get rejected? Did you choose the right account type?

Deploying an iOS app isn't just about shipping code. It's about understanding Apple's ecosystem, speaking their language, and following their rules - without losing your mind.

I've been through the launch chaos, the unexpected rejections, and the "why didn't anyone tell me this?" moments. So here's your shortcut: the 10 things I wish I knew before hitting that submit button.

Ever tapped a button in your app and waited... and waited... until you started questioning your life choices?

Yeah, that's an app hang.

It's not a crash. It's worse. Your app doesn't explode, it just freezes. Quietly. Awkwardly. Like someone forgot their lines on stage and now the whole audience is staring.

App hangs are sneaky. They don't always show up in crash reports. But your users feel them. In the lags, the unresponsive screens, the moments when they swipe but nothing moves. And if it happens too often? That uninstall button starts looking real attractive.

But it doesn't have to be that way.

Let's fix the freeze before the curtain falls.

You're test-driving a car. Everything seems fine, until you hit 60 mph and the steering wheel starts shaking. Weird, right? You take it back to the shop, only to hear, "Oh, that only happens on highways. We didn't test for that."

Now imagine that same moment, but with your iOS app. It passes all your tests locally. Looks great on your simulator. But when it lands in the real world? Crash on iOS 16.3. A layout glitch on the iPhone SE. A memory spike on iPadOS.

Here comes your first comment, "App keeps crashing when I switch tabs. iOS 16.3."

And boom! Your 5-star rating dips, users uninstall, and your team scrambles in damage-control mode.

That's why modern iOS teams don't just test. They test right.

Let's talk about Appxiom + BrowserStack - a killer combo that brings you deep device coverage and smart issue detection in one efficient workflow.

What is BrowserStack?​

BrowserStack is your all-access pass to testing iOS apps on real devices, without needing to build your own hardware lab. From the latest iPhones to older iPads running quirky iOS versions, it gives you cloud-based access to actual devices (not emulators), so you can run both manual and automated tests with ease. Think of it as having a fully-stocked Apple device warehouse right in your browser. Whether you're running regression tests or checking cross-device compatibility, BrowserStack helps you ensure your app looks sharp and works flawlessly, no matter where or how your users open it.

What Is Appxiom?​

Now here's where Appxiom steps in, and turns up the heat in the best way possible.

Appxiom is a real-time issue detection platform that helps you catch crashes, performance drops, and user-impacting bugs during testing, before your users ever see them.

If BrowserStack shows you where your app might stumble, Appxiom shows you why. While your tests run across real iOS devices, Appxiom is silently at work in the background, listening in on everything that happens beneath the surface.

Crashes during navigation? It catches them. Memory leaks hiding behind a clean UI? Detected. Janky scrolls, sluggish taps, or performance drops? Marked. Bugs that quietly kill conversions? Flagged with business impact.

Appxiom doesn't just collect this data, it translates it into rich, actionable insights. You get real-time issue reports that include severity, device context, and user flow impact, all wrapped in a developer-friendly dashboard. Instead of digging through logs or guessing what went wrong, you know exactly what to fix, and why it matters.

The result? You stop reacting to bug reports after users complain and start resolving issues before they ever hit production. With Appxiom riding alongside your BrowserStack tests, every test session becomes a proactive debugging session. It's like running your app through an MRI while it performs on stage—and getting the results instantly.

How to Integrate BrowserStack and Appxiom Together for Smarter iOS Testing​

Here's how to integrate BrowserStack and Appxiom into your iOS workflow:

Step 1: Setting Up BrowserStack​

Head to browserstack.com and create your account. Explore their documentation to understand device setup, automation tools, and test configuration. Install required SDKs and dependencies for running your iOS tests.

Step 2: Integrating Appxiom​

Register with Appxiom at appxiom.com and log in to the dashboard. Click "Add App" to connect your iOS app. Follow integration steps in the Appxiom Docs to embed the Appxiom framework into your app. Run a quick sanity test to make sure the integration is successful.

Step 3: Running Tests on BrowserStack​

Choose your target iPhones or iPads from BrowserStack's real device lab. Configure the test environment and load your Appxiom-integrated app. Use your test framework to run automated test cases. Monitor UI behavior, response times, and user flow - all in real-time.

Step 4: Analyzing Appxiom Reports​

Log in to your Appxiom dashboard after running tests on BrowserStack. Identify performance issues, crashes, UI glitches, or slowdowns detected during testing. Review detailed bug reports with data points like issue type, severity, device info, and timestamps. Use these insights to reproduce and resolve bugs quickly.

The Power of Pairing: Why BrowserStack + Appxiom Just Makes Sense​

Imagine this: You're testing your iOS app on a real iPhone 14 using BrowserStack. Everything looks smooth on the surface. But beneath that pixel-perfect UI, Appxiom is quietly watching for deeper issues - things no visual test would catch.

That's the beauty of using both tools together. One handles the "outside," the other handles the "inside." And when paired, they give you something every developer dreams of: complete visibility.

Here's what you really get when you bring them together:

1. Enhanced Device Coverage​

With BrowserStack, you're testing on actual iOS hardware. No flaky emulators, no simulator - only bugs. You see what your users see.

2. Silent Bug Surveillance​

Silent killers like API issues, memory spikes, UI jank usually go undetected until it's too late. Appxiom flags them in real time, even if no one reports them.

3. Crystal-Clear Reproduction​

When a bug appears, Appxiom shows you where, how, and why it happened, right down to the device, OS version, and line of code. Combine that with BrowserStack's stable testing environment, and reproducing bugs becomes effortless.

4. Fix What Matters, Fast​

Not all bugs deserve a panic patch. Appxiom tells you which ones are impacting your users the most, so you prioritize smart, not out of fear.

5. Save Time. Save Budget. Save Face.​

No more post-release chaos. With better pre-release coverage and proactive detection, you catch problems early, and avoid costly fixes later.

In Summary​

Testing on real devices? Necessary. Catching hidden bugs before users do? Priceless.

With BrowserStack, you test how your app looks and behaves. With Appxiom, you understand how it performs and fails, even when it looks fine.

Together? You've got a world-class iOS testing workflow that keeps your app sharp, your users happy, and your team confident.

Start using Appxiom with BrowserStack today!

Because flawless apps aren't built by chance. They're built by choice.