Stop Hardcoding API URLs!

Show Notes

Why does localhost work on your desktop but fail inside an Android emulator?

Hardcoded API addresses can quickly become frustrating when developing cross-platform applications.

In this episode of the TSJDEV Apps Podcast, Thomas Sebastian Jensen explores how Aspire’s service discovery helps .NET MAUI applications communicate with ASP.NET Core backends.

Using the TaskBoard project, we’ll look at logical service names, endpoint configuration, standalone fallback addresses, and some of the networking challenges developers encounter on mobile devices.

In this episode

• Why localhost behaves differently across environments.
• How Aspire service discovery works.
• Using logical service names instead of fixed ports.
• Keeping mobile applications independently configurable.

Coming next

Creating a custom seven-segment display with SkiaSharp.

TSJDEV Apps Podcast - Short Episodes. Big Developer Ideas.

Full Transcript

Localhost works perfectly on your computer. So why doesn’t your Android emulator connect to your API?

Welcome to the TSJDEV Apps Podcast! Short Episodes. Big Developer Ideas.

I’m Thomas Sebastian Jensen, and today we’re talking about a problem many mobile developers know: API addresses.

Imagine you’re developing a .NET MAUI application that communicates with an ASP.NET Core backend.

On Windows, your API might be available through localhost.

But once you run the app in an Android emulator, things change.

The emulator has its own networking environment. And localhost suddenly points to a different place.

A common solution is to introduce platform-specific addresses.

It works, but maintaining these configurations can become frustrating.

This is where Aspire’s service discovery can help.

In my TaskBoard project, the backend is registered with a logical service name: taskapi.

When the application runs through Aspire, the MAUI client can use that service name instead of depending on a fixed local port.

Aspire supplies endpoint configuration, and service discovery resolves the address.

The interesting part is that the application can still run independently.

Outside Aspire, TaskBoard falls back to a conventional API address from its configuration.

That flexibility is important. Development orchestration shouldn’t make your app dependent on a particular production environment.

For mobile devices, additional networking support, such as development tunnels, may still be necessary.

The takeaway?

Keep endpoint selection in configuration, not scattered throughout your application code.

And speaking of reusable application code, what if we wanted to create our own visual controls?

Next time, we’ll build a digital seven-segment display with .NET MAUI and SkiaSharp.

Until then, stay curious, keep experimenting, and keep building!