
I'm spinning up a React Native app that needs to use the device's built-in camera. Not something that is often required in my day-to-day work in web development, but something I figured would be straightforward in 2025!

_So I thought!_

My jumping off point is Expo's example repo showing how to use expo-camera in your app. Full example file is [here](https://github.com/expo/examples/blob/master/with-camera/App.tsx). Below, I'll show the relevant code:

```TypeScript
export default function App() {
	const [uri, setUri] = useState<string | null>(null);
	const ref = useRef<CameraView>(null);

	const renderPicture = () => {
		// . . .
	}

	const renderCamera = () => {
	    return (
	      <CameraView
	        ref={ref}
	        mode={mode}
	        facing={facing}
	      >
	        <View style={styles.shutterContainer}>

	        </View>
	      </CameraView>
	    );
	  };

	return (
		<View style={styles.container}>
			{uri ? renderPicture() : renderCamera()}
		</View>
	);
}
```

Our app has two views: The camera and the picture display. Once you take a photo from the camera, the picture display shows the photo. After closing that, you return to the camera.

I'm starting with iOS, since that's what I use. Camera functionality is not available on the device simulator on Mac, so I'm reaching for my own iPhone SE 2.

After playing around with the example in Expo Go, the app crashes.

At first, I didn't think much of it. It could have been a number of small things! Perhaps the code needs refactoring, the render functions broken out to components, the state management being optimized, the camera ref being converted to state that's cleared on unmount.

Needless to say, dear reader, _none of that_ did the trick.

Below, I'll outline the methods I tried out. If you're experiencing the same issue, one may work for you. At the end, we'll discover a big ol' twist as far as how I resolved it.

## Preview

I began to think it was an issue with the Camera preview. Perhaps, when leaving the page, the preview was running in the background, and returning to it caused the crash.

The camera instance has methods for pausing and resuming the preview. I chose to handle this in a useEffect: resuming on component mount and pausing on unmounting.

```TypeScript
  useEffect(() => {
    ref.current?.resumePreview();
    return () => {
      ref.current?.pausePreview();
    }
  }, [ref.current]);
```

Alas, no luck.

## Focused

