Suppose I have a mobile app that uses an API at api.myapp.com. I want to be able to test the app on my personal dev machine mymac.local and also on a production-standard test server test.myapp.com.

What's the best way to allow a production mobile app to switch to an alternative API endpoint?

Options I've thought of with the cons I've thought of:

  1. Put an Easter egg somewhere in the app that only devs know about. e.g. tap 5 times on the logo and an API endpoint input box pops up.

    Cons: Easter eggs get discovered.

  2. Put a settings option in the normal settings menu (I think Twitter used to do this).

    Cons: Looks amateur?

  3. Create an URL schema like myapp://change_api?endpoint=api.mysite.com

    Cons: This is a bit of a pain to use.

Are there other, better ways to do this that I haven't thought of?

  • Hi Andrew. This sounds more like a technical implementation question than a UX problem so it's probably off-topic for this site.
    – Matt Obee
    Mar 17, 2015 at 11:29
  • I think this is much more of an implementation issue than a UX one. A typical solution for this is to produce a dev and production versions of the app itself, which can use whatever API one wants.
    – Izhaki
    Mar 17, 2015 at 11:30
  • @MattObee I was about to post it on stackoverflow and then thought it was maybe more UX - oh well!
    – awidgery
    Mar 17, 2015 at 12:03
  • @Izhaki granted that's definitely one way - but it doesn't allow you to easily test the actual production app (in the App/Play Store) on a test API - or the development app on the production API
    – awidgery
    Mar 17, 2015 at 12:05
  • @AndrewWidgery There's definitely a UX angle to it but I think it needs more technical input than you will get here.
    – Matt Obee
    Mar 17, 2015 at 12:06

4 Answers 4


It depends on the use-cases of the application. If its an app for kids, a 5 tap easter egg would get discovered in no time. But if its say, a financial app then its reasonably expected that no one would routinely discover the easter egg.

I personally like the easter egg option, as it adds an element of discovery and surprise for the user who discovers it, even if they don't have anything to do with it. May be add a couple of easter eggs in there anyway.

  • If anyone ever discovers an easter egg in a financial app, down goes your trust index. Even if that is intentional.
    – Harshal
    Mar 17, 2015 at 19:23
  • You are right, but my suggestion is to the OP, who doesn't seem to be developing a financial app.
    – Adnan Khan
    Mar 20, 2015 at 23:01
  • Wanted to accept an answer, and this is the way we went. It's not a financial, or a kids app, and this was simple and worked well.
    – awidgery
    Apr 29, 2015 at 15:31

Write the code such that your build has a flag that switches URLs. Only release your build to yourself.

  • The problem with this is it doesn't allow you to test the actual production app (downloaded from the App Store) on a non-production server, which we occasionally need to do - e.g. a friend says "Hey, your app doesn't work right on my phone" - I can switch over to the dev API and test it without adding a device to a provisioning profile.
    – awidgery
    Apr 29, 2015 at 15:34

Minimise solving this through UX

If this app is going out to users, it's not a good idea to have anything in the code base that points to your local machine or a test machine.

I would suggest that:

  • Add an invisible interaction sequence (eg tap corners of the screen in a particular order) to bring up a developer console. The key here is, the app has to be designed so that it's okay for that console to be accidentally or maliciously discovered.
  • Console issues a call to the production server to your credentials to make sure you are a super user. Ie it checks your phone number, login credentials, secret API key, Android/iPhone identity or whatever identifying credentials you use to make sure it's you and not another user.
  • If so, it issues you a token authorizing the use of the test API. If not it logs and quotas the call to guard against brute force attacks.
  • The app then issues the normal API calls to the server, but with the additional authorizing token.
  • Server checks for token, and if it's valid, then reroutes your API calls to local or test. This routing is done server side and not client side so your local and test machine IP addresses cannot be discovered.

I think this is a valid UX question since it could be solved using a pure-UX approach (eg admin passcode). But I think in this case a minimal, discovery-safe UX approach combined with server side security is better.

  • I like the idea of the production server authorizing a the use of a test API via a superuser flag. Additionally, this would be possible without the use of a special interaction sequence at all, just simply login to production and the super user flag is received by the app enabling test API use. The only downside is it depends on the production server always being available (or at least once) to start using the test API.
    – Emeka
    Aug 24, 2017 at 14:13

@awidgery Personally I think this is more of a technical question but I will try to answer it for you;

If your app is an Android app you will be able to use Gradle to switch your app between Production and Development. What you want to take a look at is build types.

If your app is an iOS app you should be able to do this using a Configuration File.

If you app is a Windows app then I don't know what you can do but I'm sure you can do something similar to the above.

If you are looking to be able to switch the app over from production to development within the app, I don't think thats a good idea as the production version should be simple to use for "real users" and not when developers want to do development or testing tasks. Just my opinion.

Sorry about all the if's and I hope it helps 👍

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.