Building mobile apps: Isaac Juracich’s React Native experience

My mobile engineering experience includes building StudyFetch’s React Native application from scratch and leading its development until October 2025. The application brought an AI learning platform onto a phone, connecting study content and tutoring features to a mobile experience. That role is documented in my background and project portfolio.

The app is more than a set of screens

A mobile product has to connect navigation, account state, content, and services. Consider a learner opening an AI tutoring feature: the app needs to know which material they are studying, whether it is ready, and what to show while a response is being prepared. Those are product decisions as much as implementation details.

A useful engineering plan describes this sequence before describing the component tree. What happens when the learner returns to a previous session? What remains available when a request fails? Which actions need an explicit retry? Answering those questions gives the interface a consistent structure.

Where React Native fits

React Native is part of my core technical experience, alongside React, TypeScript, and Expo. Working across web and mobile helps when the same product needs shared concepts such as accounts, content, and permissions. It does not remove the need to design for each device.

For a new mobile project, I would start by identifying device-specific requirements and the existing backend. A content application, a camera workflow, and a background location tool have different constraints. The framework decision should follow those requirements.

Making AI work understandable

My StudyFetch work included integrating AI services for content processing, generation, and tutoring. A key design concern for this kind of application is making asynchronous work visible. The person using the app needs to understand whether a task is starting, still running, complete, or ready to retry.

That same concern appears in my work on AI tools: the interface should explain what the system is doing and what control the user has.

What to bring to a mobile project discussion

A useful brief includes the intended users, the essential action, supported devices, existing services, and the information the app must store. If the product already exists on the web, include the parts that should carry over and the parts that need a different mobile experience.

See the Product Sprint offer or discuss a mobile application.