Forem: Bugfender

Android Geofencing: How to Set Up and Troubleshoot Location Triggers

Bugfender — Thu, 29 May 2025 05:40:44 +0000

You’re probably familiar with Android Geofencing already, but in case this is your first rodeo, it’s a location-based system that can receive access to a mobile device’s location data, and trigger all kinds of functions when users pass in and out of specific areas. The ads our users see, the content they can stream, the offers they receive via push notifications… all can be triggered by geofencing.

Geofencing and location updates can be tricky, particularly for those who are still starting out in Android app development. So in this article we’re going to unpack it for you, looking specifically at:

How to set up Android Geofencing.
How to create an Android Geofence API.
How to handle geofence transitions.
How to deal with edge cases and unexpected problems.

And loads of other stuff around geofence monitoring. By the end of the article, you should have a sound working knowledge of geofencing, which you can take into your day-to-day work as an Android developer.

First, can you give me a bit more context?

Why sure.

Android Geofencing allows a mobile app to define a circular, virtual boundary with the three parameters of latitude, longitude and radius. This. in turn, allows the creation of a notification when the mobile device enters, exits or stays within the geofence area defined by these parameters.

Geofencing is activated through the GeofencingClient API. The Google Play Service provides location tracking, and Google Maps provides geofence visualization. The location of the Android device is established through GPS, cellular networks and WiFi.

A key point to note here is that Google Maps does not work with the geofencing app system directly. Instead, it indicates the device’s location on a map, as the following code demonstrates:

              // Initialize Geofencing Client

var geofencingClient: GeofencingClient = LocationServices.getGeofencingClient(this)

                   // Define a geofence

val geofence = Geofence.Builder()
            .setRequestId("MyGeofence")
            .setCircularRegion(37.7749, -122.4194, 500)
            .setExpirationDuration(Geofence.NEVER_EXPIRE)
            .setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
            .build()

Now, how do we create Geofencing in an Android application?

Ok, let’s get into it.

As we mentioned earlier, we can use Google Play services to create geofencing technology in an Android mobile app. But how do we go about implementing it?

Well to get started, we’ll need to add Google Play service dependencies in the build.gradle file provided via Android Studio, and sync the project. Google Maps is optional, so if we need to visualize a device’s location information, or indicate where a geofenced area is on a map, we’ll need to go ahead and add Google Maps specifically. Here’s some code to show you how:


dependencies {
    implementation 'com.google.android.gms:play-services-location:21.0.1' 
    implementation 'com.google.android.gms:play-services-maps:18.1.0'   
}

Now let’s add location services and background permission in the AndroidManifest.xml file.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION"/>

Runtime permission is also required on Android OS 6.0 API onwards.

val myRequest= registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->
                if (permissions[Manifest.permission.ACCESS_FINE_LOCATION] == true) {
                    Log.d("MyGeofence", "permission granted")
                } else {
                    Log.e("MyGeofence", "permission denied")
                }
            }
        myRequest.launch(
            arrayOf(Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_BACKGROUND_LOCATION)
        )

Great, now we’re cooking! Let’s initialize the Geofencing Client API and define the Geofence object.

// Initialize Geofencing Client

var gClient: GeofencingClient = LocationServices.getGeofencingClient(this)              



     // Define a geofence

val geofence = Geofence.Builder()
            .setRequestId("MyGeofence")
            .setCircularRegion(37.7749, -122.4194, 500)
            .setExpirationDuration(Geofence.NEVER_EXPIRE)
            .setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
            .build()

Ok, we’re nearly done. But next, we need to define location-sensitive requests and pending intent. This is required to trigger an event when the geofencing Android app enters or exits a geofenced location.

     // Create Geofencing Request

 val gRequest = GeofencingRequest.Builder()
            .setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
            .addGeofence(geofence)
            .build()

      // Create Pending Intent 

        val intent = Intent(this, MyGeofenceBroadcastReceiver::class.java)
        val pIntent = PendingIntent.getBroadcast(
            this, 0, intent , PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_MUTABLE
        )

        // Add Geofence

       gClient.addGeofences(gRequest , pIntent )
            .addOnSuccessListener {
                Log.d("MyGeofence", "successfully added")
            }
            .addOnFailureListener { e ->
                Log.e("MyGeofence", "Failed to add", e)
            }

Lastly, we need to create a broadcast receiver class to receive pending intent, and notify the user when they enter or exit the geofenced area.

class MyGeofenceBroadcastReceiver: BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val myGeofencingEvent = GeofencingEvent.fromIntent(intent)
        if (myGeofencingEvent.hasError()) {
            Log.e("MyGeofenceReceiver", "error: ${geofencingEvent.errorCode}")
            return
        }

        when (myGeofencingEvent.geofenceTransition) {
            Geofence.GEOFENCE_TRANSITION_ENTER -> Log.d("MyGeofenceReceiver", "Entered!")
            Geofence.GEOFENCE_TRANSITION_EXIT -> Log.d("MyGeofenceReceiver", "Exited!")
            else -> Log.d("MyGeofenceReceiver", "Unknown")
        }
    }
}

Ok, awesome. Now, let’s create a geofence transition in our app

When we talk about a geofence transition, we’re talking about when we define a circle with a certain radius on a map. It triggers when the mobile device enters, exits or stays within the boundary of the circle. This is something that Android app developers often struggle with, but really it’s pretty simple.

The geofencing API helps to create transitions, and triggers can be handled through the BroadcastReceiver class.

class MyGBR: BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val myGf = GeofencingEvent.fromIntent(intent)

        when (myGf.geofenceTransition) {
            Geofence.GEOFENCE_TRANSITION_ENTER -> Log.d("MyGBR", "Entered!")
            Geofence.GEOFENCE_TRANSITION_EXIT -> Log.d("MyGBR", "Exited!")
            Geofence.GEOFENCE_TRANSITION_DWELL -> Log.d("MyGBR", "Dwell!")
            else -> Log.d("MyGBR", "Unknown")
        }
    }
}

Note that we need to register BroadcastReceiver class in AndroidManifest.xml file.


<receiver android:name=".MyGBR"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.android.gms.location.GeofenceTransition"/>
    </intent-filter>
</receiver>

Ok, let’s look at how to create an Android geofence API

Here, we will create a geofence API with the help of Node.js and Firebase (remember that Firebase is used to store data). We will need to use the Restful API in our Android application later.

First, let’s create a directory and install node.js.


mkdir geofence-api
cd geofence-api
npm init -y


npm install express firebase-admin cors body-parser

Now it’s time to create a Firebase Store project and download the serviceAccountKey.json file. Then, we can incorporate this file into the project directory, and create a server.js file for backend code.

To get things going, let’s create a Restful API.

const express = require("express");
const admin = require("firebase-admin");
const bodyParser = require("body-parser");
const cors = require("cors");

const app = express();
app.use(cors());
app.use(bodyParser.json());

admin.initializeApp({
  credential: admin.credential.cert(require("./serviceAccountKey.json")),
});

const db = admin.firestore();
const geofenceCollection = db.collection("geofences");