As per the [expo-camera docs](https://docs.expo.dev/versions/latest/sdk/camera/#usage), it's important that only one instance of the camera be available at any given time. This apparently can be tricky with multi-screened apps. Not all components may fully unmount, say, when you open up a modal, for example.

The way to handle this is to render your camera behind a check for if the page is focused. Thankfully, there's a hook available for this:

```TypeScript
import { useIsFocused } from '@react-navigation/native';

export default function Index() {
	const isFocused = useIsFocused();
	if (isFocused) return <Camera />;
}
```

No dice in my case. Crashes continued.

## Reloading The App

I'll truncate the rest of the story to say I tried several hacky solutions. I was starting to get desperate!

I'd narrowed it down to being related to the expo-camera component and remounting it after an initial load. However, it was never a problem on first load. So what if I could reload the app?

Thankfully, there's a programmatic way to do it. So, after sending a picture, I set the app to reload.

```TypeScript
export default function ImagePreview({ uri }: ImagePreviewProps) {
	const handleSend = async () => {
    setSending(true);
    setTimeout(() => {
      setSending(false);
      setSent(true);
      setTimeout(() => {
        if (Platform.OS === 'ios') {
          console.log('iOS detected');
          reloadAppAsync();
        } else {
          router.back();
        }
      }, 2000);
    }, 4000);
  };
}
```

You'll notice I'm only doing this on iOS. By this point, I discovered the issue was not present in my Android simulator.

It's an ugly solution. I couldn't wrap my mind around how I was getting such spotty performance here. Though the Android success started to get me thinking about another angle to take.

## Testing Multiple Devices

As mentioned, my tests were on an iPhone SE 2. What I soon realized is that I was _only_ testing on that phone.

I picked up an iPad and ran my app. I reverted back to the original example code. After some testing, I didn't experience any crashes.

A bitter-sweet victory! Relieved that the problem was device-specific, and stunned that I spent so much time trying to handle what was largely a non-issue on most devices!

## Device Specific Code

Thankfully, from here on out, the solution was simple. I already had a hack that seemed to mitigate the issue on my iPhone. And I have a couple of examples of the original code working seamlessly.

The solution then was to do what I'm sure takes up a major part of a React Native app: device-specific code!

I'll have to gather results on more devices as I continue. But, it seemed a safe bet that there was an issue with my phone's OS version. With my phone on version 16 and iPad on 17, I decided to use the reload hack only on iOS version 16 devices.

```TypeScript
const isMajor16 = (ver: string | null) => ver && /^16\./.test(ver);

// . . .

if (Platform.OS === 'ios' && isMajor16(osVersion)) {
  console.log('iOS 16 detected');
  reloadAppAsync();
} else {
  router.back();
}

```

## 👋

In the world of web development, we're fortunate to have fairly unified environments. Developing across mobile environments is a bit messier. On top of differences between OS's, version differences caught me off guard.

So, if you're jumping into mobile dev, have multiple devices handy, friends!


Debugging React Native App Crashes While Using Expo Camera


![🦜](http://res.cloudinary.com/cpadilla/image/upload/v1743372758/chrisdpadilla/albums/zwqx8tumg5iz7yigqgfo.jpg)

I'm launching an app today!!

[Go learn more here](/birdbox), where you'll find download links for iOS and Android!


New App – Bird Box!


Gifs work great out of the box in React Native using expo... _except!_ When building to android.

On Android natively, this is accomplishes with Fresco. However, to use this package in Expo with React Native, we have to do [a bit more work](https://github.com/s3131212/expo-gif/pull/1/files).

Cedric van Putten has thankfully already done the heavy lifting. The meaningful config file setup is demonstrated in [this PR](https://github.com/s3131212/expo-gif/pull/1).


Animated Gifs on Android with Expo and React Native


Both [React Native](https://reactnative.dev/docs/getting-started) and [Expo](https://docs.expo.dev/tutorial/create-your-first-app/) have great quick start guides for getting your hands dirty.

If you're _really_ in a rush to see what developing with React Native looks like, I've boiled it all down to one file for you!

```
import React, { useEffect, useState } from 'react';
import { View, Button, StyleSheet, Platform } from 'react-native';
import { Audio } from 'expo-av';
import { Sound } from 'expo-av/build/Audio';

type SampleComponentProps = {
  soundSource: any; // an MP3 File
};

export default function SampleComponent({ soundSource }: SampleComponentProps) {
  // React hooks work as expected
  const [sound, setSound] = useState<Sound>();

  useEffect(() => {
    const loadSound = async () => {
      // Handle mobile device interactions with expo libraries
      const { sound } = await Audio.Sound.createAsync(soundSource);
      setSound(sound);
    };
    loadSound();
  }, [soundSource]);

  async function playSound() {
    if (sound) {
      // Run certain logic on specific platforms
      if (Platform.OS === 'ios') {
        await sound.setPositionAsync(0);
      }
      await sound.playAsync();
    }
  }

  // Use core library components to render elements
  return (
    <View style={[styles.container]}>
      <Button title="Play Sound" onPress={playSound} />
    </View>
  );
}

// Style components with CSS-like properties
const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    backgroundColor: '#ecf0f1',
    padding: 10,
  },
});


```

Let's dig in:

**State Management**: For the most part, you're writing React code. Hooks such as `useEffect` and `useState` work just as they do when writing for the web.

**Core Components**: A big difference, though, is that you'll be using React Native's Core Components instead of HTML elements. This ensures smooth transitions between the different platform environments. You can see me using `Button` and `View` as replacements for html `button` and `div` elements.

**Expo Libraries**: Expo comes with some great handlers for interfaces such as zooming and touch interactions. In my example, I'm using the [expo-av library](https://docs.expo.dev/versions/latest/sdk/audio-av/) to handle playing a sound on button click.

**Styling**: Very familiar to anyone who's used style objects in React. Knowledge of CSS translates largely here.

**Platform Exceptions**: Naturally, some devices handle logic differently. You'll see that I've added a check `if (Platform.OS === 'ios')`. Here, if running on an Apple device, I'm going to set the audio position back to the beginning of the track before playing again.

That's it! Once this renders out, we'll have a button playing the audio file passed into this component.


A Beginner's Intro to React Native in One Component


I was in need of a detour. I've been pretty focused on large projects in the web dev category. So, to scratch the curiosity itch, I hacked away at a very simple iOS app.

I had a few questions I was looking to answer going in. I was largely curious about how big the gulf really was between web development and native.

Additionally, what are the benefits of fully committing to an ecosystem? VS Code is fine-tuned for JavaScript and web development, while Visual Studio is a full IDE for C# and .NET. In that sense, I had some experience, but I was still curious about how this plays out on the Apple side.

Note: I've only given this a couple of weeks of playing around in my off time. Thoughts here are first impressions, not expert opinions from a seasoned iOS dev. Take all of the following with a grain of salt.

## Swift

Apple's programming language for their products is fairly quick to pick up. [The tour of the language](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/guidedtour/) on the swift docs site gets you most of the way there, and most of it is analogous to any other language that supports classes.

### Unwrapping

The one concept that takes getting used to is _unwrapping_. I'll do my best to explain concisely, since I don't want to distract too much from the rest of the post.

Swift has an `Optional` type that you can denote with a question mark. If I were to try to use this value later, I would get a compile time error:

```
let color: String? = nil

print(color) // Warning: Expression implicitly coerced from 'String?' to 'Any'
```

`color` as a variable has reserved space in memory for a value, but it's not guaranteed that the value is there. That is what the `Optional` type is communicating. Hence the warning when `print` receives an optional type.

The swift way of handling this is to _unwrap_ the value.

```swift
if let color = color {
    print(color)
}
```

On the left side of the operator, I'm declaring a new `name` variable for the block scope. On the right, I'm assigning it the value of my original `name` variable. At the start of this line, I'm checking that a value exists with an `if` statement.

By this point, if a value exists, Swift knows this is no longer an `Optional` value and we are safe to call print with `color`.

There's even a shorthand since this is so commonly done:

```swift
if let color {
    print(color)
}
```

Essentially, _unwrapping_ is a fancy term for asserting that a value exists on the variable. The nice thing about swift as a statically typed language is that it will encourage you to check your values in ambiguous scenarios.

### XCode

XCode has been interesting to use. Unsurprissingly, the typography and design is very Apple. In that sense, it's delightful.

Like any new program, it's easy to be overwhelmed by the sheer number of menus and options to toggle. However, it doesn't take long to find the few options you'll use the most often.

It's a seamless dev experience working with iOS apps here. Unsurprisingly, when the software is designed for a specific platform, it works really well with said platform. Spinning up a simulated app environment is quick and easy. UI wise, you have a couple of options between SwiftUI and UIKit when sticking to Apple support. And adding components from those libraries is as easy as drag-and-drop.

One thing that takes getting used to is a UI interface for adjusting any elements I add to the Storyboard visual editor. When you're used to scanning documentation or skimming through the options in intellisense to find input options, it feels a bit slow and laborious to have to paw through menus to find where I can resize a button element. Perhaps there are other ways of working with elements that are more text driven. Either way, I'm sure it would just take some time to familiarize oneself with where all the menus are.

One of the most interesting features lies in the intersection between Interface Builder elements and the hand written code. Interface Builder is the WYSIWYG style visual pane for adding elements to a view. However, you can connect them to your own custom written swift classes. Doing so even has the nice UI flare of simply dragging and dropping the element into a line of swift code.

```Swift
import UIKit

class DetailViewController: UIViewController {
    // This line was added by dragging and dropping (while holding ctrl)
    // the imageView from the Interface Builder
    @IBOutlet var imageView: UIImageView!
    var selectedPhoto: String?
    var photoTitle: String?

     override func viewDidLoad() {
        super.viewDidLoad()
        title = photoTitle

        if let imageToLoad = selectedImage {
            imageView.image = UIImage(named: imageToLoad)
        }
    }
}
```

There is a certain magic there. Seeing a visual element and being able to hook into it this way.

## Impressions

My assumption was that learning Swift would take a bulk of the on ramp time, and then developing on Apple's platform would be smooth sailing. I found the opposite to be true. Swift, at least at this stage in my tinkering, wasn't event the meat and potatoes of my development. It was largely working with interface building, laying out elements there, and then writing a few lines of swift code to get specific functionality.

Perhaps that's unsurprising at the entry level. But I'll say, since a bulk of the benefit of native development is using native interfaces and components, it makes sense that I don't have to type nearly as much boilerplate or initialization code to get started. So in that sense, the language is not the barrier to entry.

However, gettinng up to speed on platform development _does_ take time here. I've come to find this more true with the more tooling I use. Languages are largely similar in their feature set. The frameworks and platforms, however, all require you to learn their way of developing. It's as true for iOS dev as it is for React. So, when learning this sort of thing, much of the time will be spent here.

Largely, though, once that hurdle is covered, the all-encompassing IDE is a smooth experience. Apple is known for excellent design. So it's nice to know that, out of the box, I'm working with components that are elegant to use.

All in all, a great first impression.