// Add a new geofence
app.post("/create-geofence", async (req, res) => {
  try {
    const { id, latitude, longitude, radius } = req.body;
    await geofenceCollection.doc(id).set({
      latitude,
      longitude,
      radius,
    });
    res.status(200).json({ message: "Geofence created successfully!" });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

// Get all geofences
app.get("/geofences", async (req, res) => {
  try {
    const snapshot = await geofenceCollection.get();
    const geofences = snapshot.docs.map(doc => ({ id: doc.id, ...doc.data() }));
    res.status(200).json(geofences);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

// Remove a geofence
app.delete("/delete-geofence/:id", async (req, res) => {
  try {
    const { id } = req.params;
    await geofenceCollection.doc(id).delete();
    res.status(200).json({ message: "Geofence deleted successfully!" });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

// Start server
const PORT = process.env.PORT || 5000;
app.listen(PORT, () => console.log(`Server running on port ${PORT}`));

Nice, clean code right? Note that the endpoint of the API will be http://your-server-ip:5000/.

Testing Android geofencing using Google Maps

Next, we need to implement Google Maps in our app to test the geofencing function. This is a really important part of the process, as geofencing can throw up lots of edge cases.

Let’s initialize the map in Kotlin code; the SupportFragmentMagaer class will provide an instance of MapFragment.


class MyMapActivity : AppCompatActivity(), OnMapReadyCallback {

    private lateinit var gfClient: GeofencingClient
    private lateinit var gMap: GoogleMap

    private val gfLatLng = LatLng(37.7749, -122.4194)
    private val gfRadius = 500f // 500 meters
    private val gfId = "MyMapActivity"

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // Initialize Geofencing Client
        gfClient = LocationServices.getGeofencingClient(this)

        // Load the Google Map
        val mapFragment = supportFragmentManager.findFragmentById(R.id.map) as SupportMapFragment
        mapFragment.getMapAsync(this)

        // check permissions
        checkPermission()
    }

    override fun onMapReady(map: GoogleMap) {
        gMap = map
        gMap.uiSettings.isZoomControlsEnabled = true

        // Add marker and circle for geofence
        gMap.addMarker(MarkerOptions().position(gfLatLng).title("Geofence Location"))
        gMap.addCircle(
            CircleOptions()
                .center(gfLatLng)
                .radius(gfRadius.toDouble())
                .strokeColor(0xFFFF0000.toInt()) // Red outline
                .fillColor(0x22FF0000) // Transparent fill
        )

        gMap.moveCamera(CameraUpdateFactory.newLatLngZoom(gfLatLng, 15f))

        // Set up geofencing
        createGeofence()
    }

    private fun createGeofence() {
        if (ActivityCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) {
            Log.e("MyMapActivity", "Location permission not granted")
            return
        }

        val geofence = Geofence.Builder()
            .setRequestId(gfId)
            .setCircularRegion(gfLatLng.latitude, gfLatLng.longitude, gfRadius)
            .setExpirationDuration(Geofence.NEVER_EXPIRE)
            .setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
            .build()

        val gfRequest = GeofencingRequest.Builder()
            .setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
            .addGeofence(geofence)
            .build()

        val intent = Intent(this, MyGBR::class.java)
        val pIntent = PendingIntent.getBroadcast(
            this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_MUTABLE
        )

        gfClient.addGeofences(gfRequest, pIntent)
            .addOnSuccessListener {
                Log.d("MyMapActivity", "Geofence added successfully")
            }
            .addOnFailureListener { e ->
                Log.e("MyMapActivity", "Failed to add geofence", e)
            }
    }

    private fun checkPermission() {
        val requestPermissionLauncher =
            registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->
                if (permissions[Manifest.permission.ACCESS_FINE_LOCATION] == true) {
                    Log.d("MyMapActivity", "Location permission granted")
                } else {
                    Log.e("MyMapActivity", "Location permission denied")
                }
            }
        requestPermissionLauncher.launch(
            arrayOf(Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_BACKGROUND_LOCATION)
        )
    }
}


class MyGBR: BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val myGf = GeofencingEvent.fromIntent(intent)

        when (myGf.geofenceTransition) {
            Geofence.GEOFENCE_TRANSITION_ENTER -> Log.d("MyGBR", "Entered!")
            Geofence.GEOFENCE_TRANSITION_EXIT -> Log.d("MyGBR", "Exited!")
            Geofence.GEOFENCE_TRANSITION_DWELL -> Log.d("MyGBR", "Dwell!")
            else -> Log.d("MyGBR", "Unknown")
        }
    }
}



<receiver android:name=".MyGBR"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.android.gms.location.GeofenceTransition"/>
    </intent-filter>
</receiver>

Now, the fun bit; we can open the emulator and run the code.

Click on the ‘More’ section with the three-dot icon, then move to the location information section and enter the above latitude and longitude. Remember to check the logcat after entering the geofenced area, and again when exiting.

What if Android geofencing does not trigger?

If moving in or out of the geofenced area is not triggering an event, you’ll need to troubleshoot the error. This will likely have arisen from one or more of the following issues:

Whether device location permission granted or not.
Whether the latest Google Play service installed or not (if not, be sure to update).
Whether GPS is enabled with an option for high location accuracy.
Whether the PendingIntent is properly used with correct flags.
Whether the radius is correct (if not, increase and then test again).
Whether geofence permissions have expired (check geo fence expiry and transition type).

Also, be sure to ceck logcat messages and errors, and debug each line with a mock location.

If everything is working fine and set up correctly, restart the device and try again.

Android Geofencing FAQ

What is Android Geofencing and how does it work?

Android Geofencing uses latitude, longitude, and radius to define a virtual area. When a device enters or exits this area, it triggers events through the GeofencingClient API.

How do I set up Android Geofencing in an app?

To set up Android Geofencing, add location permissions, initialize the GeofencingClient, create a geofence, and use a BroadcastReceiver to handle transitions.

What permissions are needed for Android Geofencing?

You need ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, and ACCESS_BACKGROUND_LOCATION permissions, plus runtime handling for Android 6.0 and above.

How do I visualize a geofence on Google Maps?

To show a geofence on the map, draw a marker and circle using the Google Maps API. This gives users a visual of the geofenced area.

How do geofence transitions work in Android?

Geofence transitions are triggered when the user enters, exits, or dwells in the set area. You handle these using the GeofencingEvent inside a BroadcastReceiver.

What is a PendingIntent in geofencing and why is it used?

A PendingIntent lets the geofencing service send events to your app, even when it’s not running. It links transition triggers to your logic.

How do I build a backend geofence API using Node.js and Firebase?

You can build a backend using Express and Firebase to store and manage geofence data. These APIs connect with the app to create or remove geofences.

Why is my Android geofence not triggering?

Check permissions, GPS status, radius size, Google Play Services updates, and your PendingIntent setup. Use logcat for deeper debugging.

What’s the best geofence radius for Android apps?

Use a radius between 100 to 500 meters. It balances accuracy and performance across most devices and network conditions.

How can I test Android geofencing in the emulator?

Use the emulator’s location settings to send test coordinates. Monitor the logcat to confirm whether the geofence was entered or exited.

And we’re done!

Well, nearly. No coding article would be complete without some take-home points, so here are some key things to remember when testing the geofencing function of an Android app:

The radius should be defined between 100 and 500 meters for better performance.
High Accuracy mode must be selected for fast location-tracking.
PendingIntent.FLAG_MUTABLE must be used for Android 12+ device testing.
Test a mock location, to ensure it is working properly in the emulator, before testing the real app.

If we are still encountering errors, we can register geofences using GeofencingClient and check the event in the BroadcastReceiver class.

Any other questions? Just write to us. We’re always happy to chat Android Geofencing, or any other Android coding topic. So whatever questions you’ve got, hit us up.

Happy Coding!

How to Use Android Vitals to Improve App Stability and Google Play Ranking

Bugfender — Tue, 20 May 2025 08:25:47 +0000

If you want to run a health-check on your Android app, Android Vitals is a great piece of kit.

Developed by Google and available on the Google Play console, this performance and stability checking tool helps us fix issues proactively, improve the technical quality of our apps, and avoid uninstalls. Crucially, it will also improve our Google Play ranking, because Google Play ranks app quality using Android Vitals data.

And the really great news? We don’t need to write any code to use Android Vitals; Google automatically collects data from our app and shows the relevant metric in the Play Console. However, if we want to really maximize Android Vitals, we need to do a bit more digging.

So over the next few hundred words, we’re going to open up Android Vitals, looking at stuff like:

How we set up Android Studio.
How we can maximize the benefits of Google Play.
How we deal with edge cases and common technical issues.
How can we achieve app store optimization by monitoring core vitals proactively.

The article should be ideal for any developer who is new to Android Vitals and wants a working knowledge. It’s a topic that you can get to grips with quickly, so by the end of this article you should be ready to fly.

But first, some core concepts to understand

As an Android Vitals rookie, there are some acronyms you’ll need to grasp. Here are three that every Android developer should know.

The Application Not Responding (ANR) rate shows the percentage of sessions where the app freezes.
The LMK (low memory kill) rate shows the percentage of foreground service.
The crash rate shows the percentage of user-perceived crashes of active users on a daily basis.

And there’s some other core stuff that will come up when we get our Android Vitals reports.

Start-up times. When the app initially starts and calls the onCreate() method, it has three metric data points: cold start (when the app is relaunched after running in the background for a while), warm start (when the app is brought to the foreground from the background), and hot start (when the app’s activity is already in the foreground).

Rendering UI. This refers to the rate at which a frame is generated from our app, and displayed upon the screen. If our apps have a UI refresh rate below 60 FPS, this is termed excessive slow frames. If a frame takes more than 700 ms to render, this is called excessive frozen frames.

Battery Usage: This provides a metric for how much battery life is being drained in different sessions. The key sessions are app wakeup, wake locks (when the app carries on running when the screen is off), background WiFi scans and background network usage.

Permission: This shows how many permissions we are denying the user. If we are taking unnecessary permissions, this indicates bad UX design and may impact our app store optimization.

Now, I now what you’re wondering: how can I find all that data?

Well all we need to do is log into the Play Console and select the apps for which we want to receive Android Vitals data. Here’s a screenshot.

Ok, now let’s look at setting up Android Vitals

How do we set up Android Vitals using Android Studio?

As mentioned, we don’t need to write any code in our app to set up Android Vitals. Google Play does the work for us, and all we’ve got to do is follow this path.

Select the app that we want to monitor in our Play console.
Navigate to “Monitor and improve > Android Vitals > Overview.”

Simple! Once we upload the file to the Play Store, Google will start collecting data about its performance and quality, and the dashboard means we can monitor it easily.

Now let’s see how Android Vitals works in Google Play

Once Android Vitals has processed the data, it will show in the Play Console in different metrics. Let’s go point by point.

Data Collect: When the app runs on an Android device, Google will collect the performance data automatically and store the data in its database. The data is stored in different metrics, like devices and regions.
Data Process: Google Play processes raw data into specific Android Vitals metrics. These metrics are grouped by device, device OS, region, country, and app version. The groupings help us to identify the issues properly.
Monitor Dashboard: We can easily view the data in the Android Vitals dashboard to identify app performance and stability.

And that’s the basics done! If you still have any doubts, check out the official Android app developer video.

Part 2: More advanced concepts on Android Vitals

Ok, now we’re hitting the big stuff: complex debugging, deep-checking of performance issues and analysis of Play Console reports. These advanced concepts will help us improve app stability and, just as importantly, reduce crashes and ANR.

Once we’ve optimized the crashes, Google will automatically improve our ranking in the Play Store, and our app will become virally popular around the world (ok, we can’t control the last bit, but you get my point).

So let’s look at some ways we can improve our ranking.

Debug ANR (Application Not Responding): When the main UI thread is blocked for more than 5 seconds, the ANR dialog appears. How do we fix this? Well first, we need to analyze when the main thread blocks the UI from the Play Console report, then fix the code and upload the new build in the Play Console accordingly (heads-up: most cases of ANR occur during network operation, query execution and complex calculation, and they prevent the user from providing input in the app).
Battery drain and wake lock: As goes without saying, we need to be careful that the app does not consume much battery life. Thankfully, the Battery Historian tool provided by Android Studio helps us cut the code into pieces, execute it in different time frames and analyze partial wake locks and background processes. If we have a wake lock issue, we can optimize it using the WakefulBroadcastReceiver or JobScheduler tasks.
Background Network Usage: We can check network usage using Network Profiler in Android Studio, or once again we can use JobScheduler.
Native code and JNI Issues: When dealing with Java Native Interface (JNI) issues, we need to debug crashes from C++/NDK code. Google Play Console native crash reports help to optimize the issue, and we can use ndk-stack to symbolize the crash logs from the native library.
UI render and frame drops: Poor UI performance leads to frame drops – simple. But there’s plenty we can do here. After analyzing a UI report from the rendering section of the Android vitals dashboard, we can use GPU Profiler to detect UI overflow. We have to analyze Choreographer logs to measure the frame rendering time.7

As general points of good practice, it’s advisable to use SVG images instead of PNG or JPEG images (SVG images reduce out-of-memory errors), and handled runtime permissions properly. Specifically, we need to be careful that users cannot skip the permission dialog.

Finally, let’s look at different metrics and edge cases

One of the great things about Android Vitals is that we can use it to measure different metrics and plan for edge cases. This will help us carry out deep debugging and fix issues, while metrics data helps to categorize issues and priorities.

Here are some possible edge cases that we should anticipate and fix proactively, to ensure our apps are error-free and maintain that precious Play Store ranking.

Slow networks or repeated network calls cause the ANR dialog.
Large bitmap image processing in low-memory devices causes out-of-memory errors.
App start-up will be delayed because lots of operations are on the onCreate() method.
The app will hang when too many SDKs initialize at app launch.
If the app wakes up on the device too frequently, it will drain too much battery.
Continuous location updating in the background will cause high battery consumption.
Complex UI or animation requires too much time to render frames.
Nested RecyclerViews cause slow performance in the app.
An API request with retry options, or an API running on the main thread, will cause the ANR dialog.
Downloading large images or videos blocks the UI.
If Android 6.0 permissions are denied, this can affect app functionality and lead to increased crash frequency.

Android Vitals FAQ

What is Android Vitals and why is it important for app developers?

Android Vitals is a Google Play tool that tracks app performance, crashes, and battery usage. Monitoring it helps developers fix issues and improve app stability, which can boost Google Play rankings.

How can I access Android Vitals in the Google Play Console?

To access Android Vitals, go to the Play Console, select your app, and navigate to Monitor and improve > Android Vitals > Overview. You’ll see metrics like crash rate, ANR rate, and battery usage.

Do I need to add code to use Android Vitals in my app?

No, Android Vitals collects data automatically. You don’t need to add code—just upload your app to the Play Store and Google handles the rest through the Play Console.

What does ANR rate mean in Android Vitals?

The ANR (Application Not Responding) rate shows how often your app’s UI thread is blocked for more than 5 seconds. High ANR rates hurt user experience and affect app rankings.

How can I fix battery drain issues highlighted in Android Vitals?

To fix battery drain, use tools like Battery Historian or JobScheduler. Look out for wake locks, background WiFi scans, and frequent background activity—all of which can drain battery fast.

What causes slow UI rendering in Android apps?

Slow UI rendering happens when frames take too long to render. Common causes include complex layouts, animations, or nested RecyclerViews. Use GPU Profiler and Choreographer logs to spot these issues.

How does Android Vitals affect my app’s ranking on Google Play?

Google uses Android Vitals data to rank apps. Apps with fewer crashes, better battery use, and smoother UI are more likely to appear higher in Play Store search and recommendations.

And we’re done!

Well, almost. Before we go, let’s summarize what we have learned today, from app creation to app publishing in the Play Store.

We need to regularly follow up on the Android Vitals report and continuously fix crashes for a better user experience and optimal Google Play ranking.
During app development, we need to remember the above edge cases and develop the app accordingly.
We should think about the user experience at all times. User permissions provide a prime example; even a slight error with permissions can have a major impact on the overall look and feel of our app.

Any other questions? Just write to us. We’re always happy to chat about Android Vitals or any other Android topic. So whatever questions you’ve got, we’re hear to chat.

Happy Coding!

Kotlin Extension Functions: Add Functionality Without Modifying Code

Bugfender — Fri, 16 May 2025 08:24:51 +0000

Imagine you own a car. It’s reliable, runs smoothly and gets you where you need to go. But one day, you realize you need a GPS navigation system for better routes. What do you do?

Would you redesign the entire car just to integrate GPS, or would you simply install a GPS device on the dashboard? Of course, the smarter choice is to add the GPS instead of modifying the car’s built-in system.

This is exactly how a Kotlin Extension Function works. Instead of modifying the code of an existing class or interface, or relying on its inheritance, developers can add new functionality externally – just like upgrading your car without altering its core structure.

And here’s the really cool part about extension functions: whereas in Java they look like regular functions, in Kotlin, they appear as if they are directly part of the inner class itself. This makes them more intuitive, and it’s great for static method coding (where we call a class directly by name, without creating an object).

Today, we’re going to dive into the whole topic of extension functions usage in Kotlin. It should be ideal for:

Developers taking their first steps in the Kotlin programming language.
Those who want to see how static function coding can improve their daily lives as devs.
Those who need to see the Kotlin class methodology in practice.

Good to go? Let’s get stuck into it.

First off: how do we create a Kotlin function?

In Java, if you want to add a new function to an existing class (such as String or List), you typically extend the class through inheritance or create a separate utility function, both of which can make the code clunkier and harder to maintain. In Kotlin? Well, to show you the difference, let’s run some code.

For example, let’s create a function that performs an operation on a String. In Java code, a developer might do it like this:

String myString = someOperation(input);

But with Kotlin Extension Functions, the source code is way simpler and more natural:

val escaped = input.someOperation()

Here, input is a String, and we are calling someOperation() on it, just like a built-in method of String class.

Not only is this easier to read, but Integrated Development Environments (IDEs) will be able to offer the extension method as an autocomplete option, as if it were a standard method on the String class.

An important thing to note

As we’ve noted, extension functions don’t actually modify the classes they extend. As a Kotlin developer, when we define an extension, we aren’t adding new members to the original class itself, we’re simply allowing new functions to be called using dot notation on the relevant Kotlin variable.

One key thing to remember is that extension functions are resolved at compile time. Kotlin determines which extension function to call, based on the type of the variable, before the program runs.

Excited to learn more?

Great: we’re excited to teach you! Let’s dive in and explore:

Writing our own extension functions. Syntax and fundamentals of creating extensions.
Leveraging nullability in extension functions. Handling nullable types effectively.
Generics in extension functions. Making extensions more flexible.
Extension properties. Adding properties without modifying the class.
Infix with extension functions. The cherry on the top – Enhancing readability and elegance.
Companion object extensions. Extend the companion class object.
Advanced extension function ideas. Useful functions you can implement right away.
Using extension functions in Java (interoperability). Calling Kotlin extensions from Java.
When and how to use extension functions. Best practices and real-world use cases.
Organizing extension functions. Keeping your code clean and maintainable.

Writing our own Extension Functions

Now, this is the moment we’ve all been waiting for, right? We’ve talked enough about theory, now let’s get into the coding!

Understanding the Anatomy of an Extension Function

fun ClassName.functionName(parameters): ReturnType {
    // Function body
}

Writing an extension function is just like writing any regular function in Kotlin. The only difference? We specify the class that we are extending before the function name; this is how we declare an extension!

Example: Creating a Full URL from a Path

Imagine you have an image path, and you always need to append a BASE_URL before using it in your app.

// Base URL
val BASE_URL = "<https://some.base.url>"

// Extension function to convert a relative path into a full URL
fun String.toFullUrl() = BASE_URL + this

fun main() {
    val image = "/images/my_image.jpg"

    val url = image.toFullUrl()

    println(url)
}

// OUTPUT
// <https://some.base.url/images/my_image.jpg>

The toFullUrl() function extends the String class seamlessly, without modifying its internal implementation or structure.

But why use an extension function?

Instead of writing BASE_URL + imagePath everywhere, an extension function keeps it reusable and clean!

Leveraging nullability in Extension Functions

When working with nullable numbers, comparison operations can get tricky due to the need for explicit null checks. Let’s see how we can simplify this using extension functions!

The Problem: Comparing Nullable Numbers

Imagine you have two nullable numbers that need to be compared:

val numA: Int? = 5
val numB: Int? = null

val isNumAGreaterThanNumB = numA > numB // ERROR!

Oops! The IDE throws errors:

Type mismatch: Required Int, but found Int?
Operator call issue: 'numA.compareTo(numB)' is not allowed on a nullable receiver

A Quick Fix: Using `?:` (Elvis Operator)

val isNumAGreaterThanNumB = (numA ?: 0) > (numB ?: 0)

This instance works, but writing ?: 0 everywhere is a waste of your time. Instead, it can be improved with an extension function.

The Better Solution: Using an Extension Function

Instead of adding null checks manually every time, let’s create a reusable extension function that handles nullability for us:

fun Number?.isGreaterThan(number: Number?): Boolean {
    if (this == null) return false
    if (number == null) return true
    return this.toDouble() > number.toDouble()
}

fun main() {
    val numA: Int? = 5
    val numB: Int? = null
    println(numA.isGreaterThan(numB)) // true
}

And that’s it – no more manual null checks!

This simple extension function removes boilerplate code, improves readability and ensures our comparisons always work, regardless of null values or numeric types.

But wait, there’s more!

We’ve mastered handling nullability, but what if we want our extension functions to be even more flexible?

Let’s dive into the power of Generics in Extension Functions!

Generics in Extension Functions!

Generics allow us to write a single extension function that works with multiple types.

For example, instead of writing different functions for Int, Double, and String class, we can create a generic extension function that works with any type.

Example: A Generic LoggingFunction

fun <T> T.log() {
    println("Value: $this (Type: ${this::class.simpleName})")
}

fun main() {
    val number = 42
    val text = "Hello, Kotlin!"
    val pi = 3.14159

    number.log()
    text.log()
    pi.log()
}

Output:

Value: 42 (Type: Int)
Value: Hello, Kotlin! (Type: String)
Value: 3.14159 (Type: Double)

Here, <T> makes the function work with any type without needing separate functions.

Extension Properties

We’ve explored extension functions, but Kotlin has another powerful feature, called Extension Properties. Just like functions, you can add properties to a class without modifying its original definition.

How do Extension Properties work?

Let’s say you have a Person class, and you want to add an extension property that returns the full name without changing the class itself:

class Person(val firstName: String, val lastName: String)

// Extension property to get the full name
val Person.fullName: String
    get() = "$firstName $lastName"

fun main() {
    val person = Person("Jhon", "Doe")
    println(person.fullName) // Output: Jhon Doe
}

Limitations of Extension Properties

Cannot Store Values. Extension properties don’t have a backing field, so they can only return computed values, not stored data. This means mutable (var) extension properties are not allowed.
No Private Access. They can’t access private properties or methods of the class they extend, only public members.
No Field Addition. They don’t actually add new properties to a class, just a way to compute values dynamically.
Naming Conflicts. If an extension property has the same name as a class property, the class property takes priority, which can lead to confusion.

Infix with Extension Functions: The cherry on top!

In Kotlin, functions marked with the infix keyword can be called without using dots or parentheses. This makes function calls look more natural and readable, especially when designing DSL-style code.

However, not all functions can use infix notation. Instead they must meet the following conditions:

They must be member functions or extension functions.
They must have exactly one parameter.
The parameter must not be vararg and must not have a default value.

Understanding Infix Expressions

Normally, when calling a function, we use dot notation:

fun Int.add(number: Int): Int {
    return this + number
}

val num = 10
val newNum = num.add(5)
println(newNum) // Output: 15

By adding the infix keyword, we can call the function without the dot and parentheses, making the syntax cleaner:

infix fun Int.add(number: Int): Int {
    return this + number
}

val num = 10
val newNum = num add 5 // Now called using infix notation
println(newNum) // Output: 15

This approach improves readability and makes function calls feel more natural.

Companion Object Extensions

What if you want to extend the functionality of a companion object? Kotlin allows this through companion object extensions. These work just like regular extension functions, but they specifically extend the companion object of a class.

In Kotlin, a companion object is a special type of object that belongs to a class but acts like a static member (similar to static in Java). It allows you to define functions and properties that can be accessed without creating an instance of the class.

Example:

class MyClass {
    companion object { } // This is the companion object
}

// Define an Extension Function for the Companion Object
fun MyClass.Companion.printCompanion() { 
    println("MyClass companion") 
}

This function extends the companion object of MyClass.
It can be called using just the class name , without needing an instance of MyClass.

Usage:

fun main() {
    MyClass.printCompanion() // Calling the function directly on the class
}

Output:

MyClass companion

Advanced Extension Function ideas

Network Connectivity Check (Android)

fun Context.isOnline(): Boolean {
    val connMgr = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val networkInfo: NetworkInfo? = connMgr.activeNetworkInfo
    return networkInfo?.isConnected == true
}

// Usage
val isOnline = applicationContext.isOnline()
// or
val isOnline = context.isOnline()

Converting Any Object to JSON (Using Gson)

fun Any.toJson(): String = Gson().toJson(this)

// Usage
data class User(val name: String, val age: Int)

val user = User("Jhon", 25)
val json = user.toJson() // Output: {"name":"Jhon","age":25}

Converting JSON String to Any Object (Using Gson)

inline fun <reified T> String.fromJson(): T = Gson().fromJson(this, T::class.java)

// Usage
val jsonString = """{"name":"Jhon","age":25}"""
val user: User = jsonString.fromJson()
println(user.name) // Jhon

Deep Copy Using (Using Gson)

This function converts an object to JSON and then deserializes it back into a new object, ensuring a deep copy is created.

inline fun <reified T> T.jsonCopy(): T {
    val json = Gson().toJson(this)
    return Gson().fromJson(json, T::class.java)
}

// Usage
data class User(val name: String, val age: Int)
val user = User("Jhon", 25)
val copiedUser: User = user.jsonCopy()

println("Original: $user")
println("Copied: $copiedUser")
println("Are objects the same? ${user === copiedUser}") // false (different instances)

Prevent Double Clicks on a View

fun View.setSingleClickListener(delay: Long = 500, action: (View) -> Unit) {
    this.setOnClickListener(object : View.OnClickListener {
        private var lastClickTime = 0L

        override fun onClick(v: View) {
            val currentTime = System.currentTimeMillis()
            if (currentTime - lastClickTime >= delay) {
                lastClickTime = currentTime
                action(v)
            }
        }
    })
}

// Usage
button.setSingleClickListener {
    println("Button clicked!")
}

Since you can create functions based on your needs, the possibilities are endless.

Android-KTX libraries frequently use extension functions to simplify development. Examples include:

List<T>.getOrNull() – Safe element retrieval.
List<T>.lastIndex – Gets the last valid index.
Canvas.withClip() – Simplifies clipping operations.
Bitmap.toDrawable() – Converts a Bitmap to a Drawable.

Extension functions reduce boilerplate and improve code readability, making Kotlin even more powerful

Using extension functions in Java (Interoperability)

Since Kotlin is built on top of Java, it ensures seamless interoperability between both languages. However, Kotlin extension functions don’t directly translate into member functions in Java. Instead, they act as static utility functions, requiring explicit calls from Java class.

Example: Accessing an Extension Function in Java class

Let’s say we define an extension function in StringExt.kt:

// Extension function to convert a relative path into a full URL
fun String.toFullUrl() = BASE_URL + this

To call this function from Java, we refer to the Kotlin file name followed by Kt, as Kotlin compiles extension functions into static methods:

String image = "/images/my_image.jpg";
String url = StringExtKt.toFullUrl(image);

Although extension functions behave like utility functions in Java, they remain a powerful tool for keeping Kotlin code concise and readable.

When and How to Use Extension Functions

Extension functions are powerful, but they should be used thoughtfully. Here are some best practices and real-world use cases:

When to Use Extension Functions

Enhancing Existing Classes. Add functionality to third-party or built-in classes without modifying their source.
Improving Code Readability. Replace repetitive utility functions with cleaner, more natural syntax.
Reducing Boilerplate Code. Avoid redundant code by defining reusable extensions.

When to Avoid Extension Functions

If it makes code hard to understand. Overuse of extensions can make it unclear where a function is defined.
If it conflicts with class members. If an extension function has the same name as a class function, the member function takes precedence.
If you need private access. Extension functions can’t access private members of the class they extend.

Organizing Extension Functions

To keep your code clean and maintainable, extension functions should be structured properly.

Best Practices for Organizing Extensions

Group by context. Store extension functions in files related to their purpose.
- StringExt.kt → String-related extensions
- ViewExt.kt → Android View extensions
- NetworkExt.kt → Network-related extensions
Use meaningful file names. Avoid dumping all extensions into one file. Use descriptive names based on functionality.
Keep extensions modular. Avoid making extensions too large or complex. Each extension should be focused on a single responsibility.
Document important extensions. If an extension function does something non-obvious, add documentation to avoid confusion.

By following these practices, you ensure that extension functions remain an asset rather than a burden, keeping your Kotlin codebase clean, structured and easy to navigate.

To Recap

Kotlin’s extension functions provide a clean and efficient way to enhance existing classes without inheritance or modification. They allow better code organization, reusability, and readability, making development faster and more intuitive.

We explored how extension functions work under the hood, their syntax, and real-world use cases.
Extension properties help add computed properties, while infix notation makes function calls more expressive.
Advanced extension functions demonstrate their power in Android, JSON serialization, and utility operations.
Interoperability with Java ensures Kotlin extension functions remain useful in mixed-language projects.
Best practices for structuring and using extension functions help maintain a scalable and organized codebase.

By leveraging extension functions effectively, you can write concise, elegant, and highly maintainable Kotlin code.

May your coding adventures in Kotlin be productive and enjoyable. Happy coding!

iOS vs Android Error Monitoring: Key Differences Explained

Bugfender — Mon, 12 May 2025 09:43:51 +0000

When it comes to error monitoring in mobile apps, iOS and Android take distinct approaches due to their unique architectures and tools. Here’s a quick breakdown of the key differences:

iOS : Relies on TestFlight and App Store logs for error reporting. Debugging requires dSYM files for symbolication, and app reviews can take up to 7 days.
Android : Uses Android Vitals for crash reporting. Debugging involves ProGuard mapping files, and updates can be deployed same-day without lengthy reviews.
Programming Languages : Swift (iOS) uses explicit error handling (throws), while Kotlin (Android) offers more flexibility and optional runtime exception handling.

Quick Comparison

Feature	iOS	Android
Initial Cost	Lower	Higher (device variety)
Review Time	~7 days	Same-day possible
Debug Files	dSYM files required	ProGuard mapping needed
Crash Analysis	Symbolication required	Multiple trace types
Test Environment	Limited devices	Multiple configurations

Understanding these differences helps developers build stable, user-friendly apps. Tools like Bugfender simplify cross-platform error monitoring by providing unified logging, automated debugging, and secure data handling.

Mobile crash reporting and debugging best practices

Platform Differences in Error Monitoring

iOS and Android handle error monitoring differently due to their distinct architectures and environments. Understanding these differences is crucial for implementing effective monitoring strategies. Below, we explore the native tools and language-specific error handling methods that define these platforms.

Built-in Error Reporting Tools

iOS developers rely on tools like TestFlight and App Store logs, while Android developers use the Google Play Console’s Android Vitals. iOS app distribution comes with a $100 yearly fee, which also covers testing on devices. On the other hand, Android’s Google Play Console provides flexible crash reporting and faster deployment, skipping the lengthy review process typical for iOS.

Here’s a quick comparison of error reporting features across the two platforms:

Feature	iOS	Android
Initial Cost	Lower	Higher (due to device variety)
Review Time	~7 days	Same-day possible
Test Environment	Limited devices	Multiple configurations
Analytics	TestFlight + App Store	Android Vitals
License Fee	$100/year	$25 one-time

Swift vs Kotlin Error Handling

The programming languages used for iOS and Android – Swift and Kotlin – also influence error management approaches, shaping the way monitoring is implemented.

Swift Error Handling
- Requires explicit error throwing with throws and integrates with optionals using try? or try!.
- Runtime exceptions cannot be caught.
- The compiler does not enforce error type checking.
Kotlin Error Handling
- Does not use checked exceptions.
- Supports optional @Throws for Java interoperability.
- Offers a more flexible approach to error handling.
- Runtime exception handling is optional.

These language differences call for platform-specific monitoring strategies tailored to their unique error handling mechanisms.

Crash Data Collection and Analysis

Standard Crash Metrics

Both iOS and Android automatically collect crash data to help developers identify and fix issues. Here’s a breakdown of the key metrics captured:

Metric Type	Data Points Collected
Device Info	OS version, device model, memory status
System State	Battery level, storage space, network status
Error Context	Stack traces, thread details, crash timestamp
App State	Active views/activities, app version, build ID

Platform-Specific Crash Data

Although iOS and Android share common crash reporting features, their processes and specific details vary significantly.

iOS Crash Reporting

On iOS, debugging relies heavily on symbolication, a process that uses dSYM (debug symbol) files to translate memory addresses into readable information. Each app build generates a unique dSYM file with a UUID that must match the crash report for accurate debugging. iOS crash reports typically include the type of crash or exception, thread stack traces, and a list of loaded images with their UUIDs ^[1].

Android Crash Analysis

Android compiles crash data using several methods:

Exception Stack Traces : Offer detailed insights into failures.
ANR (Application Not Responding) Traces: Track app freezes or unresponsiveness.
NDK Tombstones : Log crashes within native code.

According to a 2015 Crittercism study, Apple had a slightly higher crash rate (2.2% on iOS 8) compared to Android (2.0% on Lollipop) ^[2].

Platform-Specific Challenges

Each platform presents unique challenges for developers:

Android : ProGuard obfuscation can make stack traces unreadable without the correct mapping files.
iOS : Proper handling of dSYM files is essential for effective symbolication and debugging.

Here’s a quick comparison of the two platforms:

Feature	iOS	Android
Debug Files	Requires dSYM files	Needs ProGuard mapping files
Crash Analysis	Relies on symbolication	Uses multiple trace types
Data Detail Level	Focused on single app data	Handles multi-process data

These differences highlight the complexities of crash analysis across platforms. Up next, we’ll explore how Bugfender offers a streamlined solution for cross-platform error monitoring.

Bugfender‘s Cross-Platform Monitoring

Bugfender offers a unified solution for monitoring iOS and Android apps. With over 30,000 apps using its services, it provides a reliable way to track errors across platforms.

Key Bugfender Features

Bugfender does more than just crash reporting – it gives developers detailed insights into how their apps behave. Its standout features include:

Feature Category	iOS Capabilities	Android Capabilities
Remote Logging	Real-time log capture, offline buffering	Real-time log capture, offline buffering
Error Context	Stack traces, device info, user actions	Stack traces, ANR traces, user interactions
Performance Impact	Lightweight SDK, battery-efficient	Minimal memory footprint, battery-optimized

A great example of Bugfender’s impact comes from Schneider Electric. By using Bugfender, they improved their bug resolution process, enabling teams across the globe to share logs and feedback instantly. This helped streamline workflows and speed up development ^[3].

Tailored Solutions for iOS and Android

Bugfender addresses platform-specific challenges with ease. For iOS, it automatically handles symbolication, while for Android, it simplifies debugging with ProGuard mapping.

“Bugfender allows me to have remote logs, and investigate really rare bugs and fix them”, says Volodymyt Shevchenko from AppQ

The platform captures:

Crash stack traces with automatic symbolication
Detailed error context, including user actions
Device-specific details for accurate diagnostics
User interaction traces leading up to issues

These features work seamlessly within Bugfender’s secure environment.

Quick Setup and Robust Security

Bugfender can be integrated into your app in under five minutes. It also meets high security standards:

Certified under ISO 27001 for enterprise-level security
GDPR compliant with data processing agreements available
TLS 1.3 encryption for data in transit and encryption at rest
EU-based data storage with a 30-day retention period for premium plans
Two-factor authentication and detailed audit logs

“Bugfender is very easy to use and offers great support. Its ability to help find silent bugs is invaluable”, says Tudor Watson from Frog Yellow

Error Monitoring Guidelines

To make error monitoring more effective across platforms, consider these practical steps for improving detection and resolution processes.

Early Crash Detection

Detecting crashes early is essential for keeping your app stable. For instance, the Google Home app reduced null pointer exception crashes by 30% after refining its monitoring strategies ^[4].

Here’s how you can enhance early crash detection:

Detection Phase	iOS Implementation	Android Implementation
Development	Enable NSLog logging and UI event tracking	Utilize Android Vitals for monitoring
Testing	Capture stack traces with symbolication	Analyze crash stack traces thoroughly
Production	Monitor crash rates as experienced by users	Track user-perceived crash rates

GymNadz experienced faster issue detection through real-time monitoring. Martin Kovachev shared:

“The ability to look under the hood in realtime gives us a much better and faster way to detect and fix issues for production apps!”

Besides early detection, understanding the context of errors can speed up troubleshooting.

Using Error Context Data

CARFIT leveraged detailed error context logs during testing to uncover issues more effectively.

Key types of contextual data to monitor include:

Data Type	Purpose	Impact
User Actions	Tracks steps leading to crashes	Simplifies reproducing issues
Device State	Captures system conditions	Pinpoints device-specific problems
App Version	Identifies version-specific issues	Allows targeted fixes

Bugfender’s approach highlights the importance of context:

“Bugfender logs all bugs on all devices and sends the results in seconds – enabling you to find and fix bugs before your users even get an error message.”

Equally important is ensuring the security of your error data, which brings us to essential security practices.

Data Security Requirements

Combine error detection and context analysis with robust security measures to protect sensitive data.

Key Security Practices

Use TLS for secure data transmission
Encrypt data at rest
Enable two-factor authentication
Comply with GDPR and other relevant standards
Utilize ISO 27001-certified data centers
Maintain audit logs for account activities

The team behind Six Ages demonstrated the benefits of secure monitoring by identifying and fixing a bug before their QA team even reported it.

“We understand that protecting your customer’s data is vital for you. It’s just as important for us.”

For apps handling sensitive information, consider private instances that comply with PCI and HIPAA standards.

Summary

As discussed earlier, challenges like platform-specific log access, error context, and integration can be addressed with a unified monitoring solution.

Real-world examples from top-performing teams show how unified logging can speed up development processes.

Here’s a quick comparison of how platforms differ and how a unified solution bridges the gap:

Aspect	iOS	Android	Cross-Platform Solution
Log Access	Device-restricted	More accessible	Remote access for all devices
Error Context	Stack traces with symbolication	Detailed crash stack traces	Unified error context view
Integration	Swift-specific	Kotlin/Java implementation	Single SDK integration

These differences lead to better troubleshooting and improved app stability. For instance, Disney successfully resolved a production bug, demonstrating the effectiveness of unified monitoring^.

“Bugfender is very easy to use and offers great support. Its ability to help find silent bugs is invaluable.”

FAQs

What are the biggest challenges developers face when managing crash data on iOS and Android, and how can they address them?

Managing crash data on iOS and Android comes with unique challenges due to the differences in their ecosystems. Developers must navigate platform-specific tools, frameworks, and error-handling methods to effectively diagnose issues.

On iOS, challenges often involve working with Swift and managing symbolicated crash reports, which require uploading .dSYM files to interpret stack traces. For Android, handling crashes in Kotlin or Java can be complicated by diverse device configurations and OS versions. To address these challenges, developers should use robust crash reporting tools that capture detailed context, such as user actions, device specs, and logs, to streamline debugging and improve app reliability.

How does Bugfender improve error monitoring for iOS and Android apps, and what features make debugging easier?

Bugfender simplifies error monitoring for iOS and Android by collecting detailed app logs to help you quickly identify and resolve issues. With remote logging , you can capture errors, crashes, and exceptions directly from user devices, even if they don’t report problems themselves.

Key features include real-time error alerts , automatic crash stack trace symbolication, and detailed context with logs and user actions. Bugfender also takes a device-focused approach, making it easier to track and troubleshoot issues specific to individual users. These tools ensure a smoother, more efficient debugging process for developers.

Why is it important for developers to understand the differences in error handling between Swift and Kotlin, and how does this impact error monitoring?

Understanding how Swift and Kotlin handle errors is essential because each language has its own distinct approach, which directly influences how developers monitor and manage errors. Swift requires methods that can throw errors to be marked with the throws keyword, and developers use do-catch blocks to handle these errors. However, Swift does not mandate specifying the types of errors a method can throw, which can sometimes lead to broader or less targeted error handling.

Kotlin, on the other hand, does not require methods to declare exceptions they might throw. While this offers more flexibility, it can result in unchecked exceptions that may be missed if not carefully managed. These differences mean developers need tailored strategies to ensure all potential errors are effectively logged and monitored, especially when using robust tools like Bugfender for remote logging and debugging. By understanding these platform-specific nuances, developers can optimize their error tracking workflows and maintain high app performance.

How to Use MapKit in iOS with SwiftUI

Bugfender — Wed, 07 May 2025 12:14:12 +0000

In this article we’ll learn about Apple’s MapKit framework. MapKit is the native way to include map views in our iOS application to display map or satellite imagery. It is quite useful for any map-centric view and to show coordinates , annotate on them with a custom annotation , or just generally view world locations or specific map features.

This article will be very hands-on and will include several examples on how things are done using MapKit and the mapkit api.

MapView

Showing a Map

Let’s start with the simplest possible thing, showing a map on our app. The simplest way of doing so is just adding a Map view to our SwiftUI view. A simple SwiftUI view with a map can look like:


port SwiftUI
import MapKit

struct ContentView: View {
    var body: some View {
        VStack {
            Map()
        }
        .padding()
    }
}

#Preview {
    ContentView()
}

That’s as simple as it gets, and when we run our application we’ll get a full screen MapKit view with our location service defaulted to our current country.

Changing the location of the map

Just showing a map centered in our country is cool, but what if we wanted to change the location that is being shown to us?

While this could seem trivial, the only way to change a Map’s location programmatically is by injecting that location into the Map’s initialization, using the MapKit library. So if we wanted to start our map centered in London, this is what we would need to have:


Map(initialPosition: MapCameraPosition.region(
    MKCoordinateRegion(
        center: CLLocationCoordinate2D(latitude: 51.5072, longitude: 0.1276),
        span: MKCoordinateSpan(latitudeDelta: 1, longitudeDelta: 1)
    )))

What if we wanted to have several different positions and change the map between them? Maybe based on specific locations such as Tokyo or Washington DC?

For that to happen, we would need to make the initial position a @State property, and we could change its state for it to be reflected in the interactive map.

As an example, let’s have 3 buttons at the bottom of our map view , and each one linked to real-world location data for three major cities.

By default, we’ll be opening the Map centered in London.

Here’s the code example:


import SwiftUI
import MapKit

struct ContentView: View {

    @State private var position = MapCameraPosition.region(
        MKCoordinateRegion(
            center: CLLocationCoordinate2D(latitude: 51.5072, longitude: 0.1276),
            span: MKCoordinateSpan(latitudeDelta: 1, longitudeDelta: 1)
        )
    )

    var body: some View {
        VStack {
            Map(position: $position)
            HStack(spacing: 50) {
                Button("Washington") {
                    position = MapCameraPosition.region(
                        MKCoordinateRegion(
                            center: CLLocationCoordinate2D(latitude: 47.7511, longitude: -120.7401),
                            span: MKCoordinateSpan(latitudeDelta: 1, longitudeDelta: 1)
                        )
                    )
                }

                HStack(spacing: 50) {
                    Button("London") {
                        position = MapCameraPosition.region(
                            MKCoordinateRegion(
                                center: CLLocationCoordinate2D(latitude: 51.5072, longitude: 0.1276),
                                span: MKCoordinateSpan(latitudeDelta: 1, longitudeDelta: 1)
                            ))
                    }

                    Button("Tokyo") {
                        position = MapCameraPosition.region(
                            MKCoordinateRegion(
                                center: CLLocationCoordinate2D(latitude: 35.6897, longitude: 139.6922),
                                span: MKCoordinateSpan(latitudeDelta: 1, longitudeDelta: 1)
                            )
                        )
                    }
                }
            }
        }}
}

#Preview {
    ContentView()
}

Now we can just press any of the bottom buttons and see our map view taking us there in real time, just like a web app would with a live interactive map.

Placing Annotations on our Map

Now that we know how to make the map move to our bidding, the next logical step is to learn how to place annotations on it. Let’s say we really like the London Eye, and we’d like to add a custom annotation at its specific coordinate.

First, we would need the London Eye’s location, which is lat: 51.503399 , long: -0.119519 , and we would add it using a marker. A Marker for London Eye could look like:


Marker("London eye", coordinate: CLLocationCoordinate2D(latitude: 51.503399, longitude: -0.119519))

Now let’s update our content to include this:


import SwiftUI
import MapKit

struct ContentView: View {

    var annotations: [IdentifiableLocation] = [
        IdentifiableLocation(id: ObjectIdentifier(MyClass(name: "London eye")), location: CLLocationCoordinate2D(latitude: 51.503399, longitude: -0.119519))
    ]

    @State private var region = MKCoordinateRegion(
        center: CLLocationCoordinate2D(latitude: 51.5072, longitude: 0.1276),
        span: MKCoordinateSpan(latitudeDelta: 1, longitudeDelta: 1)
    )

    var body: some View {
        Map(coordinateRegion: $region,
            annotationItems: annotations)
        { place in
            MapPin(coordinate: place.location,
                   tint: Color.purple)
        }
    }
}

#Preview {
    ContentView()
}

struct IdentifiableLocation: Identifiable {
    var id: ObjectIdentifier
    var location: CLLocationCoordinate2D
}

class MyClass {
    var name: String
    init(name: String) {
        self.name = name
    }
}

Our map view now displays the map item pointing at London Eye with a simple pin:

Other basic types of annotations that MapKit supports include:

MapMarker , a simpler alternative to the Pin
MapAnnotation , for designing fully custom annotations

Getting tap coordinates

An important feature of interactive maps is getting the location data where users tap.

We can use a onTapGesture on a Map view like so:


Map().onTapGesture() { position in
    print(position)
}

But to get longitude and latitude coordinates instead of simple X,Y screen positions, we should use a MapReader:


import SwiftUI
import MapKit

struct ContentView: View {

    var body: some View {
        MapReader { proxy in
            Map().onTapGesture() { position in
                if let coordinate = proxy.convert(position, from: .local) {
                    print(coordinate)
                }
           }
        }
    }
}

#Preview {
    ContentView()
}

You will now receive output like:


CLLocationCoordinate2D(latitude: 38.1225410362762, longitude: -8.471839602579648)

This can be very useful in developer apps when saving specific locations or building offline maps.

Map Styles

MapKit allows us to switch between different styles:

Standard (default street maps)
Imagery (satellite view)
Hybrid (satellite + roads)

Switching map styles is simple:


Map()
    .mapStyle(.hybrid(elevation: .realistic, showsTraffic: true))
    .mapStyle(.standard)
    .mapStyle(.imagery)

The imagery map is particularly beautiful when you want to showcase satellite imagery in your ios application.

Map interaction modes

Another important aspect of building with MapKit is setting interaction modes. These define how users can interact with the map content.

Example setting:


Map(interactionModes: [.all, .pan, .pitch, .rotate, .zoom])

Interaction modes can heavily impact your app’s functionality when designing with mapkit library and offline maps use cases in mind.

Summing up

MapKit is a wonderful tool for building powerful, intuitive maps in your ios applications or web apps. We have seen how to use MapKit framework , how to manipulate the user’s map view , how to add annotations , how to use routes and directions, and even how to change between different map features like satellite imagery and hybrid styles.

Hopefully this article gives you the inspiration and technical skill to incorporate MapKit into your own projects, build new features , and make your content rich and interactive!

7 Best Practices for Remote App Debugging in 2025

Bugfender — Fri, 02 May 2025 07:19:32 +0000

Remote debugging saves time but comes with challenges like security risks and performance issues. In 2025, developers use advanced tools and strategies to debug apps running in distributed systems, microservices, and modern frameworks like Flutter, React, and SwiftUI. Here’s a quick summary of the best practices to make remote debugging faster and more secure:

Secure Remote Access : Use two-factor authentication, SSH tunneling, and TLS 1.3 to protect debugging sessions.
Real-Time Error Tracking : Monitor crashes and performance issues live with tools that capture stack traces and user impact.
Device-Based Log Collection : Gather logs for network requests, user actions, and performance metrics using structured and encrypted logging.
Collaborative Debugging : Use tools that allow multi-user access, live code editing, and secure data sharing.
Framework-Specific Tools : Leverage built-in debugging tools like Flutter DevTools, React Native DevTools, and Jetpack Compose Hot Reload.
Performance Monitoring : Track app speed, network latency, and resource usage to ensure smooth user experiences.
User Reporting Systems : Create templates for users to report bugs, including screenshots, steps to reproduce, and system details.

Quick Comparison of Remote vs. Local Debugging

Aspect	Remote Debugging	Local Debugging
Infrastructure Costs	Lower (no physical devices needed)	Higher (requires local devices)
Scalability	Debug across distributed systems	Limited to available devices
Security Risks	Higher (requires strict protocols)	Lower (local environment only)
Connection Dependency	Requires stable internet	Not dependent on connectivity

Key Takeaway : Implementing these practices can reduce debugging time by up to 30% and improve app stability. Start by securing access, using live error tracking, and leveraging framework-specific tools for efficient debugging.

Remote Debugging Complete Crash Course | Visual Studio …

1. Set Up Secure Remote Access

In today’s world of distributed systems, securing remote debugging is more critical than ever, especially with the rise in cyber threats.

Authentication and Access Control

Start by enforcing strong authentication methods. Use tools like Google Authenticator or FIDO U2F Security Keys to add an extra layer of security. Here are some key practices to follow:

Two-Factor Authentication (2FA): Add an additional security step to user accounts to protect against unauthorized access.
SSH Key Management : Keep private keys secure, rotate them periodically, and treat them with the same care as passwords.
Network Security : Use network segmentation to isolate debugging environments and reduce the impact of potential breaches. Modern VPNs like WireGuard offer notable advantages, such as:FeatureBenefitAdvanced cryptographyStronger securitySimple architectureEasier to maintainBetter performanceFaster debugging sessions

Data Protection Measures

Protect debugging data by using secure communication protocols like TLS 1.3 (or TLS 1.2 if compatibility is needed). For added security, tunnel JDWP traffic through SSH.

Monitoring and Compliance

Track and secure your debugging activities with these steps:

Maintain detailed logs of all debugging sessions.
Use automated monitoring tools to flag unusual activity.
Conduct regular security audits and ensure compliance with industry standards like GDPR and ISO 27001.

For enterprise setups, consider using a dedicated SSH bastion host. This acts as a centralized access point, making it easier to monitor and manage security while protecting your debugging infrastructure. These measures lay the groundwork for integrating additional tools and team workflows effectively.

2. Use Device-Based Log Collection

Device logs give you real-time insights into how your app behaves, even without physical access. Here’s how to set up effective and secure log collection.

Key Log Categories

A remote logging SDK can help capture essential log types, such as network requests and user actions. Here’s a breakdown:

Log Category	Purpose	Key Data Points
Network Requests	Monitor API interactions	Response codes, timing, payload size
User Actions	Track user behavior	Screen views, button taps, gestures
Performance Metrics	Assess app performance	Memory usage, frame rates, load times
System States	Understand device context	OS version, device model, storage space

Advanced Logging Techniques

Use structured logging with meaningful tags to simplify debugging. For example, tag network-related logs with “API” to easily filter and diagnose connection issues. This is especially useful for tracking down intermittent problems.

Securing Your Logs

To protect sensitive data, follow these steps:

Use TLS 1.3 encryption for secure log transfers.
Apply strict access controls to limit who can view log data.
Store passwords securely using key derivation functions.

Framework-Specific Tools

If you’re working with Flutter, the DevTools logging view is a powerful resource. It can capture:

Dart runtime events
Framework-level activities
App-specific logs
Garbage collection metrics

Log Management Tips

To make the most of your logs, consider these practices:

Define Log Levels : Use categories like DEBUG, INFO, WARNING, and ERROR to prioritize issues.
Set Retention Policies : Keep logs only as long as necessary based on their importance.
Add Context : Include details like device type and session data to make debugging easier.

3. Set Up Live Error Tracking

Monitoring errors as they happen is crucial for maintaining app stability, especially in distributed development environments. With teams often spread across various locations, keeping an eye on issues in real time ensures your app runs smoothly and delivers a solid user experience.

Key Components of an Error Tracking System

An effective error tracking setup should include the following:

Component	Purpose	Key Metrics
Crash Reporting	Logs crashes and exceptions	Stack traces, affected users, crash rates
Error Context	Provides detailed context	User actions, device state, network status
Performance Monitoring	Tracks app stability	Response times, memory usage, CPU load
User Impact Analysis	Evaluates error severity	Users affected, session data

How to Implement

Set up a secure error tracking system that collects meaningful data while respecting user privacy. Make sure to capture details like stack traces, device specs, user actions, and network conditions at the time of errors. This rich data helps you assess the impact on users and debug efficiently.

The Value in Action

Error tracking tools can dramatically improve your app development process. Alexis Caruana from Schneider Electric shared their experience:

“Bugfender has significantly improved our bug resolution process. The ability to share logs and feedback instantly between our globally dispersed teams has streamlined our workflow and accelerated our development timelines.” ^[4]

Keeping Data Secure

When setting up error tracking, prioritize security with these steps:

Encrypt data transfers using TLS 1.3 for maximum protection.
Control access to error logs to ensure only authorized personnel can view them.
Set retention policies that align with legal and compliance requirements.
Anonymize sensitive data to safeguard user privacy.

By securing your error tracking system, you can safely integrate it into your team’s workflow without compromising data integrity.

Best Practices for Distributed Teams

For teams spread out across different locations, clear protocols are essential. Here are some tips to stay on top of errors:

Configure notifications for critical errors affecting multiple users.
Use automated grouping to spot recurring issues.
Add custom tags to categorize errors effectively.
Monitor severe problems in real time to address them quickly.
Develop workflows to prioritize and resolve errors based on their impact.

“Bugfender is crucial for our product. Without it, we would be running blind. Its real-time logging and feedback features are indispensable for testing with our beta users and resolving issues on production.” ^[4]

4. Enable Team Debug Coordination

Remote debugging works best when the entire team is on the same page. Building on secure access and error tracking, coordination ensures smoother collaboration and faster resolutions.

Real-Time Collaboration Tools

Debugging today demands tools that allow teams to work together seamlessly and provide instant feedback. Here are some key features to look for:

Feature	Purpose
Multi-user Access	Allows multiple users to access apps or windows simultaneously
Live Code Editing	Enables collaborative debugging in real-time
Secure Data Sharing	Ensures sensitive data stays protected during sessions
Integrated Communication	Facilitates contextual discussions within the debugging platform

Improving Debug Communication

Having great tools is only part of the equation. Clear communication practices are just as important for resolving issues quickly:

Centralize tracking and standardize procedures : This reduces confusion and speeds up bug fixes.
Securely share debugging data : Protect sensitive information when collaborating. As Microsoft Learn advises: “You should only share your code, content, and applications with people you trust” ^[5].

Success Stories

Real-world examples highlight the power of coordinated debugging. Netflix, for instance, processes over 500 billion events daily through its analytics platform. This setup allows the team to detect and resolve streaming issues almost immediately. As a result, their average bug resolution time has dropped from days to just hours.

Security Measures

When running remote debugging sessions, keep these security steps in mind:

Use end-to-end encryption for all shared sessions.
Assign unique identifiers to each session.
Apply strict access controls to debugging data.
Maintain detailed logs of all activities during debugging.

Tips for Remote Debugging Sessions

To get the most out of your remote debugging efforts:

Schedule regular sync meetings to avoid overlapping work.
Document all decisions in your issue tracker for clarity and accountability.
Use screen-sharing tools that allow multi-user control.
Enable cross-user copy/paste functionality to streamline code sharing.

5. Apply Framework-Specific Debug Tools

Using tools tailored to specific frameworks can make remote debugging more effective by leveraging each technology’s unique features.

Frameworks today come with built-in debugging tools designed to tackle their specific challenges. Here’s a quick look at some popular frameworks and their key debugging features:

Framework	Key Features
Flutter	DevTools, Hot Reload
React Native	DevTools, Hermes Engine
Jetpack Compose	Hot Reload, Layout Inspector
SwiftUI	Xcode Previews, Time Profiler

For example, the March 2025 release of Compose Hot Reload (v1.0.0-alpha02) introduced faster UI inspection for desktop apps. While it’s still in beta, keep in mind that some migration tweaks might be necessary.

Implementation Guidelines

Flutter To unlock Flutter’s debugging capabilities, run flutter upgrade. You’ll gain access to tools for performance profiling, memory analysis, and network inspection.
React Native React Native’s DevTools works seamlessly with Hermes-enabled apps. It allows real-time inspection of components and monitoring of network activity.
Jetpack Compose Add the org.jetbrains.compose.hot-reload Gradle plugin to your build script to enable near-instant UI updates. This feature has already shown its usefulness in projects like Suhyeon Kim’s “Would You Rather Game” in March 2025.

Security Measures for Debugging

Turn off debug tools in production environments.
Use conditional imports to separate debugging features from production code.
Ensure secure data transmission during debugging sessions.
Keep logs of debugging activities for accountability.

Tips for Better Integration

Use the same debugging tools across your team to maintain consistency.
Automate issue reporting to save time.
Schedule regular performance profiling to catch issues early.
Create clear protocols for remote debugging to keep everyone aligned.

6. Track App Speed and Network Status

Did you know that improving load times by just one second can increase conversion rates by 27% and reduce abandonment by 70%? ^[6]

Key Performance Metrics

To deliver a smooth user experience, keep an eye on these metrics:

Metric Type	Target Value	Impact
Cold Launch	2–4 seconds	Time for initial app start
Warm Launch	2–3 seconds	Time to resume from background
Hot Launch	1–1.5 seconds	Time for memory-cached start
UI Response	Under 100ms	Feedback from user interactions
Frame Render	17ms per frame	Ensures smooth animations
Network Response	Under 1 second	Speed for API requests

Network Performance Monitoring

AI is transforming network monitoring by detecting issues and providing real-time diagnostics ^[7]. For example, SPI Health and Safety used AI-driven tools to improve response times significantly ^[8]. These insights enable faster, more precise performance fixes.

Implementation Steps

Set Up Performance Baselines

Monitor core indicators like CPU usage, memory consumption, and network latency. Aim for client-side response times under 1 second and ensure images are compressed to under 100KB ^[9].

Configure Network Analysis

Enable detailed logging for network events and set up automatic retries for connection timeouts. Addressing bottlenecks isn’t just about speed – it’s about creating a seamless experience.

Optimize Resource Usage

Keep tabs on:

Battery usage patterns
Memory allocation and potential leaks
Network bandwidth consumption
Cache performance metrics

Best Practices for Remote Monitoring

To maintain top performance, combine these steps with automated alerts and regular profiling:

Set up alerts for when performance thresholds are exceeded
Use compression to reduce network payload sizes
Conduct periodic performance profiling
Allow remote access to metrics for team debugging

7. Create Clear User Report Systems

In addition to secure access, live error tracking, and coordinated team debugging, having a clear user reporting system is key to effective remote troubleshooting. These systems can help organizations save up to $125,000 annually by speeding up bug detection and resolution ^[10].

Key Elements of Effective User Reports

A detailed bug report should include the following components:

Component	Description	Why It Matters
Visual Proof	Screenshots or recordings	Speeds up issue verification
Environment Details	Device, OS, app version	Helps replicate the issue
Console Logs	System messages and errors	Adds technical context
Steps to Reproduce	Exact user actions	Ensures the issue is reproducible
Expected vs. Actual	Comparison of outcomes	Makes the problem clearer

To make these reports even more effective, integrate them with in-app feedback tools to gather additional context.

Using In-App Feedback

Incorporating in-app feedback systems can reduce negative reviews by up to 80%. For example, Schneider Electric implemented a reporting tool that allowed instant log sharing across global teams, drastically speeding up their bug resolution process.

Tips for Managing User Reports

Use Standardized Templates : Predefined templates can cut debugging time by 45%. Include fields for environment details, reproduction steps, and expected results.
Automate Assignments : Automatically route bug reports to the right teams, such as UI/UX, backend, or security teams.
Integrate with Development Tools : Link your reporting system to project management tools to streamline the debugging process between users, testers, and developers.

Real-World Example

“Bugfender helped us to fix a production level bug in our app that we just couldn’t replicate ourselves.” – John Jordan, Disney

Keeping Reports Secure

Encrypt all data during transmission.
Use secure authentication and access controls.
Follow GDPR guidelines for log storage and data protection.

Remote Debugging Benefits and Limitations

Balancing the pros and cons of remote and local debugging is key to optimizing your development workflow. Here’s a breakdown of how the two approaches stack up.

Cost-Benefit Analysis

Aspect	Remote Debugging	Local Debugging
Infrastructure Costs	Lower hardware requirements and reduced expenses	Higher initial investment in testing devices
Time Efficiency	Speeds up time to market by around 20%	Faster iterations but limited by device access
Resource Usage	Minimal reliance on local resources	Heavy use of local machine resources
Scalability	Can test across many devices, regardless of location	Restricted by available physical devices

Performance Considerations

These advantages come with some technical challenges:

Connection Stability : Remote debugging relies on a stable, low-latency internet connection. High latency or network disruptions can significantly impact the debugging process.
Security Risks : According to NIST, 42% of vulnerabilities in open-source software arise from poor resource management during debugging. To counter these risks, teams should enforce:
- Strong authentication protocols
- Encrypted connections
- Careful handling of sensitive data to avoid accidental exposure during logging

These precautions align with secure practices outlined in earlier sections, ensuring a safer debugging environment.

Real-World Impact

“Remote debugging doesn’t always deal with a remote machine, we often need it when debugging into Kubernetes or Docker.” – Shai Almog

This insight underscores how remote debugging has expanded beyond traditional setups. Forrester Research found that companies using remote debugging tools can reduce their time to market by up to 20%.

Technical Limitations

Despite its advantages, remote debugging has some notable drawbacks:

Susceptibility to network latency and outages
Security vulnerabilities, particularly with JDWP
Dependence on reliable connectivity for effective operation

Best Practices for Mitigation

To address these challenges, consider the following measures:

Use SSH tunneling for secure connections
Apply minimal privilege access controls
Keep debugging environments isolated from production systems
Maintain detailed logs of all debugging sessions for accountability

Conclusion

Remote debugging has become a core aspect of modern app development, directly influencing both development efficiency and the quality of applications. By following best practices, teams can address challenges in distributed environments while improving outcomes.

Incorporating secure access, detailed logging, live error tracking, collaborative debugging, framework-specific tools, performance monitoring, and user reporting leads to clear advantages:

Development Impact

Allows developers to interact directly with applications in real-world settings.
Facilitates collaboration among distributed teams in real time.
Provides structured monitoring for better insights.
Simplifies resolving issues in complex systems.

Performance Benefits

Speeds up identifying and fixing problems.
Improves application stability with robust error handling.
Detects potential issues early.
Enhances user experience through ongoing monitoring.

“At the same time, multi-client remote debugging allows for a more realistic debugging scenario as typical servers establish multiple asynchronous connections with clients.” – Tom Granot, Chief Growth Officer at Stealth

By focusing on consistent logging, strong error management, and secure communication channels, teams can produce higher-quality applications while navigating the challenges of remote work ^[11]. As remote debugging tools continue to evolve, they play an increasingly important role in supporting distributed development and ensuring reliable applications.

Adopting these practices not only strengthens your development workflow but also enhances application performance in today’s distributed environments.

FAQs

What security measures should you take when setting up remote debugging for distributed systems?

When configuring remote debugging for distributed systems, it’s essential to prioritize security to protect both your application and sensitive data. Use secure connections like SSH tunnels or VPNs to safeguard communication, and implement strict access controls to ensure only authorized personnel can access the debugging environment.

Additionally, configure firewall rules to restrict unnecessary access, keep your debugging tools up-to-date with the latest patches, and disable remote debugging when it’s not actively in use. These practices help maintain a secure and efficient debugging process in distributed environments.

What are the best ways for developers to collaborate effectively during remote debugging sessions?

To collaborate effectively during remote debugging sessions, developers can focus on clear communication, shared tools, and streamlined workflows. Use dedicated communication tools like Slack or Zoom for real-time discussions, and establish clear guidelines for response times and preferred methods of communication. Maintain a centralized knowledge repository (e.g., Notion or Google Docs) to document processes, share insights, and avoid knowledge silos.

Version control systems like GitHub or GitLab are essential for managing code and ensuring consistency, while collaborative debugging tools can help teams reproduce and resolve issues together. Additionally, plan tasks around time zones, set overlapping work hours for live collaboration, and use asynchronous methods when needed. These practices foster teamwork, improve efficiency, and ensure smoother remote debugging sessions.

What are the best tools for debugging apps remotely in 2025, and how do they improve the process for popular frameworks?

For remote debugging in 2025, leveraging framework-specific tools can significantly enhance efficiency and accuracy. Jetpack Compose developers can use tools like Android Studio’s Composable Preview, Live Edit, and Layout Inspector to visualize UI changes in real-time and troubleshoot layout issues. Similarly, SwiftUI benefits from Xcode’s Previews and Debug Navigator for streamlined debugging workflows.

For Flutter , the DevTools suite offers powerful features like the Widget Inspector for analyzing UI hierarchies and the Performance View for monitoring app performance under different conditions. React and Angular developers can rely on browser-based debugging tools like React Developer Tools and Angular DevTools to inspect component trees and track state changes effectively.

These tools are designed to simplify the debugging process, reduce errors, and improve collaboration in distributed development teams, ensuring apps perform optimally across platforms.

How to Read and Analyze iOS Crash Reports: A Developer’s Guide

Bugfender — Tue, 29 Apr 2025 09:55:37 +0000

The crash-proof app doesn’t exist. It never has, and it probably never will. Because apps can crash for all kinds of reasons, some of them impossible to foresee. No matter how well we build them, crashes are going to happen to our apps.

So, as devs, we need to know how to react to a crash when it happens. And in this context, understanding crash reports is crucial. They provide the clues we need to put the pieces together.

In this article, we’re going to look specifically at understanding iOS crash reports, so you can find the root cause and track it, and ultimately fix problems faster.

A quick summary of what you’ll learn today

What crashes actually are, with examples.
How to use crash reporting and the crash log to figure out the root cause.
How stack traces and other crash data can make our lives (waaaayyyy) easier.
How to avoid crashes through proactive use of crash reporting and logging tools.
How you can find the right iOS crash reporting tool for you, and go beyond the simple crash report to achieve proactive defense.

Before we go on, a quick note to say that yes, we offer a crash reporting tool at Bugfender. But we’ll try to be as objective as we can.

Ok so first, what are crashes?

An app crash is any force termination of our app that happens due to an unhandled exception. Those exceptions can take many forms. Here are just a few:

Index out of range

This is a particularly common exception type, and occurs when we try to access an index, on any collection, that does not exist. You can easily reproduce an index out of range instance, with the following code:

let array = ["1"]
print(array[2])

Force unwrapping

Any time we force unwrap, there is the possibility of creating an app crash. That’s why, in general, it is advisable to use safer coding practices. As an example:

var optionalValue: String? = nil
print(optionalValue!)

Dividing by zero

Another common termination reason is the failure to put any checks into our code, and when we come to a division and the divisor is 0:

func divideTenBy(divisor: Int) -> Int {
    return 10 / divisor;
}
...

divideTenBy(0)

Invalid casting of types

When we force out a cast to an unrelated type, we also get a crash:

    let a = 10

    print(a as! String)

We could go on here, because, as you’ll know, there are lots of ways to crash an app, and even if we avoid any of these mistakes, our users can trigger a crash by exposing unexpected edge cases.

So now, let’s look at what action we can take, starting with the stack trace, the most important analytics data at your disposal.

Reading a stack trace

A stack trace is the most crucial crash report we can obtain, because it tells us exactly what was happening when the crash unfolded.

Specifically, it shows us the method calls that our iOS app was processing when everything went wrong. With stack traces, we can see who was calling who at the moment of the crash, and pinpoint where the execution stopped.

For example, if you run the previously given example of the invalid casting type and run an app with it, you will get something akin to:

The ViewModel.init shows exactly where we had our crash. By looking specifically at this, we can determine what was causing the unhandled exception.

Additional tip: while running your iOS app, you can check, or log, your stack trace at any time simply by using:

for symbol: String in Thread.callStackSymbols {
    print(symbol)
}

Finding device crash logs

Now let’s take things a stage further. If you have physical access to an iOS device that has crashed, you can access the logs on the device directly to get priceless debug information.

To do this, open up Xcode, then, on the Window Menu, open Devices and Simulators:

Here, we can choose a device and look at the device’s logs:

Now we’ve got access to the stack trace, just like we saw earlier.

Symbolication

Symbolication is the translation of a crash’s information from memory addresses into a more humanly readable format. As an example how would you prefer to look at a crash report, A, or B?

Thread 0 Crashed:
0 App 0x0000000103478abc 0x103470000 + 35516
1 App 0x0000000103478f32 0x103470000 + 36658

Thread 0 Crashed:
0 App 0x0000000103478abc -[ViewController viewDidLoad] + 40
1 App 0x0000000103478f32 myScreen + 22

It is obviously B, since we can tell where things went wrong in that, while A is just an unreadable stack.

How does it work?

For us to be able to symbolicate crashes, we need dSYM (Debug Symbol) files that are generated in each build of our app. You can download these dSYM files from App Store Connect by going:

Your App > TestFlight tab > Choose the build you’d like to have dSYMs for > Build Metadata tab > Download dSYMs button

Once you have your dSYM, you are able to symbolicate it to be more readable.

Symbolicating a dSYM

Xcode is the preferred way to symbolicate crash reports because it uses all available dSYM files on your Mac at once.

To symbolicate in Xcode, click the Device Logs button in the Devices and Simulators Window, that you can access from the Windows menu button on top, then you just need drag and drop the crash report file into the list of device logs.

Avoiding crashes

Now as we said at the top, there will always be an issue somewhere in your apps, and it’s nigh-on impossible to make them bug-free. However, there is a way we can avoid many common issues, and it’s known as defensive coding.

We will now go back through all the crashes we showed earlier, and using simple safe coding practices, we will make changes to fix the issues shown:

Index out of range

Checking the index beforehand is the best way to avoid an inexistent index. In our case, if we wanted to still be able to access the index 2, here’s how we’d do it:

let array = ["1"]

if(array.count >= 3) {
   print(array[2])
} else {
...
}

Force unwrapping

There are many ways to avoid force-unwrapping, from guards to if lets, to default values:

var optionalValue: String? = nil

guard let value = optionalValue else { return }

print(value)

---//---

if let value = optionalValue { 
    print(value) 
}

---//---

print(optionalValue ?? "")

Dividing by zero

One of the approaches we can take is to check whether the divisor is 0. If it is, just return 0.

func divideTenBy(divisor: Int) -> Int {

    return divisor > 0 ? (10 / divisor) : 0;
}
...

divideTenBy(0)

Invalid Casting of types

We should always check for the type with is:

    let a = 10
    if(a is String) {
        print(a as! String)
    }

Crash and error reporting tools

Ok, so we´ve got a basic grasp of how to catch errors in our apps. But the best way to understand the issues that our apps face in our users’ devices is to have a platform that provides total visibility over all issues that show up.

As we write this piece in 2025, there are two primary crash reporting tools that provide this kind of service, and one is Bugfender. Below, we’ll give you a quick (and we hope, fair) overview of each:

Bugfender

One of the key USPs of Bugfender is that it supports both crashes and general device logs. In other words, the program logs everything, even when the app is running fine. As well as being a great crash analytics tool, it allows you to carry out proactive, round-the-clock performance monitoring of your app quality and app performance.

You can configure the priority of all different kinds of performance issues, and also configure how you get alerts of said issues. With the logs displayed alongside the crashes, you get a truly complete crash report, so you can truly understand what was happening on the device at the time of the crash.

If you’d like to incorporate Bugfender into your app, we’ve recently made an article on how you can do so using SwiftUI and also integrate Alamofire. you can read the piece here.

Firebase Crashlytics

Firebase Crashlytics is a pure crash reporter, and it has lots of real plus-points, notably the fact that it automatically collects crash information alongside application specific information about the device.

The main downside when comparing to Bugfender is that Crashlytics will not capture logs by default, nor does it automatically support non-crashing issues. You can manually log any errors that don’t lead to crashes, and it’s really simple, but you can’t add logs to Crashlytics.

So if you’re purely interested in the crash details, this is a great option. If you want a more proactive product, we’d recommend ours,but in reality, both will give you a valuable crash report.

Summing up

it is near impossible to have an app without crash occurrences, especially in the early stages of the build. However there are ways to avoid crashes, using defensive coding, and also ways to figure out where the issues lie.

What’s more, there are platforms we can use to help us track those issues and have an overview of how often/when they occur to help us mitigate them and fix them as fast as possible.

Hopefully this article has helped you in any way understanding iOS crashes. If you want any more info on how to analyze a crash report, and compare the different crash report tools on the market, we’d be happy to help.

Happy coding!

Android Emulator Setup Guide for App Testing

Bugfender — Tue, 22 Apr 2025 12:01:02 +0000

The Android emulator is an Android virtual device that is used to test and debug Android code. It looks and behaves the same as a physical Android device, and while it has some limitations (more of which later), it provides real time and cost savings for developers.

Unlike the iPhone, which is limited to one manufacturer and a specific number of iOS versions, there are thousands of Android device types out there. Android themselves say there are over 24,000 (yep, that’s not a mis-print) different device types worldwide.

As devs, we simply can’t have physical access to all these devices when building Android app. However, with Android Emulators, we can easily install the APK/AAB file and test the app code on loads of different types, without a physical device. In fact, a single emulator allows us to:

Test multiple instances and customize resources for better performance.
Easily change device configuration and API level and test the code in various API labels.
Import hardware profiles to test our app.
Debug the code and execute the automation code script.

So, the Bugfender team thought we’d do an article on this awesome tech. We’re going to show you how to set up an Android Emulator, so you can bring this vital technology into your Android developer toolkit, and give you loads of hints and tips to customize the emulator to your specific needs.

Who this article is for

Rookie Android devs and small software companies who want to make their Android application testing more efficient via virtual machine technology.
Those with a geographically diverse audience whose app will be used on loads of different devices.
Those who are building Google Play games, which will naturally throw up all kinds of edge cases.
Those who are getting used to Android O and want a way to test for all the challenges it provides.

Ready to go? Then let’s get into the weeds. And, just to be double-clear, we’re talking about the official Android Studio Emulator here (we’ll mention some more niche alternatives further down).

Ok, first, let’s start with the tools we’ll need

In Android Studio, we can use lots of tools to test the app with Android Emulators. The tools are as follows:

Android Virtual Device Manager (AVD Manager), a command-line tool that allows us to create the virtual device in Android Studio. AVD Manager provides an option to customize the virtual Android device, such as RAM size , storage and API version.
With the help of a command , we can install the APK file in the emulator and test it. This helps us to pull and push the code from Git using the Git command.
It’s also important to use Logcat , another command-line tool, in tandem with Android Studio. This helps us to analyze the real-time system logs and debugging messages from the emulator, and find out the exact cause of an app crash.

Now let’s create an Android Emulator

Step 1: Android Studio and Java setup

First, download Android Studio and complete the installation process, which is very intuitive. You need to install Java on your machine to run Android Studio, and don’t forget to set HOME_PATH on your computer.

If you are using Linux or Mac, then you need to install through the command prompt. You should not forget to select the Android SDK and emulator components during installation. Android Studio will launch after installation.

Now, move to the Tools menu and click SDK manager. Take a look at the image below for reference.

Step 2: Create the emulator

A window will open from the right side, as you can see in the image below. There is a plus button, and when you click it, the hardware window will open.

Select the device you want to use, and click the Next button.

Step 3: Select system image

Now, it’s time to choose the Android version you want. One of the awesome things about Android Emulator is that there are loads of pre-configured devices (like Pixel), and you can add your own if it’s not built in.

If the specific Android version you’re looking for is not pre-installed, then click the button beside it. You need to download and select the version before proceeding to the next window.

Step 4: Verify configuration

Here you need to provide a meaningful name for the virtual device. Remember, you can change the device orientation at this step, which is very handy.

After selecting the device, click the Finish button.

Advanced configuration and tips

Ok, so we’ve learned how to create a virtual Android device, which is a great start. Now, it’s time to customize it as per our requirements.

You can customize several things, like hardware, software, device boot, and system image. Ready to take a look?

Hardware customization

You can change the hardware via the new hardware profile or import hardware profile section. You can set device type, screen size, screen resolution, and memory size. There are lots of screen sizes available.

You can also use the previously created custom hardware. In fact, you can customize whether the Android device will open in portrait mode or landscape mode. There are several resolution devices available.

For the sensor section, there are various options you can adopt and adapt. Accelerometers, GPS… all the nuts and bolts that will define the look, feel and function of your app (quick FYI: we typically use the back camera to take a picture on a virtual device).

System image

You need to keep three things in mind during the installation of the system image.

The Google API system image is used when you need maps and Firebase tests on an emulator.
The Google Play system image helps us to install the apps from the Play Store.
The x86 image is used for faster performance.

There are two types of processors you can choose to install. Either Intel (HAXM) processors or AMD Hypervisor processors, which allow you to run a Windows hypervisor platform. Note that AMD processors are faster than HAXM.

RAM and storage customization

By default, we get 2048 MB of RAM and storage out of the box during device creation. But to make things even better, we can customize the size as per our requirements. Remember that you’ll need at least 4 GB of RAM to run the apps on a virtual device smoothly.

And just quickly, some pro tips

Through trial and (a lot of!) error, we’ve discovered these little nuggets while using Android Emulator at Bugfender.

Use Intel HAXM or AMD Hypervisor for better performance.
Enable Quick Boot to save the startup time of the device.
Use the foldable device profile to test dual apps.
Update the Android SDK, Emulator, and Android Studio regularly for better performance (this may seem obvious, but it’s easy to forget when you’re right in the middle of a testing sprint).

How to work with different Android versions

Now, it gets complicated. To make our test as thorough as possible, it’s vital to test our app in different Android versions (remember that some of your users will be using different software editions).

To do this, we need to install different Android APIs from the SDK manager. The benefit of testing the app in various APIs is fewer bugs; we don’t need to create virtual devices separately to use various APIs.

Here’s how to switch APIs on a single device:

Navigate to the Android Studio menu.
Select SDK device manager from the tools menu, and choose which API you want to use to test the app.
Click the ****button if the API is not found.
After clicking next, choose a hardware profile. After that, select System Image and click Finish to complete the process of device creation.

We need to repeat the same process each time we need to change the API and test it. On the other hand, we can handle the API label in the build.gradle file.

How to test with Android Emulators

This is the bit you’ve been waiting for, right?

After clicking the Finish button, we need to revisit the device manager section again. Here, we can find a list with the emulator name along with the API level. It’s important to choose one of them, and click it.

On the right-hand side, a Start button will appear. When we click on the Play button, the emulator will start to launch.

Now we have to wait a few minutes to boot the device. After booting, the device will get ready for operation. Sometimes it takes 5-10 minutes to get ready, so don’t fret if you think it’s dragging.

And finally, it’s time to run our app in the emulator!

To do this, simply click the Run button and select the virtual device. The app will appear on the screen after successfully installing on the device.

And that’s it! Your Android Emulator is ready to go.

Some stuff to try

With Android Emulator set up, there’s loads of stuff we can do right away. Exciting, right? Here’s some stuff you should definitely play around with.

Emulator supports various system images for advanced testing, as well as quick boot and snapshots for faster startup. Even if your current app project doesn’t require these, it’s worth trying them out to see how they look and feel.
Think of all the different edge cases your audience may throw up. Change the RAM size, SSD size and CPU core.
Test the app on various network types, like 2G, 3G, 4G, and 5G. Remember, your users will be running your app in all different locations: homes, offices, planes, trains… you get the point.
Look at the pre-configured devices that Emulator provides. Their Pixel and and Emulator provides pre-configured popular devices like Pixel.
Take screenshots and create video recordings, and it’s great for a bug fix.

Different Emulators to use

Remember when we mentioned at the top that the official Android Studio emulator has some limitations? Well, it’s time to unpack that in a bit more detail.

There are some minor drawbacks to Android’s official emulator. GPU capacity is a bit limited (which is not great for graphics-intensive apps) and there can be issues around speed and storage. So, we’d recommend using the official emulator in tandem with other, more niche products, to ensure your tests are as good as possible.

Cloud-based emulators can be great. We’d recommend Bluestacks or NoxPlayer.
Genymotion is another Cloud-based emulator, and it’s also great for advanced-level testing.
If you’ve built a gaming app, we’d recommend LDPLayer. One of the key USPs is that you can download all kinds of Android games for free.
Firebase Test Lab is great for the breadth of devices and operating systems it provides. We can switch between Android Sdk versions with a simple bit of code, like so: android { compileSdkVersion 33 defaultConfig { minSdkVersion 21 targetSdkVersion 33 } }

This isn’t about choosing the best Android emulator; there are loads of blog posts out there for that. Instead, we’d urge you to use a blend of emulators for your specific needs.

Annnddd we’d done!

Fun, right? You should now have a good working knowledge of how to set up an Android Emulator, how to use it and how to add different tools to your kit.

Remember, once you’ve installed the Android Emulator, be sure to play around with it as much as you can. There’s loads you can do with it, so don’t be afraid to get creative.

And if you have any questions about Android Emulator or any other aspect of Android app testing, don’t be afraid to reach out to us. Happy Coding!

Jetpack Compose Fragments: How to Migrate and Integrate in Android Apps

Bugfender — Thu, 10 Apr 2025 07:37:03 +0000

Imagine you’re a toolmaker. You’ve got an old-school toolshed with loads of ancient equipment: hammers, pickaxes, all the stuff people used hundreds of years ago. And then one day you walk into your toolshed to find laser cutters, 3D printers and loads of other digital tools at your disposal. Life would suddenly seem a lot simpler, right?

Well, that’s kind of how it’s been for developers moving from old-school XML coding to Jetpack Compose, the modern toolkit made by Google to build UI for Android apps. There are loads of benefits to Jetpack Compose that we could mention, but here are the most common ones:

We don’t need to write code in an XML file separately; we simply need to write code in the Kotlin class.
This means we can create a solid product that’s fully compatible and adoptable with existing code content, so we don’t need to take care of it via a separate route.
What’s more, the data will automatically refresh when its state has been changed, which saves a lot of time.
And Jetpack Compose provides a ready-to-use collection of layouts to get you started.

Best of all, Jetpack Compose allows us to denote UI behaviors with the @Composable annotation, which means we can easily implement each new feature with minimal code content. For example, here’s a button we’ve built using Jetpack Compose. Look at how nice and simple the code is in this window:


@Composable
fun ButtonExample(onClick: () -> Unit) {
    Button(onClick = { Log.d("Button : ", "button clicked.") }) {
        Text("Click Button")
    }
}

But there’s one really important thing to know with Jetpack Compose. It doesn’t use fragments natively.

Composable (and Navigation) are designed to replace Fragments. For new apps, with no legacy code, this is fine. But if we’re migrating old projects, which contain fragments, this may seem like a hassle.

So, today, we’re going to show you how to handle fragments in Jetpack Compose, and all the stuff that comes with them, with plenty of code samples.

The article is going to be useful for:

Entry-level Android developers who want some simple explainer content around Jetpack UI.
Advanced developers who have a specific fragment they want to port over to Jetpack Compose and don’t have a method for it.
Developers who are just looking for advanced coding topics to sharpen their game and add new tools to their kit.

Ready? Let’s dive in. (Remember: if you have questions about anything you read here, we’re happy to provide support).

Part 1: The basics of Jetpack Compose fragments

How do we create a Jetpack Compose fragment?

Jetpack Compose is fully declarative. This means that we can simply call the function of the Jetpack Compose UI, and this will transform our data to a UI hierarchy automatically.

However, this also means that if we are migrating fragments from an old project, we are obliged to declare ComposeView inside the fragment itself.

Now, how do we do this? Well, there’s a workaround here. You can embed Jetpack Compose inside a fragment using ComposeView, as shown in the example below.


class ExampleFragmentWithoutXml : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        return ComposeView(requireContext()).apply {
            setContent {
                Text("Hello Its a basic text Compose!")
            }
        }
    }
}

Now let’s take a closer look without Jetpack Compose

In this case, we need to put the ComposeView in our XML layout file. Here’s what the code looks like.

<LinearLayout xmlns:android="<http://schemas.android.com/apk/res/android>"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

  <androidx.compose.ui.platform.ComposeView
      android:id="@+id/compose_view"
      android:layout_width="match_parent"
      android:layout_height="match_parent" />
</LinearLayout>

Once we’ve done this, we have to inflate the XML layout file in our Kotlin code.

class ExampleFragmentUsingXml : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        val view = inflater.inflate(R.layout.fragment_example, container, false)
        val composeView = view.findViewById<ComposeView>(R.id.compose_view)
        composeView.apply {
            setContent {
               Text("Hello Anupam")
            }
        }
        return view
    }
}

And we’re done! Nice and straightforward so far, right?

Part 2: A more advanced view

Now, how do we create a composable?

As mentioned, a Composable in Jetpack Compose is a function annotated with @Composable that defines a piece of UI. When we mark a function with the @Composable annotation, this means the function will be used to build UI elements.

So let’s create a basic Composable function that displays text:

@Composable
fun MyComposeText(name: String) {
    Text(text = "Hi, $name!")
}

// To update UI

@Composable
fun showCmposeText() {  
    MyComposeText("I am Anupam") // call compose function
}

Here, Text is the inbuilt compose function that will be used to display text values. We previously used this in our XML file with the <TextView> tag.

To update the UI dynamically, we need to use the composable functions like remember and mutableStateOf, like the code below.


@Composable
fun ShowButtonClickCountInText() {
    var i by remember { mutableStateOf(0) } // State variable
    Button(onClick = { i++ }) { 
        Text("Count is : $i") 
    }
}

Ok, so how do we deal with dependencies?

A dependency tag is used to implement libraries, and it’s declared in the build.gradle.kts file.

For any Android projects, dependencies are managed through Gradle. As we know, compose is part of the Jetpack library, so we need to implement the required library in the Gradle file.

Before adding the library, we need to ensure that the correct build file ( Module: App ) is open. Within this file, we need to place the link under the dependency tag.

In addition, to enable compose functionality, we need to set compose=true under the buildFeatures tag.

android {
    buildFeatures {
        compose = true // Enable Jetpack Compose
    }
}

If you found any type of conflict, such as “version” or “ can’t resolve ” , then use strictly to enforce a specific version, like this.

dependencies {
    implementation("androidx.compose.ui:ui") {
        version { strictly("1.6.0") }
    }
}

If we want to update the compose dependency with the latest version, then we need to update the project-level build.gradle.kts file.

plugins {
    id("com.github.ben-manes.versions") version "0.50.0"
}

Now, let’s add a few dependencies

We can easily add a few dependencies that are necessary for the Jetpack Compose project, including the core Compose UI.

Here’s the code to show you what that destination looks like.

dependencies {
    // Compose BOM (Manages all versions automatically)
    implementation(platform("androidx.compose:compose-bom:2024.02.02"))

    // Core Compose UI
    implementation("androidx.activity:activity-compose:1.9.0")
    implementation("androidx.compose.ui:ui")
    implementation("androidx.compose.material3:material3")

    // Tooling for debugging
    debugImplementation("androidx.compose.ui:ui-tooling")

    // ViewModel integration
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose")

    // Navigation (If using Compose Navigation)
    implementation("androidx.navigation:navigation-compose")
}

Part 3: Trouble-shooting

Firstly, how do we deal with reflection?

When we talk about reflection, we’re talking about code that can inspect other code.

Reflection is commonly used in tasks such as serialization (where we convert the object state into a storable format), but this isn’t usually a good thing, because it can increase memory usage, slow your execution and require the usage of Dagger, a dependency injection framework that can greatly increase build time.

For example, when analyzing the Employee class, we may be tempted to use the Gson library. This will involve reflection, and thus impact performance.

val gson = Gson()
val user = gson.fromJson(jsonString, Employee::class.java)

However, as a Kotlin-based framework, the Jetpack Compose library usually avoids these problems. In the case of serialization, Kotlinx serialization is compiler-based, so there is no need to use reflection.

@Serializable
data class Employee(val name: String, val empcode: Int)

val json = Json.encodeToString(Employee("Anupam", 1))
val user = Json.decodeFromString<Employee>(json)

Ok, but we know what you’re asking here: what if we absolutely need to use reflection? How do we use it without sacrificing performance?

In this case, we need to update the rules for two code-shrinking tools, ProGuard and R8. Both of these tools will identify and remove unused code, keeping your build nice and lean. Here’s how we put these into practice.


// com.example.MyClass replce with your own class with package name

-keep class com.example.MyClass { *; }    
-keep class kotlinx.serialization.** { *; }

Right. Now, how do we deal with Jetpack Compose memory leaks?

Memory leaks are a commonissue that can affect any kind of Android application. Jetpack Compose has loads of advantages (as you’ve hopefully seen by now!) but it can still suffer memory leaks due to poor lifecycle management practices, such as the retention of objects, forgetting to get rid of observers and not dealing properly with lambda expressions, which are crucial to Jetpack Compose.

Here’s an example of what happens if we use context in a ViewModel.

class MyViewModel(context: Context) : ViewModel() { // Can leak Activity
    private val myContext = context
}

However, we can significantly reduce memory leaks in applications by deploying applicationContext instead of context or activity .

class MyViewModel(application: Application) : AndroidViewModel(application) {
    private val context = getApplication<Application>().applicationContext //Safe to use
}

We can also use the leakcanary library to detect memory leaks in Android applications. We need to add the dependency in the Gradle file the following way.

dependencies {
    debugImplementation("com.squareup.leakcanary:leakcanary-android:2.12")
}

Ok. Any other lifecycle management tips for me?

Why sure!

Jetpack Compose does not use activity or fragment lifecycle methods like onCreate(), onStart(), and onDestroy(). Instead, when Jetpack Compose runs your composable function the first time, it is called initial composition.

During this time, Jetpack Compose keeps track of all the composables that will be used to build the UI. Then, when the state of our app has been changed (as with a text update or a color change), it will automatically update the UI without calling it again. This is called recomposition.

Composition can be called single-time in code, but recomposition is used multiple times in code. The instance of composable is distinct by each composition.

@Composable
fun MyComposable() {
    Column {
        Text("Anupam")
        Text("Jetpack")
        Text("Compose")
    }
}

In the above example, we use three pieces of text within a column. Here, when the composable enters the composition, three instances will create. Each has its own lifecycle in the composition, as you can see here.

And finally…how do we handle errors in Jetpack Compose?

We can handle errors in Jetpack compose in several ways. It depends on which type of error we are dealing with, like UI, network, or exception.

Here’s an example of an UI error handle. As you can see, we can use try catch block to handle the UI error. This is really useful.

@Composable
fun ShowUserName(userName: String) {
    try {
        Text("Welcome, $userName")
    } catch (e: Exception) {
        Text("Failed to load user details")
    }
}

We may write a further blog in due course, highlighting how to handle errors in Jetpack Compose.

To recap

Jetpack Compose is the future of Android UI that replaces the XML layout with Kotlin code. If we have older code, then we can easily migrate it in Jetpack Compose. Jetpack provides an in-built function; we need to call in our code using a parameter, and the view will automatically build up.

We don’t need fragments with Compose. We can navigate to another screen without needing a fragment or an activity. Using compose navigation, we can navigate from one screen to another screen. But if we are going to use Compose, there are lots of workarounds we can use.

If you have any questions about Android Jetpack Compose Fragment, don’t be afraid to reach out to us. Happy Coding!

Kotlin Apply and other Kotlin Scope Functions

Bugfender — Thu, 03 Apr 2025 07:59:21 +0000

Last week, we got a question from one of our users asking us how to use Kotlin Apply. Specifically, the reader wanted to know whether it was best to use the apply function in their Android application, or another of the many Kotlin scope functions.

So we got to thinking: Why not write an article about the whole topic of Kotlin scope functions? After all, they’re awesome: they let us write readable, concise code in Kotlin, and work with an object without the need for repeated references.

This not only cuts down boilerplate code, it provides a method to enhance the readability of our Kotlin apps and allow us to handle complex logic with minimal app maintenance. And if we want to build our own Kotlin DSL, then scope functions are absolutely crucial.

So today we’re going to cover all the main Kotlin scope functions (and yes, there’ll be a big section on the apply function) with practical examples and use cases. The blog is ideal for:

Existing Kotlin developers who already know or have seen scope functions in their programming lives, but struggle to fully grasp them.
Android developers who work with Kotlin and want to write more idiomatic, less verbose code in their next Android app, and explore object oriented programming.
Java developers learning Kotlin and Kotlin multiplatform who want to drive their learning towards better practices in a new programming language.

One key thing you’ll learn is how to leverage scope functions in Android development, and why it is totally worth the effort for every Kotlin developer, whether they’re seasoned or new to the language.

First, an introduction to scope functions

What are scope functions?

If you’re new, scope functions are provided by a Kotlin standard library to simplify working with an object in a scope, and make our code much more readable and easy to maintain.

They allow us to write code without writing the object reference every time, which can be a pain, and assist in realigning our code so that we can easily perform operations on an object, without polluting the base.

Types of scope functions

There are a total of five scope functions in Kotlin, each with their own distinct use cases and advantages. The higher-order functions we will cover today are let, run, with, apply and also. Here is a really quick deep-dive on each one:

let :

Let is used to run blocks of code on object, and then return the result or follow up with other operations in a chain (see example below), as well dealing with null safely. Here’s a code snippet to show you what we mean.

val user = User("John", "Doe")
user?.let {
    Log.d("User", "First name: ${it.firstName}, Last name: ${it.lastName}")
}

run :

Run is great because it combines the work of let and functions in tandem, facilitating both side effects while returning a value.

val fullName = user.run {
    "$firstName $lastName"
}
Log.d("User", "Full name: $fullName")

with :

This function lets us perform an operation on a object without actually extending it. Like run, this is a non extension function (i.e. it doesn’t extend another class or type), and it requires the object as its parameter.

with(user) {
    Log.d("User", "First name: $firstName")
    Log.d("User", "Last name: $lastName")
}

apply :

Now, we’re back to what we discussed at the top. Apply is a constructor, which is used to set up an object and return the object itself.

val user = User().apply {
    firstName = "John"
    lastName = "Doe"
}
Log.d("User", "User created: $user")

also :

This is the same as the apply function, but for side-effects, like logging or validation. It returns the object itself.

val user = User("John", "Doe").also {
    Log.d("User", "User created: $it")
}

Comparing scope functions

The specific scope function to use depends on what you want to accomplish in your code. Here are some tips to choose the right one:

let: We use let when we perform a certain operation with a non-null object or transform the result. This is great for chaining calls or working with nullable objects to prevent null pointer exceptions. user?. let { }
run: This is great when we want to execute a block of code and get a receiver result from the last expression. Very useful for value object configuration and computation of your own.

val result = configuration.run { //do computations and return result. }

with: With is particularly useful for chaining multiple function calls over an object without repeating a reference to the same thing. Useful if you are doing a number of things to an existing object.

with(configuration) { /* lots of operations */ }

apply:Apply comes into its own when you need to initialize or configure the object and want the function to return itself. Great for constructor execution and object initialization.

val paint = Paint().apply { properties }

also: We can use also to peform more operations on an object, like logging or debugging. Appropriate for operations returning the object itself, after performing the side effect. val file = File(path).also { Log.d("File", "File path: ${it.path}") }

Differences and similarities

Now let’s go deeper.

Each scope function carries its own explicit behavior, so let’s look at the specific use of each of them: in other words, where and when we can use these different scope functions in the Android app development pipeline. We will also explore the similarities (and differences) of the various functions along the way.

Context object:

let & also require the use of it as the context object in a lambda function.
run, with and apply require the use of this as the context object in a lambda expression.

Return value:

let & run return the result of the lambda function.
with returns the lambda result.
apply and also return the object itself.

Usage pattern:

let is used for null-checks and transformations.
run – is the computation and result return code.
with – is an operand that declares an already initialized object so you can perform a task with it.
apply is used to instantiate and configure objects.
also is used for side effects, like logging and additional operations that do not violate the main object.

Ok, that’s the basic primer done. Now let’s really dig into those weeds.

Advanced usage of scope functions

Now we’re really cooking! We’ve gone through all the definitions and distinctions, so let’s start looking at advanced use cases and seeing how the different scope functions can be used in tandem.

Nested scope functions

Nesting scope functions are great when performing complex object hierarchies. And with careful nesting of scope functions, you can maintain a clean, readable structure where operations related to each object are all inside the relevant block.

To show you what we mean, let’s look at a code snippet involving apply and let.

//Example of usng appy and let scope functions together
val user = User().apply {
    firstName = "Sam"
    lastName = "Doe"
}.let { user ->
    // We can perform additional operations here
    Log.d("User", "User is created: ${user.firstName} ${user.lastName}")
    user
}

Chaining Scope functions

Now this bit is crucial. Let’s look at chaining functions together.

The most common way to chain scope functions is popping out of the last block, calling a new function and repeating that until we get what were expecting. It’s nice and simple, and is a really good way to avoid that dreaded boilerplate code.

As an example, here’s a code snippet showing how to chain apply, also and let.

//Chaining example of the apply, also and let functions. 
val userDisplayName = User().apply {
    firstName = "Sam"
    lastName = "Doe"
}.also {
    Log.d("User", "User is created: ${it.firstName} ${it.lastName}")
}.let {
    "${it.firstName} ${it.lastName}"
}
Log.d("User", "Display Name: $userDisplayName")

Now let’s say we want to set some properties for a UserProfile object, log its properties and then finally display a summary. How would we do this? Well, let’s get into the language.

//Example of UserProfile class that has user properties and showing the use of different scope functions. 
data class UserProfile(
    var firstName: String = "",
    var lastName: String = "",
    var age: Int = 0,
    var email: String = ""
)

fun main() {
    val userProfileSummary = UserProfile().apply {
        firstName = "Sam"
        lastName = "Doe"
        age = 30
        email = "Sam.doe@test.com"
    }.also { profile ->
        Log.d("UserProfile", "Profile is created: $profile")
    }.run {
        "Name: $firstName $lastName, Age: $age, Email: $email"
    }

    Log.d("UserProfile", "The Profile Summary: $userProfileSummary")
}

Real-world use cases

The bit you’ve been waiting for, right? A goold old hand-ons tutorial.

In a real-world application of Android example, the code above will feature scope functions.

To build the use case, let’s start by creating a simple example where we have to create a user profile screen. These tasks often involve fetching user data, initializing views or displaying fetched data on screen.

To initialize views in a user profile screen and set them, use apply.

class UserProfileActivity : AppCompatActivity() {

    private lateinit var binding: ActivityUserProfileBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityUserProfileBinding.inflate(layoutInflater)
        setContentView(binding.root)
        // Initialize views using apply
        binding.apply {
            userNameTextView.text = ""
            userEmailTextView.text = ""
            userProfileImageView.setImageResource(R.drawable.placeholder_profile)
        }

        // Fetch and display user data
        fetchUserDataAndDisplay()
    }

    private fun fetchUserDataAndDisplay() {
        val userRepository = UserRepository()

        // Fetch user data using run
        val user = userRepository.run {
            getUserData()
        }

        // Display user data using let
        user?.let {
            binding.userNameTextView.text = "${it.firstName} ${it.lastName}"
            binding.userEmailTextView.text = it.email
            // Assuming you have an image loading library like Glide or Picasso
            Glide.with(this).load(it.profileImageUrl).into(binding.userProfileImageView)
        }
    }
}

There we go! Not bad right? The code all flows smoothly (if we say so ourselves!) and it’s all nice and clear.

Best practices

Ok, we’re nearly at the finish line now. Let’s cap things off by exploring some best practices that we can use when working with scope functions in our Kotlin projects.

Pick your scope function: Choose the appropriate scope function for your case. For example, apply is great for object initialisation, let is good for null checks and to transform a value, and run is best on computations that return something.
Keep the code short: Never write large blocks of code into scope functions. The shorter your code, the more readable it will be, and the easier it will be to determine what the scope function does.
Retain scope functions for a proper level of nesting: As nesting can be deeper down to the last level, you should not bury scope functions deep inside one another.
Clarify context object naming: Use let or also where appropriate, When using the let keyword in a regular lambda, provide more meaningful names to the context object if necessary.
Use scope functions for null-safety: let is used to execute blocks of code on nullable objects and avoid null pointer exceptions. In the context of Android app development, we often have to work with value references, so this particular facet is really useful.
Use a scope functions chain: You can chain scope functions to make the code look more clean and readable. Each step or function in the chain should do one, and only one thing.

To sum up

Wow, we’ve covered a lot there right? We’ve discussed the key features of scope functions, we’ve introduced the basics behind scope functions and how they can make your Kotlin code more clean and concise, before detailing each scope function (let, run, with, apply, also), its purposes and syntax and its use in real-life applications. We have also discussed the advanced usage of scope functions via nesting or chaining, to handle complex conditions more effectively.

Remember: scope functions are ultimately a way of writing clean, concise code in Kotlin. The better we utilize scope functions, the more bespoke (and less boilerplated) our code will look. Happy coding guys!

Swift Concurrency Explained: GCD, Operation Queues, and Async/Await

Bugfender — Thu, 27 Mar 2025 08:33:16 +0000

Concurrency is the ability of an app to perform multiple tasks at once, and it’s a crucial concept for apps that need to perform multiple tasks at once in an efficient, usable way. Thankfully Swift has made great strides with concurrency, and now provides simple tools for writing robust apps that are responsive and enjoyable to use.

In this article we’ll explore two main ways of using threads for concurrency models. We’ll start with the classic way of doing it from the straight-up use of threads, Grand Central Dispatch and Operation Queues. Afterwards we’ll look at async/await, a more modern, simple, approach to concurrency that has recently been added to the arsenal of Swift tools at our disposal.

But before that, a quick look at the key concepts needed to fully grasp concurrency and threading.

What Is Concurrency?

Concurrency means apps can run multiple tasks or processes, regardless of each other’s life cycle. This improves the overall performance and responsiveness of an app, since it allows multiple operations to run at the same time, whether they are in parallel or not.

What are threads?

We’re going to talk about threads in more detail soon, so here’s a quicker explanation of what they actually are:

A thread is the context in which operations are executed. We can think of each thread as a small, independent worker who has a single task to execute, and will execute it independently.

We can manually create threads, and use them, with some simple code:

let thread = Thread {
    print("Here we can perform our task")
}

thread.start()

Note: Even though we’ve given the code string, this course of action is not usually recommended. It should only be used for very specific, low-level tasks. Using the abstractions, like Grand Central Dispatch, which we will explain shortly, is safer, simpler, and generally more advisable.

Classic Concurrency in Swift

We will now look at the older concurrency models in Swift, including Grand Central Dispatch (GCD) and Operation Queues. We could look directly at threads but, as we’ve just explained, they’re not the most recommended method of implementing concurrency, so we’ll put that to one side.

1. Grand Central Dispatch (GCD)

Grand Central Dispatch (GCD) is one of the oldest and most commonly used concurrency tools in iOS and macOS development. GCD is a low-level API that enables developers to manage tasks asynchronously, using dispatch queues. These queues can run tasks either serially (one task at a time) or concurrently (multiple tasks at once).

Queues

One of the key concepts is that of Queues. These are essentially lists of tasks that need to be executed in a specific order. There are many types of queues, so let’s take a look:

Serial queues and concurrent queues

Serial queues guarantee Tasks are executed in a serial manner. In other words, one after the other. Meanwhile, concurrent queues can execute and run many tasks simultaneously, as long as there are CPU cores to do so.

They are very similar in usage, as shown here:

//Serial:
let serialQueue = DispatchQueue(label: "mySerialQueue")

serialQueue.async {
    print("1 started")
    print("1 finished")
}
serialQueue.async {
    print("2 started")
    print("2 finished")
}

//Concurrent
let concurrentQueue = DispatchQueue(label: "myConcorrentQueue", attributes: .concurrent)

concurrentQueue.async {
    print("3 started")
    print("3 finished")
}
concurrentQueue.async {
    print("4 started")
    print("4 finished")
}

While the serial Queue will print:

    print("1 started")
    print("1 finished")
    print("2 started")
    print("2 finished")

It’s likely that the concurrent Queue would have a different order of operations, so it could be:

 print("1 started")
 print("2 started")
 print("1 finished")
 print("2 finished")

 print("1 started")
 print("2 started")
 print("2 finished")
 print("1 finished")

Since we’re talking about prints, the concurrent Queue is likely to have the same output as the serial one. But with more complex operations it is certain to differ.

Global Queues

Global Queues automatically let us choose a Quality of Service level, which refers to the priority in which they get executed. There are several QoS, or priority levels to note:

.userInteractive: The highest priority for a Global Queue. This is to be used in tasks that require immediate results, usually triggered by user actions.
.userInitiated: This has lower priority than userInteractive but it should also be completed quickly to provide a good user experience.
.default: The default priority for GlobalQueues. That means it will run after any high-priority queues, and before any low-priority ones. It is, in practice, the average priority of all of them.
.utility: This is usually used for tasks that are not being actively tracked by the user, like downloading a higher resolution asset to use in apps.
.background: The lowest priority. Tasks with this priority can run in the background without interfering with anything, even if they take a while to complete.

They are all similar when it comes to usage, as we can see in this example:

DispatchQueue.global(qos: .userInteractive).async {
    print("My userInteractive task")
}

DispatchQueue.global(qos: .userInitiated).async {
    print("My userInitiated task")
}

DispatchQueue.global(qos: .default).async {
    print("My default task")
}

DispatchQueue.global(qos: .utility).async {
    print("My utility task")
}

DispatchQueue.global(qos: .background).async {
    print("My background task")
}

The main Queue

The main Queue is a special case, since it’s the only one we rely on to update our UI. This means that if we use it for any task that takes a huge amount of time to complete, the UI of our apps will be frozen while the Task completes.

Thus, it is common practice to run more time-consuming tasks on other Queues, and then to get the results back to the main Queue to update our App’s UI:

 DispatchQueue.global(qos: .background).async {
    print("My background task that might take a while to complete")

    DispatchQueue.main.async {
        //Update the UI here after completing what was processing on the background global queue
    }
}

Important: You should not use the main queue for expensive/slow computing, since that will freeze your UI and impact your users’ experience.

2. Operation Queues

While Operation Queues are also built on top of GCD, they are a higher-level abstraction over it. This means they’re simpler to learn and use, and provide us with enough tools to control task execution.

They allow us to add operations, which are literally instances of the Operation class, to a queue, manage dependencies between Operations, and configure the maximum number of concurrent Operations we’d like to have.

To get a better idea, let’s look at a simple example of Operation Queues:


let operationQueue = OperationQueue()

let operation1 = BlockOperation {
    // Perform a Task
    print("Task 1 started")
}

let operation2 = BlockOperation {
    // Perform another Task
    print("Task 2 started")
}

operationQueue.addOperations([operation1, operation2], waitUntilFinished: false)

Here, our Operation Queue will manage two BlockOperation objects running concurrently. We can also set them to run sequentially if we configure the Operation Queue that way. There are many important things we can do on our OperationQueues, including:

let operationQueue = OperationQueue()

//Define how many concurrent operations we'd like, 
//if we set it to 1, in practice it becomes a sequential queue
operationQueue.maxConcurrentOperationCount = 1;

//Define the QoS of our Queue, as we saw earlier for Global Queues
operationQueue.qualityOfService = .background

//Define a name to help us identify a Queue
operationQueue.name = "myQueue"

//Set it to wait until all operations are finished, which is useful in some scenarios
operationQueue.waitUntilAllOperationsAreFinished()

//Cancel all operations if something made the queue finish irrelevant to us
operationQueue.cancelAllOperations()

Modern Concurrency: Async/Await in Swift

Now that we’ve seen the basics of Classic concurrency in Swift, let’s have a look at the new kid on the block: Async/Await.

This was introduced with Swift 5.5. and drastically improves how we write and handle concurrency. Everything becomes way simpler and easier to use, without losing any capability.

The Basics of Async/Await

We use async to mark any function/method as asynchronous. We then use await, on a caller, to instruct that it needs to wait for the async function/method to finish.

It really is that simple. We don’t need blocks or callbacks, like we saw earlier.

Let’s look at how it all works in practice:


func makeWebRequest() async -> String {
    // Simulate a network request
    try await Task.sleep(nanoseconds: 2 * 1_000_000_000)
    return "Data is here"
}

Task {
    let data = await makeWebRequest()
    print(data)
}

makeWebRequest is marked with async, indicating that it performs an asynchronous operation.
The await keyword is used to call makeWebRequest() and wait for its result.

Async Let and Task Groups

Swift 5.5 introduced structured concurrency , a new way of managing asynchronous tasks that makes the lifecycle of tasks more predictable and easier to manage. Structured concurrency ensures that asynchronous tasks are completed or canceled in a controlled manner.

Swift now allows asynchronous tasks to be created using async let and the managing of multiple tasks with TaskGroup.


func fetchDataFromMultipleSources() async {
    async let data1 = fetchDataFromSource1()
    async let data2 = fetchDataFromSource2()

    let result1 = await data1
    let result2 = await data2

    print("Data1: \\(result1), Data2: \\(result2)")
}

async let is used to create two asynchronous tasks that run concurrently.
The Tasks are awaited individually, and their results are processed.

Task groups allow you to create multiple asynchronous tasks, aggregate their results, and handle their cancellation together.


func fetchMultipleData() async {
    await withTaskGroup(of: String.self) { group in
        group.async {
            return await fetchDataFromSource1()
        }

        group.async {
            return await fetchDataFromSource2()
        }

        for await result in group {
            print(result)
        }
    }
}

Here, withTaskGroup manages multiple concurrent tasks, and the for await loop collects their results in a safe, structured manner.

Summing up

If you’re going to take three things away from this post, we urge you to remember the following.

Avoid blocking the main thread, regardless of what concurrency model we’re implementing.

Use async/await when possible, because it is relatively simple and easy to use.

Grand Central Dispatch, when understood, is not hard to use and we can leverage it for our background tasks*

If you remember these things, you’ll have a blast with Swift Concurrency. Happy coding!

SwiftUI Navigation Explained: Best Practices for Seamless App Flow

Bugfender — Wed, 19 Mar 2025 07:39:01 +0000

Navigation is one of the most basic functionalities of any app, and among the most crucial aspects of our work as developers.

From replacing a login screen with our actual logged-in state app, to showing a modal with details of any item inside our app, all of these are navigational challenges we need to tackle in our day-to-day.

SwiftUI has introduced a modern approach to navigation in Apple-based platforms. It replaces the older UINavigationController navigational system, which had issues around reliability and consistency, with different, more modern approaches. These new approaches can take a bit of getting used to, so we’re going to unpack them today.

This article will be very hands-on and give you examples on how to navigate in scenarios that you will find in your own apps. All the insights are drawn from our own work as devs, building navigation into all kinds of projects.

But that’s enough intro. Let’s get into it.

1. Navigation Basics

We typically use the NavigationStack and NavigationLink components to handle navigation In our apps.

Example

import SwiftUI

struct FirstView: View {
    var body: some View {
        NavigationStack {
            VStack {
                Text("Navigation article")
                    .font(.title)
                    .padding()

                NavigationLink("Go to the second view", destination: SecondView())
                    .padding()
            }
            .navigationTitle("First View")
        }
    }
}

struct SecondView: View {
    var body: some View {
        Text("This is the Second view")
            .font(.headline)
            .padding()
            .navigationTitle("Second View")
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        FirstView()
    }
}

Now let’s take a detailed look at the most important navigational aspects:

NavigationStack : This stack will handle our navigation. We wrap our content with it.
NavigationLink : This creates the link that will allow us to navigate to a different page.
.navigationTitle : This allows us to define a title to each of our pages on the Navigation bar.

2. Injecting data to views

We’re going to go slightly off-track here, if that’s ok. Injecting data into views isn’t directly related to navigation, but we often need to pass data between views, and this may still be useful when sharing new views.

While there are many ways for views to access the business logic, and data, they need, we will look into a simple way of injecting data from one view to another.

Example

import SwiftUI

struct FirstView: View {
    var recipes: [String]

    init(recipes: [String]) {
        self.recipes = recipes
    }

    var body: some View {
        NavigationStack {
            List(0..<recipes.count) { index in
                NavigationLink("\\(recipes[index])", destination: DetailView(recipe: recipes[index]))
            }
            .navigationTitle("Recipe List")
        }
    }
}

struct DetailView: View {
    let recipe: String

    var body: some View {
        Text("Here are the recipe details")
            .font(.largeTitle)
            .padding()
            .navigationTitle(recipe)
    }
}

And to launch our app:

@main
struct OurApp: App {
    var body: some Scene {
        WindowGroup {
            FirstView(recipes: ["Garlic bread", "Pepperoni Pizza", "Beef Gnocchi", "Fish and Chips"])
        }
    }
}

Now, looking at both examples together:

The DetailView accepts a parameter recipe, which is provided when creating the NavigationLink. The same exact thing happens with our FirstView: it accepts an array of recipes that we need to feed it.
Each NavigationLink dynamically passes its recipe name to the DetailView and we then use those as the titles of the DetailView.

3. Navigation depending on our State

The navigation we’ve seen so far is explicitly based on tapping a certain view. However, sometimes we might want to navigate forward/backward depending on the @State of our View. So let’s look at how to do this:

Example

import SwiftUI

struct FirstView: View {
    @State private var isDetailViewActive = false

    var body: some View {
        NavigationStack {
            VStack {
                Button("Go to Details") {
                    isDetailViewActive = true
                }
                .padding()

                .navigationDestination(isPresented: $isDetailViewActive, destination:{ DetailView()})
            }
            .navigationTitle("First View")
        }
    }
}

struct DetailView: View {
    var body: some View {
        Text("This is the detail view")
            .font(.headline)
            .padding()
            .navigationTitle("Detail View")
    }
}

The isDetailViewActive state variable controls the activation of the NavigationLink.
This is useful when there’s the need to control when/where we should show a different page.

Important note:

While this is a very useful resource to navigate, be careful on how to use it. The user may find it odd if an app just navigates without telling them why, so don’t use this feature without contemplating user experience.

4. Navigation in Lists

Lists play a key role in many of our apps, and the cool thing is that integrating navigation within them is simple. We’ve already seen this on the second example, when we injected data into the next shown View, but we didn’t focus on that. So now let’s look again:

Example

import SwiftUI

struct FirstView: View {
    var recipes: [String]

    init(recipes: [String]) {
        self.recipes = recipes
    }

    var body: some View {
        NavigationStack {
            List(0..<recipes.count) { index in
                NavigationLink("\\(recipes[index])", destination: DetailView(recipe: recipes[index]))
            }
            .navigationTitle("Recipe List")
        }
    }
}

struct DetailView: View {
    let recipe: String

    var body: some View {
        Text("Here are the recipe details")
            .font(.largeTitle)
            .padding()
            .navigationTitle(recipe)
    }
}

Two importan things are happening here:

List generates rows dynamically for each item in the recipes array.
Each row contains a NavigationLink that leads to the DetailView for the selected item, in which we then know what item was previously selected.

5. Customizing Appearance

One of the great things about SwiftUI is that you can customize the navigation bar’s appearance, including adding buttons or changing UI styles.

Let’s look at an example of add a few of those buttons and, additionally, how we can navigate from them, modally, to new Views.

Example

import SwiftUI

struct FirstView: View {
    @State var areSettingsSelected: Bool = false
    @State var isHelpSelected: Bool = false

    var body: some View {
        NavigationStack {
            VStack {
                Text("Main View")
                    .font(.largeTitle)
                    .navigationDestination(isPresented: $areSettingsSelected, destination:{ SettingsView()})

                        .navigationDestination(isPresented: $isHelpSelected, destination:{ HelpView()})
            }

            .navigationTitle("Main page")
            .toolbar {
                ToolbarItem(placement: .navigationBarLeading) {
                    Button("Settings") {
                        areSettingsSelected = true
                    }
                }

                ToolbarItem(placement: .navigationBarTrailing) {
                    Button("Help") {
                        isHelpSelected = true
                    }
                }
            }

        }
    }
}

struct SettingsView: View {
    var body: some View {
        Text("This is the Settings view")
            .font(.headline)
            .padding()
            .navigationTitle("Settings")
    }
}

struct HelpView: View {
    var body: some View {
        Text("This is the Help view")
            .font(.headline)
            .padding()
            .navigationTitle("Help")
    }
}

Use the .toolbar modifier to add custom buttons or other controls to the navigation bar.
The ToolbarItem placement determines where the control appears.
We use the technique shown before, on 3, to show the user Settings or Help depending on the View State.

6. Deep Linking and Navigation Paths

For any less basic navigational needs, SwiftUI provide us with the NavigationPath APIs, that help us handle the navigational stack.

Example

import SwiftUI

struct FirstView: View {
    @State private var path = NavigationPath()
    let fruits: [Fruit] = [Fruit(name: "Apple"), Fruit(name: "Banana"), Fruit(name: "Strawberry")]

    var body: some View {
        NavigationStack(path: $path) {
            List(fruits) { fruit in
                Button(fruit.name) {
                    path.append(fruit.id)
                }
            }
            .navigationDestination(for: String.self) { fruit in
                DetailView(fruit: fruit)
            }
            .navigationTitle("Fruits")
        }
    }
}

struct DetailView: View {
    let fruit: String

    var body: some View {
        Text("You selected \\(fruit)")
            .font(.title)
            .padding()
            .navigationTitle(fruit)
    }
}

struct Fruit: Identifiable {
    var id: String

    var name: String

    init(name: String) {
        self.name = name;
        self.id = name
    }
}

Things of note:

NavigationPath allows us to set the fruit’s ID as a new path node. This can later be used to dismiss all Views until we reach a destination one.
Use .navigationDestination(for:) to specify how to handle destinations dynamically, based on the type of the path element. So we could have different things, like animals, and it would handle them accordingly for each type.

Conclusion

SwiftUI’s navigation tools, including NavigationStack, NavigationLink, and NavigationPath, provide the flexibility to build intuitive, dynamic navigation flows in your apps. From simple links to complex navigation paths, SwiftUI ensures your app’s navigation is smooth and user-friendly.

Explore the examples above, adapt them to your projects, and you’ll be able to maximize SwiftUI’s capabilities to create great user experiences.

Happy coding!

Forem: Bugfender

Android Geofencing: How to Set Up and Troubleshoot Location Triggers

First, can you give me a bit more context?

Now, how do we create Geofencing in an Android application?

Ok, awesome. Now, let’s create a geofence transition in our app

Ok, let’s look at how to create an Android geofence API

Testing Android geofencing using Google Maps

What if Android geofencing does not trigger?

Android Geofencing FAQ

What is Android Geofencing and how does it work?

How do I set up Android Geofencing in an app?

What permissions are needed for Android Geofencing?

How do I visualize a geofence on Google Maps?

How do geofence transitions work in Android?

What is a PendingIntent in geofencing and why is it used?

How do I build a backend geofence API using Node.js and Firebase?

Why is my Android geofence not triggering?

What’s the best geofence radius for Android apps?

How can I test Android geofencing in the emulator?

And we’re done!

How to Use Android Vitals to Improve App Stability and Google Play Ranking

But first, some core concepts to understand

Ok, now let’s look at setting up Android Vitals

How do we set up Android Vitals using Android Studio?

Now let’s see how Android Vitals works in Google Play

Part 2: More advanced concepts on Android Vitals

Finally, let’s look at different metrics and edge cases

Android Vitals FAQ

What is Android Vitals and why is it important for app developers?

How can I access Android Vitals in the Google Play Console?

Do I need to add code to use Android Vitals in my app?

What does ANR rate mean in Android Vitals?

How can I fix battery drain issues highlighted in Android Vitals?

What causes slow UI rendering in Android apps?

How does Android Vitals affect my app’s ranking on Google Play?

And we’re done!

Kotlin Extension Functions: Add Functionality Without Modifying Code

First off: how do we create a Kotlin function?

An important thing to note

Excited to learn more?

Writing our own Extension Functions

Understanding the Anatomy of an Extension Function

Example: Creating a Full URL from a Path

But why use an extension function?

Leveraging nullability in Extension Functions

The Problem: Comparing Nullable Numbers

A Quick Fix: Using ?: (Elvis Operator)

The Better Solution: Using an Extension Function

But wait, there’s more!

Generics in Extension Functions!

Example: A Generic LoggingFunction

Output:

Extension Properties

How do Extension Properties work?

Limitations of Extension Properties

Infix with Extension Functions: The cherry on top!

Understanding Infix Expressions

Companion Object Extensions

Example:

Usage:

Output:

Advanced Extension Function ideas

Network Connectivity Check (Android)

Converting Any Object to JSON (Using Gson)

Converting JSON String to Any Object (Using Gson)

Deep Copy Using (Using Gson)

Prevent Double Clicks on a View

Using extension functions in Java (Interoperability)

Example: Accessing an Extension Function in Java class

When and How to Use Extension Functions

When to Use Extension Functions

When to Avoid Extension Functions

Organizing Extension Functions

Best Practices for Organizing Extensions

To Recap

iOS vs Android Error Monitoring: Key Differences Explained

Quick Comparison

Mobile crash reporting and debugging best practices

Platform Differences in Error Monitoring

Built-in Error Reporting Tools

A Quick Fix: Using `?:` (Elvis Operator)